Re: [DNSOP] EDNS0, the DO bit and acceptance of responses [Re: A different question]

2008-08-22 Thread Mark Andrews

> One other issue around DO is that it was introduced to signal "understanding"
> of DNSSEC as per RFC 2535.  The reaction of hypothetical 2535 only
> resolvers to DNSSECbis responses is to be explored.  I vaguely remember that
> we've had this discussion of versioning the DO "bit".

It's not a issue with BIND 9.1 or BIND 9.2.  They will just
ignore the DNSSEC-4035 records.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] EDNS0, the DO bit and acceptance of responses [Re: A different question]

2008-08-22 Thread Peter Koch
On Wed, Aug 20, 2008 at 04:06:05PM -0700, David Conrad wrote:

> - if the advertised EDNS0 buffer size is not large enough, it will  
> trigger truncation and, as a result, an increase in the number of TCP  
> sessions going to the root.

assumed that it's reasonable to focus on referrals and NXDOMAIN responses
only, we'd usually see a DS and RRSIG(DS) or an NSEC plus RRSIG(NSEC) for
the former and two NSECs plus two RRSIG(NSEC) for the latter.
As per RFC 3226 (or 4035, section 6), the resolver sending DO is expected
to support at least 1220 octet responses.
Hard data on the advertized sizes for both DO and "EDNS, but not DO" would
be helpful.

> - if the advertised EDNS0 buffer size is large enough, but the network  
> MTU is too small, fragmentation will occur which may cause the  
> response to be dropped (for a variety of reasons).

Since, as Mark has pointed out, EDNS is used in many queries today, resulting
in referral responses larger than 512, this problem should have been faced
even without DNSSEC (or DO inparticular) involved.  Again, measurement data
showing the response size distributions for root name servers would be helpful.

> - if there are middle boxes in the way that do stupid things (e.g.,  
> disallow DNS over TCP), those middle boxes will likely drop the larger  
> responses.

Much of this has already been initiated by resolvers using EDNS (with sizes
> 512 octets) and either large referrals or  RRs in priming responses.
The remaining risk is that DNSSEC responses would increase the size above
some critical value that doesn't regularily appear today.

> The concern I see (that I had hoped would be avoided by DO being set  
> to 1 only when the caching server administrator had explicitly  
> configured DNSSEC awareness) is that folks who are blissfully unaware  

DO can only signal from the resolver to the server, but for responses to
reach the resolver, anything in the way must also leave "larger packets"
alone.
One other issue around DO is that it was introduced to signal "understanding"
of DNSSEC as per RFC 2535.  The reaction of hypothetical 2535 only
resolvers to DNSSECbis responses is to be explored.  I vaguely remember that
we've had this discussion of versioning the DO "bit".

-Peter
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop