On 10/25/23, 12:19 PM, "DNSOP on behalf of Johan Stenstam" <[email protected] on behalf of [email protected]> wrote:
>Of course you have to agree that “push” is a better mechanism than “pull” when >it comes to propagating information about a change in one end to the other end. Perhaps pulling this entirely out of context, but I'm not sure I agree with that statement. Certainly, push is more elegant than pull, but that doesn't mean it is better. Pull is simpler, and I'd argue more in line with the flow of the DNS protocol than push. The action to be taken is by the parent. The parent is being requested to change its zone contents based on information at the child (much like a name server change). As the parent is going to have to do something, it's more natural to have the parent initiate the action by finding the request and acting upon it. In contrast, if a child pushes a notice to the parent, the parent needs to be prepared to react at that non-predictable moment. The DNS is a downward protocol. Parent's point to children and not the other way around. This contributes to the protocol's ability to scale so well. The "downwardness" is evidenced in the query process (referrals) and in the provisioning process (NS, DS records). We used to have a "referral to the root" for lame delegations - that didn't go so well. (This observation comes from failed research efforts trying to build more robust DNSSEC chains-of-trust. Never could make security go back up the tree. Upward components don't seem to work so well. ) NOTIFY, as it is defined today, is a lateral mechanism, used within a zone. A zone's name servers tell the name in the SOA record (the MNAME, not owner name) that they have a new version of the zone. NOTIFY is not a generalized messaging platform, not defined for inter-zone management. Defining NOTIFY for inter-zone or inter-DNS-administration management would be precedent setting, it would represent a change to the way NOTIFY works and possibly the role it plays in AXFR and IXFR. I have some hesitation in trying to shoe-horn provisioning matters into the DNS query-response protocol "band". If it works, fine, but realize that the IETF has a different protocol defined for DNS provisioning - EPP. That protocol is designed for registrar to registry traffic, not DNS operator traffic, but I hold it up to say provisioning is so different from publishing data about names that DNS provisioning has its own protocol. Further, EPP and RDAP are entirely different protocols that exist to handle DNS meta-data, examples of how not everything the DNS needs to function can be done "in-band." FWIW, I've never heard an operator say they can't scan their own zone's delegations. I've heard a few say that scanning is easier on them than setting up place where registrants (via registrars if needed) can send them notices (or NOTIFYs). I think it is great that zone operators can publish the "desired" DS and DNSKEY resource records (CDS and CDNSKEY), that is a great way to marshal the data from source to destination. The gap is error reporting - what if the registry will not accommodate the request? The debate between polling (scanning) and event driven (NOTIFY) is significant but does not address that gap. But this is getting off the topic a bit. Okay, so what I mean to say...I'm not sold that push is better than pull. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
