On 5/4/18, 05:59, "DNSOP on behalf of Shane Kerr" <[email protected] on
behalf of [email protected]> 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.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
