Opened 4 years ago

Closed 4 years ago

#2766 closed defect (fixed)

Fix reverse DNS records

Reported by: matze Assignee: matze
Priority: P2 Milestone:
Module: Infrastructure Keywords:
Cc: fhd, fred, trev, Kirill Blocked By:
Blocking: #2761 Platform: Unknown / Cross platform
Ready: yes Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by matze)

Those servers of ours which are named after the 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 (the current response to reverse lookups already) actually resolves to the respective server's IP.

What to do

  • Duplicate the values in corresponding A and AAAA records without the underscode (
  • 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..

Change History (10)

comment:1 Changed 4 years ago by 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 and

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.

comment:2 Changed 4 years ago by matze

  • Description modified (diff)

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 ( 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.. ;-)

comment:3 Changed 4 years ago by matze

  • Cc trev added

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

  • 38400 IN A
  • 38400 IN AAAA 2a01:4f8:a0:640b::2

Any objections on dropping these records (@trev)?

comment:4 Changed 4 years ago by 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.

comment:5 Changed 4 years ago by matze

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

comment:6 Changed 4 years ago by 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$; dig @$nameserver A $fqdn | sed -n -e 's/\s\+/ /g' -e s/^$fqdn..//p; done | tee ip4-without-underscore.txt 
86400 IN A
86400 IN A
86400 IN A
86400 IN A
86400 IN A
86400 IN A
86400 IN A
86400 IN A
86400 IN A
86400 IN A
86400 IN A
$ for i in $@; do fqdn=server$; 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_$; 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_$; 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.

comment:7 Changed 4 years ago by matze

  • Review URL(s) modified (diff)
  • Status changed from new to reviewing

comment:8 Changed 4 years ago by matze

  • Review URL(s) modified (diff)

comment:9 Changed 4 years ago by matze

  • Cc Kirill added

@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..

comment:10 Changed 4 years ago by matze

  • Resolution set to fixed
  • Status changed from reviewing to closed
Note: See TracTickets for help on using tickets.