[ppml] Policy Proposal -- Eliminate Lame Server policy

On 9/11/07, Owen DeLong <owen at delong.com> wrote:
> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0
>
> 1.      Policy Proposal Name: Deprecate Lame Server Policy

I oppose the proposed deprecation of NRPM section 7. It is important
for policy to assure ISPs have the responsibility to maintain the IN-ADDR
domain records, and to say when ARIN can maintain records through SWIP,
section 7.1 does this.

Removing section 7.1 may cast some doubt as to who is responsible for what.


I would say it is best that ARIN identify servers that are
entirely lame for an allocation; this is trivial to do, since very few DNS
queries are required of each listed reverse DNS server, at the time it
is added, to
verify it is not lame for the allocation.


If a DNS server is truly lame, then either the DNS server does not exist
any longer -- the WHOIS record is wrong, but that's not too bad.

What's worse is if the lame delegation is pointing to someone else's DNS server
who no longer has an agreement to provide DNS records / further delegations for
the reverse zone.


I oppose expanding the policy just about the same as removing it.


Even in the everyday non-lame situation, the reverse IN-ADDR for the whole
allocation is not necessarily always mapped --  some number of blocks of
addresses allocated to an organization may not actually yet have  been assigned
to hosts or networks.

The ultimate destination for reverse DNS requests might not yet
be online (when addresses haven't been assigned yet, especially if
a subdelegated rDNS server will be in the new network, which is
not yet online), or PTR records may not  yet exist for hosts that do
not yet exist, but will eventually -- the whole PA block being
advertised doesn't necessarily mean that every possible IP
address already corresponds to a subnet that is already live
and has been named.


Eliminating lame servers has little to do with preventing the
possibility of slow lookups (awaiting timeout) and user protocols
relying excessively on  Reverse DNS.

Though it can have positive effects there as well as reducing UDP packets,
and these are good effects.


rDNS is for logging and diagnostic purposes.. any protocol relying on it for
anything else already has to be prepared for the possibility that third-party
untrusted DNS servers are misconfigured.

ARIN delegation is no indication that a DNS server is "trustworthy,"
"fast," or "stable".

Forward DNS servers are often slow, lame, or unresponsive too, and some
protocols will take the result of the "reverse DNS map" and attempt a forward
lookup.

Slow reverse lookups, non-existent reverse mappings happen all the time, are
a fact of life, and have to be anticipated, by any robust service --
the responsiveness of third-party DNS servers is not to be trusted.


Slow lookups already often occur, if for some reason   rDNS servers run slowly,
or all of a large ISP's reverse DNS servers happen to be down simultaneously;
this may degrade performance of certain protocols, but robust protocols should
be sufficiently independent of DNS to continue to function.

An outage or slow responsiveness from a DNS server can happen without a
lame delegation situation actually existing.


ARIN's mission isn't to fix slow lookups, or fix problems in the design of
protocols, it's to be a good steward of addresses  -- The delegation of the
request is also  the delegation of the responsibility for the request, once
the delegation is made, the ISPs are responsible for the quality of the
actual data and the responsiveness of their servers.


But I feel it actually is ARIN's responsibility to do their part to
fix the situation,
if the delegation  is being made to third-party hosts that do not consent
to serve DNS for that allocation, good stewardship of the address space, would
dictate wiping out the bogus records on ARIN's rDNS servers.


As for slow lookups, ISPs not fleshing out a full reverse zone, there
are ways  other than ARIN policy to deal with it: like making
a note to the points of contact requesting their attention.


Reverse lookups can generally be turned off on the server side,
especially for Telnet/SSH.


Failing that, caching/manually entering the fact that no response was
received, use of
local /etc/hosts, etc, or blocking access to service from ranges of IPs without
proper reverse, are possibilities.

These last two are of course, suboptimal compared to ISP fixing their
rDNS services.

--
-J