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] More private algorithms for DNSSEC
> On Mar 23, 2022, at 5:45 AM, Peter van Dijk > 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. > > On Mon, 2022-03-21 at 19:32 +, Paul Hoffman wrote: >> On Mar 21, 2022, at 11:34 AM, Wessels, Duane >> wrote: >>> Is it in response to the DNS-OARC talk we saw about implementing PQC Falcon >>> in PowerDNS, and they used the next unused algorithm number rather than a >>> private algorithm? >> >> Nils could have picked 253 but probably didn't even think of looking down to >> the bottom of the list. He was just following the time-honored pattern in >> the IETF. :-) > > (I am not speaking for Nils, to be clear.) > > 253 is not for experiments - it is for private production. It requires > (as most of you might know) prefixing DNSKEY content with a private > algorithm specifier that looks like a domain name (or, for 254, with a > OID). This means if you were to use it for an experiment, your DNSKEY > content, and thus signer and validation code, would need to be changed > when you get a number assigned. Hey! There is an RFC about this! RFC 4955. If you look that one up, you might understand why I might be aware of that one ;) That said, I didn't remember the number. Anyway, that RFC describes using the 253 and 254 private code points for *doing experiments*. Although, to be clear, we weren't really thinking of new DNSSEC algorithms as experiments (those would be "backwards compatible" experiments). > So, Paul, I support the idea behind your draft, but not the current > wording. While more 253-like points might be somewhat useful, what we > really need are experimental code points with non-253 semantics. Well, we clearly don't need more code points with 253 semantics. I can see that Paul updated it to say that (on 3/24): This document updates [RFC4034] to add seven more private use algorithms. Unlike private use algorithm 253, there is no restriction on the public key area in the DNSKEY RR and the signature area in the RRSIG RR. Thus, there are no domain names embdded in the public key or signature like there are with private use algorithm 253. This update brings the total number of private use algorithms that use the same format to eight. > > > Kind regards, > -- > Peter van Dijk > PowerDNS.COM BV - > https://secure-web.cisco.com/13BiMZSXDSomVBiVLMO81OOpFAzfdgvv6ubBC4kBzp0MFNVxHAjB-U0ggojjjGqRr633YTsQpP9EWS2fps_2PkDMl4Npp7TAkKrLQ2C7KPz71WB0XyUMrEira9LFixKJ542ReDXMA1xPBeIa1jrOCzOmcw2DovEmQ9MAC7IlFW1c37fpfSq7bAfpavOsW26_IDGIlwEGzkC77lfGns3pefv-h8jqziBjFgyH6i56EY5jDjBvamSiQ-HHL8SWzOYmC/https%3A%2F%2Fwww.powerdns.com%2F > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://secure-web.cisco.com/1vz4IYPF5-AIZvqtpsjPMKkgkz9QGkTMr5dT5w0nf5ZDaqS_-qldXesfTCcYQTeol3_NPfK3d9YqfbymSWVcfqDXTQlEmOrmNcN29FH9mGE68sjotlov22qiIl-4g_pIeY73R3IbIT0QJIVEpHXwTh2GeQ3r2InHV8vx0alG_5MogRrlrzX6b22SzZs2I5zkD1YgxbPt2ZPPGoo8ts3_4o2szbVNxORxLJjnkQPMkXYMyHRODX1hCyIaba4_YgTtm/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop > -- David Blacka Verisign FellowVerisign Product Engineering smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00
On Jul 11, 2012, at 2:16 PM, Andreas Gustafsson wrote: Paul Wouters wrote: On Wed, 11 Jul 2012, Jim Reid wrote: So it may be better if the draft uses a different term for the scenario where the parent and child do not have the same NS RRset. Perhaps that can be called a Broken Delegation? Because that's what it is I've changed it from lame delegation to broken delegation. I suggest simply dropping the sentence 'If they differ, it is referred as a Lame Delegation' instead. I don't think Jim's suggestion of broken delegation is common usage for the particular situation of parent and child NS RRsets differ any more than lame delegation is, and as far as I know, there is no established shorthand term that refers specifically to this situation. broken delegation suggests to me (at least) that the delegation cannot be successfully followed. That is possible, of course, but most of the time when the parent and child disagree, the delegation works but is not optimal. If we want a term for this (very common) case, I suggest mismatched delegation. -- David Blacka dav...@verisign.com Principal Verisign Infrastructure Engineering ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis algorithm rollover corner cases
On Jul 28, 2011, at 1:29 PM, Matthijs Mekking wrote: My understanding of this paragraph is that there MUST be an RRSIG for each RRset using at least one key of each algorithm in the DNSKEY RRset. So that includes the DNSKEY RRset itself. *In addition*, the DNSKEY RRset MUST be signed with the algorithms appearing in the DS RRset. Ok, so the snippet from 4035 alone appears to be ambigous to me. Is this clarified somewhere? Perhaps draft-ietf-dnsext-dnssec-bis-updates can add that clarification, if appropriate. If this is actually desired, then it would be *very* helpful to send text to the editors. Or at the very least, make an explicit request to the editors. We are having a hard time tracking things that people might want in dnssec-bis-updates. -- David Blacka dav...@verisign.com Principal Engineer Verisign Infrastructure Engineering ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
