Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

Edward Lewis <> Wed, 02 May 2018 19:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2101812DA17 for <>; Wed, 2 May 2018 12:48:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qpqxf2j1Q782 for <>; Wed, 2 May 2018 12:48:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 78242126CC7 for <>; Wed, 2 May 2018 12:48:00 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 2 May 2018 12:47:58 -0700
Received: from ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1178.000; Wed, 2 May 2018 12:47:58 -0700
From: Edward Lewis <>
To: Shane Kerr <>, "" <>
Thread-Topic: [Ext] [DNSOP] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)
Thread-Index: AQHT2w6qGcOXLkk9v0OKTJ97EusDV6QdGRyA
Date: Wed, 2 May 2018 19:47:57 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/10.a.0.180210
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 May 2018 19:48:02 -0000

On 4/23/18, 10:23, "DNSOP on behalf of Shane Kerr" < on behalf of> wrote:

>    I don't know if this is documented anywhere so that it can be
>    referenced properly, sorry. I am happy to discuss further but I think
>    this basically covers all I know. I don't mind proposing text, but
>    probably someone (Ed maybe?) would be a better person.

I've been looking for something I recall writing a long time ago, but haven't found it.  I'm not the authority on lameness (insert self-deprecating joke here), the term has been repeatedly defined in a number of documents.  What I wrote was a survey of them, including the citations, but I haven't been able to find it.  Not on the web, that is.

The reason I bother with this was, when I was tasked with the work in 2002 or 2003, I was genuinely surprised at the definition of "lame" delegation.  I was surprised that it did not include non-responsive servers - the term referred to responding servers only.

If I can't find the text soon, I'll try to recreate the list of references at least.

(Only if you like reading history:)

The reason was a flaw in "certain old resolvers" that followed the "upwards referral" to the root that the "predominate server code of the time" had decided to use for lameness.  The result was a lot of resolver stuck in an infinite loop, hitting the root servers.  I.e., this was an operational issue.  The solution was updating and redeploying the buggy code, not stamping out lame servers (which was the goal of the task).  FWIW, the "upwards referrals" were discontinued when it became apparent they were being used in noticeable amplification attacks.