(Incorporating but not quoting various other responses in this thread, implicitly, based on the dates they were sent.)
On Mon, Apr 3, 2023 at 1:02 PM Wessels, Duane <dwessels= 40verisign....@dmarc.ietf.org> wrote: > Dear DNSOP, > > I am participating in an SSAC work party where we are writing about DNS > delegations where a delegated name server might be available for > registration, allowing an attacker to participate in the resolution for the > domain. During report drafting we considered using the term "lame > delegation" to describe this and a broader class of delegation problems. > > Naturally, we turned to RFC 8499, DNS Terminology, but found the entry not > particularly helpful since it simply quotes previous, imprecise uses of the > term: > > Lame delegation: "A lame delegations exists [sic] when a nameserver > is delegated responsibility for providing nameservice for a zone > (via NS records) but is not performing nameservice for that zone > (usually because it is not set up as a primary or secondary for > the zone)." (Quoted from [RFC1912], Section 2.8) Another > definition is that a lame delegation "...happens when a name > server is listed in the NS records for some domain and in fact it > is not a server for that domain. Queries are thus sent to the > wrong servers, who don't know nothing [sic] (at least not as > expected) about the queried domain. Furthermore, sometimes these > hosts (if they exist!) don't even run name servers." (Quoted from > [RFC1713], Section 2.3) > > The first appears to assume that the name server exists, while the latter > parenthetically notes the name server might not exist, but without any > specific meaning of existence. We are wondering if the idea of a lame > delegation should be interpreted broadly, or more narrowly to include only > cases where a response is proof of lameness. Consider a delegation of the > domain EXAMPLE.NET to name server NS.EXAMPLE.ORG. There are three > possible situations in which this might be considered a lame delegation: > > (1) NS.EXAMPLE.ORG resolves to an IP address. Queries to the IP address > result in a REFUSED, SERVFAIL, upward referral, or some other indication > the name server is not configured to serve the zone. > > (2) NS.EXAMPLE.ORG resolves to an IP address. Queries to the IP address > do not elicit a response (e.g., timeout). > > (3) NS.EXAMPLE.ORG does not resolve to an IP address, so there is nowhere > to send a query. > > We welcome the working group's thoughts whether "lame delegation" > encompasses these three possibilities. > There is one important situation which may or may not fit within any current definition, or which might need its own term: - Totally Lame This is the situation when all of the delegations from the parent are made to servers which collectively are not authoritative for the domain. This is something that unfortunately occurs more frequently than one would hope. (An absurd fraction, 15%, of traffic we see falls into this category.) The responses we send to these queries are "Refused", with EDE of "Not Auth". These are non-transient situations. All of the servers listed no longer have a relationship with the domain owner, and none of the alternative response codes are appropriate or legitimate. (The server receiving the traffic does not and cannot know why it is receiving the queries, so a partially lame set of delegations where some of the delegated servers do answer, means NXDOMAIN is the wrong answer, for example.) The absence of DNS operators from the RRR model is one of the fundamental problems. There is no feedback mechanism to the delegating servers available directly from the DNS operators to get the broken delegation(s) removed permanently. So, when discussing this general subject matter, it is probably a good idea to keep this common corner case in mind. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
