On Sat, Nov 01, 1997 at 03:49:37PM -0800, Paul A Vixie wrote:
[ I removed "Jay R. Ashworth" <jra@scfn.thpl.lib.fl.us> 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. ]
I use Mutt, and I'm about to propose to them a new "reply" key which notes that one of the addresses on a reply you're about to send is a list you've defined, and weeds the headers appropriately. IE: you're welcome, Paul. :-)
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 possible, 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.
They're in a separate _IP_ addressing domain. They are _not_, in the cases Sean advocates using NAT for, in a separate _DNS_ addressing domain/namespace. And that's exactly the problem. DNS provides mapping between names and IP addresses. NAT provides mapping between IP addresses in one domain, and IP addresses in a different domain. DNSSEC provides authentication that a particular reply from a particular DNS server in fact actually came from that server. 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.
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.
Precisely, which is why the fact that NAT and DNSSEC will not interoperate -- they _can't_, by design (not that such design was purposeful; it was unavoidable) -- is so important to understand. Does anyone wish to correct me? I'm a pretty decent thinker, but it's possible I may misunderstand some specifics, I'm _not_ a DNSSEC or NAT mechanic. Cheers, -- jr '"marvelous"? Thanks, Paul' a -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Pedantry. It's not just a job, it's an Tampa Bay, Florida adventure." -- someone on AFU +1 813 790 7592