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

[Matthew Dempsky]

On Tue, Jul 28, 2009 at 11:25 AM, Doug Barton<dougb at dougbarton.us> wrote:
> I disagree with your premise that this was ever a reasonable solution.

Common practice suggests otherwise.

> I also disagree with your premise below that the amount of work to
> update code to handle encapsulated packets exceeds that of updating
> http servers to understand https;

No, I said that updating a legacy HTTP server's code to support
X-Forwarded-For is *less* work than to update it to support HTTPS.
E.g., a lot of Python HTTP application servers support X-Forwarded-For
but don't support HTTPS.  Even Varnish supports X-Forwarded-For but
not HTTPS, and it's documentation suggests setting up an HTTPS-to-HTTP
proxy.

> both in terms of the quantity of
> work but also in the sense that your example merely relocates units of
> work, it doesn't replace or obviate them.

What "units of work" are you referring to?  Units of developer work or
units of computational work?

The improvement in units of developer work are that I can write a
single DNSCurve-to-X forwarder that can handle the DNSCurve protocol,
and pick a value for X that is even simpler for authoritative name
servers to implement than DNSCurve.  Then the total amount of work to
add DNSCurve support to N different authoritative name server code
bases is asymptotically smaller than if I were to add DNSCurve support
to each.

I'll agree it just relocates the computational work, but that's not an
argument against.  People seem to prefer to offload cryptographic
computation to dedicated hardware.