Minor editorial updates to Roy's recent PRs #32
Conversation
|
|
||
| The DELEG resource record type is unusual in that it appears only on the parent zone's side of a zone cut. For example, the DELEG RRset for the delegation of "foo.example" is stored in the "example" zone rather than in the "foo.example" zone. This requires special processing rules for both name servers and resolvers, as the name server for the child zone is authoritative for the name at the zone cut by the normal DNS rules but the child zone does not contain the DELEG RRset. | ||
| DELEG records, when present, are included in referrals. When a parent and child are served from the same authoritative server, this referral will not be sent because the authoritative server will respond with information from the child zone. In that case, the resolver may query for type DELEG. | ||
|
|
There was a problem hiding this comment.
I think this section shows the hidden complexity of the proposed "DELEG+NS" referral response, and we shouldn't be too hasty in concluding that it is the way forward. For -00, I think it's fine but we could use some additional disclaimers about the possible downsides.
| FOR DISCUSSION: The additional complexity here, with resolvers needing two very different resolution behaviors, merits further investigation. It also opens some potential paradoxes. For example, if the server is authoritative for the child via DELEG, but not via NS, then it cannot serve any answer that will work for both DELEG-aware and non-DELEG-aware resolvers. |
There was a problem hiding this comment.
Fair point. I also wonder how often of a case this would be and whether or not it is worth the special handling at all.
There was a problem hiding this comment.
Moin!
uk and co.uk
au and com.au
comes to my mind immediately. It is similar then DS which has the exact same kind of handling.
So long
-Ralf
There was a problem hiding this comment.
Since this PR was closed, I opened #33 to discuss the second part of this issue.
There was a problem hiding this comment.
ok, so I suppose this could help with sharding migration of individual second-level domains.
As much as it is probably not required in that case, there may be implications for draft-dnsop-deleg-dnssec.md though.
No description provided.