Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-01.txt

From: Havard Eidnes <[email-masked]>
Date: Fri, 19 Feb 2021 18:45:01 +0100 (CET)

> 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

---

From: [email-masked]
Date: Fri, 19 Feb 2021 13:21:17 -0800

> not be necessary, so I favour the scheme in 5.6 using a TXT

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

---

From: Peter van Dijk <[email-masked]>
Date: Sat, 20 Feb 2021 14:03:18 +0100

Hello,

> 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/