This is probably the last message from me on this particular subject..
On Sat, 30 Oct 2004 [EMAIL PROTECTED] wrote:
simple forward lookup offers no security at all. reverse+forward checking is better than nothing.
Only DNSSEC can help with 'simple forward lookup', and its out of scope here.
DNSSEC is forward/reverse agnostic. what seems to be missing here is the underlaying assertion that only one mapping is useful,
Certainly. Let me try to be more verbose, because I didn't bother to write this out at more length first.
'Simple forward lookup' seems to be only useful for "service discovery", i.e., finding the address of service X.
There are two main threats one could imagine here:
1) the requestor thinks the service X is at address A, while the correct address is at B. I.e., someone is doing DNS spoofing, or some other tricks like that. DNSSEC fixes that particular problem, by giving the requestor means to assure of the results of the lookup.
2) that the legitimate owner of the service X is maliciously pointing it to another address, rather than the real service, causing some kind of unwanted DoS attack on the victim. Doing reverse lookup after the forward lookup could mitigate this risk, (with DNSSEC for both if you wanted to be extra careful).
But as I said, I don't think 2) is a real risk, so if you're doing just a forward lookup, for service discovery, DNSSEC seems to be sufficient to fix your problems.
trusting a node who claims to be, say icbm-launch-control.dod.mil. might be reasonable if the IP address was in the range 215.0.0.0/8 while it would be more suspect if mapped to 66.198.41.0/24
yes, this does bring up whole other issues re routing and route hijacking - but the point is that it is a simple and useful check to check -BOTH- forward and reverse maps. Checking just one is not in anyway a reasonable security check.
I don't disagree with what you're saying, if it's in the context of verifying where the connection attempt (or similar is coming from). For the purposes of a simple forward lookup, this is also true in a sense, but I don't think it's worth out while, due to 2) above.
From the intended "security" perspective, the reverses must be checkedfrom the forward tree (due do who controls the data), while forwards would only need to checked from the reverse tree if you'd believe the forward tree would be used for e.g. DoS misdirection attacks. And as you can do DoS attacks already, this shouldn't be a concern.
who controls what data? the end system gets to assert a name regardless of what is in the forward tree. for packets to flow, the node must be anchored in the topology and that requires some ISP hand it an IP address.
If the owner of 1.1.1.1 said he's "president.whitehouse.gov", you probably would not believe him, unless you checked 'president.whitehouse.gov'. That's because you only "trust" those who control the IP topology to be able to say anything about the domains that they can prove (at least weakly) to be under their control.
(On the other hand, if you wanted to find where 'president.whitehouse.gov' is, and the result would be 1.1.1.1, you'd likely believe that, regardless of looking up the record for 1.1.1.1.)
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
