IXFR, NOTIFY, and NAT

Jim Reid jim at rfc1035.com
Mon Sep 30 20:48:58 UTC 2002


>>>>> "Fred" == Fred Viles <fv+abuse at nospam.epitools.com> writes:

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

    Fred> Of course, but how is that not working properly?  The name
    Fred> and IP address of the box on the inside of the NAT box are
    Fred> both meaningless to the outside box, and are often not even
    Fred> resolvable/routable.

So what? The server these NAT'ed hosts connect to are entitled to know
who/what it is they're actually talking to. NAT conceals that.
  
    >> Sometimes the same address is used for different hosts behind
    >> the NAT box, so this is at best confusing.

    Fred> How is this different than using multiple names (www, ftp,
    Fred> mail, etc) for the same *public* IP when running multiple
    Fred> servers on the same box?

You don't understand the problem. Suppose two hosts behind the NAT box
connect to the same server on the internet. The NAT box gives both
connections the same source IP address. [Assume it's using port
translation to keep the traffic apart.] For the server, it appears the
same host (source IP address) has made two connections when in fact
it's two different hosts making one each. Suppose the server only
allows one session per client IP address. Or what if the server has to
make a connection back to the client, where, if anywhere, will the NAT
box direct the traffic?

    >> It can also be dangerous. Which host do you reach if you
    >> connect to such a NAT'ed IP address?

    Fred> For the subset of cases where incoming connections are
    Fred> desired at all (public servers), the one your NAT box is
    Fred> configured to forward to for connections on the public IP
    Fred> and port in question.

And how is that local policy/configuration info made available to the
hosts connecting to stuff on the other side of the NAT box? How is
some random application supposed to figure out what somebody else's NAT
box is going to do?

    >> The same problems apply to the hosts that have to go through
    >> the NAT device to get to the Internet or some other network.

    Fred> How so?  More to the point, what problems?

See above: just change the location of inside and outside. ie The
server's behind the NAT box and the clients are outside on the
internet. Now have the server figure out who it's talking to. And the
client(s). Again.

Let's take this discussion off-line. It has nothing to do with DNS or
BIND any more.


More information about the bind-users mailing list