NAT etc. (was: Spam Control Considered Harmful)
Jay R. Ashworth
jra at scfn.thpl.lib.fl.us
Sun Nov 2 17:00:16 UTC 1997
On Sat, Nov 01, 1997 at 03:49:37PM -0800, Paul A Vixie wrote:
> [ I removed "Jay R. Ashworth" <jra at 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 at 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
More information about the NANOG
mailing list