Tony Finch wrote:
Wes Hardaker<[email protected]> wrote:
Instead, localhost is a operating system convention, a /etc/hosts name,
an NIS name, or one of the other things that is able to resolve that
name. But the DNS is not where that resolution comes from.
I think this makes sense, but it isn't the whole story. From my brief look
at a small amount of traffic, localhost queries are basically all handled
inside the stub, so it is de facto as you describe. But it has long been
the case that DNS servers are also supposed to handle localhost, e.g.
RFC 1537 section 10
RFC 1912 section 4.1
RFC 2606 section 2
RFC 6761 section 6.3
However, implementations differ - BIND requires explicit configuration,
Unbound handles localhost by default.
while i've generally included a localhost.$ORIGIN A RR in zones that
appear in my stub resolver search lists, in order that "localhost" be
found, i believe that the host name lookup library which calls and/or
depends upon, among other things, a DNS stub resolver, ought to handle
the "localhost" convention. and indeed, most of these lookup libraries
have a concept similar to "/etc/hosts" today, where "localhost" lives.
no standards-track RFC currently requires that "localhost" return NXD,
to make explicit that it's the host name lookup library "SHOULD", and
that the DNS "SHOULD NOT", handle this name to address translation. we
didn't used to standardized behaviour that was not seen "on the wire"
simply because interoperability testing would be hard to imagine. and i
don't imagine i'll have my "localhost.$ORIGIN" RR's out of any zones.
--
P Vixie
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
