Dear colleagues,
On Mon, Jan 22, 2018 at 11:18:08AM -0500, Suzanne Woolf wrote:
> Hi all,
>
> This is the opening of the Working Group Last Call for "Let 'localhost' be
> localhost”
> (https://www.ietf.org/id/draft-ietf-dnsop-let-localhost-be-localhost-02.txt).
>
I have read this document.
Let me begin by saying that I am sympathetic to what the document
wants to do and why it wants to do it. I nevertheless think the
proposal here is incorrect, and that it has bad consequences for the
DNS and for the RFC 6761 special-use registries.
I am at least a little troubled by the assertion, early in the
document, that RFC 6761 empowers anything to send queries anywhere.
This is the text in RFC 6761:
3. Name resolution APIs and libraries SHOULD recognize localhost
names as special and SHOULD always return the IP loopback address
for address queries and negative responses for all other query
types. Name resolution APIs SHOULD NOT send queries for
localhost names to their configured caching DNS server(s).
That does not sound to me like "empowering" clients to send queries to
a resolver. It sounds to me like something being advised against, and
strongly. In RFC 2119, "SHOULD" does not mean, "This is mostly
preferable." It means you ought to do it unless there "exist valid
reasons in particular circumstances to ignore" that constraint.
Nevertheless, people sometimes misread the SHOULD. Perhaps the
section of RFC 6761 dealing with localhost could use the following
clarification:
3. Name resolution APIs and libraries SHOULD recognize localhost
names as special and SHOULD always return the IP loopback
address for address queries and negative responses for all
other query types. Name resolution APIs SHOULD NOT send
queries for localhost names to their configured caching DNS
server(s). The only exception to this stricture is in the case
where a node is known not to have a loopback interface
configured and the local network is known to provide some
replacement service. For practical purposes, libraries will
never use such functionality, and resolution API and library
programmers are encouraged to treat these requirements and
mandatory behaviour.
I'd even be prepared to countenance an argument that the SHOULDs
really ought to be MUSTs in this item.
I am really very troubled by the idea that any DNS server should
return RCODE 3 to a query for "localhost". (This is items 4 and 5 in
section 3.) This is not even wrong: the name _does_ exist, and indeed
any server on the Internet would know that (since it would itself
serve the answer _to_ itself of what localhost means; whether it
should serve it to anyone else might be a different question, but it
certainly should not respond with RCODE 3).
The draft's IANA considerations are wrong, I think, because it does
not make clear that this reservation is of the label "localhost"
anywhere in the DNS at all. That is the consequence of item 2 under
section 3: since the bare label localhost, which is a relative name,
is treated as root-relative under all circumstances. I am pretty sure
this is an update to STD13: I can't think of any case where relative
qualification is treated so strangely (if example.com does not get
resolution as example.com., then the fallback to the search list
happens, but not before). This seems to be in tension with section
5.2. I understand the goal, but I don't think it is possible to
achieve it in the DNS.
The advocacy in section 5.1, that applications should do the work
themselves, seems to me to be leading in the opposite direction to an
ostensible goal of the document. In section 1 we see a note that
applications have hard-coded loopback addresses. But the complexities
of resolution are such that any application in the future that is
supposed to do its own resolution might just wire up a shortcut to a
loopback addresses, thereby enshrining the very "hard coding" into
protocol-specified behaviour for applications.
I am sorry that cannot support advancing the draft in its current
state.
Best regards,
A
--
Andrew Sullivan
[email protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
