>> > ; ANSWER
>> > ; AUTHORITY
>> > example.com. IN NS ns1.provider.net.
>> > example.com. IN NS ns2.provider.net.
>> >
>> > is a valid delegation response (and so not from this perspective a LAME
>> > delegation), whether or not the target servers actualy serve the zone.
>>
>> I agree that this is a valid delegation response. I do however
>> disagree with the latter part of this sentence; it *may* be a
>> "lame delegation" depending on the response you as a recursive
>> resolver get from the two delegated-to name servers when you try
>> to look up a name in the example.com zone.
>
> 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.
>> > A LAME delegation (response) happens when "ns1" or "ns2" respond to
>> > queries with yet another (e.g. self) delegation that does not move the
>> > resolver closer to the target:
>> >
>> > ; ANSWER
>> > ; AUTHORITY
>> > example.com. IN NS ns1.provider.net.
>> > example.com. IN NS ns2.provider.net.
>>
>> I am having problems seeing under what normal-ish circumstances
>> either ns1 or ns2 would provide this response.
>
> 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
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
dig @ns4.bpldns.com. jshsos.ksyunv5.com. ns
and
dig @ns4.bpldns.com. jshsos.ksyunv5.com. soa
which also both miss the "aa" flag, has an empty answer section, and
just lists the name servers in the authority section. It smells like
this particular DNS name server implementation disowns any knowledge
about other RR types than "A", or perhaps specifically does not
implement the concept of a "zone".
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.
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.
DNSviz.net also reveals that there are other issues with this zone,
there's no response to TCP queries and there are issues with EDNS0
support flagging -- if it's unsupported, a query using it should
elicit a FORMERR, but instead the name server just replies without the
OPT record.
> Another example, a more "normal" upward referral:
>
> ; .CO.UK:
> healthwize.co.uk. 172800 IN NS ns.mainnameserver.com.
> healthwize.co.uk. 172800 IN NS ns2.mainnameserver.com.
And they both in turn return a delegation to the root.
This is something I think I've seen Windows name servers of a certain
vintage do when not configured to serve the zone where the queried-for
name lives, and ... it's not helpful, and can be used as a DDoS
amplifier, so it is at least on the verge if not over the border of
being irresponsible to deploy on the public Internet ("response rate
limiting", what's that?)
I'm fully on-board with
https://datatracker.ietf.org/doc/html/draft-sullivan-dnsop-refer-down-00
As for "lameness" for this example -- "yes", and "fully so".
> Non-productive (LAME) delegation responses are sadly all too common.
That I can agree with.
Regards,
- Håvard
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
