[dns-wg] a historical perspective on DNS lameness

1. RFC 1912 has this definition:

    A lame delegations exists when a nameserver is
    delegated responsibility for providing nameservice for a zone (via NS
    records) but is not performing nameservice for that zone (usually
    because it is not set up as a primary or secondary for the zone).

Note - a remote party can only detect the situation if the server in 
question responds to a query, that is, if:

  the server has no IP address,
  the IP address is unreachable,
  the query drops on the way there,
  the response drops,
  the server simply won't answer,
  or etc.,
the remote party does not have the evidence to conclude lameness.

A common confusion made is that misconfigured delegations are lame, 
but that is not the case.  The distinction will be important later on.

2. There is no specified protocol response to indicate that a server 
is not set up to answer the question, nothing in the RFC's,  You can 
say this is the root cause of the failure - an old, old version of 
BIND decided to return a referral "upwards" (as to the root or maybe 
the TLD) to be kind of helpful.  This kind act turned out to be the 
problem when...

3. An implementation of an iterative resolver was released that 
"believed" the upwards referral and would follow it.  (The 
implementation was widely distributed, legend said it was a MS 
release in about 2000.  But I can't confirm that.)  What this meant 
is that a lot of resolvers would query the root, then a TLD, then a 
SLD and then be referred back to the root and keep on cycling.  That 
was the operational impact that lead to...

4. ARIN policy 2002-1 which told ARIN staff to go off an stamp out 
lame servers.  (This is where I came into the picture.)  The purpose 
was to stop this cycle of activity, but by the time the policy got in 
place the software was patched pretty much out of existence and the 
operational pain lessened.

5. At RIPE 45 I presented 
(http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-dns-testing-lameness/) 
which has some interesting bullets and slides that are still 
pertinent today on the process of dealing with lameness.  When I 
presented this, ARIN had a high lame rate and RIPE a low one, due 
largely to early registration mishaps and the difference in the 
timing of ARIN and RIPE "cutting" a delegation for a new assignment.

6.  At some time RIPE adopted a lame inspection policy.  I don't have 
a personal recollection of this. 
http://www.ripe.net/ripe/docs/ripe-400.html is the policy definition, 
I had left ARIN by then and wasn't as aware of what was going on then 
in the RIPE region.

So - what perspective I am trying to say here is - "lame" per se 
refers to name servers that led software into a loop which is why 
they were a problem for ARIN.  This is why today you probably won't 
measure the impact of "misconfigured" delegations (which is what 
RIPE-400 calls lame) by inspecting traffic.  The question of the 
value of RIPE-400 then turns into being one of database cleanliness.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.