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

[Sten Carlsen]

Clenna Lumina wrote:
> 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 zone.com in externe
>>>
>>> I have the following error :
>>>
>>> 07-Jan-2007 00:44:21.778 debug 1: zone zone.com/IN/externe: notify to
>>> 78.87.206.99#53: retries exceeded
>>>
>>> 78.87.206.99 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 { 192.168.2.3; };".
>>
>> 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. 
>
>   
I built my NAT/firewall on a redhat 9 linux, I never thought that any of
this was a common problem, I can do loopback to the external address
even using port redirection.

I had the impression that this was a common property of all NATs, so I
was a bit surprised how many things were claimed to be broken by NAT.
Guess I was lucky to select a good implementation?

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"