Zone transfer master -> slave using views on same subnet.

Clenna Lumina savagebeaste at
Mon Jan 8 19:41:51 UTC 2007

Mark Andrews wrote:
>> Thanks for the advise,
>> I have modified the "masters" reference on the slave but once I
>> modify a zone on the master and issue a
>> # rndc reload in externe
>> I have the following error :
>> 07-Jan-2007 00:44:21.778 debug 1: zone notify to
>> retries exceeded
>> is the IP of the slave on the "externe" view.
>> Notification are not sent to the correct IP.
> You are trying to send your notify messages via the NAT and
> they are not getting there.  (See the "Wildcards in reverse
> DNS" thread for more opinions on NATs).
> Use "notify explicit;" and "also-notify {; };".
> Mark

This is a common problem with many NATs. If it allowed for loop backing 
(sometimes theres an option for this) there wouldn't be a problem.

Unfortunately, this can break a lot of applications that try to connect 
to another client via an externally advertised address, in this case 
coming from an NS recor, but another example is games like StarCraft 
that use the Battle.Net service asa middle man to median the hosting and 
joining of games, in that one party creates a game, and their external 
address:port (that this middle man "sees") is advertised to any who 
attempt to join using the middles man's browser.

For clients inside the same network, NATs that do not provide loop back 
functionality (the ability for internal clients to "see" external ports 
on the NAT) will always break in these situations.

I'd go so far as to label NATs that do not at least provide an option 
for loop-back to be utterly broken, as this is a necissary for many 
applications that use any sort of middle man that return external 
information that leads to internal resources.

A proper NAT wont have this problem. FWIW, NAT32e handles these 
situations remarkably well; clients can see other clients on the network 
via their externally mapped ports, which many NATs just don't allow and 
I've NEVER been able to understand why. 

More information about the bind-users mailing list