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

[Mark Andrews]

> 
> 
> 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!!!"

	For non loopback operationa a NAT will change the source
	outbound and the destination inbound when port forwarding.
	This can all be done on the external data path.

	For a packet to loop back you have to change both source
	and destination on the internal data path.

	So depending apon how the NAT is implemented this could
	mean multiple hooks need to be installed.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org