On Thu, 24 Nov 2022, Willem Toorop wrote:
We have addressed your change requests in the freshly submitted version -08. I'll go over them individually as well as answer your questions inline below. (most of them copied verbatim from the PR for these changes: https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/pull/54 )
Agree with all the changes btw, just wanted to note that:
Sec 6: O: "Although any valid domain name can be used for the catalog name $CATZ, it is RECOMMENDED to use either a domain name owned by the catalog producer, or to use a name under a suitable Special-Use Domain Name [RFC6761]." C: I'm very confused. If I am Yahoo, are you saying that I *could* use microsoft.com as the catalog name? Presumably that woould end badly.... Also, what is a "suitable Special-Use Domain Name"? 10.in-addr.arpa.? localhost.? example.com.? Why doesn't this just say that the catalog name MUST be under a domain owned by the catalog producer? To answer your question. The catalog zone is not (necessarily) part of the global name space. It is part of the control plane and not the data plane. Using an unpublished DNS domain makes sense also to not accidentally leak the zones in the catalog. However operators should certainly not "hijack" just any name from the domain space for a catalog! That's asking for trouble! We've rephrased the paragraph to state this a bit more stronger and clearer to this: Although any valid domain name can be used for the catalog name $CATZ, a catalog producer MUST NOT use names that are not under the control of the catalog producer. It is RECOMMENDED to use either a domain name owned by the catalog producer, or to use a name under a suitable name such as "invalid." [@!RFC6761].
I looked up again what I am using, and I am using "public.nohats.catalog." :) (no please this is not an endorsement for launching a 6761 request for .catalog!!!) But it feels a bit odd to tell people to use ".invalid". Maybe in my case I should have used _catalog.nohats.ca. or something ? Is there a reason not to advise something like that (eg for example.com to use _catalog.example.com)
Sec 7. Security Considerations O: " Administrative control over what zones are served from the configured name servers shifts completely from the server operator (consumer) to the "owner" (producer) of the catalog zone content." C: Ok, so I'm Coca-Cola, and I've contracted with DNS-R-Us to serve as my secondary nameserver service. I have a bunch of zones (coke.com, fanta.net, monster-energy-ultra.org), and so I send you a catalog zone. One day I decide to send you a catalog zone containing pepsi.com (who also uses DNS-R-Us), and hilarity ensues... done (added a sentence saying the consumers MAY reject member zones based on whatever criteria found suitable)
Instead of a MAY, perhaps a SHOULD check might be nicer. But these conditions are hard to specify. What if we prevented the world becoming a better place when coca cola buys pepsi and phases pepsi out. I wouldn't want catalog zones to prevent that :) Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop