[DNSOP] Paul Wouters' Discuss on draft-ietf-dnsop-dns-catalog-zones-08: (with DISCUSS and COMMENT)
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 ", 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
Re: [DNSOP] Private-use underscored DNS node name
It appears that Eric Orth said: >-=-=-=-=-=- > >Am I interpreting the idea correctly that the goal here is to be able to >create names that are only usable as alias targets? > >If so, interesting idea, but I'm not sure such a mechanism could actually >be created and widely implemented. I don't think there's enough motivation >for all the relevant implementors to add code to block a previously-allowed >name for non-alias use or to allow a previously-disallowed name just for >alias use, ... I have my doubts about whether this is really a problem that is worth solving, since it's not very hard to invent alias hostnames that are unlikely to collide. You could for example prefix "service8000alias." to the aliased name. But if you want to do it, since the alias is a hostname, using underscores would be a bad idea since several decades of software know that hostnames can only be LDH. As part of IDNA we reserved all hostnames of the form LL--stuff where LL is letters. The only LL currently in use is XN, for IDN A-labels. I suppose you could use AL--stuff labels for hostnames that are supposed to be aliases. There may be software that rejects LL-- names but I expect it's a lot less than stuff that rejects underscore names. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements
Hi Vladimir and Florian, Thanks for the comment regarding the use of 5011, to update the trust anchors. There are two situations where TAs need to be updated: * 1) configuration so the server instances are started with the up-to-date TA. * 2) a running resolver instance that has been started with the old TA and that needs a new TA to be considered. 1) configuration: TA trust store is an essential element of the configuration, and the document recommends having a special process to ensure every new resolver instance starts with the up-to-date TAs. TAs are so essential in the elaboration of trust that special care must be considered. This means that you need a robust mechanism to update the TAs trust store. Many DRO will not implement that process and instead rely on software updates to delegate the TA trust store update to the software vendor. If the DRO is willing to have a *special/specific* additional TA that is not updated delegated to the software vendor, the DRO will have to put in place such a mechanism. This is a critical operation and the DRO must have strong reasons to do so and must balance the additional operational risks versus the additional benefits. Given the essential aspect of the TA trust store, we recommend updates to be handled by an automated process (as opposed to manually being performed) BUT we also recommend the process to be manually supervised, that is with a manual confirmation. This mechanism is likely to require a specific relation between the DRO and the TA issuer with potentially the mechanism, being out-of band. To that point 5011 is probably not the best choice as mentioned by 5011 itself in section 8.3. 2) running servers For running resolvers, there is a need to ensure that the resolver is using the up-to-date TA. For this we recommend to follow 5011 that indicates how to automatically put significant trust into the newly published DNSKEY. On the other hand, if resolvers are retarted every days we may not need to have 5011 and monitor the roll over. I think that is the purpose of your comment. My impression is that there were some confusions in the text where 5011 was used. When it is limited to the running resolver, I would recommend enabling 5011 when the TA signer implements 5011 in case the software is not updated in a timely manner - or at least let the DRO decide whether it is willing to enable this option as a sort of insurance - even if it is relying on the software update as a general mechanism. I think it might be a bit different from what you proposed initially, which is to leave that to DRO with DNSSEC strong expertise and recommend to only stay with software updates. If there are any strong feelings on just relying on software updates and leaving 5011 to DNSSEC experts, I am also fine to push toward such a direction. I updated the text as follows: * clarifying TA updates for configuration versus running instances * clarifying 5011 dot not apply for updating configuration - at least as a primary mechanism * emphasize that the non default model is only recommended for DRO with DNSSEC expertise * adding that TA update for running resolver may be performed also by software update under the condition the DRO is likely to ensure a very recent release is run. * add a recommendation that when 5011 is used, the signer needs to implement 5011 timings. The changes can be seen there: https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/commit/dbb75b72a1806520ac77cf04424b0f6de0df29b5 Yours, Daniel On Sun, Nov 27, 2022 at 7:26 AM Florian Obser wrote: > On 2022-11-25 12:26 -05, Daniel Migault wrote: > > On Wed, Nov 23, 2022 at 10:29 AM Vladimír Čunát < > vladimir.cunat+i...@nic.cz> > > wrote: > >> I am surprised you would not recommend RFC 5011 > >> > >> 5011 needs persistent state, a thing that resolvers/validators often > don't > >> need at all otherwise (cache is safe to delete). 5011 doesn't always > work, > >> so you need to combine with some fallback mechanism(s) anyway - for new > >> installations and for stale ones (missed rotation). Root rollover has > >> happened only once in history, non-root TAs aren't that common, and 5011 > >> algorithm isn't very simple, so the code can easily get some bugs > without > >> anyone noticing until it's too late. > >> > >> Lots of down-sides, so I rather put the TAs into SW updates, for the > root > >> TA case at least. I'd recommend trying to avoid non-root TAs, but if I > had > >> to choose, I'd put them into configuration. Again a thing that I have > to > >> provision *anyway*, so I get the occasional TA updates basically for > free, > >> without needing to worry about those 5011 disadvantages. (occasional = > >> 5011 defaults to requiring 30 days of overlap) > >> > >> > > Oh! sure for the TA. My understanding of the text is that it recommends > > 5011 for running instances, but that new instances are configured with > > up-to-date TA that in most cases are updated by software update. So
Re: [DNSOP] Private-use underscored DNS node name
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 In this example, there are two services provided by one endpoint, for a total of three domain names. Using "target.example." for the HTTPS record would incorrectly assert that it provides an HTTPS service for itself. It would also prevent that domain from using HTTPS records for itself with different parameters. Using another domain, such as "alt.target.example.", would be similarly misleading. RFC 8552 reserves all global underscored node names for use according to an IANA registry, and specifies that they are meant to act as attributes for the non-underscored parent domain. That makes them ideal for this scenario, except that there is no suitable node name assigned: using an unassigned node name could cause issues if it is assigned in the future. What I am proposing is simply that "_private" be added to the registry, with no meaning beyond assuring that IANA will not assign it for something in the future. To put it another way, no special meaning will ever be ascribed to it by anyone other than the domain holder, and as a result there will never be a collision. This is basically the same as the "_example" node name that is already reserved, except intended for actual use. target.example. 2001:db8:: target.example. HTTPS 0 . _443._tcp.target.example. CNAME local-user._private.target.example. _443._quic.target.example. CNAME local-user._private.target.example. local-user._private.target.example. HTTPS 1 pg6mmjiyjmcrsslvykfwnntlaru7p5svn6y2ymmju6nubxndf4pscryd.onion. alpn="h2" local-user._private.target.example. HTTPS 2 target.example. alpn="h3,h2" local-user._private.target.example. TLSA 3 1 1 8a9a70596e869bed72c69d97a8895dfad86f300a343feceff19e89c27c896bc9 alfa.example. HTTPS 0 local-user._private.target.example. bravo.example. HTTPS 0 local-user._private.target.example. -BEGIN PGP SIGNATURE- iMwEARYKAHQWIQST9JhYTT2FVNyHHwCUsC6j0LZIGwUCY7SYaFYYJ2h0dHBzOi8v b3BlbnBncGtleS5zYWtsYWQ1LmNvbS9maW5nZXJwcmludC9GRERGQzRBNEE2N0Qw NEVGRkVCOEU0MjQ5Q0EyMTQ5NTgzRURCRjg0JwAKCRCUsC6j0LZIG1DaAQC31elj 44+eHSaC1z7NBsI45Zhk7ZjQDzs6xH5xgchwEgD/QOFWr+j8JqFsWAMbya+CriWZ 6grC3Dg+SxFfE8Y2sgg= =P1yq -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Private-use underscored DNS node name
Am I interpreting the idea correctly that the goal here is to be able to create names that are only usable as alias targets? If so, interesting idea, but I'm not sure such a mechanism could actually be created and widely implemented. I don't think there's enough motivation for all the relevant implementors to add code to block a previously-allowed name for non-alias use or to allow a previously-disallowed name just for alias use, so it just doesn't seem feasible unless all the implementations are already handling underscore-prepended names the way we want and I don't think that's the case. Too much stuff would just allow "_private" names to be resolved as a normal hostname, and I don't think you're going to convince everybody that it's worth the effort to add special code to block it. On Tue, Jan 3, 2023 at 2:45 PM Ben Schwartz wrote: > Hi Jeremy, > > This is an interesting idea, but I think it's difficult to understand in > the abstract. Could you provide some example zone files for the use case > you're considering? > > It sounds like you're concerned about the possibility that non-underscored > names could be misconstrued as host names, even though they don't hold any > address records. However, I don't believe there is any general expectation > that DNS names must be the names of hosts just because they are > syntactically valid hostnames. > > Thanks, > Ben > > On Thu, Dec 8, 2022 at 6:39 PM Jeremy Saklad 40saklad5@dmarc.ietf.org> wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA512 >> >> BCP 222 sets out guidelines for using underscored DNS node names, which >> are important for any record that should not be mistakenly interpreted as >> an actual host. However, it doesn’t seem to set aside a name for private >> use, which would be particularly helpful for deduplicating RRsets. >> >> As an example, draft-ietf-dnsop-svcb-https-11 suggests using AliasMode >> HTTPS records to maintain a separation of concerns. I’ve found this helpful >> myself, as it allows me to have the configuration for a web server and >> single onion service in one RRset, with each of the served hostnames >> aliasing to that. >> >> However, that suggestion recommends using non-underscored TargetNames, >> which have the side-effect of incorrectly stating that the TargetName is >> itself an origin. It would make much more sense to alias to an underscored >> node name for this. >> >> Upon looking into my options, however, I can’t find any >> standards-compliant way of actually doing that. The closest option is >> “_example”, which doesn’t seem meant for actual use. Am I missing >> something, or is it outright impossible to name arbitrary DNS records >> without the possibility that future specifications ascribe unwanted meaning >> to it? >> >> If I am in fact not missing anything, I propose registering “_private” as >> a reserved node name for all RRTypes. >> -BEGIN PGP SIGNATURE- >> >> iMwEARYKAHQWIQST9JhYTT2FVNyHHwCUsC6j0LZIGwUCY5J1DVYYJ2h0dHBzOi8v >> b3BlbnBncGtleS5zYWtsYWQ1LmNvbS9maW5nZXJwcmludC9GRERGQzRBNEE2N0Qw >> NEVGRkVCOEU0MjQ5Q0EyMTQ5NTgzRURCRjg0JwAKCRCUsC6j0LZIG1hwAP9fQoJv >> UrWZA8GnQWK+sStyneA4t5IsTOmOSdto4wcziQD/ajah2eIyUr8rOkRoM2DveTQF >> bl6EvRxLsQR2TjCmBQc= >> =xghv >> -END PGP SIGNATURE- >> ___ >> 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 > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Private-use underscored DNS node name
Hi Jeremy, This is an interesting idea, but I think it's difficult to understand in the abstract. Could you provide some example zone files for the use case you're considering? It sounds like you're concerned about the possibility that non-underscored names could be misconstrued as host names, even though they don't hold any address records. However, I don't believe there is any general expectation that DNS names must be the names of hosts just because they are syntactically valid hostnames. Thanks, Ben On Thu, Dec 8, 2022 at 6:39 PM Jeremy Saklad wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > BCP 222 sets out guidelines for using underscored DNS node names, which > are important for any record that should not be mistakenly interpreted as > an actual host. However, it doesn’t seem to set aside a name for private > use, which would be particularly helpful for deduplicating RRsets. > > As an example, draft-ietf-dnsop-svcb-https-11 suggests using AliasMode > HTTPS records to maintain a separation of concerns. I’ve found this helpful > myself, as it allows me to have the configuration for a web server and > single onion service in one RRset, with each of the served hostnames > aliasing to that. > > However, that suggestion recommends using non-underscored TargetNames, > which have the side-effect of incorrectly stating that the TargetName is > itself an origin. It would make much more sense to alias to an underscored > node name for this. > > Upon looking into my options, however, I can’t find any > standards-compliant way of actually doing that. The closest option is > “_example”, which doesn’t seem meant for actual use. Am I missing > something, or is it outright impossible to name arbitrary DNS records > without the possibility that future specifications ascribe unwanted meaning > to it? > > If I am in fact not missing anything, I propose registering “_private” as > a reserved node name for all RRTypes. > -BEGIN PGP SIGNATURE- > > iMwEARYKAHQWIQST9JhYTT2FVNyHHwCUsC6j0LZIGwUCY5J1DVYYJ2h0dHBzOi8v > b3BlbnBncGtleS5zYWtsYWQ1LmNvbS9maW5nZXJwcmludC9GRERGQzRBNEE2N0Qw > NEVGRkVCOEU0MjQ5Q0EyMTQ5NTgzRURCRjg0JwAKCRCUsC6j0LZIG1hwAP9fQoJv > UrWZA8GnQWK+sStyneA4t5IsTOmOSdto4wcziQD/ajah2eIyUr8rOkRoM2DveTQF > bl6EvRxLsQR2TjCmBQc= > =xghv > -END PGP SIGNATURE- > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Dnsdir last call review of draft-ietf-dnsop-dns-catalog-zones-08
> On Jan 3, 2023, at 12:48 PM, Peter Thomassen wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > Hi David, > > Thank you for your review. Please see inline. Thanks! Also see inline. > > On 12/27/22 18:14, David Blacka via Datatracker wrote: > >> Second, some comments: >> This draft is not quite definitive on whether or not Catalog Zones are >> directly >> queryable. Instead, it strongly discourages them from being queried, but >> usually using non-normative language. (The exception: the security >> considerations RECOMMEND limiting who can query the zone.) I wonder if the >> document would be better served with a more up-front statement on this issue? > > Good point -- the text indeed was a bit hand-wavy in this regard. I modified > as follows: > > - Replace (with better wording) or remove "casual" (non-normative) references > to DNS queries (e.g. when talking about TTL values) > > - Add justification why limiting queries is RECOMMENDED (namely, to prevent > unintentional exposure of catalog zone contents) I looked at your changes, and I think those updates work for this. > >> An appendix showing a full example catalog zone would be a nice addition to >> the >> document. There are examples throughout the text demonstrating specific >> concepts, however, so it isn't clear that such an appendix is strictly >> necessary. > > Done, based on an example from the Knot DNS documentation. (This has also > been requested by other reviewers.) Also great! > >> Catalog zones appear to be intentionally not fully interoperable between >> completely un-coordinated instances. Is this interpretation correct? I >> think >> my basic confusion arises from not seeing what can be done with catalog zones >> *without* custom properties. > > This is correct. > > As to "what can be done without custom properties": The main use case is > provisioning and deprovisioning zones on secondary DNS servers. > > Without catalog zones, the secondary has to either somehow retrieve the list > of zones via an out-of-band channel, or rely on heuristic processing of > indirect signals from the primary. For example, a common way for removing > secondary zones has been to let them "expire": check periodically whether the > primary still knows the zone, and if it doesn't for say 1 week, assume it's > not a glitch and remove the zone. This scales badly (requires lots of > checking queries) and also risks deleting a zone prematurely when there > actually is some other kind of problem causing the primary to not respond as > expected. > > This is the use case in which catalog zones are expected to be interoperable. > Beyond that, vendors are free to map whatever zone settings their > implementation offers, by means of custom properties. Examples of this could > be zone-specific rate limiting or statistics collection. Ah, I wasn’t clear. I understand the overall use case for the catalog zones, but there were so few non-custom properties I wondered if one could effectively use catalog zones without them. I was expecting a few standard properties describing (e.g.) what the secondary should use as masters and what TSIG key to use. That is, I can see you must give the zone name for the given zone, but nothing else seems to be required. Did I miss some text that describes what is expected to happen by default? smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Dnsdir last call review of draft-ietf-dnsop-dns-catalog-zones-08
Hi David, Thank you for your review. Please see inline. On 12/27/22 18:14, David Blacka via Datatracker wrote: Reviewer: David Blacka Review result: Ready with Nits Reviewer: David Blacka Review Result: Ready with Nits Hi, I'm the designated DNS Directorate (dnsdir) reviewer for this document. Overall, I think this draft is in pretty good shape. I have a nit and a few overall comments. First, a small typo that could be fixed. In section 7, As catalog zones are transmitted using DNS zone transfers, it is RECOMMENDED that catalog zone transfer are protected from unexpected modifications by way of authentication, should be: As catalog zones are transmitted using DNS zone transfers, it is RECOMMENDED that catalog zone transfers are protected from unexpected modifications by way of authentication, That is, "transfer" should be "transfers". Done. This and other changes below are part of the following PR that will be merged along with changes from other reviews: https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/pull/55/commits Second, some comments: This draft is not quite definitive on whether or not Catalog Zones are directly queryable. Instead, it strongly discourages them from being queried, but usually using non-normative language. (The exception: the security considerations RECOMMEND limiting who can query the zone.) I wonder if the document would be better served with a more up-front statement on this issue? Good point -- the text indeed was a bit hand-wavy in this regard. I modified as follows: - Replace (with better wording) or remove "casual" (non-normative) references to DNS queries (e.g. when talking about TTL values) - Add justification why limiting queries is RECOMMENDED (namely, to prevent unintentional exposure of catalog zone contents) An appendix showing a full example catalog zone would be a nice addition to the document. There are examples throughout the text demonstrating specific concepts, however, so it isn't clear that such an appendix is strictly necessary. Done, based on an example from the Knot DNS documentation. (This has also been requested by other reviewers.) Catalog zones appear to be intentionally not fully interoperable between completely un-coordinated instances. Is this interpretation correct? I think my basic confusion arises from not seeing what can be done with catalog zones *without* custom properties. This is correct. As to "what can be done without custom properties": The main use case is provisioning and deprovisioning zones on secondary DNS servers. Without catalog zones, the secondary has to either somehow retrieve the list of zones via an out-of-band channel, or rely on heuristic processing of indirect signals from the primary. For example, a common way for removing secondary zones has been to let them "expire": check periodically whether the primary still knows the zone, and if it doesn't for say 1 week, assume it's not a glitch and remove the zone. This scales badly (requires lots of checking queries) and also risks deleting a zone prematurely when there actually is some other kind of problem causing the primary to not respond as expected. This is the use case in which catalog zones are expected to be interoperable. Beyond that, vendors are free to map whatever zone settings their implementation offers, by means of custom properties. Examples of this could be zone-specific rate limiting or statistics collection. Thanks, Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Erik Kline's No Objection on draft-ietf-dnsop-dns-catalog-zones-08: (with COMMENT)
Hi Erik, Thank you for your review! On 12/22/22 21:02, Erik Kline via Datatracker wrote: Erik Kline has entered the following ballot position for draft-ietf-dnsop-dns-catalog-zones-08: No Objection ... ## Nits ### S4.3 * "Member-specific properties are described in Section 4.3" -> "Member-specific properties are described in Section 4.4" Done. ### S4.4.2.1 * S4.3.1 has quotation marks around the contents of the TXT record, whereas this section does not. Recommend standardizing on one format, and probably the one with surrounding quotation marks, i.e.: group..zones.$CATZ 0 IN TXT"nodnssec" group..zones.$CATZ 0 IN TXT"operator-x-sign-with-nsec3" group..zones.$CATZ 0 IN TXT"operator-y-nsec3" Although, perhaps I've misunderstood something and this is not relevant. Done. These changes are part of this PR that will be merged together with changes from other reviews: https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/pull/55/commits Best, Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
