Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

[Mark Andrews <[e-mail]>]

In message <alpine.DEB.2.02.1210260013030.15761@ayourtch-lnx>, Andrew Yourtchen
ko writes:
> 
> 
> On Fri, 26 Oct 2012, Mark Andrews wrote:
> 
> >> Internet involves developing for the worst case, not the best. If a small
> >> but significant enough portion of sites on the Internet drop fragments, th
> en
> >> applications will be developed to avoid using fragments. Once applications
> >> avoid using fragments to suit some sites on the Internet, then all sites
> >> on the Internet may as well drop them, because they've been rendered usele
> s=
> >> s.
> >
> > Or they learn to adapt and use fragments where they work.  DNS clients
> > do this today.  They get stuck behind equipment that:
> >
> > 	* drops packets > 512 bytes
> > 	* drops fragments
> > 	* drops EDNS packets
> > 	* drops packets with DO set
> > 	* drops packets where the initial fagment doesn't arrive first
> >
> > The clients adapt the queries they make to get responses back.
> >
> > They work much more efficiently however if they can get fragmented EDNS
> > responses back.
> 
> What about DNSSEC ? Seems like there's a problem if the fragmentation 
> does not work correctly: https://tnc2012.terena.org/getfile/1603

Which looks at a single query / response rather than a complete
system.  There are nameservers that do not respond to EDNS packets.
There are firewall that do not pass DNS/UDP packets bigger than 512
bytes.  These two issues overwhelm any issues due to fragmentation.

Nameserver vendors need to deal with these issues as they exist in
the real world ever if there isn't a RFC which says how to deal
with them.

Named sends EDNS@4096, EDNS@512 and plain DNS queries when resolving
queries.  It does this with sub second retry timeouts.  Most referrals
do not require fragmentation.  If there is not enough space in the
UDP response the server falls over to TCP.   Named drops the optional
parts of DNSKEY/DS responses reducing the likelyhood of fragmentation.
Named drops optional parts of responses when it sees a EDNS@512
query reducing the likelyhood of TCP fallback.

    isc.org referral w/ dnssec is 681 bytes from the root servers
    isc.org referral w/ dnssec is 514 bytes from the org servers
    the isc.org dnskey response is 463 bytes from the isc.org servers
    the org dnskey response is 1334 or 1723 bytes depending apon
	which nameserver impementatin you hit
    the root dnskey response is 736 bytes
    a nxdomain response for sdlkfhadslhasjdhgfjgask is 652 bytes (NSEC)
    a nxdomain response for sdlkfhadslhasjdhgfjgask.org is 1021 bytes (NSEC3)

Both the server and clients sides can limiting the sizes of UDP
responses being sent.  If you are validating and are stuck behind
a firewall that you can't change that blocks fragmented responses
you can tell the nameserver to announce a smaller EDNS UDP buffer
size that is unlikely to cause fragmentation.  Unless you are
validating plain DNS responses from signed zones do not cause any
issues.

In practice you get an occasional slow down due to fragmentation
when validating if you havn't fixed your local firewall or tuned
your nameserver to account for the firewall.

There is code (unreleased) that will do EDNS@4096, EDNS@1432 ([46]
in [46]), EDNS@1232 (IPv6 network MTU), EDNS@512 (stupid firewalls)
and plain DNS (even stupider firewalls / broken servers).  A little
bit of extra state per server talked to is used to remember this
across multiple queries.   Named already tracks response times.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]