I have read draft-berra-dnsop-announce-scanner.
I think it's a good idea, I am happy to adopt.
I had not read RFC9859 before, and I read that.
{So, is this subtyping?}Some comments: 1. "Given that a vast majority of parent zones do not operate scanners, providing a simple mechanism to inform the child of this fact will be useful." This is a rather time-specific comment. Either insert a date, or omit. Given how new 9859 is, and from what I understand the relative lack of CDS scanning, I wonder if the lack of a known schedule really what is what is holding things back. (I understand that many TLDs are contractually forbidden from talking to child zones. That registrars would have to do the scanning) 2. I think that children will need to do two lookups: a. _dsync.parent.example. b. child._dsync.parent.example. (with a possible wildcard reply) I also think that a child authoritative server will need to (b) for each zone that they host. So for me, 0. _dsync.ca. 1. sandelman.ottawa.on._dsync.ca. 2. sandelman.ottawa._dsync.on.ca 3. sandelman._dsync._dsync.ottawa.on.ca 4. sandelman._dsync._dsync.ca I'm not sure if my server would be able to omit #2 and #3. I guess one has to an SVCB lookup too. 3. I find the "bootstrap" mechanism very interesting. That seems to go beyond what the abstract and introduction say. I don't understand why in 3.4.3 it says "CDS SCANNER 0" (why the 0). I guess the subtyping of RFC9859 does not permit variations in the record format, so the 0 is the port number. And we have no place the put the actual interval, thus the SVCB. ... oh. I SEE why my confusion, the txt has: _dsync.parent.example. IN DSYNC CDS SCANNER 0 scanner.parent.example. _dsync.parent.example. IN DSYNC CSYNC SCANNER 0 . when it should say _dsync.parent.example. IN DSYNC CDS SCANNER 0 scanner.parent.example. _dsync.parent.example. IN DSYNC CSYNC SCANNER 0 . The presence/absence of "scanner.parent.example." was obscured by the wrapping. (example in 3.5 has same wrapping problem) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
