Re: [DNSOP] Paul Wouters' Discuss on draft-ietf-dnsop-dns-catalog-zones-08: (with DISCUSS and COMMENT)
Hi Paul, Hi Murray,
Hereby the responses to Paul's review. I've CC'ed you Murray, because
you mentioned explicitly that you support Paul's DISCUSS positions.
Op 04-01-2023 om 05:05 schreef Paul Wouters via Datatracker:
DISCUSS:
--
## DISCUSS
### Section 4.3.1 Versioning
What should one do if the version supported is lower than the version of zone
received? Attempt to understand it? preventively fail?
Are version 1 and 2 compatible? In what ways are they not? Should perhaps
version 1 catalog zones always be ignored ?
Version 1 and 2 are not compatible. Version 1 was bind's original but
not standardized idea/implementation. New implementations are better of
implementing version 2 because the exact details of version 1 are not
standardized (and thus kind of unknown).
Commit
https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/commit/8eed29f
adds the explicit mention that version 1 catalog zones should also be
considered broken by catalog consumers that only have version 2
implemented to the enumeration of section 4.3.1. Schema Version (version
property).
### Group Properties
It seems like Section 4.4.2 defines "group properties" that are standardized,
while Section 4.5 specifies Private Use group properties.
There are no "group properties", only "group property *values*". The
values listen in 4.4.2 are only examples and not standardized. Section
4.5 is about private use properties and is not involved in group values.
But there is actually
no registry created for Group Properties, and no definitions other than
"examples" are given. This makes the status of, for example "nodnssec",
unclear. Is this a custom (eg bind implementation only) property or is this
really a custom private use entry, in which case the example is bad as it
belongs under .bind.ext.
Since "nodnssec" seems a real use case, why does this document not create an
IANA registry for Catalog Zone Group Properties and places "nodnssec" in it?
We have done several modifications to the draft to clarify this better.
- We refer to the values of group properties now as "group property
values" or even simply as "group values".
- The group values now have non-descriptive names as to not suggest
that they have meanings in implementations (it's the operator that
determines the "meaning" and not the implementation)
- We have extended the lines about catalog producers publishing at
two consumer operators and how mapping of group values is a matter of
those producer/consumer relationships, so it now reads:
"Implementations MAY facilitate mapping of a specific group value
to specific configuration configurable on a per catalog zone basis to
allow for producers that publish their catalog zone at multiple consumer
operators. Consumer operators SHOULD namespace their group values to
reduce the risk of having to resolve clashes."
The co-authors do recognize that a registry for *properties* is a good
idea and have added that to the draft (with PR
https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/pull/67 )
### 5.3 "MUST be removed"?
```
Only when the zone was configured from a specific catalog zone,
and the zone is removed as a member from that specific catalog
zone, the zone and associated state (such as zone data and DNSSEC
keys) MUST be removed.
```
What is "removed" here? I think perhaps it should be limited to "MUST no longer
be served". For example, it would be bad if the operator made an error, and
ended up briefly removing the zone and "removing" (aka destroying) some private
DNSSEC keys, complicating the zone restoration. Also, perhaps the
implementation wants to simply keep the state on disk but move it to a
/var/lib/xxx/zones/archived/ directory. The use of "remove" sounds like that
might not be allowed.
We have added a line explicitly stating this operational consideration
to Section 5.3. Member zone removal:
"Consumer operators may consider to temporarily archive associated
state to facilitate mistake recovery."
### Operational Considerations
What are the risks and benefits of Extension group properties?
Should one try to standardize these instead? Why is this document not doing
that based on its operational experience with eg bind and knot and powerdns ?
This document will standardize three properties: "version", "coo" and
"group". Implementations can create their own custom properties below
the "ext" label. Bind9 has several custom properties ("primaries",
"allow-query" and "allow-transfer"), but the other implementations don't
have them yet. When the other implementations will create similar custom
properties (from operator feedback) they can be considered to be
standardized as regular (and not custom) properties and don't need to be
below the "ext" label.
if one is experimenting with further properties in the extension
[DNSOP] Paul Wouters' Discuss on draft-ietf-dnsop-dns-catalog-zones-08: (with DISCUSS and COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-dnsop-dns-catalog-zones-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-catalog-zones/ -- DISCUSS: -- # Sec AD review of draft-ietf-dnsop-dns-catalog-zones-08 CC @paulwouters Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. This review uses the format specified in https://github.com/mnot/ietf-comments/ which allows automated tools to process items (eg to produce github issues) Note that I am a happy user of catalog zones since a few months. While I originally thought this seemed like an "if all you have is a DNS hammer" solution, it actually has some very clear advantages over other configuration synchronization methods. Thanks for this work, I am a fan! I do have some issues I'd like to discuss though :) ## DISCUSS ### Section 4.3.1 Versioning What should one do if the version supported is lower than the version of zone received? Attempt to understand it? preventively fail? Are version 1 and 2 compatible? In what ways are they not? Should perhaps version 1 catalog zones always be ignored ? ### Group Properties It seems like Section 4.4.2 defines "group properties" that are standardized, while Section 4.5 specifies Private Use group properties. But there is actually no registry created for Group Properties, and no definitions other than "examples" are given. This makes the status of, for example "nodnssec", unclear. Is this a custom (eg bind implementation only) property or is this really a custom private use entry, in which case the example is bad as it belongs under .bind.ext. Since "nodnssec" seems a real use case, why does this document not create an IANA registry for Catalog Zone Group Properties and places "nodnssec" in it? ### 5.3 "MUST be removed"? ``` Only when the zone was configured from a specific catalog zone, and the zone is removed as a member from that specific catalog zone, the zone and associated state (such as zone data and DNSSEC keys) MUST be removed. ``` What is "removed" here? I think perhaps it should be limited to "MUST no longer be served". For example, it would be bad if the operator made an error, and ended up briefly removing the zone and "removing" (aka destroying) some private DNSSEC keys, complicating the zone restoration. Also, perhaps the implementation wants to simply keep the state on disk but move it to a /var/lib/xxx/zones/archived/ directory. The use of "remove" sounds like that might not be allowed. ### Operational Considerations What are the risks and benefits of Extension group properties? Should one try to standardize these instead? Why is this document not doing that based on its operational experience with eg bind and knot and powerdns ? ### Security Considerations Dealing with high value domains eg gmail.com is missing. If a large DNS hoster would enable catalog zones for its customers, how can it prevent rogue takeovers? If fully automated, it can never be safely deployed. If each zone needs a manual check, well than we don't really have "catalog zones" auto-populating name servers. Is there an expectation that nameservers can do some authorization call before adding a new domain that is already delegated elsewhere? Eg if GoDaddy uses catalog zones, and I am their tiny customer with "nohats.ca" and then add a new zone "gmail.com", that could cause a significant disruption. Especially if the malicious person would create another domain that depends on "gmail.com" in such a way that GoDaddy's servers will start sending "gmail.com" data in their additional data reply for other domains. The section only has a "consumer(s) MAY ", which in my opinion, is far too weak as a security control. As the above example shows, it is just too easy to start poisoning nameservers via implementations that skip this one MAY clause in the Security Considerations. -- COMMENT: -- ## Comments ### Appendix A The appendix implementation status only mentions version 2 for bind. Presumably, the other implementations never supported version 1, but this could be made more clear (although granted, it is a little weird so late in the process to do this as
