==> are these for real? If they would be serious about these checks, they'd just check the IP address against the RIR allocations and possibly the RIR->LIR allocations, because DNS operators cannot be trusted to deal with this properly. And what of '.com', '.net' or whatever? Those could reside in the restricted areas as well.
why can't dns operators be trusted? what do you base your assertions on?
The example was using DNS lookups for code export controls.
If the code would check, for example, that the reverse records would not point to '.ir' (iran), there is nothing to prevent legitimate IP address space owners from registering e.g. example.com, example.nu, or whatever non-banned domain.
Therefore, reverse(+forward) checking cannot in any way be used to check which geographical area you're from. The IP addresses themselves are the best bet for achieving that.
(Maybe 'DNS operators' was a bad word choice. I wasn't implying that the operators of the critical DNS infrastructures (e.g., root, TLD servers) could not be trusted; they'll have to be, to a certain extent at least. I was referring to whoever controls the particular reverse zone, and the forward zone(s).)
==> maybe it could be further said here that if the hostnames or domains (instead of IP addresses; using hostnames is a good idea) are used in tcp wrappers, the reverse+forward lookups obviously have to exist and match.
host names are registered in the DNS... just like addresses. if you can't trust the DNS operators...
The applications are likely very difficult.
If you'd be checking for example, '.ca', then yes, this would be of very little usefulness.
But you're checking for example, 'host.domain.ca' or 'domain.ca'.
By recommending applications avoid using IN-ADDR as a security mechanism this document points out that this practice, despite its use by many applications, is an ineffective form of security. Applications should use better mechanisms of authentication.
==> this could probably be beefed up better, see e.g. draft-ietf-dnsop-ipv6-dns-issues-10.txt. In particular, IMHO it should be noted that: 1) simple reverse lookup offers no security at all 2) reverse+forward check is not a true form of security, but could be useful combined with other forms of checking
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.
recent audits suggest that the reverse maps are in
better shape than the forward maps ... which is a
change from previous years.
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.
-- 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
