Re: [DNSOP] AD Review of draft-ietf-dnsop-dns-catalog-zones
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
Re: [DNSOP] Subject: request for adoption: draft-edns-presentation
Hi Libor and Tom, Thank you for submitting the draft. The first step is to receive feedback from the WG on the mailing list and possibly with a presentation of the draft during a DNSOP WG meeting. If there is sufficient interest from the WG, the DNSOP chairs will start with a formal call for adoption of the document. So for now, WG please provide feedback on the draft and express support that this work is relevant to WG. However, support for adoption is not (yet) polled by the WG chairs. Cheers, -- Benno On 23/11/2022 20:25, libor.peltan wrote: Hi DNSOP, we have prepared a specification document (see below), which fills a gap that appears to be missing currently — The EDNS(0) textual and JSON format. It also fixes a "specification bug" in an existing and related RFC. We believe this draft is pretty much complete and have a first PoC implementation ready. While it would be viable to submit it individually, we believe that the adoption by the WG would be generally beneficial. We would also welcome any improvement suggestions and useful corrections. However, fearing discussion loops arguments about details, we encourage to moderate discussion of details, such as if some fields in a specific option shall be separated by commas or slashes. This document is full of design decisions that might be differently appealing to everyone. The format might seem complicated, but the goal was best possible human readability. And the more general (and important) goal is to make the standard useful, so that it gets adopted by implementations. Thank you for reading the document and for considering its adoption, Libor & Tom Přeposlaná zpráva Předmět: New Version Notification for draft-peltan-edns-presentation-format-00.txt Datum: Wed, 23 Nov 2022 11:20:19 -0800 Od: internet-dra...@ietf.org Komu: Libor Peltan , Tom Carpay A new version of I-D, draft-peltan-edns-presentation-format-00.txt has been successfully submitted by Libor Peltan and posted to the IETF repository. Name: draft-peltan-edns-presentation-format Revision: 00 Title: EDNS Presentation and JSON Format Document date: 2022-11-23 Group: Individual Submission Pages: 19 URL: https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-00.txt Status: https://datatracker.ietf.org/doc/draft-peltan-edns-presentation-format/ Htmlized: https://datatracker.ietf.org/doc/html/draft-peltan-edns-presentation-format Abstract: This document describes textual and JSON representation format of EDNS option. It also modifies the escaping rules of JSON representation of DNS messages, previously defined in RFC8427. The IETF Secretariat ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AD Review of draft-ietf-dnsop-dns-catalog-zones
Thanks Warren,
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 )
Op 30-10-2022 om 11:46 schreef Warren Kumari:
AD Review: Catalog Zones.
Hi there,
Thank you for all of the work you have put into this document; I think
that catalog zones are a really useful feature, and should be documented.
Before I can start IETF Last Call, however, there are some questions
and issues that need to be addressed - the majority of these are
simply editorial changes where the document could be made clearer and
more readable, but there are also some more substantive questions /
places that need additional text.
Thank you again for writing this, and please SHOUT LOUDLY once you've
had a chance to address these and post a new version, or if you'd like
to discuss / have any questions, etc.
SSSHHHOOOUUUTTT!!!
W
Meta: The document has 7 authors, which exceeds the recommended 5.
While we can approve more, but it requires justification - why does
this document have 7?
To guarantee and maximize interoperability we wanted representatives of
some of the Open Source authoritative name server implementations (BIND,
Knot, NSD and PowerDNS) as well as one operator to be authors on this
draft. For two of the Open Source implementations also the persons that
did the actual implementation the protocol were added. So it is both to
express the endorsement from ISC, CZ.NIC, NLnet Labs , PowerDNS and
deSEC, as well as recognition of the actual implementers (which also
collaborated intimately on this draft).
All 7 authors contributed substantially to the draft's content.
Sec 1:
O: "... they must also add/remove the
zone from all secondaries, either manually or via an external
application."
P: "they must also add/remove the configuration for the zone from all
secondaries"
C: Just above it says that the zone is transferred using [AI]XFR.
done
O: "This can be both inconvenient and error-prone; it is
also dependent on the nameserver implementation."
C: I don't have proposed text, but it is unclear what is mean by "it".
Perhaps "... and error-prone; the configuration syntax ..."
done ("and error-prone; in addition, the steps required are dependent")
O: "This document describes a method in which the catalog is..."
C: Perhaps "list of zones" instead of catalog? Otherwise it feels a
bit like a circular definition. Just a thought...
done
O: "As zones are added to or removed from the
catalog zone, these changes are distributed to the secondary
nameservers in the normal way."
C: Well, no - it's really not "in the normal way" - the normal way is
that you edit the config file. I understand what you are trying to
say, but I don't think that this says it. I propose just "As zones are
added to or removed from the catalog zone, these changes are
distributed to the secondary nameservers." or "... this zone is
distributed to the secondary namesservers (just like any other zone)."
done similarly (also rephrased an adjoining sentence)
Sec 3:
O: "Catalog consumers MUST ignore any RR in the catalog zone which is
meaningless or useless to the implementation."
C: Ourgrgh... Can you reword this? "useless to the implementation" is
really really vague, and this *will* result in DISCUSS ballots.
done ("meaningless to or otherwise not supported by the implementation")
O: "The SOA record's SERIAL, REFRESH, RETRY and EXPIRE fields [RFC1035]
are used during zone transfer."
C: Erm, "are used" how? Perhaps either drop this sentence (it doesn't
seem to add anything), or "The SOA record's SERIAL, REFRESH, RETRY and
EXPIRE fields [RFC1035] are used during zone transfer, just like they
would be for any other zone"?
done (dropped)
Sec 4:
O: "More than one record in the RRset denotes a broken
catalog zone..."
C: Can you come up with a better word than "denotes"? To me "denotes"
implies that the user has *chosen* to do this. Perhaps "results in"?
Sorry I don't have a better suggestion.
done ("indicate"), both in Section 4.2 and in 4.4.1. -- Potential
alternatives: "signify", "are a sign of"
O: "The TTL field's value is not defined by this memo."
C: Erm... perhaos "The TTL field's value has no meaning in this
context, and [MUST/SHOULD] be ignored."? Otherwise someone will ask
what it means...
done, also swapped and merged with subsequent sentence.
Sec 4.4.2.1. Example
I think that the example is quite unclear, and it will raise more
questions than it answers -- for example, people are going to ask who
exactly parses "operator-x-sign-with-nsec3", and they will also try
and figure out where these verbs (e.g 'nodnssec') are defined. I think
that you need to clarify that the meaning of the text records are
opaque / defined between the
[DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-08.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : DNS Catalog Zones Authors : Peter van Dijk Libor Peltan Ondrej Sury Willem Toorop Kees Monshouwer Peter Thomassen Aram Sargsyan Filename: draft-ietf-dnsop-dns-catalog-zones-08.txt Pages : 21 Date: 2022-11-24 Abstract: This document describes a method for automatic DNS zone provisioning among DNS primary and secondary nameservers by storing and transferring the catalog of zones to be provisioned as one or more regular DNS zones. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-catalog-zones/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dnsop-dns-catalog-zones-08.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-catalog-zones-08 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Subject: request for adoption: draft-edns-presentation
Hi Libor, Tom, Thanks for this, I believe this will be a good extension to the EDNS specification to help operators hunt down issues. I support its adoption by the WG. Should the WG disagree, please submit it as an individual submission. On Wed, 2022-11-23 at 20:25 +0100, libor.peltan wrote: > Hi DNSOP, > we have prepared a specification document (see below), which fills a > gap > that appears to be missing currently — The EDNS(0) textual and JSON > format. > It also fixes a "specification bug" in an existing and related RFC. I wonder if it should update RFC 6891 and all related OPTION RFCs as well. I also wonder if it could make sense to add guidance on how to choose the correct presentation format for newly drafted EDNS options so future option-drafts and documents have presentation formats in there. > We would also welcome any improvement suggestions and useful > corrections. However, fearing discussion loops arguments about > details, > we encourage to moderate discussion of details, such as if some > fields > in a specific option shall be separated by commas or slashes. > This document is full of design decisions that might be differently > appealing to everyone. The format might seem complicated, but the > goal > was best possible human readability. > And the more general (and important) goal is to make the standard > useful, so that it gets adopted by implementations. I had a cursory glance and it looks quite complete. I'll try to get a better reading in soon. Best regards, Pieter ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
