Subject: Re: 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: Paul Vixie <[email-masked]>
Date: Tue, 05 Nov 2002 15:05:51 +0000

> > 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.
> 
> 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.
> 
> 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.

also agreed.

--
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: 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