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.