IXFR, NOTIFY, and NAT

[Jim Reid]

>>>>> "Eric" == Eric S Johansson <esj at harvee.billerica.ma.us> writes:

    >>> Why qualify this? Not using NAT is always the Right Thing To Do.

    Eric> Jim is IMO just taking a classical geek stand on the subject.

Thank you.

    Eric> The argument against address translation is that 
    Eric> it's "violating" the integrity of the packet and rewriting
    Eric> headers and occasionally the contents.

    Eric> My, just as arrogant, opinion is that if a protocol cannot
    Eric> survive traversing an address translation boundary without
    Eric> rewriting of the contents, then the protocol itself is
    Eric> broken, not the address translation technique.

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. 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? The same problems apply to the hosts that have to go through
the NAT device to get to the Internet or some other network.

On the DNS side, any NAT box that fiddles with the contents of DNS
packets is just wrong. It should not do that. 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.