> ==> 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?
> ==> 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...
> Applications SHOULD NOT rely on IN-ADDR for proper operation. The use of
> IN-ADDR, sometimes in conjunction with a lookup of the name resulting
> from the PTR record provides no real security, can lead to erroneous
> results and generally just increases load on DNS servers. Further, in
> cases where address block holders fail to properly configure IN-ADDR,
> users of those blocks are penalized.
Daniel - you should also state that applications SHOULD NOT rely
on HOSTNAME registration in the DNS for proper operation.
> 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.
recent audits suggest that the reverse maps are in
better shape than the forward maps ... which is a
change from previous years.
> The assignment of blocks of IP Address space was delegated to three
four, and soon to be five
> Pekka Savola
--bill
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
