Re: [dns-privacy] Multiple DNS requests per packet, multiple packet responses

[Ted Hardie <[e-mail]>]

On Wed, Mar 19, 2014 at 10:40 AM, Phillip Hallam-Baker <[e-mail]>wrote:

> One consequence of encrypting DNS traffic is that we break backwards
> compatibility.
>

Howdy,

Backwards compatibility with what part of the system?  Or perhaps first,
what question are we answering, that makes you presume this?

Imagine for a moment that the question is: "How do I prevent exposure of
clear text DNS queries from pervasive surveillance when they are sent from
my home to a recursive resolver in a data center?"  One answer certainly
could be "Set up an IPSEC tunnel between yourself and that data
center-based resolver, then run DNS across it".  There are a bunch of
trade-offs that will tell you whether that is a good idea, but one piece of
the puzzle is that the DNS bits would look exactly the same.

There are other approaches which retain the current syntax and change out
only the transport (for many other values of transport).  There is no
reason to believe those are wrong  on first principles, so let's not start
with a "this means DNS 2.0" until we've worked out what the actual issues
are, okay?

regards,

Ted Hardie


> Since we are going to break backwards compatibility we should take the
> opportunity to fix some of the problems in the DNS protocol.
>
> In particular, to guarantee compatibility with legacy DNS infrastructure,
> a query must:
>
> * Be 500 bytes or less
> * Have only one query (QDCOUNT = 1)
> * Have a response of 500 bytes or less
>
> Now in practice the first limit it 'usually' not enforced. But going to
> encryption is an opportunity to go from 'not enforced' to 'knock it off, if
> your implementation does not accept decent sized packets then its broken,
> broken, broken'.
>
> I would also like to fix the other two issues. In particular, if we let a
> DNS query ask more than one question at a time then we improve latency of
> responses. But much more importantly, we also make more interesting
> discovery strategies possible because asking for the AAAA, SRV, NAPTR and
> URI record along with the A record is no longer a 5 request penalty. And
> yes, it really is a penalty because much of the deployed infrastructure
> limits the number of parallel DNS queries an app can make in interesting
> and painful ways.
>
> So I would like to require a server that supports the crypto query
> protocol to be required to actually implement what is written in 1035 and
> respond to multiple queries. As in Servers SHALL implement RFC1035 and
> respond to queries with QDCOUNT>1. But since I don't think I will get
> that I will settle for this being an option that a server can advertise
> during the key setup. If the server can tell the client what its key is
> then it can tell the client what options it supports.
>
>
> One problem that comes of multiple requests is the potential for multiple
> responses being longer than one packet. And here the traditional thinking
> is rather limited.
>
> It is of course highly undesirable for a DNS server to have to respond to
> queries that are more than one packet long because that requires the server
> to maintain state. And state is expensive. It wrecks anycast, massively
> parallel server farms and any number of things that we don't want wrecked.
>
> But returning multiple response packets does not require additional state.
> The server just receives a packet, does some work and returns zero to 16
> packets in response. Moreover, even though individual queries are slightly
> more expensive, the overall load on the server goes down.
>
>
> One possible objection here is that this would enable more effective
> amplification attacks or complicate the DDoS against the server scenario.
> These are important considerations and are the main reason I don't want to
> try to use IPSEC or DTLS as the basis of a solution. When I started working
> on OmniBroker in 2012, these were the issues that drove me to adopt the
> architecture I did.
>
> In brief, I don't think we should worry about making DDoS or amplification
> attacks worse. Instead we have to have a strategy that allows us to
> mitigate them to the point where they are not worth the results.
>
> --
> Website: http://hallambaker.com/
>
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
>