[ppml] Policy Proposal 2005-3: Lame Delegations

Edward Lewis Ed.Lewis at neustar.biz
Thu Apr 14 14:17:01 EDT 2005


At 13:12 -0400 4/14/05, Glenn Wiltse wrote:

>  First off, we are told that lame delegations are a problem, and
>there needs to be action taken to correct it. I'll accept that there
>at least is the potential for overloded servers by just leaving lame
>delegations alone, however I see no data that would indicate exactly
>how big a problem it is.

Back when 2002-1 was derived, this talk was all the rage:

http://www.nanog.org/mtg-0210/wessels.html

In it, only 2% of the load at a root server was considered "legitimate."

The report does not come out and finger lame delegations, but one 
implementation confronted with lame delegations would send repeated 
queries.  Repeated queries have many causes, and totalled 25% of the 
load (10~12x the legit.)

I wish I knew of a reference to the linkage of lame delegations to 
repeated queries.  Does anyone know of one?  (The discussion leading 
to 2002-1 happened before I spent time on ARIN issues.)

>  Next we are asked by the AC to get rid of the current procedures
>for contacting the people responsible for the servers that are suposed
>to be lame. The reason we are asked to remove the details of the
>procedures for contacting these people, is because ARIN staff apparently
>don't have time to do it all. Yet we aren't told what parts of the current
>procedures are taking up all the time. We also have been given no data
>to indicate how much time is currently spent in trying to eradicate
>lame delegations.

Detecting lame delegations and reporting lame delegations are two 
steps in the process.  2002-1 is vague on the first, meaning that 
there is no issue with 2002-1 regarding "how" to test.  (I am 
suggesting that maybe the community does want to look at that.) 
2002-1 is very specific on the reporting step, however, and what 
2002-1 requires is not scaleable.  2005-3 is trying to fix that.

The policy 2005-3 is not removing the procedures for contacting 
folks, just making the procedure a matter for the staff to determine. 
Staff has a better determination of work load and resources.  Telling 
the staff "how" (as 2002-1 does) is micro-management.  Telling staff 
"what" (as 2005-3 does) is a more appropriate specification of a 
"service."

>   For now, lets just consider those two points... We don't know how
>big of a problem lame delegations are in terms of server load and we
>don't know how much time is spent trying to get rid of lame delegations.
>All we know is that ARIN staff apparently is unable to keep up with
>the current methods for getting rid of the lame delegations. For all
>I know, it might be a better use of ARIN resources to beef up the
>servers.

This is an over simplification.  Testing ARIN's delegations is not 
the long-pole in the tent.  Deciding what delegations need to be 
remedied is not the long-pole in the tent.  Informing the registrants 
that they need to fix something is the long-pole in the tent. 
Enforcing the policy by trimming bad delegation information is not 
the long pole.

One problem with informing registrants is - where do you draw the 
line between presenting a diagnosis and prescribing a fix?  Not all 
registrants use BIND, so putting up BIND-specific "steps to fix" is 
unfair to registrants using other implementations.

Once you do decide what to present to registrants, how is not always 
clear.  Contact by e-mail is clear, but it is not guaranteed to work. 
It's supposed to, but not all e-mail addresses are current - evidence 
of that is in 2002-1 which says that the next step is phone and 
postal.

As I mention in another mail, I was once close to this problem.  It 
would be inappropriate for me to go into details because of 
confidentiality rules.  However, the "for all I know" statement you 
give is a reason why I would like to see some input from the staff 
towards these discussions - if just to give us (members) an estimate 
of the costs of the policies, and perhaps where a policy can be 
adjusted to result in a significant savings without a loss of service.

>   So, aside from not having enough information to make a wise choice
>on the above to points...
>
>   I think it's important there be clear statements about the steps
>that will be taken before deleting a lame delegation. I'm no lawyer
>but I would think that there could be some liablity issues involved
>if you simply start removing delegations to the in-addr.arpa space
>without clearly stating the policy and procedures. With the current
>policy, at least there is clear wording that describes how the attempted
>contacts will proceed, and how long ARIN will wait before deleting
>a 'lame' delegation. While eliminating this wording may help ARIN staf,
>it's not clear it helps ARIN customers much.

