Hi,
First, let me be clear that I am (personally) not now, nor have I ever
been, a member of the resolver implementation party; so my opinion is
biased about what is obvious. If various resolver-writers were to
chime in to say that what is obvious to you is obvious to them too
(and I don't think we need perfect consensus, as usual), then I'll
cheerfully withdraw. Nobody ever wants to see samples of my C code,
including me.
On Fri, Feb 09, 2018 at 07:21:05PM -0500, Ted Lemon wrote:
>
> This is really fascinating. To me what this code requires it something like
> the following, in any affected stub resolver:
>
One architectural point I _think_ I've been trying to make is exactly
that "in any affected stub resolver" is in fact the entire universe of
deployed resolvers (including stubs). We have zero reason to suppose
that old habits will die -- hard, soft, or at all -- within another
generation, given the results we got with EDNS0. So, I think I am
asking, "Why isn't the original 6761 advice better?" That advice
would have the root zone return RDATA appropriate to the QNAME
"localhost" (depending on RRTYPE). It has no advice about TTL, if I
recall correctly, so one could trivially set it to the maximum. Maybe
if the roots did this, everyone else would follow 6761 too.
> resolve(name):
> if (name == 'localhost'):
> return [IPv4Addr('127.0.0.1'), IPv6Addr('::1')]
But what you have just done there is short-circuited the search
processing, thereby retroactively making "localhost" a restricted
_label_ in every network that relies on search processing. Now, I
think that such networks are broken in deep ways[1]. Those ways are,
however, mostly unobserved by many network operators. The operators we
are trying to sort out -- the ones who already aren't following 6761
-- are entirely unlikely to believe this advice either.
> So to me there is no obvious architectural superiority to what you think is
> correct.
I don't think it is _correct_. I believe the existing state of
affairs is bad. I also think that good architecture doesn't just come
along and smash existing practice, like some Corbusier Moses. We have
an existing system, and what the document wants to do is make a number
of reservations (effectively across the entire DNS tree) in an effort
to solve a problem that would be _already solved_ by the existing RFC,
were it implemented. But that RFC was apparently not implemented, and
therefore I think this I-D is dangerous because it entails rules about
a certain label that extend down the tree, even though it is solving a
problem that might already have been solved if 6761 were followed. I
don't believe we should take greater action when the previous, lesser
action has not yet been implemented.
Best regards,
A
[1] To be clear, I say this with pretty full experience of my current
employer's "enterprise network(s)". I used to think my picture of
such networks was a nasty parody, including every bad idea I could
think of. As it turns out, I was short on bad ideas.
--
Andrew Sullivan
a...@anvilwalrusden.com
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
