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
