> During the last hackathon at IETF-109, a new idea emerged where the > version of a member zone in a catalog (indicated by the member zone's > SOA serial number) is also in the catalog. This can help ensuring > dissemination of member zones in a catalog from the primary to the > secondary nameservers will happen in a timely fashion more reliably, and > can also alleviate the burden on primary nameservers in cases where > there are a large number of secondary nameservers serving a large number > of zones. > > This is presented in the new section 5: "The Serial Property"
Hm, not sure I like that part of this. I'm a fairly strong adherent of the KISS principle, and I have problems with seeing that this solves a new and significant problem. The argument for having that at all seems to be somewhat weak to justify the additional complexity: The current default mechanism for prompting notifications of zone changes from a primary nameserver to the secondaries via DNS NOTIFY [RFC1996], can be unreliable due to packet loss, or secondary nameservers temporarily not being reachable. One, if you have significant packet loss to or from a given secondary name server, it can be argued that you have chosen your secondary unwisely, and that the right fix is to resolve the packet loss issue and not to needlessly "complexify" the DNS protocol to compensate for what's ultimately an unwise move. Two, if a secondary name server is temporabily not reachable, well... The reason for that might be different. If the name server was restarted or the host rebooted, it's not unreasonable to expect the name server to query for the SOAs for the zones it acts as secondary name server for on startup. If the reason is a temporary loss of connectivity / network service, well -- is that a sufficiently frequent issue to deal with in this manner? I do realize that collecting all the SOA serials of the member zones in the catalog zone will cause the update frequency for the catalog zone to be, essentially, the "multiplication" of the update frequency for all the member zones. It is not entirely obvious that this will be a net win in terms of the work required for the primary name server(?) That said, the "serial" property appears to be intended to be optional, which is ~OK. However, "burning" a new RR just for this purpose seems to me to not be necessary, so I favour the scheme in 5.6 using a TXT record instead. Regards, - Håvard _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
