On Mon, 25 Oct 2004, Daniel Senie wrote: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.
Some rewording has been undertaken to address these concerns.
.........
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 comments are mostly out of scope. While certainly there are other mechanisms some sites use, and while on the surface they might seem better, they are unrelated to INADDR. There are commercial enterprises which attempt to sell services claiming to provide a country code in response to a lookup of an IP address. These of course fail to provide proper information for tunnelled networks, new allocations, and the like. The text suggests web sites should avoid use of the PTR record data for such lookups, and that remains valid.
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 systems have more than one host name with A records pointing at a single IP address. The PTR record will match at most one of them. reverse+forward lookups are NOT, in my opinion, a valid security mechanism. At most you can tell someone has access to both the forward and reverse DNS zones. I adjusted the text a little bit, but not to encourage the use of reverse+forward as a security measure.
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.
It would depend on the application, and how important the data is. The document is saying the data in the reverse mapping is not sufficient for security. That's the point.
For web statistics gathering, the question is whether there's sufficient harm done by someone spoofing the data. That's a matter for the person implementing the statistics gathering and those consuming the data. I can say that for sites we host for companies, the issue is not important, and that the additional costs to try and do something more detailed are not worthwhile. For some applications, that may not be sufficient. Your mileage may vary. I don't think it's something that needs more text in the document.
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.
I stand by the text. If you need security, then do something that's secure. Verifying access to both forward and reverse zones is not security.
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
reverse+forward checks is NOT security. You're verifying that someone has access to zone files, nothing more. So if the DNS servers (forward and reverse) for a CIDR block are within that block, and the block is hijacked (this is happening), then the hijacker can make you believe he's who you think he is, and all the DNS checks for reverse+forward verify it. Use a security mechanism if you want security. I don't agree there's any place for advocating reverse+forward in this document.
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.
I gave up on xml2rfc after wasting much time trying to get it to work on my systems. It seemed to make no sense to spend more time on it for a document I'm trying to put to bed. I fixed the indent issues in about 2 minutes in NROFF.
==> a placeholder IANA considerations section needs to be added, saying that there are no IANA considerations.
done.
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.
I disagree. As for covering v6, I adjusted the introductory text a bit more that covers this issue. The document uses IPv4 terminology, and the reader can and should apply it to IPv6 by understanding the issue.
The assignment of blocks of IP Address space was delegated to three
==> s/Address/address/
done.
4. Requirements
==> rename to 'Requirements and Recommendations' or just Recommendations.
done.
. dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
