Maintained by: NLnet Labs

[Unbound-users] Source address selection for replies

Alexander Gall
Fri Jan 11 15:58:30 CET 2008


On Fri, 11 Jan 2008 15:39:03 +0100, Wouter Wijngaards <wouter at NLnetLabs.nl> said:

> The problem is what interfaces to bind to. 0.0.0.0 is everything and
> thus good on a 'normal' setup. When the kernel makes bad routing
> decisions (I know, anycast configuration is hell), this gives wrong

Actually, I find anycast with loopback interfaces pretty simple to
configure and use (I'm using Linux and Solaris).

> source address on replies, and DNS requires it. Really, the kernel
> should make good routing decisions, but anyway.

But you can't leave this decision to the kernel anyway.  The semantics
that the source address of the reply must match the destination
address in the query is imposed by the DNS spec, not UDP.  How can you
expect the kernel to do the right thing?

> Unbound does not know what interfaces you have. There is no nice posix
> 'list of interfaces', as far as I know. So, the problem for me is a
> portability, "0.0.0.0" is very portable. Listing the interfaces is hard
> and likely to encounter portability problems.

> With some ioctl and fun, I could probably support *BSD, Linux, Solaris
> for such a feature. The feature might not be available on other
> platforms (if the ioctl doesn't work). Something like 'probe_interfaces:
> yes', except with a better name?

I think the new dual-stack socket API introduced for IPv6 should take
care of all of this.  You should be able to do an anonymous (wildcard)
bind on a single socket (IPv4 addresses will be represented as IPv6
addresses in the "mapped" format).  The source address is available
through ancillary data from the socket.  The beauty of it is that you
don't have to worry about interfaces at all and you should pick up new
interfaces automatically.

Unfortunatley, some operating systems do not support this or require a
global configuration or a socket option to fully use this mechanism.
But I think it is the way to go on all systems that support it.

-- 
Alex