Not that this matters, but this is the first look I have had at this document.
I’ll start with a heavy dose of skepticism as this is intended for the standards track. This is “impossible to implement”: 2.3.2. Child Nameserver Selection Parental agents will need to poll child nameservers in search of CSYNC records and related data records. One word - any cast. (Okay, the spell checker says it is two words.) A casual observer can estimate the rest of the elided comment. But, truth be told, “polling” as described here is not necessary for this proposal. I do have a more serious concern about where the parental agent gets it’s information. I accept that a properly DNSSEC-signed CSYNC record is sufficient to indicate a child has a configuration that it wants to see replicated in the parent. Tying this to serial numbers makes the CSYNC independent of the copy-on-the-server, meaning, this depends on the data space and not the server space. Getting the NS set has one challenge, making sure the NS set comes from the same serial number version as the CSYNC. When I issue “zone/IN/NS” I don’t see the serial number though. I’d have to use the ANY query type to capture the SOA and NS set resident in the answering server (and hopefully we’ll assume an authoritative server). Given: Parental agents MAY offer a configuration interface to allow child operators to specify which nameserver should be considered the master to send data queries too. This master may not be one of the publically listed nameservers in the NS set (i.e., it may be a "hidden master"). this issue is not a show stopper, but the “protocol implication” of not getting the SOA and NS in the same response is probably a significant note to add. My concern with the glue records is more substantial. There are two use cases to consider. One case is where the addresses of the NS names are owned in a different (perhaps sub) zone. The other case is where the addresses are in zone that is “above” the child but still under the parent - think multi-label deep parents. In the first case, once I can get the CSYNC and SOA and NS to be “in sync” as far as what the child is declaring, it’s not as easy to guarantee the set of zones owning the address records agree. And I say “set of zones” because, well, you can imagine. What if…the zones in question here are not under the management of the child, pertinent here not as “control” but “not monitored” and they fall out of date or experience some other failure. Or are not signed the same way the child is? In the second case, to make this a bit clearer, the child zone is "store.franchise.example." delegated from the parent zone “example.”. The NS set has names that are in corporate.example. which is also delegated from example (one-label deep). The child zone could not know that the glue is needed because the names are out of bailiwick, but to the parent zone, they are. This is, yes, a trick question. The child administrator would need to know that address records are needed in the type bit map field even though they are “over there” tree-wise. I do commend this observation (which is one of the problems I have with the CDS/CDNSKEY proposal): 2.3.1. Error Reporting There is no inline mechanism for a parental agent to report errors to operators of child zones. Thus, the only error reporting mechanisms must be out of band, such as through a web console or over email. But I am dubious on the flag for “immediate.” In my experience, I’ve never seen queue-jumping to every pay off unless the underlying system is over subscribed as it is. If this system is oversubscribed, there are bigger problems. Normally I’d let this lie, but it reminds me of the key strength field in the KEY RR - a spectacular dud of a concept. (KEY RR was the DNSSEC key holder before DNSKEY RR.) These are my comments assuming that the proposal works as advertised. I have my doubts regarding the use of the DNS to “pass messages” for a few reasons. Out-boxes aren’t always cleared out (meaning old requests hang around). In-boxes may not be checked regularly. And the lack of a reverse channel is a pretty major obstacle - as the draft says, out of band communication is needed. (This reminds me of a joke - you can talk to a diety, but if they talk back, check yourself into a hospital.) PS - What if the parental agent tries to retrieve the AAAA records and gets no response - persistently? I don’t mean “No Answer” I mean nothing back? I’m picking on this (as opposed to A) as a somewhat more realistic operational happenstance. Who would initiate the debugging of this, the parental agent who detects the failure but is mum, or the child whose patience is being tested? On Apr 2, 2014, at 15:14, Tim Wicinski <[email protected]> wrote: > > All, > > This is the beginning of the Working Group Last Call on Child To Parent > Synchronization in DNS. > The London update showed that this work is complete and ready to move forward. > > The document can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-child-syncronization/ > http://www.ietf.org/id/draft-ietf-dnsop-child-syncronization-00.txt > > Please take a moment to review the final versions and send up any comments. > > This document willhave a 2 week period for comments, closing on April 16th, > 2014. > > thanks > tim > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
