On Apr 4, 2023, at 11:49, Jared Mauch <ja...@puck.nether.net> wrote:
> On Apr 3, 2023, at 4:50 PM, John Kristoff <j...@dataplane.org> wrote: > >> Interesting dilemmas. I'm not sure there are obvious answers. Perhaps >> lame delegation is the general concept, but specific failure modes need >> better characterization? > > I suspect you could declare a definition such as > > If queryall(authorities(QNAME)).aa != 1: > Lame = True > Else: > Lame = False > > Perhaps with the referral/loop detection logic also embedded. Seems pretty > clear to me, but that’s just my historical thoughts and view. I think it's pretty common to talk about one nameserver for a zone being lame and another nameserver for the same zone not. Certainly that's not an uncommon configuration to find in the wild. I have always used "lame delegation" to refer to the situation where one nameserver in a delegation NS set (above the zone cut) not responding authoritatively for the QNAME that triggered the referral; that particular nameserver is lame for that particular zone. I think the response component is important since it speaks to how a nameserver is configured, which is important. A nameserver that does not respond might be lame or it might not be; you can't tell. It's kind of fun that there are so many ways that people think of this term when, in my experience, people generally agree enough when they are actually trying to debug something for the term to be useful. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
