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

Peter Thomassen <peter@desec.io> Mon, 08 February 2021 17:00 UTC

Return-Path: <peter@desec.io>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D393A1292 for <dnsop@ietfa.amsl.com>; Mon, 8 Feb 2021 09:00:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=a4a.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKJrjUh4EqhF for <dnsop@ietfa.amsl.com>; Mon, 8 Feb 2021 09:00:52 -0800 (PST)
Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D4033A1288 for <dnsop@ietf.org>; Mon, 8 Feb 2021 09:00:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Type:MIME-Version:Date:Message-ID:Subject:From:To: Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=t+GYJhGRpb4VNJD3dRf6ZLYRYkenmDjd9nkx1jz3ylY=; b=FcQcIOnAhTpmlvkrSZ6ZvTGG+8 49wpysc/Vy3ifM4ciFx6uLdfzuXuCeScnWbU5z1pG0G+nKPO9n5xgnlkoNkB9K7PikdjtMAjbiZHt 7JcGBLs/dZrWEQ9SS/8EiyL63/maF72e0czcjia32s0jFunIO73/3smD5vQPIvf1H0DkIvWwTHtn/ nYS74p1DXKwoIFBSVYY1AHQGyxXfYYZY6agU9U8kV6+jaE+cbkrTaHi1m29bROzH8qOS0f6tG5V0b +Ll+I52DEDu23K5eSIcqRT1yDGaceLwvAFJGOuSJQ8SPwTBnRQZbt4uO/8OWTuoXYsJaHGsa7HKMx MG5XcqwQ==;
Received: from [2a04:4540:5f0d:d00:f4b3:d9a7:e3b9:e6cd] by mail.a4a.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <peter@desec.io>) id 1l99u6-0006CO-IW for dnsop@ietf.org; Mon, 08 Feb 2021 18:00:50 +0100
To: dnsop@ietf.org
From: Peter Thomassen <peter@desec.io>
Autocrypt: addr=peter@desec.io; prefer-encrypt=mutual; keydata= xsFNBFRjVn0BEADXqtra70yxQrT4MQ9DEhN0mxG6XRAOHE6nP18mqxwSlcET7D6w+z3h4ole v0tyvUU02c2wg04X8WVfjoHnAvIa1dfUcNpB1+QmfFsw0xIJlbT1ogHkMiPQqR4ChDvE3ND/ 6YCS5+HT6hY+tfU+hpLsKw4l+u1Pg2NPVLYosET1jU84b7xhFnoicnCV3kUNltLtxLKSBAfk AXtp1AWWKJbfCr3y0qKElMriicoe5DUZfLrZK2iPcWBxh+n7KMO2g7aqx3aQqwW1+S7Sq7Is l6iSurYfIcHb4AfUy4o5nPB8kKACR6BuJmkEQ5WLuTGruWA2fcxaNpICmolMinTzW1CrIjgN PoskMYCNIZ2uWxS6LN8hBiGCRL4h9aL4wuT09SvR13oAPI1HD5ph+mH6wD37/ONBXrdjcFNb 1l/uVkHU/SwwcKDJOsX18T60Ao00fciTbFHgmKtFube0xGK/vjh461TyU+xKD8Orvyeovvxy MzCwM3UVq/dkdG2Ys/7Qy/4bUC1nJEwKlLv7ZTdtSckdoU2M6JpPX6i4KDB2YCMbwtqJ842z 8A/UuE2bL9aDimh/sF8WgPIhlxqF1STNqW1JTIbDPv8HeZnM4nyJOUWStj4uRiETQhBClPLz YWtnR+EUsfbSLy81vfupbMqRasDlt6aASobgn+K7Rb1Xs/mDnwARAQABzSBQZXRlciBUaG9t YXNzZW4gPHBldGVyQGRlc2VjLmlvPsLBeAQTAQIAIgUCVGNWfQIbIwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AACgkQ79YUOj7yLS88Dg//SbHnFGrtaImEiM69wyj4GzWnuGk9/upCym/R RzdBALCYHU9FUFFHwusiO9A0pnO8qv/GEtqqTHrcL205a6FTivkdZmOsWuN4oo7r4HBc/taI FLLUDg2wd8q4m4387sYEqrc3olGfyRB6hrMtEWVJLXHJmpcrxAaI1F2QO4Bu7kcdTnyGFz/p ZD8XAof2TWHqJb2ux69DFhiAJeAZlV+h9QrxTedL84l4hq3x1VWsnOEFaCJiThDX920kTnhJ ijrDocgAbmQBCniPACpPHYhBhmCJxfVqgfMuLMNsukOmKxsGcGV6rO1zB5ZUhm3O/Ixk6ow3 6FDKALWihg6Z4P/cJYySMn0iqvHkO8ryT9oJKX//mKaYoF6henXDRLCcRjKwGxFQTEgX+6yc pjgvX3rlypjkPT5ho4yEc5ePkQ2gIIHhvZburm1Zr4nDPx6v8+3XUjpXBRTWQ8/0/h0rtLJe yOPwGJxcfKf/GutTCqiio0mS01mIY9c2i7JWcljlIuSEUit6CHotc5lBOm2GJwguRJG6cXPY SQecwBdcjH3RTzBOv/DN6xWAIV7BmbX/e7DSGAc60mBO1/M0ut+a6CkxRQK8TaE3B3zh1/QO nG0XvtZfIY8ZYdTrdEDSV1Pj5pof/fqhhegHRxN2qi4qIuVcrW0jsUsx10IgAynHR7qQKsvO wU0EVGNWfQEQAPBA8iPCS4ZRX8stW0WuW7579axSq/Luyik4MWDFalt68lzvUbV0f6faN15+ aV7VwMTw3rSa2tP0U8crYAAAZ5NrRHXlYms5BK9vsi1322dAvhyNRawdprP627SO+Ez/84tY xz1X3M9esbN7gpJtHP6mHW76zYpT447v6c2qlbldjobZTDb6kKSGFCIrPJz9M4jVfya+ovxe 2Ab7hn2R0CcyMHATV5g1Ry0XXaj5y3bWypActbG9nflRn3NjhHZynu+WEPDUJCO8kNVNYKOw HObNTeaLvgvU0ONB8pYJv35kDXMhZLwo5MJuJd5i54CXwpo9mECwLJT1RpJi7u98nBrWyyaH s2brG9LPCRKBKOhiHFu57H+cElh+kOvehuS7DFTzjqDwJlkQzP5Hq0G++hZxfdYocKdcdFoh RP3dtDAe+Lfiy9qzJicZ6ACbzoQIN58xj0VWAn1W7SuMErOjv84D/FiXHD2Kxtx09wQl8vH0 Nbh9UgyDBNupToM0ixT+8Ko8eBuYHR53RPxshQhFw4EMIhXiOaxNe1W2Z95QPnYhUGOMoy3I v4fxMQUHa4kZSF2qxsFB1Cxol/aBPGwkwoqUvzp23pLQtJ6youYXtLgvx3pR4L52Q5CUzHMa HvM67XWgW1KqtnvNBXN9PwtDz/a9fQX1YO4CegrXv8C9Ro+LABEBAAHCwV8EGAECAAkFAlRj Vn0CGwwACgkQ79YUOj7yLS8rXA/9EGX2QRfJS94JTdtseu7saTK9a3IKwk6E33GpfXyUVpMt sOqV756XQwULZSWoxInRQtWojA8pQxDUYrbA4MpX0Efr2Dx1xIsJ5F3JajOqViB1SbOD2m0f bxXbcoWKitsKoag2SlvNOd8rD9FcgDvrkacnaQZcZE8DyyGx0JU451tfoD/igu85NZpTDaWG 6fth7QRlxmdGWrGXRdXAP29jq1n0I1wIyF/bXlZ7MXjOSsfyPddzsnHFTvNMZKps0QXNF+hi ESg9chIeo/IFDDVu6pCtm6mftojx84rczTZiNk8r2T3TU4N8uwWtXn/nj9xd61pnxD0xkTPH zxJrCs59WSfYqj3aFNkWO3Lg0/HGnO9wHQKMXcGPsnKITHVzxCNBQtVHomNA7ds6Kt3/WJgS pU2ciICvrpvKgPNWQ0d/SeY3vYIRvDLZ12Svx6M3eXDrsgZOT5be7kGVr3t7dBOYKcRHkZUq kU1kCcgp0vetISVDOc5fkpdUkAtd5/13pIpz4ikVR3OM4Br4XMVShm6RvoP4pyA+ftCi1+bw 0UbRCrnHgnG+wtCf5nMDGVLc04vITnII+ESZqlF02a1IFj0Z2MuQK2Oszl2Nsx/LG60G1e/R pzKEXIIJgHfbwUCWtV1zQu6v9Ng5H8EqVeWcdaPUwSQMGcDg/sPa4s/OxhgrYBg=
Message-ID: <2c5d7166-8d1d-4948-2fc2-4bf732d109f8@desec.io>
Date: Mon, 8 Feb 2021 18:00:49 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0m13lOaiibjpASRa4EDWDalfPkHsrfWLx"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DcdnwolVVpMjQzR4gtlrLyXsYtk>
Subject: [DNSOP] Various Thoughts on Catalog Zones (draft-ietf-dnsop-dns-catalog-zones-01)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Feb 2021 17:00:55 -0000

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/