Re: [DNSOP] Paul Wouters' Discuss on draft-ietf-dnsop-dns-catalog-zones-08: (with DISCUSS and COMMENT)

[Willem Toorop <[e-mail]>]

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 part, will these ever move to the standard part? or will non-standard extensions become a defacto standard? But I guess these could end up in a separate followup document.

Custom properties will remain in the specific implementation that made 
them I suppose (for backwards compatibility). Our document says that 
custom properties should be namespaced, quoting:

   "Implementations SHOULD namespace their custom properties to limit 
risk of clashes with other implementations of catalog zones. This can be 
achieved by using two labels as the <property-prefix>, so that the name 
of the implementation is included in the prefix: 
<some-setting>.<implementation-name>.ext.$CATZ."

If more than one implementation define a similar custom property, they 
can be standardized via RFC or via a lower barrier procedure. In the new 
version of our document, there will be a IANA registry request for 
properties, with assignment policy "Expert review" ( 
https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/pull/67 )


> ### 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 <do custom smart things>", 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.

We have made the "MAY clause" stronger with a SHOULD:

"To prevent unintended provisioning of zones, consumer(s) SHOULD scope 
the set of admissible member zones by any means deemed suitable (such as 
statically, via regular expressions, or dynamically, by verifying 
against another database before accepting a member zone)."


> ----------------------------------------------------------------------
> 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 it will get cut out before publication anyway, but if a
> new draft is done based on IESG review comments, please also clarify this.

We've extended the Appendix with this commit:

https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/commit/527e7ee


> ### NITS
> 
> ```
>          such properties MUST be represented below the label ext.
> ```
> I would use quotes, eg "ext." to make it clear this is literal string.
> 
> ```
>          Implementation and operational Notes
> ```
> 
> Weird capitalization ?

Thanks, the NITS are addressed in this commit:

https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/commit/2a0f8a4



We're once more reviewing all the changes we've made and will probably 
(if all is well) upload a version -09 with them tomorrow.

Regards,

Willem on behalf of the draft-ietf-dnsop-dns-catalog-zones co-authors