[dns-operations] Fwd: wrapup of fragmentation/do/tcp discussion requested

[bert hubert]

> From: Mark Andrews <marka at isc.org>
> > No single referral from a zone signed with NSEC3 though, or using the
> > parameters of GOV or ORG.
> 
>        Did you check secure delegations   Secure delegations are
>        take less records with NSEC3.  DS + RRSIG v/s  1 or 2 NSEC3
>        record + RRSIGs.

I can't find a secure delegation to test against, so this may well be true.
For the coming years however, unsigned delegations are the most common.

And none of them fit in 512 bytes with DO=1. 

> > Well.. why not do a fallback to 1280 first  That does not require
> > fragmentation, and does indeed have enough room to contain 99.9% of all
> > typical DO=1 responses.
> 
>        And almost all those same answers will get through with
>        EDNS at 4096.  DNSSEC referrals don't normally get fragmented
>        and they are the ones that can protentially benfit from
>        additional section record trimming.  It's the DNSKEY responses
>        that get fragmented and they can be made minimal by the
>        authoritative servers.

Hmm.. there are two cases to worry about: 

1) networks that simply don't pass fragments, but can transmit UDP up to
1500 octets

2) networks that have something special with UDP/53 and >512 bytes.

Case number '1' should have zero problems with 1280 octet packets, AND
transmit the common case unsigned delegation from ORG without problems. Case
number '2' is served "correctly" by your tactic, except that it might as
well do TCP directly for ORG and GOV.

What we are seeing does appear to point at number '2' being frequent though.
Do we have any clue what might be causing this to happen?

And should the pain for these people be born by the ORG and GOV operators?

> > I understand it is more work, but 1280 would basically mean 'business as
> > usual' if there is (as I suspect) a large class of networks that can pass
> > both 512 and 1280, but not 4096.
> >
> > Is there a good reason not to try 1280 
> 
>        You need to fit all the fallbacks into the time it takes
>        the stub resolver to timeout.

So, cache the setting per remote - you have to cache EDNS compliancy status
anyhow. 

Is 512 bytes all we are talking about? Or is there a more fundamental
discussion I am missing?

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services