Re: NAT etc. (was: Spam Control Considered Harmful)

["Jay R. Ashworth" <jra () scfn thpl lib fl us>]

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