[ppml] Policy Proposal -- Eliminate Lame Server policy

[Michael Sinatra]

Owen DeLong wrote:

> 8.	Rationale:
> 		Recent PPML discussion has called attention to the
> 		fact that lame DNS delegations are more an operational
> 		issue than one of policy.  As such, the existing lame
> 		delegation policy should be removed from the NRPM
> 		to remove the resultant confusion.  This is not meant
> 		to prevent ARIN staff from taking reasonable action
> 		WRT DNS operational issues related to resources issued
> 		by ARIN, but, such action can be covered by staff
> 		operational guidelines and is not within the scope
> 		of Address Policy.

There are actually three issues in this discussion:

1. in-addr.arpa zones that are not populated with PTR records that match 
A records in forward zones.  There seems to be consensus that this is 
not under ARIN's purview.  As has already been pointed out is NOT the 
issue that the OP raised.

2. in-addr.arpa zones with lame delegations.  I define "lame delegation" 
here as a server that returns SERVFAIL, upward referral, REFUSED, or 
simply times out for queries in a particular zone.  The OP appeared to 
be concerned about the delays involved in the time-out issue, but as I 
mention below, there is a difference in my mind as to whether the lame 
delegation comes directly from ARIN or is the result of a further 
(re-)delegation within the ISP's DNS configuration.

2a. A subset of the lame delegation is what RFC 1912 states is "an even 
worse form of lame delegation," which is listing someone else's 
nameserver without their permission because a) that was the example in 
the book; b) you needed two nameservers and heck, this one seems to work 
for some other zone, and you really don't have time to contact the owner 
of that DNS server and set up the zone, but they won't mind; or c) some 
other reason too baroque for anyone clueful to even understand.

I had a case of 2a that went on for years, where a major financial 
services company selected ns{1,2}.berkeley.edu as in-addr.arpa 
nameservers for the /16 it had.  We had no relationship with this 
company and had never agreed to provide nameservice for their /16's 
in-addr.arpa.  But it was our nameservers that received the traffic, our 
logs that had numerous entries in it for the lame zone, and in some 
cases, *we* had to answer complaints that our name server were lame for 
this zone.

I contacted the POC for the /16.  No answer.  Contacted again.  No 
answer.  I contacted the ARIN hostmaster.  They told me to contact the 
POC.  I told them I had.  Contacted the POC and the ARIN hostmaster. 
This actually went on for years until, after the lame server policy was 
passed, I escalated the issue to someone fairly high in the organization 
and our records were removed from the /16 that wasn't ours and for which 
we had not agreed to provide in-addr.arpa service.

It occurred to me that before the lame delegation policy, there was 
really no way for the ARIN hostmaster to know what to do in a situation 
like 2a.  I am not sure how they dealt with it in the past, but I 
certainly had a hard time getting anything to happen until such a time 
as there was a guideline to deal with it.

In general, I do not think there is consensus in the PPML thread that 2 
and 2a are not within ARIN's purview, where the delegations come 
directly from ARIN.  As operators of the parent DNS zone in which this 
lame delegation was made, ARIN did have a role to play when the POC 
refused to respond to repeated requests over a period of years.

I think the policy regarding lame delegations that are made directly 
from ARIN (in whois and in the zones served by the ARIN.NET nameservers) 
is appropriate.  If people who receive delegations from ARIN either a) 
do not populate their zones with PTR records; or b) re-delegate within 
their zones (say a /16 with delegated zones representing /24-sized 
blocks) and some of those re-delegations are lame, then I agree that 
this is not under ARIN's purview.  (It is not clear to me from the OP 
whether the lame delegation comes from ARIN or whether it is a lame 
re-delegation from the ISP's nameservers, but it sounds like the 
latter.)  Since the policy only covers the former case, I do not believe 
it needs to be deprecated.

Moreover, as my experience shows, I believe that the policy needs to be 
explicitly stated in order to convince POCs that they need to take 
action, and to provide a written rationale, procedure, and escalation 
path where situations like 2a exist.  Staff operational guidelines would 
work, if they were appropriately publicized, but this did not appear to 
be the case before the lame delegation policy was in place.

I also have a hard time thinking about how an expanded policy would 
actually be within ARIN's purview, but without seeing such a policy, I 
can't really comment much more on that.

michael