|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: NAT etc. (was: Spam Control Considered Harmful)
This is it: my last message on this thread. This will be the third time
I have tried to explain the answer to "why NAT doesn't break DNSSEC" and
this is now the point where I feel I must sure as hell be "wasting my
time and annoying the pig" as R.A.H. once said.
>> 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.
The DNS data from one IPspace is not relevant or useful in any other IPspace.
The name servers, mail servers, and addresses you get back will all have to
pass through a NAT before they will be usable in the "other" IPspace. If you
are in a nonoverlapping IPspace (in both addresses and names) then the names
won't have to be translated and in that sense you'd be justified in letting
the MX RR's be visible to the other-space clients. The NS RRs are all wrong,
though, since they are part of an alternative-universe DNSspace (with its own
root name servers, whose delegation chain may be different than the one you
follow). And of course the A RRs are suspicious since they refer to addresses
you cannot reach in any normal sense. If your packets ever reach those
addresses it will be with translated source addresses and NAT-border forwarders
to get you your responses back, but it's more likely that your packets will
NOT reach the destination but will rather terminate at the NAT-border and be
processed at the application layer, with application layer regeneration on the
other side.
In no case can a DNS response generated by a host in some IPspace be seen in
its original glory by some host in some _other_ IPspace. What a querier will
hear is "whatever the NAT wants it to hear" which will be "whatever it takes
to get the job done for the end-user". This means you could ask for the MX
RRset for VIX.COM and while the "real" answer (in VIX.COM's IPspace) is:
VIX.COM. IN MX 0 GW.HOME.VIX.COM.
GW.HOME.VIX.COM IN A 192.5.5.1
you might get back either:
VIX.COM. IN MX 0 GW.HOME.VIX.COM.
GW.HOME.VIX.COM IN A 10.0.0.53
or
VIX.COM. IN MX 0 NAT-MX.YOU.
NAT-MX.YOU. IN A 10.0.0.53
Given this serious disconnect between the truth and what you have to hear in
order to keep you sane and reachable, it rather follows that the DNSSEC data
in the original (correct, truthful) DNS response has to be processed by the
NAT (which as a NAT-border has "sight" in both IPspaces) and verified and so
on, and then if DNSSEC is in use in the querier's IPspace (which is shared by
one side of the NAT box and by the rootish name servers in that IPspace) then
new (faked but consistent and verifiable) DNSSEC signatures have to be made.
Clean? No. But neither is NAT. What it can be is: effective and secure.
And: the idea of forwarding NS RRs of _any_ kind is just right out.
> 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.
Sean's current stated thesis seems to be that ISP's can operate NAT boxes.
And for captive accounts like old-AOL and old-Compuserve and old-MSN that is
absolutely right. However, in the new generation ISPs who offer IP/PPP to
their users, this won't work, and precisely for the reason you stated. But
I disagree with the implication that ISP's have to offer NAT in order for NAT
and IPv4 to succeed. Ford Motor Company, Digital Equipment Corporation, and
Sony Corporation of America all have Class A networks and they are NOT ISP's.
They no more allow external IP to reach their desktop then they would allow
unshielded plutonium to reach their desktops. THOSE are the places that have
to run NAT -- they already have tight firewalls, and new companies building
what 1997 calls an "intranet" generally feel that NAT makes them more secure
anyway. These people ain't buying the end-to-end arguments, they want their
users to be secure and effective and they don't think Pee Cees can be made so.
If someone replies to me personally on this thread I will answer. I'm done
reading NANOG for a few days, I'll check back when I think this discussion is
dead and gone.
|