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 <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. ---------------------------------------------------------------------- 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. ### 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 ? _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop