> 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.
To my mind, both #1 and #2 are instances of a "lame delegation" -- in both instances will a recursor fail to get the expected response within reasonable time when resolving a query for a name in the zone in question. I hesitate a bit more to call #3 a lame delegation, since a recursor will then probably get an NXDOMAIN (and cache that fact) while trying to translate the name server name to an IP address, so will have nowhere to send the query. As I understand it, a lame delegation introduces extraneous traffic and extra delay in resolving a name, and it could be argued that #3 doesn't really do that. There's also two sub-variants alluded to already above: the NS record pointing to the non-responsive name server for the zone may come from the delegation NS RRset in the parent (delegating) zone, or it may come from one of the (other) authoritative name servers for the zone, since the latter NS RRset will typically override the NS RRset from the parent zone, since the NS RRset is authoritative in the child zone. Regards, - Håvard _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
