[ I removed "Jay R. Ashworth" <firstname.lastname@example.org> from the CC list of
this message after noting that he had been kind enough to remove me from
the CC list of his mail. After this I will stop publically noting it when
someone does the polite thing, i.e., doesn't CC me on mail to the list, and
just twang this string when someone does the impolite thing, i.e., does CC
me on mail to a list that they know I'm on. ]
> 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.
I think I may have been too easily misunderstandable, so I won't fault your
interpretation other than to say that since the folks inside a NAT are in a
separate addressing domain and therefore have their own "root" name servers,
the certification chain for DNSSEC is entirely valid, and entirely separate,
within each NATspace.
The point is that you _can't_ regenerate the signature, usefully to the
client, anyway, precisely because _it is a signature_.
And the client, and its NAT box, and their root name servers, are all very
consistent and share all of their keys and Everything Just Works. What's
going on here is that when you tell your interior clients how to find their
interior root name servers, you have to tell them the interior root DNS key
(the public one that is). If your NAT box is advanced enough to intercept
DNS to external root name servers and redirect it toward interior ones so
that the clients can all be configured as if they were normal (public) DNS
clients, then your internal net can't use DNSSEC. Depending on the size of
your organization, internal DNS validity checking may not have been the
reason you wanted to use DNSSEC anyway -- most of us are concerned about the
data which comes from _outside_ our networks.