default notify-source on alias

[hank at GreenKey.net]

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 {
  127.0.0.1; // localhost (lo0)
  192.168.53.53; // me.local (eth0)
  192.0.2.53; // 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 192.0.2.53 which is
already published in the zone as a valid NS. But instead, the notify
comes from 192.0.2.1 (eth1).

Of course the workaround is simply to add: notify-source 192.0.2.53;
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 192.168.53.53 (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.

../H