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
