Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue

From: Paul Vixie <[email-masked]>
Date: Mon, 08 Mar 2004 03:09:22 +0000

>  1) the document requires the use of EDNS0.  However, current EDNS0
> implementations typically advertise the larger sizes than they can
> handle at the IP layer, causing fragmentation.  You can argue that
> this is OK as long as the result of NOT fragmenting would end up with
> a worse result than as you would be without it (e.g., requiring
> falling back to TCP, or whatever).

most of <http://research.compaq.com/wrl/techreports/abstracts/87.3.html>'s
concerns about fragmentation have been addressed, and the ones which still
apply are relevant to small-mtu connections ("don't do that") and to high
performance/demand mobygram applications (nfs, tcp).  for dns, it's okay.

> With DNSSEC, I'm not sure that this holds anymore.  It seems to me
> that the best behaviour would be to avoid IP fragmentation by having
> correct implementations of EDNS0, and if some data must be left out,
> that it would be fetched separately, over second, third, ..., nth
> query over UDP.  Shouldn't that be possible and reasonable?

no, that really would force tcp, which really would be worse than ip-frag.

--
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: Paul Vixie <[email-masked]>
Date: Mon, 08 Mar 2004 06:26:31 +0000

> > ... would force tcp, which really would be worse than ip-frag.
> 
> Seems like a flaw in DNS spec -- too coarse granularity:
>  1) "everything fits in one UDP datagram", or
>  2) "just use TCP".
> 
> Would it make sense to add 1.5) there, "if it doesn't fit to a UDP 
> datagram of specific size, query again, but only the missing data this 
> time".

sense, yes, but the atomicity requirements are hard to adjust in that light.

for example, if what you're trying to send is a referral, and the query and
authority sections are all that fits, and you decide to just send that much
and let the initiator re-query for the parts that would have been in the
additional-data section, then it might end up being the case that they can
never query for it.  consider an authority section whose names are all under
the referral cut.

in earlier work once proposed as part of EDNS0 and then reintroduced as EDNS1,
the idea came up to indicate in a response that there were multiple messages
in the answer.  we called it MD ("more data").  ultimately this turned out to
be a lot more complicated than it sounded, and it's since been abandoned.

i dearly wish that EDNS0 had made TTCP its prerequisite.  ("ah, hindsight.")

> Not sure if that would make sense but instead of forcing everything in 
> one, probably fragmented message, it would seem to encourage "proper" 
> operation with big DNS replies.

in general, if you think the response might be larger than 3*EPMTU, use tcp,
and that will amortize the complexity nicely.  note that PMTUD hasn't been a
raging success, and that EPMTU is probably 1500 octets most of the time, and
that's where masataka's "4000" number comes from.

> Btw: note that IPv6 implementations aren't even required to defragment 
> a datagram which is larger than 1500 bytes once assembled.. so we're 
> in a bit murky waters here.  I'd certainly want to try to avoid packet 
> sizes >= ~1500.

yes but on such a host, the EDNS0 initiator would presumably be able to 
discover this limitation and advertise a 1500-octet buffer.  that's what
the EDNS0 spec says it should do, at any rate.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 08 Mar 2004 03:09:22 +0000

---

From: Paul Vixie <[email-masked]>
Date: Mon, 08 Mar 2004 06:26:31 +0000