|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: NAT etc. (was: Spam Control Considered Harmful)
[ I removed "Jay R. Ashworth" <[email protected]> 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.
|