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/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
