transparent DNS load-balancing with a Cisco ACE

[John Miller]

Thanks, Phil.  This makes perfect sense--unlike TCP, there's nothing 
inherent in UDP to make sure that packets come back from the right IP.

Thank you also for explaining this in terms of the socket APIs.  This is 
something I've only barely touched on--time for me to play around a bit 
and write some code.  I'd also just been doing an rndc stop/start to 
update the listening sockets--just what's bundled into the initscript. 
I'll keep reconfig in mind--might come in handy.

Aside: realized that I didn't reply to the list last time--doing so now.

John

On 10/25/2012 11:53 AM, Phil Mayers wrote:
> On 25/10/12 15:54, John Miller wrote:
>
>> Is BIND associating each request with a particular socket, then?  It
>> would certainly make sense if that were the case.  This was something I
>> didn't fully realize.
>
> Yes.
>
>> Something else I didn't fully realize was that by default, BIND binds to
>> _each_ of the available IP addresses on the system--_not_ to 0.0.0.0, as
>> happens with other network daemons (e.g. sshd).
>
> It does this because the cross-platform AF_INET socket APIs are limited.
> Binding a socket to each separate IP and replying from the same socket
> is the simplest cross-platform way to guarantee that UDP replies come
> from the right IP.
>
> AF_INET6 has a newer API which solves this, and if you "lsof -i :53"
> you'll see that bind only opens one socket for IPv6/UDP (unless you are
> on a system which doesn't implement RFC 3493/3542, in which case it
> falls back to one socket per IPv6 address).
>
> TCP-based daemons can ignore this, because the TCP stack takes care of it.
>
> Note that bind doesn't detect new IPs immediately - you need to do "rndc
> reconfig" or wait for the timer ("interface-interval" in the "options"
> block).