IXFR, NOTIFY, and NAT

Mark Damrose mdamrose at elgin.cc.il.us
Fri Sep 27 15:24:03 UTC 2002


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

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.

 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.

>
> 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.

 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.
>




More information about the bind-users mailing list