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 188.8.131.52 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.