default notify-source on alias

hank at hank at
Sat Oct 28 17:34:06 UTC 2006

So I think I understand the current logic, but something bothers me...

I have a multi-purpose linux box running bind 9.3. It is multihomed and
has a bunch of alias addressess. Only *one* address on each interface
is used for DNS; simply for parsimony.

listen-on {; // localhost (lo0); // me.local (eth0); // me.public (eth1:53)

However, it looks like DNS notify messages sent via the public
interface will use a different source address. Per the OS logic, I
presume, they use the IP associated with eth1 rather than the eth1:0
alias explicitly set above.

This fools the slaves and they reject the notify. They are expecting
the notify to come from the listening address which is
already published in the zone as a valid NS. But instead, the notify
comes from (eth1).

Of course the workaround is simply to add: notify-source;
but I would like that to be assumed by bind for simplicity of
configuration. And because I don't understand what will happen to
notify messages going to slaves via (eth0) which need to
see only *that* address as notify source.

Is it a reasonable feature request to have bind automatically use a
listening address as a source when crafting notify? I.e. it should
never sent notify on addresses for which it is not listening, *unless*
notify-source is explicitly set.


More information about the bind-users mailing list