Subject: [DNSOP] Various Thoughts on Catalog Zones (draft-ietf-dnsop-dns-catalog-zones-01)

From: Peter Thomassen <[email-masked]>
Date: Mon, 8 Feb 2021 18:00:49 +0100

Hi,

As we've been facing the "zone provisioning and removal problem" for a 
while, I recently looked at draft-ietf-dnsop-dns-catalog-zones-01.  I 
think it's a great effort in the right direction, and I'm glad to see 
it moving!

I have various thoughts on the current proposal (mostly on serial 
signaling and on advanced use cases), and figured I'd post them here.

The discussion ventures in several directions (not necessarily all 
compatible), so I hope you have a cup of tea ready.  If this should 
have gone into several threads, please let me know for the future (and 
accept my apologies in advance).

1. Non-exposure
---------------

The last paragraph of Section 3 says:
> It is not expected that the content of catalog zones will be
> accessible from any recursive nameserver.

In light of this, it may be useful to state that catalog zones SHOULD 
reside under "internal.".

Rationale:

a) It helps lower the administrative burden without enumerating catalog 
   zones. (In dnsdist, for example, it's enough to do 
   `addAction("internal.", RCodeAction(DNSRCode.REFUSED))`.)

b) Similarly, public-facing software may choose to categorically refuse 
   queries into "internal.", without necessarily being aware of the 
   catalog zone mechanism.  (A configuration option to turn this on or 
   off notwithstanding.)

c) It also prevents mistakes like accidentally shadowing parts of 
   another zone by mounting the catalog zone underneath (KnotDNS warns 
   against this [1]).

However, please see point 3 of this message, which is in contradiction 
to this proposal.

[1]: https://www.knot-dns.cz/docs/3.0/singlehtml/index.html#catalog-zones

2. Serial Property
------------------

The idea of (optionally) communicating the SOA serial through the 
catalog is highly intriguing.  To that end, the document proposes the 
new SERIAL record type, outlining several different methods of using 
it.  At the same time, paragraph 3 of Section 5 contains provisions for 
the case that the serial of the zone currently deployed on the 
secondary is larger than the value of the serial property.  In that 
case, the document says that the transfer MUST be aborted.

I see several issues here:

a) It is unclear to me whether decreasing serial numbers must really be 
   avoided at all times.  In particular, it is possible that catalog  
   zones may displace the serial mechanism in the future, and operators 
   may decide to make replication decisions based on other criteria 
   (such as a changing "<m-unique-N>" label, or whatever else).

   I am pointing this out because increasing serials come with serious 
   conceptual and implementional cost [2, 3].  It therefore seems to me 
   that enforcing the maintenance of serial logic indefinitely may 
   introduce an undue level of technical debt.

   My suggestion would thus be to change this to SHOULD, if making any 
   provisions at all.  (Implementors are, of course, free to offer 
   functionality that does what you'd except for increasing serials -- 
   I just don't think it should be a normative statement.)

[2]: https://tools.ietf.org/html/rfc1982
[3]: https://doc.powerdns.com/authoritative/dnssec/operational.html#soa-edit-ensure-signature-freshness-on-slaves

b) A new record type is introduced (SERIAL).  Its content is very 
   similar to the CSYNC record type from RFC 7477 (which has a serial 
   field, flags, and an NSEC-style type bitmap) [4].  Instead of 
   introducing a new record type, I'd like to suggest reusing CSYNC.

   One may object that CSYNC records are larger than SERIAL.  While 
   true in principle, the effect is very small:  At least the last 
   field (type bitmap) does not take up any space if it is empty.

   That leaves us with the "flags" field (16 bits).  The CSYNC record 
   currently has two possible flags, 0x01 ("immediate") and 0x02 
   ("soaminimum").  The first dictates whether an action should be 
   triggered automatically (or only after out-of-band approval), and 
   the second governs the behavior regarding the issue discussed above 
   under a), namely what to do if the serial given in the record is 
   "out of order".

   I think that these two flags are very well suited for the purposes 
   of catalog zones (with an anologuous meaning).  In particular, this 
   would solve both the "decreasing serial" issue as well as the issue 
   of clashing zones (a zone appearing in several catalog zones) [5].
   The procedure for managing zone transitions proposed on GitHub would 
   simplify to setting the "immediate" flag only on one of them [6]. 
   (Quite casually, this would remove the race conditions arising from 
   trying to do atomicity across several catalog zones.)

   Re-using CSYNC would therefore not only avoid the introduction of a 
   new record type, but also pave the way to addressing other aspects 
   of the problem. -- Any fear of confusion from using CSYNC for two 
   different things could be alleviated by defining a new record type 
   with wire format identical to CSYNC.  (Similar "aliases" exist for 
   DNSKEY/CDNSKEY, DS/CDS, SMIMEA/TLSA, SVCB/HTTPS.)

[4]: https://tools.ietf.org/html/rfc7477
[5]: https://mailarchive.ietf.org/arch/msg/dnsop/FyA6ofJVXAeb-YoA1ZgUChhOlb0/
[6]: https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/issues/9

c) The TTL field of the PTR record that signifies a zone as a member of 
   the catalog is currently without meaning.  It is RECOMMENDED to be 
   set to 0.

   If it is decided that just the serial (and only that, no flags) 
   should be communicated, an alternative to signaling it through a 
   separate record would be to use the PTR record's TTL field.  The 
   value range is perfectly fitted (both are 32-bit unsigned integers).

   While it may seem a bit of a stretch, I don't think this non-
   standard use would be a problem, as catalog zones are not expected 
   to be accessible from any recursive nameserver.  For the management 
   of a farm of authoritative nameservers, such semantics should pose 
   no problem.

   This is along the lines of George's idea posted here earlier [7].

