[dns-wg] a historical perspective on DNS lameness

Ed,

On Thu, Oct 8, 2009 at 6:23 PM, Edward Lewis <Ed.Lewis at neustar.biz> wrote:

> 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).
>
>
I would agree with the definition, I'm not sure whether I would 100% agree
with the 'usually because' I think it can be for a number of reasons and I
don't think anybody has looked into this in an detail. Misconfiguration or
communication issues could equally be to blame as 'no configuration'


> 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.
>


Thats quite interesting I had no idea that was the reason behind the ARIN
policy I thought it was for a similar reason to the RIPE one which basically
was a desire to ensure the reverse tree was as clean and functional as
possible.


>
> 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.htmlis the policy definition, I had left ARIN by then and wasn't as aware of
> what was going on then in the RIPE region.
>
>
Indeed I was the author of said document (following input from the RIPE
community of course) I do seem to remember discussing this with you at the
time the policy was going through the WG, but I think it was more related to
what methodology you had used to detect the lameness rather than the reason
for doing it.


> 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.
>
>
I'm not sure I really understand your point here, If an LIR has entered some
data into the DB which it believes to be correct but it (or its friends)
have misconfigured (or not configured) the servers then I would regard the
DB to be clean and that the server's need fixing.
Either way I would regard notification of the problem to the LIR to be a
good thing.


Brett


>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/dns-wg/attachments/20091013/18095e6b/attachment.html>