IXFR, NOTIFY, and NAT

[Mark_Andrews at isc.org]

> "Jim Reid" <jim at rfc1035.com> wrote in message
> news:an1ouo$fuko$1 at isrv4.isc.org...
> > >>>>> "Eric" == Eric S Johansson <esj at harvee.billerica.ma.us> writes:
> 
> > You don't appreciate the problem then. The first problem with NAT is
> > reverse lookups don't work properly: you generally get the name of
> > some NAT'ed IP address, not the name of the thing on the other side of
> > the NAT box.
> 
> Which is why you need static NAT, not dynamic NAT.  With a 1 to 1 mapping of
> external address to internal address you can guarantee which host you hit
> and have appropriate reverse records.

	getpeername() returns the NAT'd address not the real address.
	A socks based appliction gets the real address.

	["real" is the address the client wanted you to see.]
 
> Sometimes the same address is used for different hosts
> > behind the NAT box, so this is at best confusing. It can also be
> > dangerous. Which host do you reach if you connect to such a NAT'ed IP
> > address?
> 
> This is not NAT per se, it is port forwarding.  You do have to be careful
> when you do this, but it is certainly possible to get it right.

	Actually it is NAT.  The address is translated.  It *might* also
	include PAT but it doesn't have to.  It depends upon how the
	translation is configured.
 
>  The same problems apply to the hosts that have to go through
> > the NAT device to get to the Internet or some other network.
> 
> For host going out, yes I want them to all map to the same address because I
> don't *want* external devices to originate packets to the internal
> workstations on my network.  In addition to the firewall rules blocking
> this, I find it usefull for there *not* to be a path at all.

	This is just security by obscurity.  A plain firewall is just as
	good at protecting your interal machines as a NAT'd firewall.
 
> > On the DNS side, any NAT box that fiddles with the contents of DNS
> > packets is just wrong. It should not do that.
> 
> Agreed, but if it does that it is no longer a NAT device - it is an
> application proxy.  Split DNS is a much better solution.

	NAT's don't work if they don't contain application proxies.
 
>  It should not assume
> > that the client wants the addresses in the response translated. [Try
> > troubleshooting a DNS problem when you can't guarantee that the data
> > in the responses was what the server actually sent.] Tampering with
> > the contents of DNS packets like this violates the fundamental
> > principle of DNS: no matter where you are or what server you query,
> > you always get the same answer for a given lookup. In fact if DNSSEC
> > or TSIG is used, the DNS data is digitally signed. So anything that
> > alters the contents of that data breaks the signatures, invalidating
> > the response.
> >
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org