> I have one last question. Regardless of whether we agree
> precisely on what "lame" means, what is the call to action when
> a zone or its name servers are declared lame?

"Get your ducks in a row!"

A domain owner is presumably normally interested in name
resolution for names in his/hers domain to be "quick and
consistent".

When a recursive resolver tries to resolve a name and tries to
query a name server which doesn't handle the zone (a "lame
delegation"), this goes against the recursor's expectation, and
it can put the (domain,NS) tuple on a "bad, don't use for a
while", and will have to re-try the query with another of the
NSes in the delegation RRset.  This takes needless extra time.

Some delegating authorities actually refuse to update a
delegation if one of the NSes in the new delegation RRset doesn't
respond for the zone at the time when you request an update of
the delegation.  The .NO registry is among them.  Yes, I think
this is a good idea (and, no, this doesn't prevent deterioration
of this status over time, but at least it was correct and
consistent at the time of delegation update, and can be said to
be a "teaching aid").

> And how is that different from any other form of miscreant auth
> behaviour such as inconsistency?

Inconsistency is orthogonal to "lameness".  If all the NSes in
the union of the parent NS RRset and the child NS RRset serve the
zone, name resolution will not take "extra" time even if an
"extra" NS from the child NS RRset is queried about a name in the
given zone.  It's still inconsistent, though.

> I mean if "lame" is a precious historical term that warrants
> considered clarification, surely it has a very specific value
> that we can all act on, right? So what is that very specific
> value?

As a domain owner, ensure that you have all your delegated-to
name servers properly configured to serve your zone, aka. "get
your ducks in a row!"

Regards,

- HÃ¥vard

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to