NAT etc. (was: Spam Control Considered Harmful)

[ I just removed these addresses:

  ...from the recipient list, since I know they are all on NANOG. I would
  not be offended by each of the above people thanking me publically for
  not making them see two copies of this reply. Perhaps that would set
  some kind of an example for the rest of the audience, most of whom just
  say "reply-all". ]

Havard said:

...which brings me to think if it isn't so that Secure DNS (at
least as currently specified) and widespread deployment of NAT
boxes which fiddle with the contents of DNS reply/request packets
isn't exactly a properly working combination. As I understand it
you can have NAT or Secure DNS with e.g. signed A records but you
can't (easily?) have both.

This is a misdirected concern. DNS clients inside a NAT cloud are
already proscribed from seeing DNS data from other NAT clouds or from
the Internet itself. The NAT technology has to strip off DNSSEC stuff
when it imports data but it tends to strip off DNS delegation and
authority data as well, and tends to alter the address and mail exchange
records. NAT borders are already DNS endpoints, with or without DNSSEC.
Whether and how to regenerate external DNS inside a NAT cloud is a matter
of NAT implementation, but the fact that it's _regenerated_, not forwarded
or recursed, is a design constant.

Well, yes, Paul, but unless I misunderstood you, that's exactly the
point. If a client inside a NAT cloud does a DNS lookup to a
supposedly authoritative server outside, and the NAT box is _required_
to strip off the signature (which it would, because it has to change
the data), then it's not possibile, by definition, for any client
inside such a NAT box to make any use of SecDNS.

The point is that you _can't_ regenerate the signature, usefully to the
client, anyway, precisely because _it is a signature_.

-- jra