Subject: and to require that a requestor MUST NOT mark a responder as non-EDNS-aware if it receives a S2671 problem (was Re: Re: Comment on draft-reid-ipv6ok-00.txt)

From: David Conrad <[email-masked]>
Date: Sun, 03 Nov 2002 14:15:45 -0800

On 11/1/02 3:04 PM, "Kevin Darcy" <[email-masked]> wrote:
> I don't necessarily agree that RFC 3225 should be using extended-flags bits
> either, although the justification for that is probably stronger.

Actually, there is an issue here, applicable to both 3225 as well as
draft-reid-ipv6ok.

The use of a bit in the EDNS0 header can cause difficulties because the
EDNS0 negotiation mechanism specified in RFC2671 is not reliable and may
cause authoritative servers to occasionally be falsely identified as not
supporting EDNS0.  While this unreliability may be relatively harmless to
other uses of EDNS0 such as the support for larger UDP packets, such a
mis-identification can be fatal to DNSSEC resolution.

There are two sources of EDNS0 negotiation failure to be considered. The
first is due to the following definition in RFC2671:

5.3. Responders who do not understand these protocol extensions are
     expected to send a response with RCODE NOTIMPL, FORMERR, or
     SERVFAIL.  Therefore use of extensions should be "probed" such that
     a responder who isn't known to support them be allowed a retry with
     no extensions if it responds with such an RCODE.  If a responder's
     capability level is cached by a requestor, a new probe should be
     sent periodically to test for changes to responder capability.

It is entirely possible that an authoritative server will occasionally send
a response with an RCODE of NOTIMPL, FORMERR, or SERVFAIL for a reason other
than lack of EDNS0 support.  For example, a SERVFAIL response might be
returned by a server under excessive load or in the process of reloading a
zone.  When querying a forwarder rather than an authoritative server,
SERVFAIL responses are particularly common since they can be caused by any
kind of resolution failure.

The second source of EDNS0 negotiation failure is the fact that practical
EDNS0 aware resolvers, e.g., BIND 9, implement "EDNS blackhole detection" in
order to deal with broken authoritative servers that silently drop EDNS0
queries rather than returning one of the three RCODEs above.  This EDNS
blackhole detection causes servers to be classified as not supporting EDNS0
after they have failed to respond to a number of EDNS0 queries, even though
this failure to respond could in fact be caused by mere excessive server
load or network packet loss.

In accordance with section 5.3 of 2671, the resolver will cache the
incorrect indication that the server does not support EDNS0.  Therefore, a
single EDNS0 mis-negotiation will not only cause a single query to fail, but
also all subsequent queries involving the same name server until the EDNS0
information times out.

When DNSSEC validation fails due to EDNS0 mis-negotiation, it may be very
hard to diagnose the true cause of the failure.  From the perspective of the
client, it will be seen as a SERVFAIL response, indistinguishable from any
number of other DNSSEC related and non-DNSSEC-related resolution errors.
From the perspective of the DNSSEC aware resolver, the responses received
from the server mistakenly identified as not supporting EDNS0 will be
indistinguishable from correct responses in an insecure subdomain of a
secure domain, and the DNSSEC validation will only fail when the resolver
fails to obtain the DS nonexistence proof necessary to prove that the
subdomain is indeed insecure.  In practice, end users may see it as a
significant number of random but persistent resolution failures in domains
where DNSSEC is enabled.

In the case of 3225, the original proposal for a DNSSEC negotiation
mechanism that evolved into the RFC did not suffer from this problem as it
used the AD bit in the request header to indicate DNSSEC support rather than
relying on the unreliable EDNS0 negotiation mechanism.  Reverting to that
older mechanism would solve 3225's problem (albeit there are concerns with
respect to broken servers copying the flag bits incorrectly).

A more general solution, although only for the first source of failures,
could be for EDNS-aware servers to send back some indication, e.g., an OPT
RR, that they support EDNS in the SERVFAIL (et al) response to a request
containing an OPT RR and to require that a requestor MUST NOT mark a
responder as non-EDNS-aware if it receives a SERVFAIL (et al) response
containing this indication.

As for the second source of failures, it can be argued that BINDv9 has gone
too far out of its way to support broken implementations and that servers
that black hole EDNS queries instead of sending back some error response
are too stupid to live.

Thoughts?

Rgds,
-drc

------ End of Forwarded Message

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: David Conrad <[email-masked]>
Date: Sun, 03 Nov 2002 15:04:04 -0800

The subject of that last message should've been:

2671 problem (was Re: Re: Comment on draft-reid-ipv6ok-00.txt)

Apologies.

On 11/3/02 2:15 PM, "David Conrad" <[email-masked]> wrote:
>[a long message]

---

From: Rob Austein <[email-masked]>
Date: Tue, 05 Nov 2002 01:45:46 -0500

