Sent from my iPhone

> On Aug 12, 2021, at 12:21 PM, John Levine <jo...@taugh.com> wrote:
> 
> It appears that Brian Dickson  <brian.peter.dick...@gmail.com> said:
>> -=-=-=-=-=-
>> 
>> This is the work I will be submitting in DNSOP.
>> 
>> This is what has been described as a “hack”, but provides a needed 
>> validation link for authoritative servers where the latter are in
>> signed zones, but where the served zones may not be signed.
>> 
>> NB: It overlaps with the recent DPRIVE draft that Ben S submitted recently.
>> 
>> It will likely be the case that those overlaps need to be reconciled, based 
>> on use cases and scope.
> 
> It looks to me like the main difference between the drafts is that Ben's 
> scheme uses one new 
> faux algorithm and puts the rrtype inside the encapsulated data, while yours 
> uses one per rrtype.

Not quite. IIIRC, in both cases, the record(s) contain only the hashes of 
datum/data, which is a one-way function.

Unpacking isn’t possible when recreating the hash.

Having one DS per type (and possibly per record) is a small bump in total size, 
but is more resilient to semantic errors (including things that might not be 
added as glue by the parent) and any sort of rollovers (change of glue records, 
change of servers).


> The goals look a little different but other than where the rrtype is encoded 
> the mechanisms
> look the same.

It isn’t. The one way hash means the validate is unable to determine what 
rrtypes are present.

In the one rrtype per DS, that encoding is possible to determine (trivially).

> 
> In both drafts I would like to see clearer explanations of what you do when 
> the signed glue
> disagrees with their authoritative non-glue versions.  

You replace the non-auth glue with auth data, same as today. (But only if it is 
in an answer section, and ideally in a situation where that zone is signed).

If the signature on the DS set doesn’t validate , retry. Validation of the NS 
set and glue data would be done by recreating the hash(es) and looking for a 
match in the set of DS records whose signature  was validated. Only validated 
records should be used. NSEC(3) proves whether any DS exists. The child is not 
required to be signed, eg if no “standard” DS records exist.

> I'm having some trouble figuring out
> exactly what "authoritative" means here.

The DNS server serving the child zone.
If the child is “registrant1.example”, and the NS set includes 
“ns1.dns-op2.example”, the authoritative server is the latter.
If THAT zone are itself has NS set including only names like 
“ns[0-9].dns-op2-names.example”, then the zone dns-op2.example would be 
glueless (no A/AAAA glue is provided except for sibling glue). The 
dns-op2-names would ideally have in-bailiwick NS and non-optional glue.
The last set would be the only ones with the second and/or third algorithm.

All three zones are delegated, and depending on the respective values might be 
on two different sets of servers. Both of those server sets would be 
authoritative servers.

Brian


_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to