glibc does not understand DNAME (RFC 2672) DNS records

[Malcolm Scott]

When attempting to resolve a DNS name abstracted via a DNAME record (see RFC 2672), glibc's stub resolver:

(1) logs, via syslog, a debug message:
$ grep DNAME /var/log/auth.log
Apr 20 12:43:38 callisto alpine: gethostby*.getanswer: asked for "1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.2.0.0.0.d.1.1.0.8.4.3.0.1.0.a.2.ip6.arpa IN PTR", got type "DNAME"

(2) ignores the DNAME record;

(3) falls back to the synthesised CNAME record inserted by my BIND 9 recursive resolver.

RFC 2672 states that a DNS server SHOULD synthesise CNAME records where a DNAME exists in response to "DNS clients sending Extended DNS [EDNS0] queries with Version 0 or non-extended queries", which "are presumed not to understand the semantics of the DNAME record", so step (3) above is valid in the interim until full DNAME support is implemented in glibc. However in this case the debug message is irrelevant, and as DNAME records become more widespread will result in needless log spam (e.g. Cambridge University is soon to roll out DNAME records for reverse DNS).

Suggestion: only log a debug message if the answer contains a DNAME record but no CNAME record (i.e. the DNS server has not synthesised a CNAME record). Alternatively, skip the debug message entirely for DNAME records.

The relevant code is around glibc-2.9/resolv/gethnamaddr.c:342 and glibc-2.9/resolv/nss_dns/dns-host.c (2.9-4ubuntu6).

[Malcolm Scott (malcscott)]

Er, that last line was meant to say:

The relevant code is around glibc-2.9/resolv/gethnamaddr.c:342 and glibc-2.9/resolv/nss_dns/dns-host.c:792 (2.9-4ubuntu6).

[Malcolm Scott (malcscott)]

For the record, this bug is still present in lucid, although it seems to have been fixed in oneiric (and possibly some intermediate releases).