>> We welcome the working group's thoughts whether "lame delegation"
>> encompasses these three possibilities.
>
> FYI, when working on the EDE draft [RFC8914] we discussed lame
> delegations some and actually did not document a particular error code
> related to it, as the meaning both uses improperly precise terminology
> ("lame" is not really a useful adjective in this situation) and because
> of the multiple reasons why an authoritative server may not be
> responding, as you indicated.
>
> I was originally thinking of listing the various parts of section 4 in
> RFC8914 that were directly tied to the lame discussion, but I'm not sure
> I'd get it right. So instead I invite you to look at section 4 of
> RFC8914 and see if there is any of the situations that SSAC is concerned
> about that are not covered by one of those codes that are designed to be
> more specific about the actual nature of the problem being observed by a
> recursive resolver.
If I'm not terribly mistaken, EDE is for communicating recursive
lookup or validation errors between a recursor / validator and a
stub resolver, while the various instances of a "lame delegation"
will be something a recursive resolver might experience the
effects of as part of the process of actually doing the recursive
lookup. Not all "lame delegations" will result in ultimate
lookup failure for the original recursive query, but may cause
extra traffic and extra delay in the lookup process.
So it's not immediately obvious to me that the EDE RFC is all
that applicable, save perhaps for a situation where all the
delegated-to name servers are "lame", i.e. none of them provide
publication service for the zone in question.
Regards,
- Håvard
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
