Well, I had put 5PM today in my calendar as the cutoff, and got the submission for draft-ietf-dnsop-inaddr-required in at about 10AM :(
The version I was trying to submit is viewable online at:
http://www.senie.com/dan/draft-ietf-dnsop-inaddr-required.txt
I guess folks can read this and discuss at the meeting, and I'll push this version into the process once the queue opens up again.
Comments below. In short, I think there are still a couple of too strong requirements which should have been removed, but I think a document like this will be useful.
Details below.
...
The Domain Name Service has provision for providing mapping of IP addresses to host names. It is common practice to ensure both name to address, and address to name mappings are provided for networks. This practice, while documented, has never been documented as a requirement placed upon those who control address blocks. This document fills this gap.
==> 'requirement' ? This should have been updated... The same here and further along in the section:
4.1 Delegation Recommendations
Regional Registries and any Local Registries to whom they delegate should establish and convey a policy to those to whom they delegate blocks that IN-ADDR mappings are required. Policies should require those receiving delegations to provide IN-ADDR service and/or delegate to downstream customers.
.........
Web sites are in some cases using IN-ADDR checks to verify whether the client is located within a certain geopolitical entity. This is being employed for downloads of crypto software, for example, where export of that software is prohibited to some locales.
==> 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.
The popular TCP Wrappers program found on most Unix and Linux systems has options to enforce IN-ADDR checks and to reject any client that does not resolve.
==> 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.
Many web servers look up the IN-ADDR of visitors to be used in log analysis. This adds to the server load, but in the case of IN-ADDR unavailability, it can lead to delayed responses for users.
==> do the web servers also perform the forward mapping? Note that most *external* log analysers only do the reverse mapping.
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.
==> you'll need to be careful to be specific when you are talking about reverse+forward checking, or just reverse lookup. This was brought up in IESG evaluation by Thomas Narten on draft-ietf-dnsop-ipv6-dns-issues-10.txt, so you might want to check how I resolved that particular terminology issue.
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
editorial ---------
==> some sections are indented, some others are not. I'd suggest converting to using a good tool such as xml2rfc to get this right. Proper indenting helps a lot for readability.
==> a placeholder IANA considerations section needs to be added, saying that there are no IANA considerations.
Encouraging the use of DNS IN-ADDR Mapping
==> s/IN-ADDR/Reverse/ (because this covers v6 as well) There are also numerous similar occurrences throughout the document, and these should be likewise replaced.
The assignment of blocks of IP Address space was delegated to three
==> s/Address/address/
4. Requirements
==> rename to 'Requirements and Recommendations' or just Recommendations.
-- 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
