[ppml] Comments on ARIN's reverse DNS mapping policy

John Von Essen john at quonix.net
Tue Sep 11 10:34:49 EDT 2007

Wrong, wrong, wrong.

I appreciate the comments, but I think some people still are  
misunderstanding the issues.

Let me clarify, my post has nothing to do with Org's reversing IPs  
with valid PTRs. If an Org doesn't want to reverse an an IP thats  
fine, and like Owen said, with no PTR, and instantaneous NX Domain  
error comes back, no timeout.

But that is not that scenario I am describing. Consider the following  
real-world example:

# nslookup
** server can't find NXDOMAIN

Thats good. The AS who advertises has the  
239.72.208.in-addr.arpa zone configured in their name server, an SOA  
an NS record exists, but there is no PTR data. And that is perfectly  

Now consider this...

# nslookup
;; connection timed out; no servers could be reached

And the above took about 20 seconds to return. The AS who advertises (and many other /24's) does not have the  
192.161.76.in-addr.arpa zone configured at all on their DNS server.  
This is a problem for the user of that IP, and any person on the  
internet that has to talk to that IP since it will create a  
burdensome dns timeouts.

I'm sorry, but that second example is simply unacceptable. This may  
sound rude, but the amount of money ARIN brings in for ASN  
registrations, membership, and IP range allocations - the buck has to  
stop with ARIN when it comes to AS's who completely misconfigure  
massive in-addr.arpa zones and potentially create the environment to  
slow down dns traffic throughout the internet.

When ARIN delegates reverse authority to the DNS servers of an AS  
that does not have in-addr.arpa zone configured at all (for IP's in  
use), ARIN is openly supporting a practice that hurts the internet by  
allowing these dns timeouts to propagate. ARIN should take  

All I am saying is simply state in policy, that if an AS advertises a  
prefix and uses an IP range, that in-addr.arpa zone for those IPs has  
to be at least be configured to return an SOA and avoid this problem  
of timeouts. If they dont, that AS is violating policy, and if they  
dont resolve it, the dns delegation would be removed all together -  
with a specified time table (say within 30 days).


On Sep 11, 2007, at 8:34 AM, Owen DeLong wrote:

> Also, such a server should _NOT_ cause delays.  It should  
> instantaneously
> return an NXDOMAIN result.
> Your issue isn't lame servers.  Your issue is servers with  
> incomplete data,
> which is an operational issue well outside of the scope of Address  
> Assignment
> policy.

John Von Essen
(800) 248-1736 ext 100
john at quonix.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070911/0b770766/attachment.html>

More information about the ARIN-PPML mailing list