Mr Hunt!
On Mon, Apr 10, 2023 at 21:09, Evan Hunt <e...@isc.org> wrote:
> On Mon, Apr 10, 2023 at 02:35:36PM +0000, Joe Abley wrote:
>> I continue to think that if you don't get a response, you can't tell
>> whether the delegation is lame. Lameness (as I use the term) relates the
>> configuration of the nameserver, not it's availability.
>>
>> So I prefer Duane's formulation to yours, precisely for the reason you
>> gave.
>
> I understand the distinction you're making, but (serving in my occasional
> role as asker-of-the-dumb-question), does this distinction matter very
> much? Do we treat delegations differently if they're Properly Lame™ vs
> merely unusable, and thus need different words for each category?
I think there are different failure modes being mentioned that have different
operational consequences (e.g. identified differently, different causes,
different fixes). I think such differences in observation, cause and effect are
useful to describe using different phrases.
One nameserver in the delegation set of a particular child zone might provide
non-authoritative responses. By my usage, that nameserver is lame for that
zone. The delegation of that zone to that nameserver is a lame delegation.
Identified when receiving a response with aa = 0 when aa = 1 was expected.
Possible causes: wrong nameserver in the delegation set, incorrect
configuration of the nameserver.
One nameserver in the delegation set might not exist (its name doesn't exist,
or there are no A or AAAA records associated with it). Identified when
resolution of the nameserver name fails (NXDOMAIN or NODATA for QTYPE=A, AAAA.
Possible causes: wrong nameserver in the delegation set, or hosting of some
superordinate zone for the nameserver's name is broken.
(All nameservers in the delegation set might be lame, by my understanding of
the term. Mats thinks this is the necessary condition to use the term "lame",
if I am understanding him correctly. I think Mats' meaning is less useful,
since it's often the case that not all nameservers are lame, by my usage, and
in those cases there is still something to describe and fix. I am sympathetic
to the idea that "delegation" should refer to a collective of nameservers, a
whole NS set, but I think it's actually useful for it to mean that *and also* a
single nameserver in a set, depending on context.)
One nameserver in the delegation set might not respond. Identified when you get
a timeout after sending a query. Possible causes: any number of routing issues,
RRL limits tripped, misconfigured firewall, using a transport that isn't
supported, query source administratively blocked for some other reason,
nameserver recently renumbered but persisting in caches.
I don't see the value in lumping all of these (and other) failure modes under a
single term. That seems actively inconvenient. There is value in being able to
say to someone "nameserver frog.muppetlabs.org is lame for snarkhunter.com" and
have the person listening understand what you mean and where to look next.
To me this is not just a matter of philosophical semantics. Clear speech
matters when you are trying to troubleshoot and fix an active problem.
Joe
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
