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

[Willem Toorop <[e-mail]>]

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:
> 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
> 
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>