[ppml] Policy Proposal 2005-3: Lame Delegations

Edward Lewis Ed.Lewis at neustar.biz
Sat Mar 19 11:40:22 EST 2005

At 8:19 -0800 3/18/05, Randy Bush wrote:
>>  ARIN will actively identify lame DNS name server(s) for reverse address
>>  delegations associated with address blocks allocated, assigned or
>>  administered by ARIN. Upon identification of a lame delegation, ARIN
>>  shall attempt to contact the POC for that resource and resolve the
>>  issue. If, following due diligence, ARIN is unable to resolve the lame
>>  delegation, ARIN will update the WHOIS database records resulting in the
>>  removal of lame servers.
>   o if no servers remain, the delegation is removed?
>   o and if only one server remains?

Following along this path...

What if:
    o if a server for one zone out of "many" for an address range is lame
      but the rest are okay, is the one zone "delisted?"

Is the goal of this to protect the global DNS via the removal of bad 
references or is the goal to enact a clean up of the ARIN database? 
This distinction determines the gravity of the proposal.

If the goal is to protect the global DNS, then:

Finding a lame server for a zone leads to the removal of the server 
from the DNS.  This doesn't change the WhoIs entry, nor what is in 
the ARIN database.  I could imagine the implementation of this as a 
"filter" on zone file production, i.e., lame NS records are simply 
dropped from the files before hitting the DNS.  (Said for 
imagination's sake only.)

If the goal is to enact a clean up of the ARIN database, then:

Finding a lame server for a zone would put the registrant on notice 
that if registration creating the resource record leading to the 
lameness is not corrected, the registration will be "fixed" by ARIN. 
If so, then this like cleaning contact information, etc.

Does the policy cover legacy space that is now registered in ARIN?

IMHO, I'd assume that the purpose of this proposal is to protect the 
global DNS.  If that is the case, I'm more comfortable with a 
shorter-term contact period and automated deletion and replacement of 
delegation records.

There is an issue with DNS servers that don't answer.  One accepted 
remedy to the trouble of testing these is repeated and distributed 
testing.  Repeating tests is simple, distributed tests is a pain.  I 
mention this because of the requirement of a 90 day implementation.

If we want to go after non-responsive servers as lame, which I think 
is part of the goal of protecting the global DNS, 90 days is too 
short of a time period to include sufficient testing.  Prior to 
moving to production, it would be good for a test to be run for a 
realistic duration - which IMHO is a month.

Edward Lewis                                                +1-571-434-5468

Achieving total enlightenment has taught me that ignorance is bliss.

More information about the ARIN-PPML mailing list