Re: [DNSOP] [Ext] Lameness terminology

[Edward Lewis <[e-mail]>]

On 5/4/18, 05:59, "DNSOP on behalf of Shane Kerr" <[e-mail] on behalf of [e-mail]> wrote:

>    Pending Ed's archival research, it seems like we need to actually do
    some work to structure the concepts around lameness. Digging in...

Quick and dirty, using a directory with "rfc$i.txt" files so far up to 5000 or so:

(BTW, my search is: "grep lame * | grep -e delegation -e server | sort -u -k 1,1"
Yes, perhaps not optimal but quick and easy to run.)

rfc1470.txt - mentions a tool called LAMER to detect lame delegations
rfc1612.txt - a MIB definition tracking lame delegations
rfc1713.txt - first example of a lame delegation (when describing LAMER)
rfc1912.txt - first definition, here it is (with grammatical error):

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

rfc2308.txt - author uses "lame server" instead of delegation (poke at Mark)
rfc2832.txt - back to lame delegation, when talking about RRP the "pre-"EPP
rfc3658.txt - defining the DS and uses the term lame nameserver
rfc4074.txt - lame delegation in the context of IPv6
rfc4697.txt - lame or lame server is used

From this quick and dirty pass, my comments:

The concept is uniform - the situation is that the server of interest is not configured to host the zone.  I.e., this is a per-nameserver concept but not a per-cutpoint concept.

The precise term for lame "delegation|server|name server" seems to have never been cemented, although lame delegation seems most common.  Grammatically I'd choose (if I had a vote) for "A lame delegation occurs when a name server is named by a parent to be authoritative for a zone despite the name server not being configured to be authoritative for the zone.  If a name server receives a query for a domain (as opposed to zone!) for which it is not configured, the response is (Blank)."  The latter part of that would be important when writing interoperable code. ;)

I say Blank because there is no universally used response in this situation and I'm not going to promote any solution here.

FWIW, if one is to cite a definition of lame, I'd use "Common DNS Operational and Configuration Errors", February 1996, aka RFC 1912.