On 03Apr23, Wessels, Duane apparently wrote: > Naturally, we turned to RFC 8499, DNS Terminology, but found the entry not > particularly helpful
Having recently been involved in writing a tool to check delegations and report errors in a "call to action" way for generalist admins, I agree that the terminology for the various errors that can occur is rather lacking and the use of "lame" to cover a multitude of sins is perhaps, erum, lame itself. The term is certainly unhelpful in the sense that all it can convey with any certainty is that "something is wrong" without any guidance as to where to start looking to correct matters. > There are three possible situations in which this might be considered a lame > delegation: (4) What if NS.EXAMPLE.ORG does respond to EXAMPLE.NET queries but claims that the correct name server is NS.EXAMPLE.COM? Does that make the delegation NS "lame" since resolvers will generally ignore NS.EXAMPLE.ORG henceforth for resolution of EXAMPLE.NET? (5) Same thing as above excepting with in-domain name servers. If NET. says the name server for EXAMPLE.NET is NS1.EXAMPLE.NET, but when you query NS1.EXAMPLE.NET it says NS2.EXAMPLE.NET is authoritative. (6) The delegation and auth agree on the NS name, but disagree on the IP addresses. Does that make the IP addresses supplied as glue "lame"? (7) Is there a differentiation between a "lame" delegation which makes resolution impossible vs. one which makes it more difficult vs. one which risks inconsistent answers? I mostly ended up with the catchall "inconsistent" with the only benefit above and beyond "lame" being that it has a plain meaning understood by generalist admins. Mark. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop