Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

[Ted Lemon <[e-mail]>]

On Feb 1, 2018, at 11:26 AM, Andrew Sullivan <[e-mail]> wrote:
> It has the notable advantage that it's what the RFC says to do.

As a general principle, when what the RFC says to do is not the right thing to do, the solution is to update the RFC, not to ignore the problem.   So a statement in the form you have used, while it may make sense when we are talking about whether or not an implementation of the RFC is correct, is meaningless when what we are talking about is whether the RFC is correct.

Your and Paul's responses to this seem to take the position that what matters is consistency.   We should not return NXDOMAIN, because localhost has meaning, and NXDOMAIN doesn't.   But this misunderstands what NXDOMAIN means.   What NXDOMAIN means is "there is no such name in the DNS."   It doesn't mean "there is no such name."

It would be nice if there were an error code that said "you're looking in the wrong place for an answer," but there are two problems with this.   First, it's not actionable.   Looking for localhost in the DNS is a programming error.   When a program is broken, telling it that it is broken doesn't do any good.   What we want is to return a response that doesn't make things worse.   Returning REFUSED makes things worse.   Returning NXDOMAIN does not.

Second, there's no trust model for such a response.   The trust model for NXDOMAIN is clear, and we know how to do it.   The trust model for e.g. REFUSED is nonexistent.

Whether we should place special requirements on recursive resolvers is certainly something that is up for debate.   But what the right response is, if we don't place special requirements on recursive resolvers, seems extremely straightforward to me.   If you believe that the right response is not NXDOMAIN, your reason needs to be something more than "that's what the RFC says to do."