NAT etc. (was: Spam Control Considered Harmful)

:: Jay R. Ashworth writes ::

The problem on point is that NAT cannot interoperate with DNSSEC.

That the DNSSEC chains on each side of a NAT box are clean is
immaterial, because *the DNS server and the NAT box are, by definition,
not within the same span of administrative control*.

If I'm the client asking that DNSSEC server about something, I want
_it's_ authentication. I may not be willing to trust my NAT box's
operator, so the fact that _he_ signs it is immaterial to me.

In the current world, we have Router Operators between users and
servers, and those Router Operators have to be trusted. Those
same organizations would be running NAT boxes in the Brave New World
of NAT in the backbone. So putting NAT in the backbone doesn't really
mandate that you trust anyone else.

Let's suppose you query on "" and get back an A record
with IP address, with a compeltely valid set of signatures.
Then, assuming you trust the security of the DNSSEC model, you know
with a high degree of confidence that the owner of the
domain claims that the IP address of is
But it makes no claims that if you send a packet to, that
packet will route where the owner of thinks it will. In
fact, that packet will route wherever the owners of the routers between
you and want it to route. So you've got to trust them,
even without NAT.

DNSSEC can be enhanced to reflect that trust:

In a NAT + DNSSEC world, suppose that Sprint maintains a NAT between
themselves and MCI. And that, rather than translating information in
DNSSEC packets, they append signed translation information. Assume you
want to connect to WWW.X.COM. Your DNS query could return with:
   WWW.X.COM (A record) (signed by company X) (NAT's to) (signed by Sprint)
(The first line came from X's DNS. The second line was added by
Sprint's NAT box.)

You can tell from that that you should send your connection
request to In order to do that, you have to trust
Sprint's claim that they will translate to, but
remember, even in the non-NAT world, you were already trusting Sprint.
(Distribution of Sprint's public key, and the public keys of all other
NAT box operators, would have to occur somehow, and that's almost
certainly non-trivial, but also almost certainly doable.)

In short, NAT would break DNSSEC is its current incarnation, but the
problems could be fixed, and DNS in a NAT world could be made as secure
as DNSSEC currently is in a non-NAT world.

I still don't like NAT in the backbone, though.

          - Brett (