default notify-source on alias

Barry Margolin barmar at
Tue Oct 31 02:48:52 UTC 2006

In article <ei5c01$30oo$1 at>, hank at wrote:

> 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.

They'll ignore them.  I think you can configure notify-source on a 
per-zone basis, but I don't think there's a way to configure it on a 
per-slave basis.

> 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.

That seems like a reasonable suggestion.  But if you have multiple 
listen-on addresses, you still have the problem that the one it chooses 
may not be the one you want.  To at least make it predictable, perhaps 
it should default to the first one on the list.

Barry Margolin, barmar at
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

More information about the bind-users mailing list