North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: NAT etc. (was: Spam Control Considered Harmful)
On Sat, Nov 01, 1997 at 03:49:37PM -0800, Paul A Vixie wrote: > [ 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. ] 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 [email protected] 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
|