[7]: https://mailarchive.ietf.org/arch/msg/dnsop/XemioFlcS55HIB-Fl7b-o9KGwDo/

3. Advanced use of catalog zones
--------------------------------

I've long been wondering why there is no way to communicate DNSKEY/DS 
records to the parent registry "from first principles".  Of course, we 
have CDNSKEY/CDS stuff from RFC 8078 today for rolling keys [8], but 
that only works once the initial setup is done.

[8]: https://tools.ietf.org/html/rfc8078

A thing that has been on my mind is the following:  Assuming that the 
zone of (at least one) authoritative nameserver's hostname is signed 
with DNSSEC, it would be conceivable to attach the catalog zone under 
_catalog.<hostname>, and sign it.  (To avoid bloating the zone of the 
server's hostname, a CNAME or NS delegations will do the trick.)

Assuming that the "<m-unique-N>" label can be deterministically derived 
from the member zone's name, one could provision CDNSKEY/CDS records in 
the catalog as well.  The registry can then opportunistically check 
with the catalog, validate the results via DNSSEC, and use them to 
provision DS records from first principles, without any manual 
intervention beyond telling the upstream registry about the NS records 
(just as in pre-DNSSEC times).  In essence, the chain of trust is 
extended from the zone containing the auth hostname to the zones it 
hosts.  IMHO, if such a mechanism existed, it would be great progress!

I am well aware that this goes way beyond the current catalog zone 
proposal, and I am not suggesting to include such a mechanism at this 
point.  Before such a thing could happen, there are obviously many 
questions to be discussed, such as

a) under which domains the catalog zone should be mounted (all, or any 
   of the authoritative nameservers' hostnames? SOA MNAME? ... the 
   latter may not be publicly accessible),

b) how the CSYNC type bitmap field could come in handy here in some way 
   (I have not spend much time thinking about this aspect, but after 
   all, it is there for child-to-parent synchronization).

So, my point here is not to include any of 3.) in the document, but 
rather propose to design catalog zones in a way that does not preclude 
such future developments.  In particular, it may be in contradiction 
the spirit of recommending an "invalid." NS record value, and of my 
above proposal to recommend catalog zones to live under "internal.".

It seems to me that the most flexibility would be achieved by adopting 
the proposal under 2.b) while not requiring increasing serial numbers, 
and being not too strict on the NS and catalog zone name requirements.

Best,
Peter

-- 
https://desec.io/

---

From: Willem Toorop <[email-masked]>
Date: Tue, 9 Feb 2021 11:21:35 +0100

Peter, Thank you!

I am intrigued by your suggestion to use CSYNC RR to signal SOA Serial
numbers and to help out in. And indeed, the flags in CSYNC's flags rdata
field appear to have helpful names and meanings with respect to clashing
member zones and member zone transitions. What a good catch! How did we
miss that?

We will work to have a new version submitted before the IETF110 deadline
(Monday the 22th). Let's discuss and see if and how we can incorporate this.

-- Willem

Op 08-02-2021 om 18:00 schreef Peter Thomassen:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Ray Bellis <[email-masked]>
Date: Sat, 13 Feb 2021 13:20:26 +0000

> member zones and member zone transitions. What a good catch! How did we

When I had the edit pen on an earlier version of this draft I went to 
some lengths *not* to abuse the semantics of existing RRs that just 
happened to have RDATA that was sorta kinda compatible.

IMNSHO, it's unnecessary, and confusing.  Getting new QTYPEs assigned is 
not hard these days.

Ray

---

From: Peter Thomassen <[email-masked]>
Date: Sun, 14 Feb 2021 13:37:34 +0100

Hi Ray,

On 2/13/21 2:20 PM, Ray Bellis wrote:
> When I had the edit pen on an earlier version of this draft I went to some lengths *not* to abuse the semantics of existing RRs that just happened to have RDATA that was sorta kinda compatible.

The suggestion was not to use anything sorta kinda compatible.  (Coming up with some TXT-based format would be such as hack.)

CSYNC actually fits very well.  The purpose of CSYNC is to signal a "should-update" state, along with flags that govern the serial comparison mode and the question of immediate or delayed action.  As I showed in my original post, this is exactly what's needed in catalog zones.  What exactly are your doubts here?

> IMNSHO, it's unnecessary, and confusing.

It already has been recognized in earlier discussions that it's necessary to handle the transition of zones from one catalog to another, and it has been shown how "the flags of CSYNC" would enable that.  Not addressing any of those arguments, you're suggesting that "it" (?) is unnecessary.

As it stands, I'm interested in learning what would be your alternative proposal for dealing with zone transitions.

As for the confusion, I'm not sure what it stems from.  Who should be confused in the first place?  Zone owners are not going to touch catalog zone internals, so it is auth vendors who would mostly be concerned.  Given that they will (soon) have CSYNC experience anyways, I wonder how confused they really would be.  Perhaps it would be worth gathering some data from them.

> Getting new QTYPEs assigned is not hard these days.

I'm not following how that in itself is an argument for creating a new type.  I'd be delighted if you could clarify.

While assiging one is not difficult, it surely is a non-negligible effort to make all other components of the ecosystem aware.  For example, some people have replication that involves processing through libraries such as dnspython.  This particular library already supports CSYNC.  Requiring a new type would unnecessarily (!) create new adoption barries like that.

Best,
Peter

-- 
https://desec.io/