>> > Well, one would, in fact, expect a delegation to be a
>> > non-authoritative answer:
>>
>> Yes, but one would presume that before any of the two above
>> queries were sent, the recursive resolver already have cached the
>> delegation for jshsos.ksyunv5.com.
>
> It doesn't matter, there can be multiple layers of delegations, and a
> response with aa=0, ancount=0, no SOA in the authority section and some
> NS records there is definitely what a delegation looks like.
Hm, I think I disagree slightly. Let me explain why:
For just the name jshsos.ksyunv5.com there cannot be "multiple
layers of delegations". Seen in context of the example from this
thread, the recursive resolver has already learned this delegation
via an earlier query with an AA=0
;; AUTHORITY SECTION:
jshsos.ksyunv5.com. 86395 IN NS ns4.bpldns.com.
jshsos.ksyunv5.com. 86395 IN NS ns3.bpldns.com.
response. When querying one of these name servers via:
dig @ns4.bpldns.com. lzd.jshsos.ksyunv5.com. aaaa
there are basically two valid response categories, depending on
whether the "lzd" name is a part of the "jshsos.ksyunv5.com" zone or
not:
1) If the "lzd" is a part of the parent zone, the parent zone
authoritative name servers had better flag any responses with
AA=1, be that either with an RRset of the queried-for name, a
NODATA response, or an NXDOMAIN response. (From the example we
already know that the name exists, so that rules out NXDOMAIN as
a valid response, but a recursive resolver doesn't at that time
necessarily know that (though it could have already cached data
about that).)
2) If the "lzd" name is not a part of the parent zone, it implies
that "lzd.jshsos.ksyunv5.com" is the name of a child zone.
a) if the queried name server isn't also authoritative for
the child zone, it should respond with an AA=0 delegation for
the child zone, "lzd.jshsos.ksyunv5.com".
b) if the queried name server is also authoritative for the child
zone, ... "see #1", and a delegation response would be wrong.
What's *not* valid, IMHO, is to respond with an AA=0 delegation
which points back to the zone whose name servers we are already
querying:
;; AUTHORITY SECTION:
jshsos.ksyunv5.com. 86395 IN NS ns4.bpldns.com.
jshsos.ksyunv5.com. 86395 IN NS ns3.bpldns.com.
as is what's happening here. And I think you agree, since...
> When it is non-productive, it is LAME.
...and this delegation response is "non-productive" because it
does not bring the recursive resolver any closer to getting an
answer. For a delegation to be "productive", it has to reply
with a delegation for a name which includes at least "one more"
label of the query.
>> Therefore, posting a question about a name in that zone to one of
>> the name servers supposedly serving that zone
>
> It needn't be authoritative for all names in the zone, it can issue
> further delegations, and sure appears to do just that, only with a
> delegation to itself.
Well, either the queried-for name is part of the zone (at which
point answers had better have AA=1), or it's part of a child zone,
at which point it might be OK to respond with an AA=0 delegation.
What I disagree with in the above is that a name server "needn't be
authoritative for all names in the zone", since names in a child
zone by definition isn't part of the parent zone. If what you said
was true, the whole concept of "a zone" would be invalidated.
>> And secondly, do we have any inkling whether all or most of these CDNs
>> use a common codebase, or is it all truly "roll your own"? And if
>> there is a dominant codebase, do we have an inkling what it is?
>
> I don't know, but there does seem to be some commonality of behaviour.
Indeed. I see Mark had a guess.
Rgards,
- Håvard
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
