[AusNOG] "stateless TCP" for DNS

[Terry Manderson]

On 15/11/2010, at 10:49 AM, Mattia Rossi wrote:
> 
> Additionally, we are concerned about DNS responses making it back to the 
> client through the network, which is not covered by any of these 
> studies: e.g. of the 70% queries seen/answered, how many responses make 
> it actually back to the client?
> 

Lets say 'resolver' instead of client for now. There is a layering effect where a client talks to a resolver, and that resolver may pass back an answer to the client irrespective of what the resolver receives as a result of a non-cached query.

To answer your question, I am led to believe all responses made it back to the resolver as there were no obvious retries. (pretty easy to spot a retry, same resolver IP, same question, same query options etc .. just 3-5 seconds later)


> Or do i understand that wrong, and the 70% refers to complete DNS 
> lookups including responses?

Retries were one of the metrics used to look for any concerns in the DNSSEC deployment, especially when the DURZ was established. eg big response, but didn't 'validate'. The idea was to see if any networks went 'dark'. So you can assume complete DNS lookups.

> 
> What we fear though, is, that it might happen, that a major OS vendor 
> decides to "help" all the people in such a problematic network 
> situation, by changing the DNS clients to solely use TCP.

A major vendor. hmm - I'm hedging on the "unlikely" side.

> 
> Now if the 70% rate above refers to a complete DNS lookup, including 
> responses arriving at the client, something like that might never happen.
> 

I believe complete DNS lookup. However that would be to the resolver. There could be an argument for placing such a stateless TCP box inside an ISP's network as a caching resolver to allow the customers behind a 1920's[1] NAT/cable modem box to still get DNSSEC (DO bit) replies.

But really you are talking about a sub $300 item.

[1] apologies for the exaggeration.

>> 
> 
> Heh, you're right. We should have worded that differently, and replace 
> "current DNS system" with "current Internet". We agree, it's a middleox 
> problem, or as you say: the service to the client.
> As said, what we fear is, that bad service to the client forces changes 
> to the client which could affect DNS servers. If 90% of the clients in 
> the world start to use TCP only, how will that affect DNS servers?
> 

The first line that would get struck is the caching resolvers. If a large ISP see's BIND, CNS, etc crumble (?simultaneous TCP client restrictions?), or more likely a bunch of customer phone calls saying they can't get to a website then my guess is that the ISP will take steps before an impact is seen on any authoritative nameserver out on the net. So looking at the likely scenario on paper (while watching Master Chef Jnr, credibility now zero) I'm promoting the hypothesis that it will be a localised concern.

> Limiting the servers to 100 clients doesn't seem a nice move to me...

Simple fact of what is. The servers today are structured for high UDP query and very low volumes of TCP. High volumes of TCP in terms of DDoS constitutes a risk to the operation of a shared server resource and thus most people avoid it.

> 
> But again... I might have misunderstood the results of the IETF talk in 
> the first part of your message, and that's sort of crucial :-)
> 
> Otherwise we really would need to do some more research into that, as 
> Roland suggested.
> 

I guess that is what you will need to do.

T.