Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-01.txt
Hello, On Fri, 2021-02-19 at 13:21 -0800, cpol...@surewest.net wrote: > On 2021-02-19 18:45, Havard Eidnes wrote: > > 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. > > My reading of RFC 5507 "Design Choices When Expanding the DNS" > §6 ( https://tools.ietf.org/html/rfc5507#section-6 ): > > ... of all the alternate solutions, the "obvious" approach of using > TXT Resource Records for arbitrary names is almost certainly the > worst ... > > seems to favor "burning" a new RR "just for this purpose". > While RFC 5507 is informational, it does consider the general > problem (new RR vs. TXT) in some detail. 5507 is an absolutely excellent document, that cannot be summarised by its conclusion. In this case, it turns out that most of the reasons given in the full text, leading up to the 'burn an RRtype' conclusion, do not really apply to catalog zones. We do not have wildcards, and we do not have UDP message size constraints, the zones will not be queried by random tools that might have unrelated semantics. I'm not arguing that catalog zones -should- use TXT for everything (because that would be terrible); but the firmess of 5507's conclusion does not fully apply here. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-01.txt
On 2021-02-19 18:45, Havard Eidnes wrote: > 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. My reading of RFC 5507 "Design Choices When Expanding the DNS" §6 ( https://tools.ietf.org/html/rfc5507#section-6 ): ... of all the alternate solutions, the "obvious" approach of using TXT Resource Records for arbitrary names is almost certainly the worst ... seems to favor "burning" a new RR "just for this purpose". While RFC 5507 is informational, it does consider the general problem (new RR vs. TXT) in some detail. -- Charles Polisher ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-01.txt
> 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
Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-01.txt
Hi All, This new version has two new sections: "The Serial Property" and "Implementation Status". 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" The section also presents three different ways to provide a "serial" property with a member zone. We invite the workgroup to review this section thoroughly, and discuss whether or not this is a good idea, and if so, what way to provide a "serial" property would be best. The new section "Implementation Status", lists production ready implementations, as well as upcoming and Proof of Concept implementations. Experience gained during the IETF hackathon also reported in this section. Op 04-12-2020 om 23:33 schreef internet-dra...@ietf.org: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the IETF. > > Title : DNS Catalog Zones > Authors : Peter van Dijk > Libor Peltan > Ondrej Sury > Willem Toorop > Leo Vandewoestijne > Filename: draft-ietf-dnsop-dns-catalog-zones-01.txt > Pages : 15 > Date: 2020-12-04 > > Abstract: >This document describes a method for automatic DNS zone provisioning >among DNS primary and secondary nameservers by storing and >transferring the catalog of zones to be provisioned as one or more >regular DNS zones. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-catalog-zones/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-dnsop-dns-catalog-zones-01.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-catalog-zones-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
