IXFR, NOTIFY, and NAT
Mark_Andrews at isc.org
Mark_Andrews at isc.org
Fri Sep 27 22:49:11 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.
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
More information about the bind-users
mailing list