[ppml] Policy Proposal 2005-3: Lame Delegations
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...
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
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