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

[Paul Wouters via Datatracker <[e-mail]>]

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 ?