On 4 May 2018 at 05:59, Shane Kerr <sh...@time-travellers.org> wrote:
> > > Within a given NS RRset for a zone, we have a few failure modes: > > A. One or more NS do not resolve > B. NS RR points to a CNAME (technically disallowed, right?) > C. NS RR does not point to any A or AAAA that resolve > D. An A or AAAA RR is for one or more addresses that are not > authoritative > > Case C might not strictly be lame, if for example it points to a .ONION > address or similar. > > Case D might be usefully split into addresses that reply and those that > timeout. > That seems complete to me. > I think that there may be something useful in creating a term when a > delegation only points to lame servers, thus cannot be resolved at all. > Perhaps "broken delegation"? 😉 > The way this has always worked in my head is that a zone can be delegated to one or more lame servers. If the zone is delegated entirely to lame servers, then the delegation is lame. But I take your point that perhaps that is too much overloading of the term 'lame'. > > > There are also a few related issues coming from mismatches at parent & > child. > > 1. "Lame hint" might describe an NS that is above the zone cut, and > points to one or more lame servers > The NS set above the zone cut comprises the delegation, doesn't it? That's not just a hint. > 2. "Authoritatively lame" might describe an NS that is below the zone > cut > 3. "Totally lame, man" might describe a lame NS that is in both > > We can also have: > > 4. "Confusingly lame" which might describe when there is a mismatch > between NS answers of authoritative servers, some of which point to > lame servers 😆 > Now I don't feel so bad about using 'lame server' and 'lame delegation' to mean not-entirely-overlapping things. :) > > > I hesitate to suggest it, but is there value in a draft around lameness? > > There's value in describing common misconfigurations and how to detect/name/avoid them. Does it need to just be a draft about lameness?
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
