On Tue, Apr 04, 2023 at 10:48:11PM +0200, Havard Eidnes wrote:
> > At the time such a delegation response is being processed by a resolver,
> > it looks just fine. Nothing to see here, move along (down the tree)...
>
> I disagree. If either ns1.provider.net or ns2.provider.net is not
> provisioned to provide name service for the example.com zone, that
> delegation record would be a "lame delegation", and it's the
> responsibility of the domain owner for example.com to intervene and
> fix the situation, either by contacting the DNS publication service
> provider to (re-)establish service or to contact the registrar to
> update the delegation NS RRset.
What I'm trying to suggest (resolver perspective), is that questions of
responsibility, ... are not something a resolver can or should attempt
to determine. All one can attempt to do is classify query responses.
- It sees a delegation from a parent that is structurally valid, and is
therefore processed.
- It then may see a non-progressive delegation response (the only kind
of LAME a resolver can effectively divine) from the allegedly
responsible nameservers, a can classify that as a LAME delegation
response.
- If all the nameservers fail to provide a usable response, the final
EDEs may include "LAME delegation" from one or more of the respective
nameservers, and "Unreachable Authority" overall.
Any other definition of LAME is not something that a resolver can
reliably infer or report. Some term that covers questions of correct
configuration, responsibility, authority, that lie outside the scope of
what a resolver can determine, may indeed be useful, and perhaps the
term LAME is generally defined from *that* perspective... It is just
that I see a a clear need for a more technical term that classifies bad
delegation responses and LAME has so far worked well for that purpose.
If some day my informal use in this thread of "non-productive" gains
broader currency in the community, and begins to be "understood" without
much further explanation when used, I might stop using "LAME" in its
narrow (know it when I see it in a response) sense.
> > I can't tell you **why** they do it, but there are many that do in fact
> > respond with non-productive delegations:
>
> Hmm, in the response to
>
> dig @ns4.bpldns.com. lzd.jshsos.ksyunv5.com. aaaa
>
> I think the only real problem is the absence of the "aa" flag in the
> response, especially since you get it in the response to
>
> dig @ns4.bpldns.com. lzd.jshsos.ksyunv5.com. a
Well, one would, in fact, expect a delegation to be a non-authoritative
answer:
$ dig @a.gtld-servers.net. -t a www.google.com \
+norecur +noedns +qu +nocmd +nocl +nottl +nostats +noadd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39726
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 8
;; QUESTION SECTION:
;www.google.com. IN A
;; AUTHORITY SECTION:
google.com. NS ns2.google.com.
google.com. NS ns1.google.com.
google.com. NS ns3.google.com.
google.com. NS ns4.google.com.
So our "bpldns.com" server is doing a darn good job of simulating a
delegation response, that is non-productive, so LAME.
> This smells of a "roll your own" DNS name server implementation which
> doesn't even correctly implement the required minimum of the DNS
> standards.
>
> Clearly, the name lzd.jshsos.ksyunv5.com exists in the DNS name space
> (ref. the "a" response), and the name server being queried here should
> obviously be authoritative for the jshsos.ksyunv5.com zone, so the
> "aa" flag should be set in the reply to the "aaaa" query. But also
> see the responses to
Definitely, but that's extrinsic knowledge that the resolver can't infer
from just the current query response. In the heat of the moment, we all
we have is a well-formed, but non-productive delegation, which is the
only kind of LAME delegation that a resolver can unambiguously infer.
> If I'm not terribly mistaken, this sort of mis-behaviour is all too
> common among the CDN crowd, and I dearly wish we could stomp it out.
Shall we? Please lead the way!
> Now... Is the delegation "lame" in this case? I'm leaning towards a
> crystal clear "maybe" :) Perhaps the apparent "lameness" isn't the
> biggest problem in this case.
This and many others like it are indeed often more deeply broken, but
that goes beyond classifying the particular responses that are
non-productive delegations.
> I'm fully on-board with
>
> https://datatracker.ietf.org/doc/html/draft-sullivan-dnsop-refer-down-00
Yes, perhaps that draft is worth reviving in some form.
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
