On Mon, Apr 03, 2023 at 08:02:16PM +0000, Wessels, Duane wrote:
> 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.
>
> [...]
>
> (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.
I believe that the most natural perspective is from the view point of a
resolver attempting to classify a (non?)response to a query sent to an
authoritative server. The following cases then arise:
- A server that returns a non-productive delegation:
* NOERROR + 0 answer count
* NO covering SOA in the authority section
* At least one NS record in the authority section
* BUT: the owner names of the NS records are not *closer*
to the qname than the queried zone (known to the resolver,
but not explicit in the query).
The delegation may be "upward" (see:
https://datatracker.ietf.org/doc/html/draft-sullivan-dnsop-refer-down-00#section-2
), or to the queried zone or "sideways", but regardless it is not
closer to the qname and so is LAME. This is the *core* example of
a LAME delegation (response).
- Somewhat more ambiguous is a REFUSED response. In light of the
words of wisdom in the above I-D:
https://datatracker.ietf.org/doc/html/draft-sullivan-dnsop-refer-down-00#section-2.4.4
https://datatracker.ietf.org/doc/html/draft-sullivan-dnsop-refer-down-00#section-2.4.5
a "REFUSED" answer is often a symptom of what might have otherwise
been an upward referral LAME delegation, but the signal is no
longer unambiguous, and so this just a nameserver that is refusing
service for some reason (the domain is often retired, and there
are no working nameservers at all, a "dangling" or "orphan"
delegation might be a better term). So a resolver does not
classify this case as LAME.
- Non-responding server. This could be an outage, a rate limit,
a deliberate policy blocking the resolver, ... So calling it
a LAME delegation is not a viable option even if the reason for
the non-response is a misconfiguration that results in the wrong
server being present in the NS (glue or authoritative) RRSet.
Bottom line, the definition that has a clear meaning (resolver
perspective) that a LAME delegation is a "non-productive" delegation
response. Everything else is somewhat arbitrary.
On Mon, Apr 03, 2023 at 10:18:42PM +0200, Havard Eidnes 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.
> >
> > 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.
Thus I only concur on upward, sideways or self-referrals in case (1),
and none of the rest.
On Mon, Apr 03, 2023 at 01:36:56PM -0700, Wes Hardaker wrote:
> FYI, when working on the EDE draft [RFC8914] we discussed lame
> delegations some and actually did not document a particular error code
> related to it, as the meaning both uses improperly precise terminology
> ("lame" is not really a useful adjective in this situation) and because
> of the multiple reasons why an authoritative server may not be
> responding, as you indicated.
This is unfortunate, because the EDE implementation I'm working on
consequently can only classify these as "Other" with LAME in the
extra_text. I'll be asking for that code point at some point once
the dust settles.
On Mon, Apr 03, 2023 at 08:31:28PM +0000, Mark Delany wrote:
> (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.
A nameserver that adequately serves the zone, but reports an
authoritative NS RRset that does not include its own name is not a
problem as such, or in any case this is not a LAME delegation, just
some inconsistency between parent and/or various auth server NS records.
> (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"?
No.
> (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?
If, as I'm suggesting, LAME delegations are limited to actual
delegations (NODATA + NS in AUTHORITY sans SOA) then this ambiguity does
not arise. What's LAME is a delegation response (DNS message), not a
configuration.
> 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.
Right, "inconsistent" is more applicable to describing configurations.
The inconsistency may or may be a problem, and a resolver may or may
not be aware of the inconsistency.
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
