Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-06.txt

[Joe Abley <[e-mail]>]

On Jul 8, 2022, at 08:50, Bob Harold <[e-mail]> wrote:

> I thought the catalog zone was required to be a valid zone. 

I think it might be worth exploring what "valid zone" might mean. 

All consumers of catalogue zones digest the whole zone as an atomic unit; they don't retrieve it piecemeal or walk the zone. To retrieve a zone you need prior knowledge of a server that hosts it. While I suppose it's possible to identify such a server by means of referrals, I'm not aware of anybody who thinks that is sensible. So there is no need for a functional zone cut above the catalogue zone; the zone can exist in a disjoint, isolated namespace. 

More generally, a zone can be syntactically valid without the servers specified in its apex NS set existing in the global namespace or being reachable, or without an apex NS set at all. The only RR required for a zone to be valid is an SOA at its apex (but see the trailing comment in this reply). Implementations intended for general use might still complain about the absence of an apex NS set for reasons of (quite reasonable) local policy. 

So I think it's ok and expected for a catalogue zone to be weird, but that doesn't necessarily make it invalid. 

> We certainly should not be requiring changes to the code that verifies a valid zone.  Is an NS record part of the validation in some DNS code bases?  If so, it should be mandatory.

If local policy requires an apex TXT record containing a version control string, that might be a local requirement. I think the presence of an NS set is similar. I don't think all possible local requirements need to be anticipated in this draft, although common or expected ones might reasonably benefit from a mention.

> Do the RFC's require an NS record?

"The RFCs" and "require" in the context of the DNS is more usually a matter of religion than science. See above for examples. 


Joe