[sig-dns]George's #1 (What is lame?)

[Edward Lewis <edlewis@arin.net>]

A while back George wanted to kick start discussions on lameness. 
Off and on there have been private discussions, but evidently nothing 
has made it to this list.  Recently, at the RIPE meeting, George once 
more asked some of us who have spent time on this topic to contribute 
to the list.

What I'm going to write here is based on my experience as someone who 
has worked on DNS, as opposed to being a spokesperson for ARIN.  I'll 
rely on my experience at ARIN, but take what I say as just 
engineering input.

At 8:55 +1000 5/2/03, George Michaelson wrote:
> Firstly, a definition of lameness, which identifies criteria under which APNIC
> specifically (but hopefully any registry with duty of care over a sub-tree of
> the DNS) can apply tests, and for stated tests, if persistently 
> failing, >de-list the domain. I think this is what interests most of 
> the other registries >in this process, and is work which would lead 
> into dnsops WG in IETF.
I'll start by suggesting a definition of lameness - or whatever it is 
we need to define.  I promise that it will be unsatisfactory (;)) so 
I expect a conversation to start on it.

The first appearance of a definition for lameness is in RFC 1612, as 
far as I can tell.  It defines lameness in the sense of a "returning 
a lame delegation," which is significant in that it is stated in a 
protocol point of view.  In this perspective, lameness is the 
incorrectly naming of a child server by a parent server in a referral 
message.  The exact text is:

       "A lame delegation has occured when a parent zone
       delegates authority for a child zone to a server that
       appears not to think that it is authoritative for the
       child zone in question."

Similar definitions also appear in RFC 1713 and 1912.  I've no 
quarrel with the definitions in the RFC's, but recall that they are 
written for a protocol development organization.

In looking at lameness in our context, I am more concerned about 
zones being "unreachable."  An unreachable zone is one whose servers 
are either lame as defined in the RFC's and/or answers from them 
cannot be obtained.  The latter category includes machines that:
 1) are not running a DNS server on port 53 (UDP, TCP or both)
 2) refuse to answer (REFUSED)
 3) have an address for which no route is available to the client
 4) do not have a route to return to the client
 5) do not have an available address for their domain name
 6) simply are not working/existing
 7) are on the other side of some temporary congestion problem (UDP drops)
 8) have some other reason I am forgetting

Case #5 is a bit more involved because it can have subcases - one of 
all the others.  Recall that an NS RDATA is a domain name, not an IP 
address.  Looking up the address can fail for the same reasons that 
the check for lameness can fail.

Note that none of 1-8 meet the definition of lameness in the RFCs.

I don't think we need to overload the term lame, although we have 
been doing so  up to now.  What I'll propose is defining an 
unreachable zone.

An unreachable zone is one from which I cannot get any data. 
Unreachability may be passing or it may be persistent.  E.g., now I'm 
on a plane and have no routes to any servers - the root of DNS is 
unreachable for me.  When I get home it will be reachable.  We need 
to be concerned about persistently unreachable zones.

Reachability is also dependent upon the position of the client 
relative to the servers for the zone in question.  I am hard pressed 
to give names to the kinds of reachability - global reachability is 
what we desire, but there are always pockets of the DNS that will not 
be reachable for performance as well as design reasons.  This needs 
to be developed further.

I suppose that the desire is to identify persistently unreachable 
zones from selected sites in the Internet.  Persistent needs to be 
defined - e.g., no answer to daily queries for 30 days straight. 
Although not all network prefixes are desired to be routed globally, 
if the prefix is delegated in the global DNS, then at least the 
servers should answer.  Perhaps the thing to do is to first encourage 
putting DNS servers that are listed in the DNS out where the Internet 
can get to them and then second to have the testing process specify 
the locations from which the tests are run.

So far I haven't talked about the query.  I probably should save this 
for another message, but I think that all you can ask for is the SOA 
resource record.  Is is the only record guaranteed to be in a zone 
and be only available from the authority.  (The NS set could be 
obtained from the parent.)  The query also ought to be sent with no 
RD and the answer needs to have the AA bit set.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Your office is *not* a reality-based sit-com TV show.