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

[Peter Thomassen <[e-mail]>]

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/