Subject: [dnsop] Review of draft-ietf-dnsop-inaddr-required.txt

From: Brett Carr <[email-masked]>
Date: Tue, 24 Jan 2006 22:52:04 +0100 (CET)

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