[prev in list] [next in list] [prev in thread] [next in thread] 

List:       namedroppers
Subject:    Re: [dnsext] EDNS0 fallback "revisited"
From:       Eric Osterweil <eoster () CS ! UCLA ! EDU>
Date:       2009-08-31 21:05:10
Message-ID: 7CD8A493-FCFA-4135-91AC-BC1800BDDF3F () CS ! UCLA ! EDU
[Download RAW message or body]


Sorry for the Johnny-come-lately response:

On Aug 25, 2009, at 11:44 AM, Olafur Gudmundsson/DNSEXT chair wrote:

>
> Dear colleagues,
>
> After reading all the messages on EDNS0 buffer sizes and fallback
> your chairs have huddled and tried to agree on an approach to go  
> forward
> and what/if protocol work is needed.
>
> For the sake of argument we want to limit the discussion to
>       "ENDS0 capable entities"
> and their behavior.  The goal is to minimize fallback.
> By decreasing fallback cases we speed up DNS resolution for everyone.
>
> We think that the current evidence suggests three main problems:
>   - inability or refusal to handle UDP packets larger than 600 bytes.
>   - inability or refusal to handle UDP fragments.
>   - failure to set the advertised EDNS0 buffer sizes correctly given
>     the actual network conditions
>
> Model:
> A is the issuer of a DNS query
> B is the target server of the query
>
>       A <---pipe1---> INTERNET <----pipe2----> B
>
> If A advertises a ENDS0 buffer size that is larger than will go  
> through
> "pipe1" then B may send back an answer that is larger than fits  
> through the
> pipe. Then A will time-out and do a fallback.
>
> If B attempts to put an answer into "pipe2" that is larger than fits  
> into
> it A will not get an answer and will do a fallback.
>
> If both A and B know the "width" of their LOCAL pipes fallback
> between them is rare and if B has an answer that does not fit, it will
> set the TC bit.
>
> If the problem is actually in the INTERNET part of the diagram,
> fallback is needed no matter what.  We can put of evaluation of how
> much of the problem is in fact in the middle, because we know for sure
> right now that there are problems at the end points.  Since those are
> under the control of the affected parties, we can tackle this problem
> first.
>
> The assumption here is A and B can detect the "width" of their local  
> pipes
> and either fix them or set UDP-buffersize parameters to values that  
> their
> local pipe will pass. If either A or B have multiple paths to the  
> Internet
> they should set their buffer sizes to the smallest pipe width.
> In particular B should NEVER provide an answer to a normal (i.e. non  
> ANY and
> non RRSIG) query that does not pass through "Pipe2".
>
> Work to be done:
> -  Provide tools that measure local pipes and provide configuration  
> hints

We presented dnsfunnel for this at IETF 75, and I think it would be  
great for people to download it and try it out to see this for  
themselves:
	http://www.vantage-points.org/

You can point dnsfunnel at any zone and it will tell you if there is a  
problem and what sizes fit.  This has the benefit of testing the path  
from _your_ stub to each name server in whichever zone you aim it at.

Eric
é

>
> -  Educate users to use the tools, where to look for problems and how
>       to update configurations.
> -  Make the firewall community aware that firewall's are causing DNS  
> problems
>  and educate them in how to update their configurations, to allow well
>  formed UDP fragments to pass. (i.e. non overlapping fragments)
> -  ditto for DNS proxy vendors.
> -  Improve EDNS0 fallback strategies.
>
> Only the last one is a protocol work that DNSEXT can undertake, all  
> the others
> are external educations activities that are outside the scope of the  
> working
> group.
>
> As DNS is not the only UDP based protocol that is affected by the  
> restrictions on
> UDP packets, modifying DNS to work around misbehaving middle boxes  
> is counter
> productive to making the Internet better in the long run.
> Adding complexity to DNS to handle the misbehaving units is a wasted  
> effort
> as the educational tasks will still have to be undertaken and  
> provide a
> quicker return on investment.
>
>       Olafur & Andrew


["PGP.sig" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]