[dns-operations] Load balancing DNS queries across many machines

[Matthew Dempsky]

Let me make an analogy with HTTPS.

When HTTPS was first introduced, web servers didn't have native
support for it, so a reasonable solution was to setup an HTTPS-to-HTTP
proxy server that accepted HTTPS requests, handled the SSL protocol,
and forwarded the encapsulated request to a plain HTTP server.  Even
today this is a popular solution.

However, one problem with using a forwarder like this is that the HTTP
server sees the TCP connection came from a machine on the network
instead of the actual client, so log files store the wrong IP address
and server-side code that uses IP address might break.  For a lot of
users this might not be much of a problem, but for cases where it
matters, people have de facto standardized on the X-Forwarded-For
header field to communicate the client IP address to the HTTP server.

Admins that need their HTTP servers to see the IP address still have
to update their HTTP server code, but the change to make an HTTP
server understand X-Forwarded-For is much simpler than the change
required to make it understand SSL.


Similarly, for DNSCurve, most authoritative DNS servers don't have
native support for it, so a reasonable solution is a DNSCurve-to-DNS
proxy server that accepts DNSCurve requests, handles the DNSCurve
protocol, and forwards the encapsulated request to a plain DNS server.
 And for similar reasons, we can expect this might stay a popular
solution even after DNS servers start natively supporting DNSCurve.

Part of my original email was to basically ask if anyone has an
equivalent to X-Forwarded-For for DNS yet.


The other part was that when a DNSCurve-to-DNS proxy server receives a
DNS response from a backend server, it needs to know what key to
encrypt the response with.  The direct analog to the HTTPS-to-HTTP
proxy server is to have the DNSCurve-to-DNS proxy server just maintain
some extra state in memory to keep track of
keys/nonce/encoding-format/etc.  However, because having to keep state
like this is not ideal, it would be nicer to just encode the state in
a cookie that the proxy server sends along to the backend DNS server.
Then the forwarder can just rely on the backend server echoing the
cookie.  (In the HTTPS-to-HTTP case, because the protocols are TCP,
the server already has to maintain some state in memory, so the extra
state for SSL isn't as much of a concern.)

This would similarly require some (small) additional changes to the
backend server for support (comparable to EDNS PING).


To be compatible with existing DNS servers, we'll need DNSCurve-to-DNS
proxy servers that keep state in memory anyway.  But for high traffic
sites where keeping state might be problematic or where the DNS
servers want to know the client's IP address, the backend protocol
will need to be extended.  This can either be DNS + some new EDNS
options or some new (non-backwards-compatible, but simpler) DNS +
extended header protocol.

It's no problem to have multiple backend protocols (e.g., how the web
world has HTTP, SCGI, FCGI, and probably others), but before inventing
anything new, I was just curious if anyone had already tackled this
matter.