On 4/3/23, 4:02 PM, "DNSOP on behalf of Wessels, Duane" <[email protected] on behalf of [email protected]> wrote: > > (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.
In 2003+/-1 I worked on a project to identify lame delegations in response to a then bug-in-a-popular-resolver that followed upwards referrals to the point that it would no longer answer any other queries. "Lame" meant that the nameserver indicated in an NS resource record answered (i.e., responded) explicitly that it was not authoritative for the subzone, at the time, this was indicated only by the upwards referral. The SERVFAIL and REFUSED responses came later in history, partly as a response to amplification concerns. While this may not be the fully correct answer, I was taught that a lame delegation is "singular" (i.e., not applied to a set) and "active". Afterall, the problem I was to help solve was the upwards referral issue (by eliminating lame delegations in a portion of the DNS tree), which may bias what I was taught. Singular - in the sense that the label "lame" referred to individual instances named in a NS resource record set and not the resource record set in its entirety. Active - in the sense that lameness was judged by a response, not a timeout. Timeouts were ruled out( - as they didn't suffer the upwards referral issue I was supposed to address). So, only #1 would qualify for lame under that usage. #1,#2,#3 would make a delegation "broken" (unofficial term)... _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
