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
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
