Fix reverse DNS records

[matze]

Those servers of ours which are named after the server_%d.adblockplus.org scheme do not have proper records for reverse DNS resolution: they all miss the underscore. This can lead to issues with verifying their identity in various protocols and should thus become fixed.
All of them are Hetzner servers. Unfortunately, their robot interface rejects reverse records with an underscore. I am not sure whether this is an explicit restriction in their software or a bug.

However, today we use a naming scheme without underscores anyway. Thus we need to ensure that server%d.adblockplus.org (the current response to reverse lookups already) actually resolves to the respective server's IP.

What to do

• Duplicate the server_%d.adblockplus.org values in corresponding A and AAAA records without the underscode (server%d.adblockplus.org)
• Replace the underscore-versions of the A and AAAA records with CNAMEs to their respective counterpart

Later on we may want to actually drop the underscore version, in which case a bit more effort is required..

[fred]

Hetzner probably does not allow underscores in hostnames in their robot interface because they are not allowed in A record host names, according to RFC952.
See also ​https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_host_names and ​https://www.ietf.org/rfc/rfc1912.txt

RFC1912 also states:
"Also, PTR records must point back to a valid A record, not a alias defined by a CNAME."
And since an A record with an underscore is not valid, a PTR record may not point to such an A record.

[matze]

Indeed, CNAMEs not being valid PTR values is something I suspected but hoped to be not the case. Well, I guess we cannot go the shortcut here then - just duplicating the values is senseless. I've updated the ticket description accordingly.

Please note though that underscores are perfectly valid within (%s.adblockplus.org) names; see ​RFC 2181. This being a clarification RFC, however, I guess Hetzner not supporting them for PTRs is not much of a mystery anymore. Well, not that it matters anymore anyway.. ;-)

[matze]

While creating the copies, I've encountered a set of records I cannot associate with any existing entity:

• server_22.adblockplus.org. 38400 IN A 85.10.192.15
• server_22.adblockplus.org. 38400 IN AAAA 2a01:4f8:a0:640b::2

Any objections on dropping these records (@trev)?

[trev]

server22 was decommissioned more than a year ago, looks like we forgot to remove its DNS entries.

Note that the difference between "external" and "internal" names for servers (with and without underscore) was intentional and not the result of technical limitations. Still, it's questionable whether the reasons behind it were valid back then - they definitely aren't now.

[matze]

Thank you for the info. The obsolete record has been deleted.

[matze]

Step one from this ticket, creating copies of the records that are identical except for the underscore, has finished:

$ for i in $@; do fqdn=server$i.adblockplus.org; dig @$nameserver A $fqdn | sed -n -e 's/\s\+/ /g' -e s/^$fqdn..//p; done | tee ip4-without-underscore.txt 
86400 IN A 78.46.51.35
86400 IN A 88.198.7.4
86400 IN A 88.198.48.196
86400 IN A 88.198.10.10
86400 IN A 88.198.50.132
86400 IN A 78.47.20.216
86400 IN A 88.198.15.197
86400 IN A 88.198.35.145
86400 IN A 88.198.16.240
86400 IN A 88.198.66.34
86400 IN A 178.63.103.200

$ for i in $@; do fqdn=server$i.adblockplus.org; dig @$nameserver AAAA $fqdn | sed -n -e 's/\s\+/ /g' -e s/^$fqdn..//p; done | tee ip6-without-underscore.txt 
86400 IN AAAA 2a01:4f8:101:102b::2
86400 IN AAAA 2a01:4f8:130:428d::2
86400 IN AAAA 2a01:4f8:131:20c5::2
86400 IN AAAA 2a01:4f8:130:40e7::2
86400 IN AAAA 2a01:4f8:131:2144::2
86400 IN AAAA 2a01:4f8:d16:443::2
86400 IN AAAA 2a01:4f8:130:1486::2
86400 IN AAAA 2a01:4f8:a0:20c3::2
86400 IN AAAA 2a01:4f8:130:11c8::2
86400 IN AAAA 2a01:4f8:121:5208::2

The integrity of the new records has been verified by comparision with their respective counterparts:

$ for i in $@; do fqdn=server_$i.adblockplus.org; dig @$nameserver A $fqdn | sed -n -e 's/\s\+/ /g' -e s/^$fqdn..//p; done > ip4-with-underscore.txt
$ diff -s ip4-with{,out}-underscore.txt
Files ip4-with-underscore.txt and ip4-without-underscore.txt are identical

$ for i in $@; do fqdn=server_$i.adblockplus.org; dig @$nameserver AAAA $fqdn | sed -n -e 's/\s\+/ /g' -e s/^$fqdn..//p; done > ip6-with-underscore.txt 
$ diff -s ip6-with{,out}-underscore.txt
Files ip6-with-underscore.txt and ip6-without-underscore.txt are identical

Before migrating the former ones to CNAMEs I'll double-check whether any resources of ours explicitly assume the underscore ones to be A/AAAA records (which I doubt) or if there are other implications (e.g. regarding hosts.yaml and the Puppet resources created from that file's data).

Note that while this ticket is not closed yet, the reverse lookup itself is considered fixed by now.

[matze]

@Kirill: You probably want to check your scripts for possible effects these modifications may have. While the underscore-versions will continue to work (they are replaced by CNAMEs, see above), the plan is to remove these aliases in the long turn..

[matze]

​https://hg.adblockplus.org/infrastructure/rev/c964a4176356