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

[Phillip Hallam-Baker <[e-mail]>]

One consequence of encrypting DNS traffic is that we break backwards
compatibility. 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/