After a quick read of Generalized DNS Notifications, -01, I have some comments:
It would be ludicrous of me to argue against the notion that event driven approaches are superior to polling approaches. However, event driven approaches require more design work which is why it is natural for polling approaches to normally lead the way until they break. In section 3, there is this phrase which caught my eye: "An increasing number of TLD registries are implementing periodic scanning for CDS and CDNSKEY records in child zones." Operators are choosing and deploying the scanning approach. Perhaps because it is the only option, nevertheless, the early deployments are scanning. At a recent event, I heard a few measurements of the scanning approach, done with skepticism regarding the ability of such an approach to scale, but none of the measurements pointed to a bottleneck. There was even an off-hand comment that perhaps scanning isn't scary at all. I don't doubt the logic that is present in section 3 leading to the conclusion that there's a need to develop an event-driven approach. In fact, I'm a fan of the logic. However, there's no data to back up the claims that the polling approach won't work. It would be good to have that included in the document to establish the need for the NOTIFY approach. And why establish the need? Deep in the nature of the DNS is the notion that parents know about children, but not vice versa. In the DNS, delegations - both name server (NS) and security (DS/DNSKEY) - to date point downward. Nothing points upward. CNAME and DNAME are query-rewriting tools, not delegation tools, I'm excluding them. The historical architecture of the DNS is hostile to the idea of an event-driven approach - that's my fear. NOTIFY, as it is in use today does not cross zones, it works only within the set of nameservers that a zone administrator has configured for a zone. "Also-notify" is a static configuration option available in implementations but being a configuration plane feature is not evident or supported in the standard protocol. NOTIFY exists in a pool of familiar servers, all participants are managed by one entity or via an out of band arrangement. It does not challenge the DNS "downward" architecture. Using NOTIFY in another context may prove to be a significant change. Perhaps the resource record format is general enough, but how a recipient would respond to the resource record would be different. This is why I'm not greatly encouraged by the observation that we already have a record defined although that helps. Using NOTIFY from a child to parent to trigger a CDS, CDNSKEY, CSYNC action makes sense, but the context is novel (for NOTIFY). The message is used to cross administrative boundaries, upward even. Mentioned earlier, in the DNS children don't talk up to the parent (easily), so a few things are needed. One is the proposed NOTIFY record to tell the child where to send the notification query. The other is figuring out how to set up a receiving server at the parent that is not a new burden on the zone administration. This latter item concerns me the most as adding more modules to operations is a burden unless this can be adequately automated, buried in code, to the point it has no operational knobs an operator needs to manage and track. (And there's always that DDoS/Firewall hole punching/traffic engineering challenge.) Using NOTIFY from one operator for a zone administration to an independent other operator (aka multi-signer) is another novel environment. In this case it is not shaped by a child to parent situation, but it exists in a potentially flat, out-of-band defined space. I usually hear of multi-signer featuring two operators, but there could be more. E.g., a TLD might decide to have a different signer for each of their half-dozen or so anycast name server contracted operators. There are quite a few design considerations for this. Another way is to classify NOTIFY today as a "1:me" protocol, from one of my elements to another element by me. From child to parent, it is "many:1" - a parent has many children (the many) with all the children trying to hit the 1 parent. Between co-operators of a zone, I'm not sure how to put that into a category of "1:1" or "1:many" or "many:1" protocol, but it's different. I suppose it's 1:1 but neither of these might be the zone administrator, which is a problem. Struggling to define the latter, here's what I'm concerned with. When you have an administrator who contracts to two, or more, operators for service and there is a fault, how is the fault handled? I.e., the error handling will need attention. NOTIFY now, when it breaks, it's all within one administration to heal. From child to parent, you could (perhaps) define fault handling in the registration agreement. But between co-operators for one zone, it's harder to manage. This puts the onus on the protocol definition to be self-healing...leave nothing for the operator to fix. The goal is to make the protocol increasingly operator friendly. It's not always easy to do that. Note: I'm not criticizing the proposal in the document, I haven't absorbed it yet. I'm just trying document criteria I'll have in mind when reading the proposed solution. Ed Lewis _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