That is the concern that I believe (speaking as someone not in the 
know as I wasn't involved in the lead up to 2002-1) the original 
policy was so specific on this point.  Still, I think that the staff 
is responsible enough to carry this out - there are other legal 
protections and liability protections in place.  There is also legal 
council available.

>   I also don't like that nether the current or proposed policys would
>be clear as to wether a whole CIDR blocks worth of delegations will
>be droped when there may only be one portion of that block being actualy
>lame...

Well, this is a topic I would like to see discussed in a 
technically-bent arena.  One solution, which causes the least amount 
of liability concerns (see above) is to retain all delegations 
wherein one delegation is healthy.  This could be categorized as 
"getting the low hanging fruit."  Not complete, but better than 
nothing at all.

>   Well I said I was going to sumerise this... I haven't made much
>progress in doing that yet...  but I guess as close as I can get is...
>
>I can not support the "Policy Proposal 2005-3: Lame Delegations" since
>I see numorious flaws with it. I also have virtualy no data that would
>help me make an informed decsion about this proposal.

I sympathize with your plight.  However, given my angle on this, 
2005-3 is a step in the right direction.  If we go no further, we 
will be better off.  If we do decide to form a discussion on this 
topic, I think we can wind up with a technically better pruning of 
the DNS tree.  The question remains if the better pruning would be 
worth the cost.

>
>Glenn
>
>On Thu, 14 Apr 2005, Azinger, Marla wrote:
>
>>  I must say there has been alot of good informative debate on this policy.
>>
>>  However, I hope everyone realizes that the Lame Delegation Policy
>>  "meaning" itself is not what this policy proposal is about.  The only
>>  reason this proposal is in front of the community is to ask permission
>>  to deviate from the strict "notification" guidelines that were included
>>  within the original approved policy.  ARIN staff will continue to carry
>>  out this policy as written...they just need some breathing room to work
>>  the notification process as fit per customer.
>>
>>  This proposal is ONLY a modification to the "notification" part of 
>>the policy.
>>
>>  That said...if anyone should choose to suggest changes to the 
>>actual Policy and its "meaning" then I urge you to bring it up 
>>seperately at the open sessions so that your concerns get heard and 
>>evaluated.  AND so that we do not bog down our proposal to "modify" 
>>the "notification process" within the policy.
>>
>>  Thank you
>>  Marla Azinger
>>  Electric Lightwave
>>
>>  -----Original Message-----
>>  From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of
>>  Edward Lewis
>>  Sent: Wednesday, April 13, 2005 3:49 PM
>>  To: David Conrad
>>  Cc: Paul Vixie; ppml at arin.net
>>  Subject: Re: [ppml] Policy Proposal 2005-3: Lame Delegations
>>
>>
>>  At 12:19 -0700 4/13/05, David Conrad wrote:
>>  >On Apr 13, 2005, at 11:11 AM, Paul Vixie wrote:
>>  >>>  Why?  Why is this nessasary? If someone's got their in-addr.arpa stuff
>>  >>>  broken, it's not really hurting anyone but themselves. Seems like this
>>  >>>  is a waste of ARIN resources to me.
>>  >>  i don't agree.  bad or missing in-addr.arpa or ip6.arpa data 
>>hurts us all.
>>  >
>>  >While I do not necessarily disagree, can you expand on why you 
>>believe lack of
>>  >reverse information hurts us?
>>
>>  I see Paul has answered this, but I think that there's a non-sequiter here.
>>
>>  The lame delegation policy is meant to trim bad referrals from an
>>  ARIN managed name server to a supposedly running server that is not.
>>  The point isn't the worthiness of the reverse map at all - the point
>>  is the health of what is there.
>>
>>  Paul's "bad or missing" - IMHO - refers to data incorrectly stating
>>  that DNS is running on a system and/or "missing" servers, not to the
>>  presence or absence of "name servers on a network block."
>>
>>  Incorrect referrals have induced some DNS implementations to overly
>>  burden the root servers (and others).  Partly to blame is the
>>  convention of a name server, in claiming lameness, is to refer the
>>  requestor back to the root.  Unwary implementations would loop
>>  forever.  Wary implementations that just won't take an intermediate
>>  "no" for an answer keep pounding away too.  Such observations led to
>>  the original lame delegation policy.
>>
>>  As someone who lives and breathes DNS, I can't imagine why a network
>>  operator wouldn't have at least a stub zone for their address range
>>  mostly because it's so trivial to set up and some DNS-using
>>  applications expect there to be something.  But I won't go so far as
>>  to say that the reverse map is mandatory.
>>
>>  --
>>  -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>  Edward Lewis                                                +1-571-434-5468
>>  NeuStar
>>
>>  If you knew what I was thinking, you'd understand what I was saying.
>>
>>  !DSPAM:425e98c0129051373527317!
>>
>>

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.



More information about the ARIN-PPML mailing list