ietf
[Top] [All Lists]

Re: last call discussion status on draft-iab-2870bis

2015-03-05 15:49:02

In message <6056F80B-2188-4E52-AE18-35E84BA98147(_at_)vpnc(_dot_)org>, Paul 
Hoffman writes
:
On Mar 5, 2015, at 12:47 AM, Jari Arkko 
<jari(_dot_)arkko(_at_)piuha(_dot_)net> wrote:
3) Mark Andrews' suggestion of further requirements regarding EDNS0
has
not been discussed, but I would note that at this stage we should not
add
major requirements without substantial community portion indicating
that
this is needed. I'm not hearing it.

I suspect this is because the root servers actually correctly
implement EDNS.  If a server was changed to a implementation that
failed to correctly implement EDNS that would change.

Perhaps. What do others think?

Mark's proposed addition of EDNS0 is a very nice thing to have. If all
the root servers always responding to queries that have EDNS0 with EDNS0
in their responses, the DNS would be operationally more stable,
particularly as response sizes increase over time.

However, it seems inappropriate for the IETF to say "and here is the
exact list of protocol bits that we require for the root service" when we
are sure that servers using few of those bits will work adequately. Also,
it is important to note that RSSAC-001 says:

[E.3.2 - A] Individual Root Servers will adopt or continue to implement
the current DNS protocol and associated best practices through
appropriate software and infrastructure choices.

EDNS0 very clearly falls under "best practices": no one can deny that.
So, to some extent, the expectation is already on the root server
operators to use EDNS0. It's not clear if the IETF saying "here's a thing
we insist on" will help the cause.

Further note: just saying "EDNS0" is not sufficient: we would have to say
which features, options, and extensions would be needed. This is
"obvious" to many folks, and not at all clear to others.

You comment makes no sense.  Please go read RFC 6891 (it fixed the
handling of unknown EDNS options, RFC 2671 failed to state the
behaviour).

EDNS version 0 is a frame work.  There are almost no extensions
there.  There are no EDNS options defined.  There are no EDNS
flags (DO is listed as existing but that is defined in RFC3225).
There are is just the initial version of 0.  And the ability to
offer a larger EDNS UDP size.  It tells you the expected behaviour
when you get a unknown EDNS option (ignore), a unknown EDNS flag
(ignore), a unknown EDNS version (return BADVERS w/ highest version
you support).

RFC3225 adds the DO flag which should be supported as DNSSEC is
required.  Yes, there are servers that do DNSSEC but don't correctly
handle DO (it is not echoed in the response).  The current root
servers are do not exibit this mis-behaviour.  This however comes
from requiring DNSSEC support not EDNS support.  The reports only
flag DO when RRSIGs are returned indicating that DNSSEC is supported
by the server.

It is the well defined behaviour when presented with unknown
extensions that is needed.  That is what I test conformance to in
http://users.isc.org/~marka/tld-report.html.  Failure to follow the
well defined behaviour when presented with unknown extensions is
what causes interoperability problems and cause resolvers to do
trial and error.

If you want to see how bad other server implementations can be see:

http://users.isc.org/~marka/gov-report.html
http://users.isc.org/~marka/au-report.html
http://users.isc.org/~marka/bottom-report.html
http://users.isc.org/~marka/alexa-report.html

We really don't want the errors that show up in these reports
appearing on root servers.

Mark

--Paul Hoffman


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka(_at_)isc(_dot_)org

<Prev in Thread] Current Thread [Next in Thread>