Some time ago I commited to review draft-ietf-dnsop-inaddr-required.txt so here goes.
First of all I applaud the author's effort and fully support moving this document forward. My opinion is to encourage the use of reverse dns as much as possible. >Abstract > Mapping of addresses to names has been a feature of DNS. Many sites, > implement it, many others don't could be re-worded as 'has been a feature of DNS since the early days' or 'has been a feature of DNS for a significant amount of time' or 'Is a major feature of DNS' the third option would be my preffered one. > address, and address to name mappings are provided for networks. This > practice, while documented, has never been required, though it is > generally encouraged. maybe to be re-worded as "This practice, while documented has never been required within the context of an RFC, although certain technical issues can occur if it is not implemented and hence it is strongly encouraged" > ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger > allocations. For smaller allocations, ARIN can provide > IN-ADDR for /24 and shorter prefixes. [ARIN]. APNIC provides methods > for ISPs to update IN-ADDR, however the present version of its policy > document for IPv4 [APNIC] dropped the IN-ADDR requirements that > were in draft copies of this document. As of this writing, it appears > APNIC has no actual policy on IN-ADDR. RIPE appears to have the > strongest policy in this area [RIPE302] indicating Local Internet > Registries should provide IN-ADDR services, and delegate those as > appropriate when address blocks are delegated. It is probably worth reviewing the information here and updating, for example details for Afrinic should be added. Additionally it may be worth mentioning that in order to encourage the stability of reverse, RIPE require that any /16's must be secondaried on ns.ripe.net. Also maybe worth mentioning that the RIPE region /8's are now being signed and the public keys are available from the RIPE website. > Some anti-spam (anti junk email) systems use IN-ADDR to verify the > presence of a PTR record, or validate the PTR value points back to > the same address. maybe also add: It is fairly common practice for mail relays to reject mail from any ip address which cannot be resolved back to a PTR record this is a major reason to ensure reverse is working for ip addreses allocated to smtp servers, and is a very common problem seen by customers who have reverse dns which is not working. > 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 recommended. In my opinion change to: recommended and strongly encouraged. > Policies should > recommend those receiving delegations to provide IN-ADDR service > and/or delegate to downstream customers. again recommend and strongly encourage. > 7.2 Informative References > [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date > unknown, http://www.arin.net/regserv/initial-isp.html This url no longer exists the current one is http://www.arin.net/policy/nrpm.html#seven1 > [APNIC] "Policies For IPv4 Address Space Management in the Asia > Pacific Region," APNIC-086, 13 January 2003. Extensive info of APNIC's reverse dns policy is detailed here http://www.apnic.net/services/dns_guide.html > [RIPE302] "Policy for Reverse Address Delegation of IPv4 and IPv6 > Address Space in the RIPE NCC Service Region", RIPE-302, April 26, Afrinic's Policy for Reverse Delegation is here http://www.afrinic.net/docs/policies/afpol-re200407-000.htm Hope all that helps get this document moving along. Brett -- Brett Carr Ripe Network Coordination Centre System Engineer -- Operations Group Singel 258 Amsterdam NL http://www.ripe.net +31 627 546046 GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8 . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