At Sun, 03 Nov 2002 14:15:45 -0800, David R. Conrad wrote:
> ...

This sounds like a reasonable approach.

> that black hole EDNS queries instead of sending back some error response

I'm inclined to agree with this argument.  Resolvers making and
caching guesses based on incomplete information seems to lead to
interoperability problems sooner or later, as shown both by your
example and by the otherwise unrelated issue of how queries for DS RRs
interact with deployed lame server detection code.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 05 Nov 2002 15:05:51 +0000

> This sounds like a reasonable approach.

to me, as well.  unless there are objections, i will incorporate this into
EDNS1.

> > As for the second source of failures, it can be argued that BINDv9
> > has gone too far out of its way to support broken implementations
> > and that servers that black hole EDNS queries instead of sending
> > back some error response are too stupid to live.
> 

also agreed.

---

From: David Conrad <[email-masked]>
Date: Tue, 05 Nov 2002 09:17:30 -0800

Hi,

> to me, as well.  unless there are objections, i will incorporate this into

Fine, as long as there is no objection to having an RFC that fixes EDNS0
too. 

Rgds,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Tue, 05 Nov 2002 19:21:01 +0000

> Fine, as long as there is no objection to having an RFC that fixes EDNS0

i don't see any point in updating/fixing/rereleasing EDNS0.  the 
implementation work folks would do to get such a fix into the
field is equal in magnitude to the work they would have to do to
get EDNS1 into the field.  let's press forward.

---

From: David Conrad <[email-masked]>
Date: Tue, 05 Nov 2002 11:47:45 -0800

Paul,

On 11/5/02 11:21 AM, "Paul Vixie" <[email-masked]> wrote:
> i don't see any point in updating/fixing/rereleasing EDNS0.

I see a point because I'd like to see DNSSEC deployed in my lifetime.  This
bug will also have an impact on IPv6 deployment given IPv6 requires EDNS0.

> the 

I do not believe there is consensus on EDNS1 (to put it mildly).  I do not
want to get bogged down in yet more IETF sludge.

Can't we just fix the known problem I identified and, for once, not try to
add a raft of other "features"?

Rgds,
-drc

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 5 Nov 2002 14:09:48 -0800 (PST)

> get EDNS1 into the field.  let's press forward.

Speaking as an implementer, I strongly disagree with this statement.

The changes needed to fix EDNS0 are trivial, while implementing EDNS1
would require major changes to recursive servers in particular, if it
is implementable at all.

The job of a DNS implementer is already extraordinarily difficult due
both to the loose specification of the DNS in STD0013 and to the
numerous extensions to the DNS protocol that have appeared over the
last few years.  One major difficulty in implementing a full resolver
is defining a complete and correct algorithm for classifying and
interpreting a DNS response, since each section of a DNS response can
contain a bewildering jumble of records: The answer section can
already contain CNAMEs, DNAMEs, synthetic CNAMEs, answers, SIGs of
answers, SIGs of the CNAMEs and SIGs of DNAMEs in no particular order.
The authority section can contain NSes, SOAs, NXTs proving the
nonexistence of a type, NXTs proving the nonexistence of a name, NXTs
proving the nonexistence of a wildcard, SIGs of the SOAs, and SIGs of
the NXTs, DSes, and SIGs of DSes.  Sorting all this out in a way that
correctly handles the general case is already an extremely difficult
task, and having to also deal with multiple answers in response to the
multiple questions of EDNS1 would make it even worse if not completely
impossible.

The DNS protocol has numerous corner cases that the draft does not
even begin to consider.  For example, what if one of the multiple
queries is a CNAME query?  Should the CNAME be followed (as the
non-CNAME query requires) or not (as the CNAME query requires)?  What
happens if one of the queries is for type DS, which has special lookup
rules?  If one or more of the query types does not exist, will the
response have a DNSSEC nonexistence proof in the authority section?

My suggestion is to fix EDNS0 and kill EDNS1.
-- 
Andreas Gustafsson, [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Wed, 06 Nov 2002 05:03:22 +0000

> I do not believe there is consensus on EDNS1 (to put it mildly).

the current EDNS1 proposal is just multiple queries.  there was one
dissenter who agreed that multiple queries was a good thing but
disagreed that it solved the problem then under discussion.  (you
might be thinking of the previous EDNS1 proposal, but all of the
controversial swill from that was pushed into EDNS2.)

> I do not want to get bogged down in yet more IETF sludge.
> 
> Can't we just fix the known problem I identified and, for once, not
> try to add a raft of other "features"?

yes.  the simplest thing would be to fix this when EDNS0 goes from
proposed to draft.

---

From: Randy Bush <[email-masked]>
Date: Tue, 05 Nov 2002 18:37:34 -0800

> add a raft of other "features"?

i can dig it