[ppml] Policy Proposal 2005-3: Lame Delegations

[Edward Lewis]

At 0:04 -0800 3/20/05, Owen DeLong wrote:
>>  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?"
>[snip]
>
>If the server to which ARIN delegates answers with either referrals for
>more specifics (2317 or /24 from /16, etc.) or Zone Data (SOA, PTR, etc.),
>then, that server is not LAME.  Servers to which that server delegates are
>not and should not be part of what is considered in this proposal.  The
>entity running the delegating server should develop and implement their
>own policy towards their downstreams.  Hopefully this would be consistent
>with BCP and standards.

There's a misunderstanding here.  To try to clear this up, I'll use a 
fictional example.

Let's say I, an ISP, am allocated 365.29.0.0-365.29.31.255, which is 
equivalent to 365.29.0/19, and I register "ns0.example". as my name 
server for this range.  (I'm using one name server to keep the 
example simple.)

ARIN's 365.in-addr.arpa zone will then that the following records for me:
    0.29.365.in-addr.arpa.  NS  ns0.example.
    1.29.365.in-addr.arpa.  NS  ns0.example.
    2.29.365.in-addr.arpa.  NS  ns0.example.
    ...
    31.29.365.in-addr.arpa. NS  ns0.example.

The question is: What happens if, after a few months, I've 
"reassigned-simple" the first 10 "/24's" worth of space and set up 
reverse for them, but haven't set up reverse for the the remaining 
zones?

I.e., [0,1,2,3,4,5,6,7,8,9].29.365.in-addr.arpa are configured and 
running on ns0.example.  The zones from [10..31.29.365].in-addr.arpa 
are not configured.

(The proper action is to set up all 32 zones, even though there are 
no entries in the "unused" zones.)

The question I posed has nothing to do with any delegation record not 
published by ARIN.  If my ISP had a /16, there would be just one NS 
record to my server.  I think it would be out of bounds for ARIN to 
test whether referrals issued by my machine referenced lame servers.

>[summary:]
>Question of Purpose:
>	o	Global DNS Protect
>	o	WHOIS Cleanup
>[snip]
>
>I do not see this proposal as targeted specifically at either of these
>concerns, and, I don't see them as mutually exclusive.  I would like  to
>see this as a start towards both issues.  I think that leaving the NS
>information in WHOIS with a "LAME" marker on it, and, removing it from
>the DNS is the ideal solution if contact and resolution cannot be achieved.

I think this proposal ought to be targeted at something, it makes a 
difference when trying to engineers a solution.  ARIN staff is to be 
given the latitude in making implementation decisions, but the 
membership ought to given the staff an indication of "what to 
optimize for."

I agree with you that leaving lame servers marked as such in WhoIs. 
But look at my example above.  What happens if I get an answer for

    dig -x 365.29.4.138

and a lame response (which looks like a referral "up" the DNS tree) for

    dig -x 365.29.14.138?

Is this server marked a lame in WhoIs or not?

>Again, I do not think that ARIN should take any action in regards to
>data or DNS entries which are not delgated by ARIN (e.g. LAME SWIPs
>should not be modified by ARIN, although it would be good if ARIN
>contacted the upstream supplying the SWIP under the first part of
>this policy).

That's a good bounding for the policy.  On the one hand, such 
lameness is also a problem and ARIN has the data to test for it, on 
the other hand, this would be unmanageable.  Maybe in the future, but 
definitely not now.  And maybe not even in the future.

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

Achieving total enlightenment has taught me that ignorance is bliss.