It’s going a bit far to say that 8.8.8.8 is responding incorrectly—the actual RFC 6761 text merely says that it “should” return loopback answers for A/AAAA queries, not that it “must.” I agree that current behavior by 1.1.1.1 is correct—but there are multiple possible correct approaches, including the response given by 8.8.8.8.
One of the problems with returning loopback A/AAAA records is that they cannot be validated with DNSSEC. There is no insecure delegation for localhost (it simply doesn’t exist in the root zone) and the loopback records cannot be signed without the root zone private keys, which are very strictly controlled. This is a concern, but does not mean that providing loopback A/AAAA record answers (as done by many public DNS servers, including those that validate DNSSEC themselves, like 1.1.1.1, 9.9.9.9, and 64.6.64.6) is incorrect—the RFC says that clients “should not send queries for localhost names to their configured caching DNS server(s)”—so if they get an answer that they cannot validate it is arguably their own fault.
However, if we look at the real motivation for these requirements, which is “to avoid unnecessary load on the root name servers and other name servers” an argument can be made that the response by 8.8.8.8 is more effective than many of the others.
It should first of all be noted that both 8.8.8.8 and 1.1.1.1 implement RFC 8198 (Aggressive Use of DNSSEC-Validated Cache) to synthesize negative responses (such as NXDOMAIN) from NSEC records returned in DNSSEC-enabled responses, which significantly reduces the query load on the root name servers for any non-existent name, not merely those that have special consideration in RFC 6761. So although it is true that 8.8.8.8 may sometimes query the root name servers for localhost, it will only do so very rarely, either returning a cached negative response from traditional RFC 2308 negative caching or synthesizing one from the NSEC and SOA records it would have received from the root name servers for queries for any domain (such as elevator.lobby) between LOANS and LOCKER.
It’s instructive to look at a full response from 8.8.8.8 in this case:
$ dig +nocmd +noquestion +dnssec +nocrypto localhost @8.8.8.8
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 29085
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; AUTHORITY SECTION:
. 42439 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2018041700 1800 900 604800 86400
. 42439 IN RRSIG SOA 8 0 86400 20180430050000 20180417040000 39570 . [omitted]
. 42439 IN NSEC aaa. NS SOA RRSIG NSEC DNSKEY
. 42439 IN RRSIG NSEC 8 0 86400 20180430050000 20180417040000 39570 . [omitted]
loans. 42439 IN NSEC locker. NS DS RRSIG NSEC
loans. 42439 IN RRSIG NSEC 8 1 86400 20180430050000 20180417040000 39570 . [omitted]
;; Query time: 21 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Apr 18 03:13:39 EDT 2018
;; MSG SIZE rcvd: 1030
The last NSEC record (with its RRSIG) proves the non-existence of localhost (the previous NSEC proves that there is no root wildcard). The SOA of the negative response—with a TTL of 42349, it is close to the median and smaller than SOA MIN of 86400—shows that it can be cached for a bit more than 11 hours 45 minutes; the answers from root name servers have an original TTL of one day. As a result (barring restarts), the number of queries to all root name servers for all the names between LOANS and LOCKER together will not exceed one per day for each 8.8.8.8 resolver. And the cache lifetime of up to 24 hours for localhost queries applies to clients of 8.8.8.8 regardless of whether DNSSEC is used or not.
By comparison, the positive responses from other resolvers mostly have shorter TTLs:
$ dig +noall +answer +auth +dnssec +crypto localhost @1.1.1.1
localhost. 900 IN A 127.0.0.1
$ dig +noall +answer +auth +dnssec +crypto localhost @9.9.9.9
localhost. 10800 IN A 127.0.0.1
$ dig +noall +answer +auth +dnssec +crypto localhost @64.6.64.6
localhost. 10800 IN A 127.0.0.1
$ dig +noall +answer +auth +dnssec +crypto localhost @4.2.2.2
localhost. 86400 IN A 127.0.0.1
$ dig +noall +answer +auth +dnssec +crypto localhost @resolver1.opendns.com
localhost. 604800 IN A 127.0.0.1
It’s probably not an accident that the OpenDNS public resolvers (which handle queries from almost 1% of all DNS clients) return the largest TTL of all. Since the volume of localhost queries received by public resolvers can easily make it into the top-10 TLDs by query volume, trying to get clients to cache the responses for longer can make a non-negligible difference in the total query load (although it seems unlikely many clients will actually cache anything for a whole week).
It also may be, though it’s hard to prove, that the NXDOMAIN responses returned by 8.8.8.8 have some deterrent effect on clients who might otherwise send localhost queries (and get loopback addresses) rather than handle them internally. This is the motivation for the Internet Draft RFC “Let ‘localhost’ be localhost”. Time will tell whether that argument sways the IETF sufficiently to make it an official RFC.
