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 19:21:01 +0000

> > to me, as well.  unless there are objections, i will incorporate this into
> > EDNS1.
> 
> Fine, as long as there is no objection to having an RFC that fixes EDNS0
> too. 

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.

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