Re: [DNSOP] Followup One Week Working Group Last Call for draft-ietf-dnsop-avoid-fragmentation
On Tue, 2023-09-19 at 14:27 -0400, Tim Wicinski wrote: > In the case of the DF bit, the wording is changed from > "UDP responders are RECOMMENDED" to "UDP responders MAY" With this change, the document appears to in fact document Best Current Practice. The added note in the Security Considerations about DF makes sense to me - we will have to see if anybody is willing to do the DF experiment for real, of course. Kind regards, -- Peter van Dijk PowerDNS.com B.V. - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Dnsdir telechat review of draft-ietf-dnsop-caching-resolution-failures-07
Reviewer: Peter van Dijk Review result: Ready Thank you for addressing my last nit. This looks ready to me. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Dnsdir last call review of draft-ietf-dnsop-caching-resolution-failures-06
Hi Duane, On Fri, 2023-08-18 at 15:52 +, Wessels, Duane wrote: > > > > I don't have a strong suggestion for rewording. Perhaps replace "recursive > > clients generally" with "some recursive clients might"? I can also live with > > the current text, but I did want to point out this nuance. > > > > Peter, thanks for the feedback. > > How about this change to that paragraph? > >Upon receipt of a FORMERR response, some recursive clients will retry >their queries without EDNS(0), while others will not. Nonetheless, >resolution failures from FORMERR responses are rare. Looks good to me, thanks. Kind regards, -- Peter van Dijk PowerDNS.com B.V. - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Publication has been requested for draft-ietf-dnsop-avoid-fragmentation-14
Hello Tim, On Wed, 2023-08-16 at 15:45 -0700, Tim Wicinski via Datatracker wrote: > Tim Wicinski has requested publication of > draft-ietf-dnsop-avoid-fragmentation-14 as Best Current Practice on behalf of > the DNSOP working group. > > Please verify the document's state at > https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ In https://mailarchive.ietf.org/arch/msg/dnsop/lrPbp6B8Mkz2S7HBXlxSPoIhTOw/ I pointed out that zero of the implementers honour item 2 in section 3.1. In https://mailarchive.ietf.org/arch/msg/dnsop/QOxTZHG03UVLom9E-y6iYG5s6po/ you said "good point, we need to address this". After that I have seen no communication on the list about addressing this, so I'm very surprised to see this publication request. Kind regards, -- Peter van Dijk PowerDNS.com B.V. - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Dnsdir last call review of draft-ietf-dnsop-caching-resolution-failures-06
Reviewer: Peter van Dijk Review result: Ready with Nits Thank you for processing my previous comments. The document is in great shape. I have one nit: One of the new sections based on my earlier comments is "2.7. FORMERR Responses". It currently says > Upon receipt of a FORMERR response, recursive clients generally retry their queries without EDNS(0). For most resolver implementations (Knot, Unbound, PowerDNS, but not BIND), this is only true if the FORMERR response does not contain EDNS(0)/OPT. There are auths out there that send FORMERR+OPT responses, and they are not getting non-EDNS0 fallback behaviour from such resolvers. > Thus, resolution failures from FORMERR responses are rare. This, meanwhile, remains true. When they happen, they tend to be persistent, and noticed, leading to fixes. I don't have a strong suggestion for rewording. Perhaps replace "recursive clients generally" with "some recursive clients might"? I can also live with the current text, but I did want to point out this nuance. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification - draft-ietf-dnsop-avoid-fragmentation-13.txt
On Wed, 2023-07-05 at 18:51 -0400, Tim Wicinski wrote: > All > > The authors of draft-ietf-dnsop-avoid-fragmentation worked with > different implementers to expand upon the index of Known > Implementations, and what they implement specifically. > > The chairs would like to have a one week follow up Working Group Last > Call comment period. We are looking for substantive comments regarding > the changes made, and if they are enough to address concerns raised. As Vladimir also said in his dnsdir review, this document is in way better shape than it was. I do see one obstacle. In section 3.1, the draft says: > 2. UDP responders are RECOMMENDED to set IP "Don't Fragment flag (DF) bit" [RFC0791] on IPv4. Then in Appendix D (Known Implementations), all implementations have indicated they do *not* set the DF bit. It seems wrong to RECOMMEND something, especially in a document targeted for BCP, that nobody is doing. > This comment period will end Wednesday July 12, 2023. If there > are substantive comments raised, we can address these during the > meeting. > A friendly request: please indicate Last Calls in the Subject! I missed this one until now. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Dnsdir last call review of draft-ietf-dnsop-caching-resolution-failures-03
> > and > > suggest that implementations document what they choose here. > > The relevant text here currently says: > > The implementation might cache different resolution failure conditions > differently. For example, DNSSEC validation failures might be cached > according to the queried name, class, and type, whereas unresponsive > servers might be cached only according to the server's IP address. > > So we provide two examples, although not really phrased as “tuples”. I guess > you’re suggesting to see more options here and talk about them more as tuples? Yes, I think that would make sense. > For the documentation suggestion, maybe something like this?: “Developers > SHOULD document their implementation choices so that operators know what > behaviors to expect when resolution failures are cached.” Wonderful. > > > First, we apologize for not realizing that this and two other “for > discussion” questions were not yet resolved. We plan to remove the first > (from the Introduction). > > For the one that was in section 2.6, we propose this updated text and new > section 3.4: > > 2.6. DNSSEC Validation Failures > > For zones that are signed with DNSSEC, a resolution failure can occur > when a security-aware resolver believes it should be able to > establish a chain-of-trust for an RRset but is unable to do so, > possibly after trying multiple authoritative name servers. DNSSEC > validation failures may be due to signature mismatch, missing DNSKEY > RRs, problems with denial-of-existence records, clock skew, or other > reasons. > > Section 4.7 of [RFC4035] already discusses the requirements and > reasons for caching validation failures. Section 3.4 of this > document strengthens those requirements. Good. > 3.4. DNSSEC Validation Failures > > Section 4.7 of [RFC4035] states: > > To prevent such unnecessary DNS traffic, security-aware resolvers MAY > cache data with invalid signatures, with some restrictions. > > This document updates [RFC4035] with the following, stronger > requirement: > > To prevent such unnecessary DNS traffic, security-aware resolvers > MUST cache DNSSEC validation failures, with some restrictions. Good :) > And for the one in section 3.3 we propose this: > > 3.3. Requerying Delegation Information > > Section 2.1 of [RFC4697] identifies circumstances in which "every > name server in a zone's NS RRSet is unreachable (e.g., during a > network outage), unavailable (e.g., the name server process is not > running on the server host), or misconfigured (e.g., the name server > is not authoritative for the given zone, also known as 'lame')." It > prohibits unnecessary "aggressive requerying" to the parent of a non- > responsive zone by sending NS queries. > > The problem of aggresive requerying to parent zones is not limited to > queries of type NS. This document updates the requirement from > section 2.1.1 of [RFC4697] to apply more generally: Upon encountering > a zone whose name servers are all non-responsive, a resolver MUST > cache the resolution failure. Furthermore, the resolver MUST limit > queries to the non-responsive zone's parent zone (and other ancestor > zones) just as it would limit subsequent queries to the non- > responsive zone. Looks great. Thanks! Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Dnsdir last call review of draft-ietf-dnsop-caching-resolution-failures-03
On Mon, 2023-06-26 at 07:47 -0700, Peter van Dijk via Datatracker wrote: > ## 3.2 > > A previous review > (https://mailarchive.ietf.org/arch/msg/dnsop/sJlbyhro-4bDhfGBnXhhD5Htcew/) > suggested that the then-chosen tuple was not specific enough, and also said it > was too prescriptive. I agree with both. The current draft prescribes nothing, > which I'm generally a fan of! > > However, speaking to a coworker (the one likely responsible for implementing > this draft, if it turns out our implementation deviates from its final form) > told me "some guidance would be nice". After some discussion on > prescriptiveness, here is our suggestion: do not prescribe, but mention > (without wanting to be complete) a few tuple formats that might make sense, > and > suggest that implementations document what they choose here. I can't believe I forgot this bit: While this document is in draft status, an implementation status section would be great. This would allow us to see if the document is implementable as is (I'd hope so, as it describes behaviour, with plenty of developer freedoms), and if implementers make choices for which it turns out it *does* make sense to perhaps write them down normatively. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Dnsdir last call review of draft-ietf-dnsop-caching-resolution-failures-03
Reviewer: Peter van Dijk Review result: Almost Ready I have been selected as the DNS Directorate reviewer for this draft. The DNS Directorate seeks to review all DNS or DNS-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the ADs. For more information about the DNS Directorate, please see https://wiki.ietf.org/en/group/dnsdir This document is generally in good shape. It is not too prescriptive, leaving room to implementers to honour the requirements in a way that makes sense for their implementations. The document has not seen a lot of WG discussion; I hope this means people have read it and generally agree. Section 3.3 contains a "FOR DISCUSSION" note. I believe this means the document cannot currently pass Last Call. (See below for some notes on that discussion item.) I have various nits and suggestions. Please see them below. Section numbers are for -03. ## 2 I know section 2 is not meant to be exhaustive, but I wonder if FORMERR deserves a mention. In theory, a FORMERR response will not improve with time until an auth operator actively intervenes (by updating/replacing software to a more compliant version). SERVFAILs, by comparison, can be much more transient. ## 2.1 current: > Authoritative servers, and more specifically secondary servers, > return server failure responses when they don't have any valid data > for a zone. That is, a secondary server has been configured to serve > a particular zone, but is unable to retrieve or refresh the zone data > from the primary server. proposed: > Authoritative servers, and more specifically secondary servers, > return server failure responses when they don't have any valid data > for a query. For example, a secondary server has been configured to serve > a particular zone, but is unable to retrieve or refresh the zone data > from the primary server. ## 2.2 The first paragraph correctly mentions "policy reasons". The second paragraph correctly says "they are not authoritative". I am not sure not being authoritative can be considered a policy reason, so perhaps these two paragraphs can be connected with an "or"? ## 2.3 "If, however, the implementation does not join outstanding queries together, ..." - this could use a reference to 5452 4.3 and 5452 5, pointing out that implementations really should be joining queries together for security reasons whenever they can, beside the reason given in the draft of not overloading authoritatives. ## 3.1 "A resolver MUST NOT retry a given query over a server's transport more than twice" - should this be clarified to say "in a short period of time" or something like that? Clearly a retry is allowed *eventually*. Also, "MUST NOT" is pretty strong language. Given the various process models of resolver implementations, two subprocesses (threads) both retrying the same or a similar thing a few times can not always be avoided. Would you settle for SHOULD NOT? The "given" in "retry a given query" gives some leeway, but not enough, I feel. "may retry a given query over a different transport .. believe .. is available" - this ignores that some transports have better security properties than others. One currently active draft in this area is draft-ietf-dprive-unilateral-probing. Perhaps add some wording, without being too prescriptive, such as "available, and compatible with the resolver's security policies, ..". ## 3.2 A previous review (https://mailarchive.ietf.org/arch/msg/dnsop/sJlbyhro-4bDhfGBnXhhD5Htcew/) suggested that the then-chosen tuple was not specific enough, and also said it was too prescriptive. I agree with both. The current draft prescribes nothing, which I'm generally a fan of! However, speaking to a coworker (the one likely responsible for implementing this draft, if it turns out our implementation deviates from its final form) told me "some guidance would be nice". After some discussion on prescriptiveness, here is our suggestion: do not prescribe, but mention (without wanting to be complete) a few tuple formats that might make sense, and suggest that implementations document what they choose here. ## 3.3 > FOR DISCUSSION: the requirement quoted above may be problematic > today. e.g., focusing on NS as the query type (a) probably goes > against qname minimization, and (b) is not the real problem. Also > RFC 4697 doesn't place any time restriction (TTL) on this. *Before* qname minimization, queries that yield delegation answers often did not have type NS. With qname minimization, depending on the implementation, those queries might in fact be NS. (7816 specifies NS; 9156 relaxes the qtype requirement for qname-minimized queries). That said, there is no reason for the requery (w
[DNSOP] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: PowerDNS
PowerDNS Authoritative Server, PowerDNS Recursor, PowerDNS dnsdist: * IP_PMTUDISC_OMIT with fallback to IP_PMTUDISC_DONT * default EDNS buffer size of 1232, no probing for smaller sizes * no handling of EMSGSIZE * Recursor: UDP timeouts do not cause a switch to TCP. "Spoofing nearmisses" do. PowerDNS Authoritative Server: * the default DNSSEC algorithm is 13 * responses are minimal, this is not configurable Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dns-catalog-zones
On Tue, 2022-09-13 at 17:30 -0400, Tim Wicinski wrote: > As we mentioned during the last IETF the chairs plan on running working > group > last calls during the month of September. > > This starts a Working Group Last Call for draft-ietf-dnsop-dns-catalog- > zones > > Current versions of the draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-catalog-zones/ > > The Current Intended Status of this document is: Standards Track On the day this Last Call started, we finally released a real implementation of Catalog Zones for PowerDNS. This brings us to 3 production ready implementations of this specification, which I think is an excellent number. I'll update the draft text (in GitHub) to reflect this. More details at https://doc.powerdns.com/authoritative/catalog.html Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation
On Sat, 2022-08-13 at 21:49 +0900, Daisuke HIGASHI wrote: > I wrote an experimental "avoid-fragmentation" patch for NSD (as per > section 3.1 and Appexdix C). Due to dependency on getsockopt(IP_MTU), > currently it should work on Linux only. > > https://github.com/hdais/nsd-avoid-fragmentation#avoid-fragmentation-implementation-for-nsd > https://github.com/hdais/nsd-avoid-fragmentation/commit/e34931ece95d4bcc20d71d3f3a18e037d2772f23 > > I did several tests on avoid-fragmentation, and got some findings or > questions: > > - avoid-fragmentation (current draft) can be implemented by small > modifications as you can see above. Note that the function called "probe_pmtu" does not really probe. At best, it finds some data the kernel cached recently. At worst (i.e. usually), it tells you the MTU of your local networking interface. > - A first response (to requester with small PMTU) can be lost because > nobody knows PMTU for destination that a large packet was never sent. > It slows down name resolution - Fortunately this is not a big problem > because 1) will be recovered by retransmission by the requestor (a) why would a requestor retransmit? (b) why would the retransmit help? (I can imagine answers to these, but they're incomplete - so I'm curious about your thought process here) > 2) > This rarely occurs. Most advertised EDNS bufsize fits in most MTU > (slightly smaller than 1500) thanks to DNS flag day 2020. > > - API to get PMTU to any destination is available on many platforms > (other than Linux)? As far as such APIs exist, they rely on the few bits of data your kernel happens to have learned recently. Usually, the data you want will not be there. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt
On Fri, 2022-08-12 at 08:48 -0700, Wes Hardaker wrote: > This document retires the use of SHA-1 within DNSSEC (Half-echoing what Mark Andrews said elsewhere in the thread.) This document fails to retire the use of SHA-1 in NSEC3, and is thus, given its current title, incomplete. We can do several things here: (1) figure out the NSEC3 upgrade path [as Mark also says, this likely means burning ~10 algorithm numbers - plus years of pain] (2) improve this document so that it clearly avoids touching NSEC3 (3) Obsoletes: RFC5155 While 3 may seem tongue in cheek, I am not entirely kidding. I do see it's not the most likely outcome :-) (2, then 1, perhaps?) Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Working Group Last Call for aft-ietf-dnsop-dnssec-bcp
On Fri, 2022-07-29 at 13:50 +, Paul Hoffman wrote: > On Jul 29, 2022, at 8:58 AM, Peter van Dijk > wrote: > > The mention of 5011 talks about the root, but 5011 does not mention the > > root at all. 5011 is not limited to the root. > > It is limited to "trust anchors", and essentially all DNSSEC trust anchors > are for the DNS root. Still, the wording can be improved. On the Internet, this is true, and I think it would be unwise (and unnecessary) to use 5011 for anything. But I've been told 5011 sees non- root usage inside some private networks. > Current: > - [RFC5011] explains how recursive resolvers and the DNS root can work > together to automate > the rollover of the root's key signing key (KSK). > > Proposed: > - [RFC5011] describes a method to help resolvers update their DNSSEC trust > anchors in an > automated fashion. This method was used in 2018 to update the DNS root trust > anchor. Wonderful. > Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for aft-ietf-dnsop-dnssec-bcp
Hello, On Thu, 2022-07-28 at 15:06 -0400, Tim Wicinski wrote: > All > > > This starts a Working Group Last Call for aft-ietf-dnsop-dnssec-bcp, > "DNS Security Extensions (DNSSEC)" > > Current versions of the draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bcp/ > > > The Current Intended Status of this document is: Best Current Practice > > Please review the draft and offer relevant comments. This is a good document and we should publish it, perhaps with a few more edits. Some nits: I agree with Chris Box' suggestion, that language also seemed unclear to me. The mention of 5011 talks about the root, but 5011 does not mention the root at all. 5011 is not limited to the root. In the list of "Additional Documents of Interest", I think 7129 deserves to be pointed out as an especially important document, as NSEC/NSEC3 are almost impossible to understand without it. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation
Hello, On Tue, 2022-07-26 at 21:13 +, Suzanne Woolf wrote: > Dear colleagues, > > > This message starts the Working Group Last Call for > draft-ietf-dnsop-avoid-fragmentation > (https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/). The > requested status is BCP. > > Since we're starting the Last Call during the IETF week, and many folks are > on holidays in the next few weeks, the WGLC will end in three weeks (instead > of the usual two), on August 16. > > Substantive comments to the list, please. It’s fine for minor edits to go > direct to the authors. We need to hear positive support to advance it, or > your comments on what still needs to be done. Avoiding fragmentation is good. Putting that in a document is also good. But this document is not ready for publication. It also most definitely does not describe Best Current Practice; it also does not prescribe a Best Current Practice I can agree with or even really implement. I'll call out a few specific problems below, but this list is not complete. The (normative!) reference to RFC8900 is very vague. The IP_DONTFRAG reference (well, not really a reference) is handwavy and ill-defined. The discussion of socket options is also incomplete. (See also: Petr's email) > * If the UDP responder detects immediate error that the UDP packet > cannot be sent beyond the path MTU size (EMSGSIZE), the UDP > responder MAY recreate response packets fit in path MTU size, or > TC bit set. If an answer does not fit, there is often no legitimate smaller answer that will fit, as convincingly argued by draft-ietf-dnsop-glue-is-not- optional. Some additionals may be an exception to this. Furthermore, this situation (a responder receiving a message size error from the kernel) is extremely unlikely, unless there is a requester that talks to this responder a lot. (That said, the advice is good.) > * UDP responders MAY probe to discover the real MTU value per > destination. I have no clue how a responder would do this. If I'm wrong, and this is possible at all, the document should explain how this would be done. I assume section 3.2 means the EDNS bufsize in the request when it says "their payload size", but I am not sure. The text could be clearer on that. > * UDP requestors MAY probe to discover the real MTU value per > destination. How? > To avoid name resolution fails, UDP requestors need to retry using > TCP, or UDP with smaller maximum DNS/UDP payload size. This lacks 2119/8174 keywords. "need" sounds like SHOULD or MUST, but I do not think this behaviour should be mandated of implementations. Several resolver implementations currently do none of this, and they work fine on the existing Internet. We should not be adding code compensating for potential breakage we can imagine. So, I suggest this would at most be a MAY, or a lowercase "can retry using ...". >The proposed method supports incremental deployment. In its current shape, this document does not really propose a method for anything. If the document gets updated to provide implementable advice, it should get an Implementation Status section. Section 5 is solid advice. I also agree with the full text of Petr's response. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Technical Errata Reported] RFC7686 (6761)
Hello Robert,
On Tue, 2021-11-30 at 11:51 -0500, Robert Edmonds wrote:
> If the goal is to avoid mandating extra code paths in typical
> authoritative servers
To me, this indeed is the goal.
> , I would suggest something like the following
> which narrowly answers only the questions asked in 6761 ("Are developers
> of authoritative domain name servers expected to make their
> implementations recognize these names as special and treat them
> differently? If so, how?"):
>
> Original Text
> -
> 5. Authoritative DNS Servers: Authoritative servers MUST respond to
> queries for .onion with NXDOMAIN.
>
> Corrected Text
> --
> 5. Authoritative DNS Servers: Authoritative servers SHOULD NOT
> recognize .onion names as special and MUST NOT treat queries for
> .onion names differently from other queries.
I like this.
> Splitting the "recognize ... treat" conjunction between "SHOULD NOT"
> and "MUST NOT" would, for instance, allow an authoritative server to
> log a warning message if an operator intentionally configured an
> "onion." zone in the server.
>
> A slight expansion of the text might read:
>
> Corrected Text
> --
> 5. Authoritative DNS Servers: Authoritative servers SHOULD NOT
> recognize .onion names as special and MUST NOT treat queries for
> .onion names differently from other queries. By default,
> authoritative servers MUST NOT respond authoritatively to
> queries for .onion names.
I like this even more.
> The "By default" qualifier covers the case of a non-default
> configuration (such as being configured to serve the root zone) where an
> authoritative server would need to respond authoritatively for .onion
> names.
Perfect.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] More private algorithms for DNSSEC
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. 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. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-05.txt
Wes, Viktor, On Sun, 2022-03-06 at 20:36 -0800, internet-dra...@ietf.org wrote: > Filename: draft-ietf-dnsop-nsec3-guidance-05.txt Thank you for your continued work on this. This appears to be in excellent shape - you'd have my support in a WGLC. I love that we managed to get to "iterations count to 0 MUST" in this important document! A few nits: > Because hashing provides only moderate protection, as shown recently in academic studies of NSEC3 protected zones [GPUNSEC3][ZONEENUM]. This sentence appears to be lacking a second half. > Operators are encouraged to forget the salt entirely "forgo" perhaps? Or, easier on the eyes, "not use the salt at all"? > Note that this specification significantly decreases the requirements originally specified in Section 10.3 of [RFC5155]. Should this document say "Updates: RFC5155" ? > man-it-the-middle attacks man-in-the-middle > Thus, validating resolver operators and software implementers SHOULD set the point above which a zone is treated for certain values of NSEC3 iterations counts to the same as the point where a validating resolver begins returning SERVFAIL. Is "as insecure" missing after "treated"? Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)
On Mon, 2021-11-29 at 14:16 -0500, Paul Wouters wrote: > On Mon, 29 Nov 2021, RFC Errata System wrote: > > > Original Text > > - > > 5. Authoritative DNS Servers: Authoritative servers MUST respond to > > queries for .onion with NXDOMAIN. > > Corrected Text > > -- > > 5. Authoritative DNS Servers: Authoritative servers MUST respond > > non-authoritatively to > > queries for names in .onion. > > The original text for 5 and 6 is conflicting. A name server cannot respond > > with NXDOMAIN (which is an authoritative answer) without having a zone > > configured to serve that NXDOMAIN from. Clearly the intent of the text is > > that clients will not find authoritative answers to .onion queries anywhere > > in the DNS. > > The corrected text does not describe what to return though. I guess the > text implies REFUSED, but perhaps the WG reasoned this was not good as > it would lead to more queries to other servers or instances of the > authoritative server set? Yes, it implies REFUSED. I was unsure REFUSED was standardised, or whether it is still a convention that almost all auths happen to follow. REFUSED would indeed lead to resolvers trying other auths (although that seems a bit theoretical - where did the resolver even come up with the idea to ask a bunch of auths about .onion names?). I also now realise that the root servers do not honour my new text, and their behaviour -is- correct, so perhaps: 5. Authoritative DNS Servers: Authoritative servers (other than the root servers) MUST respond non-authoritatively to queries for names in .onion. ? > So I agree the Original text has an issue. I haven't been convinced yet > the suggested solution is the right one. After all, we are talking about > "special domains", so perhaps it does warrant an NXDOMAIN despite that > normally being used only within an authoritative context. I don't think we should be prescribing extra code paths in authoritative servers in this document, and I think non-authoritative NXDOMAINs would be very confusing. In particular, resolvers would not believe them anyway. That all said, I can certainly see that other texts than my suggestion could make sense. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hardaker-dnsop-intentionally-temporary-insec-01.txt
On Fri, 2021-10-22 at 12:44 -0400, Rose, Scott W. wrote: > On 22 Oct 2021, at 12:13, Wes Hardaker wrote: > > > Peter van Dijk writes: > > > > > > It remains to be debated whether these ideas that you shouldn't use > > > > unless you have to should eventually be published as an RFC. > > > > > > I'm torn on this one. Sometimes going insecure is what has to happen, > > > and for those cases, operational guidance is good to have. > > > > Thanks Peter. I agree completely on the "I'm torn" feeling. > > We can’t ignore the fact that going insecure in order to do a DNSSEC > algorithm rollover happens and sometimes happens in ways that results in > errors. Having a documented way that will cause the least amount of > headaches seems wise. Domain operators may do it regardless of the > caveats in place, but hopefully do it without causing resolution > failures. "Anything worth doing is worth doing well." I've been pondering whether this document would work, fully fleshed out, but never hitting RFC status - a web search would still find it. But then again, at least once a week I tell people "no, that's an expired draft, the WG did not want that" So, I'm starting to lean strongly towards publication. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hardaker-dnsop-intentionally-temporary-insec-01.txt
Hi Wes, On Thu, 2021-10-21 at 09:55 -0700, Wes Hardaker wrote: > It adds a new section using multiple authoritative servers with > different data to get around algorithm roll difficulties. That section only works for some validator implementations. Others will simpy go bogus, the only question is how many times they will hit each authoritative name server before deciding so. I strongly suggest removing section 2.2, or perhaps changing it to say "whatever you do, don't do this" - but I'm not sure we really want a repository of bad ideas. > It remains to be debated whether these ideas that you shouldn't use > unless you have to should eventually be published as an RFC. I'm torn on this one. Sometimes going insecure is what has to happen, and for those cases, operational guidance is good to have. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] wrapping up draft-ietf-dnsop-nsec3-guidance
On Wed, 2021-10-20 at 11:24 -0700, Wes Hardaker wrote: > So, the question: what's the right FINAL value to put in the draft > before LC? I don't know what the -right- value is, but I know what I want: 0 iterations, empty salt, otherwise the NSEC3 gets ignored, presumably leading to SERVFAIL. This removes the 'insecure' window completely. So, I'll support any push to lower the numbers. Editorial nit, already hinted at above: the text currently has "Validating resolvers MAY return SERVFAIL when processing NSEC3 records with iterations larger than 500." - I suggest changing this to "validating resolvers MAY ignore NSEC3 records with iterations larger than 500". That way, zones in the middle of a transition from 1000 to 0 iterations do not get punished. Zones at 1000, not in a transition, will still get SERVFAIL by virtue of the NSEC3 proof missing (because it is ignored). Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Question on interpretation of DO and CD
On Wed, 2021-10-06 at 16:47 -0700, Eric Rescorla wrote: > Hi folks, > > We've been trying to take some measurements of the success of endpoint > DNSSEC validation and run into some confusion about the implications > of the DO and CD bits. Sorry if these are dumb questions. Not dumb questions! > Summarizing all this, I have the following table of what the stub > should expect to receive if the recursive is a validating resolver and > it asks for an A record (just as an example) > > > Bits set Records validRecords invalid > - > None A + ???Error > DO A + DNSSEC Error > CD A + ??? A + ??? > DO + CD A + DNSSECA + DNSSEC > > Where "A + DNSSEC" means "A + plus the DNSSEC records" and "A + ???" > means "A + maybe some DSNSSEC records depending on what the recursive > wants". Looks right to me. I'd expect no DNSSEC records in your "???" cases. During the implementation of DNSSEC validation in the PowerDNS Recursor we also found that it's impossible to make sense of it all without laying out all permutations. Here's a table Pieter Lexis built around that time (it has different dimensions than yours, but given your initial understandable confusion, maybe you want to read it and see if anything surprises you): https://doc.powerdns.com/recursor/dnssec.html#what-when Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IETF 111 DNSOP WG session II agenda updated
Hi Benno, On Thu, 2021-07-29 at 23:48 +0200, Benno Overeinder wrote: > As a follow up to Shumon's email, the order is indeed different than > usual. Normally we schedule current business first, but for > agenda-technical reasons (allowing discussion) we have changed the order. > > Hope you understand the exception to the rule. Right, that argument works both ways, of course. Option 1: schedule the draft at the end and promise to get to it 10 minutes before the end - in other words, hope that you can manage to cut the priority discussion short. Option 2 (chosen here): get the draft out of the way first and hope that we manage to limit discussion time on it, to leave time for the wider WG discussion on priorities. It is understood. Thank you. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IETF 111 DNSOP WG session II agenda updated
Hello Shumon, On Thu, 2021-07-29 at 14:49 -0400, Shumon Huque wrote: > > I'm sure the chairs will answer you on process, but I wanted to state that I > had actually posted -00 before the draft cutoff (-01 posted later was a minor > tweak) and asked for agenda time then. The chairs apologized to me later > that they hadn't responded earlier and said they could fit me on Thursday. Ah, apologies, then - I assumed it was post-cutoff because I did not notice any email about the draft on dnsop pre-cutoff. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IETF 111 DNSOP WG session II agenda updated
On Wed, 2021-07-28 at 17:04 +0200, Benno Overeinder wrote: > Dear WG, > > We have updated the agenda for DNSOP WG session II on Thursday 29 July. > The updated agenda is uploaded to datatracker: > https://datatracker.ietf.org/meeting/111/materials/agenda-111-dnsop-06 On this version, I see under New Working Group Business a draft (the black lies sentinel) that was posted two days ago. Can somebody please explain to me what the purpose of the draft cutoff is, if drafts can appear in the datatracker, and on an agenda, after the cutoff? In the latest version ( https://datatracker.ietf.org/meeting/111/materials/agenda-111-dnsop-07) , I see the new business has now been moved -in front- of both current business, and the discussion on prioritisation of WG activities. This is not a comment on the specific draft at all. This is a comment on WG process. It seems weird to me to discuss prioritisation -after- we spend time talking about current and, especially, new business. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Empty Non-Terminal sentinel for Black Lies
Hi Shumon, On Tue, 2021-07-27 at 19:34 -0400, Shumon Huque wrote: > Folks, > > While we have the attention of DNSOP folks this week, I'd like to ask for > review of this draft (I meant to send it earlier in time for f2f discussion > on Tuesday, but better late than never). > > https://datatracker.ietf.org/doc/html/draft-huque-dnsop-blacklies-ent-01 > > Excerpt: > >Empty Non-Terminal Sentinel for Black Lies > > Abstract > >The Black Lies method of providing compact DNSSEC denial of existence >proofs has some operational implications. Depending on the specific >implementation, it may provide no way to reliably distinguish Empty >Non-Terminal names from names that actually do not exist. This draft >describes the use of a synthetic DNS resource record type to act as >an explicit signal for Empty Non-Terminal names and which is conveyed >in an NSEC type bitmap. I have read the draft, and I believe I understand what the draft is doing. I have also read the Introduction and Motivation section. While it does contain some motivation, I do not think it contains enough motivation. One might argue that ENT/NXDOMAIN problems do not exist with these operators, precisely because they do Black Lies. Furthermore, it looks like a trick that could only be relied on with specific operators (such as, for now, NS1) that have implemented it. There are plenty of differences between the implementations already. In fact, when promoting RFC8482, CloudFlare heavily argued how the difference between NODATA and NXDOMAIN is a very expensive one for them. So presumably, it would not make sense for them to implement this signal. Because of that, I wonder if it would not make more sense if the individual implementers/operators of things that are somewhat similar under the 'Black Lies'-umbrella document how they signal the difference between ENT and NXDOMAIN. (It would of course be fine if some of them agree on the signal). I also hope, but want to say that out loud here, that there is no expection of -resolver- software to handle this signal in any special way. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis
tl;dr: No. On Wed, 2021-07-07 at 13:54 -0400, Warren Kumari wrote: > If resolving " _ldap._tcp.ad.example.com", once you hit the _tcp label > you are quite likely in ENT territory, and some implementations > (especially those behind firewalls / middleboxes) are still broken. Then they shall suffer. It is not the job of the resolver vendors and operators to keep working around broken auths. We'd like to remove more workarounds from the resolver, not add more. > There is also a performance hit. This is fair. > Version 10 of the document added: > "Another potential, optional mechanism for limiting the number of > queries is to assume that labels that begin with an underscore (_) > character do not represent privacy-relevant administrative > boundaries. For example, if the QNAME is "_25._tcp.mail.example.org" > and the algorithm has already searched for "mail.example.org", the > next query can be for all the underscore-prefixed names together, > namely "_25._tcp.mail.example.org"." This is good text, with the note that I like Peter Thomassen's modification of only jumping to the next non-underscore label, instead of immediately to the end the moment an underscore is found. > What does the WG think? Does the privacy win of getting this deployed > and enabled sooner outweigh the potential small leak if there *is* a > delegation inside the _ territory of the name? This looks like a false choice to me. I am unconvinced deployment is hindered by the difference between MAY and SHOULD for this recommendation. I also don't think the leak potential is very interesting. > Should the advice above be strengthened to SHOULD / RECOMMENDED? No. MAY is a perfect level for this advice. It is good to let implementers know that somebody thought of this trick, and it might make sense for many implementations, but we should not be overly prescriptive. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IETF meeting prep and what
Hello DNSOP, > I propose replacing rfc5011-security-considerations with a short document > deprecating 5011 in its entirety. I am happy to write text for that, if there > is an appetite - when the WG queue is small enough! I see this ruffled some feathers. Here's a more nuanced version. I feel that 5011, for the purpose of root key rollovers, is the wrong tool, -especially- combined with the trust anchor signaling that various resolver stacks sent to the root. Lack of clarity about where various signals came from, combined with some interesting bugs in implementations, has led to a lot of wild goose chases, and it would not surprise me (but I cannot prove) that bad data is what delayed the first roll for so long. Not actual problems predicted by the data; just bad data. (I have mentioned before that I think the trust anchor signalling was a mistake too, and any calls for 'more of this' are 'calls for more bad data' and we do not need more bad data.) I feel that the right mechanism for root key distribution is software distributors. This is working fine for the CA system, and with keys announced far enough in advance, should work fine for DNSSEC. Software distributors have solved this problem; they are very good at distributing things; I suggest we let them solve this for us. rfc5011-security-considerations is a good document, and I apologise for targeting it unfairly - my problem with 5011 is as above. Given my next two point, it probably makes sense to publish rfc5011-security-considerations. With heaps of 5011 'client' implementations out there, I am in no way proposing that root rolls happen in a way that that software could not follow along. I am only proposing that we write down that 5011 is not the best fit for the problem, and recommend against more client implementations of it *for the purpose of root key rolls*. I think (can't find it right now) that somebody mentioned that 5011 has its place outside of the root key system, inside enterprises. I'm inclined to disagree, but do not feel entirely capable of judging that. If (again, when there's WG bandwidth) we draft a document about why 5011 is a bad fit for the root, perhaps somebody can contribute text about the level-of-fit for other use cases. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IETF meeting prep and what
On Wed, 2021-06-16 at 19:38 -0400, Tim Wicinski wrote: > All > > The chairs have been doing prep work for the upcoming IETF meeting; one issue > that we are working on is reaching out to authors whose working group > documents have recently expired. While doing this, Benno did some datatracker > stuff and ended up with this list > > https://datatracker.ietf.org/doc/search?name=draft-ietf-dnsop&sort=&olddrafts=on&by=group&group=DNSOP > > All documents from 1 January 2016 onward are open for discussion. For the > older documents that are left - if someone wishes to take them on, please > reach out. aname can go; I trust the WG feels SVCB will supersede it. I hope MarkA can revive glue-is-not-optional. I propose replacing rfc5011-security-considerations with a short document deprecating 5011 in its entirety. I am happy to write text for that, if there is an appetite - when the WG queue is small enough! There are quite some things I like in rfc2317-bis, especially the parts where it proposes something -other than- slashes in labels. I am not offering to take it on at this time, though. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-salgado-dnsop-rrserial
On Tue, 2021-06-01 at 08:59 +0200, Shane Kerr wrote: > And maybe cache the value if desired? I'm already looking forward to having serials in resolver cache dumps! > At the very least, maybe the draft should be agnostic towards > non-authoritative servers? > > So instead of: > > This EDNS option is aimed only to authorative servers for a zone. > Resolvers and forwarders should ignore the option. It's only > intended for hop-to-hop communication (not transitive). > > Maybe: > > This EDNS option is aimed only at authoritative servers for a zone. > It's only intended for hop-to-hop communication (not transitive). > Resolver and forwarder behavior is undefined. I like this. I suspect defining it well for answers from resolvers to clients would open up a big can of worms that could kill the draft, like many other drafts that have been crushed under the sheer weight of scope creep. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-ttl-05.txt
Hello DNSOP and IESG, I believe I have handled all review comments from the IESG, resulting in the version below. Changes from draft-ietf-dnsop-nsec-ttl-04 to draft-ietf-dnsop-nsec-ttl- 05: * various minor rewordings (from IESG review, and things I spotted while handling IESG review comments) * added a note on the secondary impact of changing the SOA TTL and/or MINIMUM (IESG review) Thanks, Peter On Thu, 2021-05-20 at 04:11 -0700, internet-dra...@ietf.org wrote: > 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 : NSEC and NSEC3 TTLs and NSEC Aggressive Use > Author : Peter van Dijk > Filename: draft-ietf-dnsop-nsec-ttl-05.txt > Pages : 10 > Date: 2021-05-20 > > Abstract: >Due to a combination of unfortunate wording in earlier documents, >aggressive use of NSEC and NSEC3 records may deny the existence of >names far beyond the intended lifetime of a denial. This document >changes the definition of the NSEC and NSEC3 TTL (Time To Live) to >correct that situation. This document updates RFC 4034, RFC 4035, >RFC 5155, and RFC 8198. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-ttl/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-dnsop-nsec-ttl-05.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-nsec-ttl-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > -- Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-nsec-ttl-04: (with COMMENT)
On Wed, 2021-05-19 at 12:28 +0200, Peter van Dijk wrote: > Hello Benjamin, > > On Tue, 2021-05-18 at 20:36 -0700, Benjamin Kaduk via Datatracker > wrote: > > I don't think I understand what a "deviating value" would be (and in > > which direction it would deviate). > > This sentence was added because some implementations may need time to > rework the whole NSEC/NSEC3 chain after a TTL change. The deviation > would be 'part of the chain still has the old, wrong, value - for a > while'. I'll ponder better words - suggestions are very welcome, of > course. I took Job's text for this, thanks Job! > > Section 4 > > > >If signers & DNS servers for a zone cannot immediately be updated to > >conform to this document, zone operators are encouraged to consider > >setting their SOA record TTL and the SOA MINIMUM field to the same > >value. That way, the TTL used for aggressive NSEC and NSEC3 use > >matches the SOA TTL for negative responses. > > > > Are there any negative consequences of such a move that would need to be > > weighed against the stated benefits? > > Signers might use either value (the SOA TTL or the SOA MINIMUM) as a > default for some other value. For example, PowerDNS uses the SOA > MINIMUM value as the TTL for DNSKEYs. So, lowering the SOA MINIMUM > would also lower the DNSKEY TTL (in PowerDNS). > > A quick skim of the BIND dnssec-keygen manual page suggests that BIND > might sometimes take the SOA TTL as the DNSKEY TTL. > > So, yes, there might be consequences. I will add a note. I have now added this: > Note that some signers might use the SOA TTL or MINIMUM as a default for other values, like the TTL for DNSKEY records. Operators should consult documentation before changing values. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-nsec-ttl-04: (with COMMENT)
Hello Benjamin, On Tue, 2021-05-18 at 20:36 -0700, Benjamin Kaduk via Datatracker wrote: > -- > COMMENT: > -- > > I put a (small) handful of editorial suggestions up at > https://github.com/PowerDNS/draft-dnsop-nsec-ttl/pull/11 . Thanks, I merged them! > Section 3.1, etc. > >| The TTL of the NSEC RR that is returned MUST be the lesser of the >| MINIMUM field of the SOA record and the TTL of the SOA itself. >| This matches the definition of the TTL for negative responses in >| [RFC2308]. A signer MAY cause the TTL of the NSEC RR to have a >| deviating value after the SOA record has been updated, to allow >| for an incremental update of the NSEC chain. > > I don't think I understand what a "deviating value" would be (and in > which direction it would deviate). This sentence was added because some implementations may need time to rework the whole NSEC/NSEC3 chain after a TTL change. The deviation would be 'part of the chain still has the old, wrong, value - for a while'. I'll ponder better words - suggestions are very welcome, of course. > Section 3.4 > >| A resolver that supports aggressive use of NSEC and NSEC3 MAY >| limit the TTL of NSEC and NSEC3 records to the lesser of the >| SOA.MINIMUM field and the TTL of the SOA in a response, if >| present. It MAY also use a previously cached SOA for a zone to >| find these values. > > The original 8198 has "SHOULD reduce", but now we only have "MAY limit". > Why should the requirements level be weaker for the new, more-correct, > guidance? Rob Wilton also raised this - please see my reply here: https://mailarchive.ietf.org/arch/msg/dnsop/pMPe-KcbWUrFVcITCf3fmGk5ztY/ > Section 4 > >If signers & DNS servers for a zone cannot immediately be updated to >conform to this document, zone operators are encouraged to consider >setting their SOA record TTL and the SOA MINIMUM field to the same >value. That way, the TTL used for aggressive NSEC and NSEC3 use >matches the SOA TTL for negative responses. > > Are there any negative consequences of such a move that would need to be > weighed against the stated benefits? Signers might use either value (the SOA TTL or the SOA MINIMUM) as a default for some other value. For example, PowerDNS uses the SOA MINIMUM value as the TTL for DNSKEYs. So, lowering the SOA MINIMUM would also lower the DNSKEY TTL (in PowerDNS). A quick skim of the BIND dnssec-keygen manual page suggests that BIND might sometimes take the SOA TTL as the DNSKEY TTL. So, yes, there might be consequences. I will add a note. > Section 8 > > Why is RFC 8174 only an informative reference? Shouldn't it be given > the same treatment as RFC 2119? An oversight, already fixed in my local copy. Thank you! Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-nsec-ttl-04: (with COMMENT)
Hello Rob, On Tue, 2021-05-18 at 08:04 -0700, Robert Wilton via Datatracker wrote: > -- > COMMENT: > -- > > Hi, > > Thanks for this document. > > Regarding: > > 3.4. Updates to RFC8198 > >[RFC8198] section 5.4 (Consideration on TTL) is completely replaced >by the following text: > >| The TTL value of negative information is especially important, >| because newly added domain names cannot be used while the negative >| information is effective. >| >| Section 5 of [RFC2308] suggests a maximum default negative cache >| TTL value of 3 hours (10800). It is RECOMMENDED that validating >| resolvers limit the maximum effective TTL value of negative >| responses (NSEC/NSEC3 RRs) to this same value. >| >| A resolver that supports aggressive use of NSEC and NSEC3 MAY >| limit the TTL of NSEC and NSEC3 records to the lesser of the >| SOA.MINIMUM field and the TTL of the SOA in a response, if >| present. It MAY also use a previously cached SOA for a zone to >| find these values. > > I'm not a DNS expert, and this is just a non binding comment, but I was > wondering why it is only "MAY" limit the TTL on NSEC and NSEC3 records to the > lesser of the SOA.MINIMUM field and the TTL of the SOA in a response rather > than a "SHOULD". Thank you for your comment. The old text was this: > A resolver that supports aggressive use of NSEC and NSEC3 SHOULD reduce the > TTL of NSEC and NSEC3 records to match the SOA.MINIMUM field in the authority > section of a negative response, if SOA.MINIMUM is smaller. but this text did nothing (this is also noted in section 1 of the draft), as signers/authoritatives already took that TTL from the SOA.MINIMUM field - which this document corrects. Furthermore, during WG discussion we realised that in many cases, a validator handling NSEC/NSEC3 records would not have access to the relevant SOA at all - for example, in wildcard responses. 'SHOULD' is quite strong language for something that often is not even possible. And, finally, the MAY you ask about is behaviour that is only useful in validators until signers/authoritatives become compliant with this draft. It is a secondary measure (that the WG explicitly requested so as to attempt to solve the problem in multiple places) that should become irrelevant as signers (most of which already have software fixes pending, merged, or released) get upgraded. I hope this answers your question; please let me know if not. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Murray Kucherawy's No Objection on draft-ietf-dnsop-nsec-ttl-04: (with COMMENT)
On Mon, 2021-05-17 at 22:42 -0700, Murray Kucherawy via Datatracker wrote: > > Please make RFC 8174 a normative reference rather than an informative one. > (RFC 2119 already is, but the two documents together make up BCP 14, so I > don't > think you can split them as was done here.) Of course. Updated in my copy. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-nsec-ttl-04: (with COMMENT)
Hello Roman, On Mon, 2021-05-17 at 07:50 -0700, Roman Danyliw via Datatracker wrote: > -- > COMMENT: > -- > > Thank to Tiru Reddy for the SECDIR review. > > Section 5. Per: > > An attacker can prevent future records from appearing in a cache by >seeding the cache with queries that cause NSEC or NSEC3 responses to >be cached, for aggressive use purposes. This document reduces the >impact of that attack in cases where the NSEC or NSEC3 TTL is higher >than the zone operator intended. > > Shouldn’t this text read s/An attacker can prevent future records/An attacker > can delay future records/? That's right, it should read that. I have updated my local copy. > Per Section 9 of RFC8198, “If the resolver is > making aggressive use of NSEC/NSEC3, one successful attack would be able to > suppress many queries for new names, up to the negative TTL." If the timing > is > right, this delay could be indefinite. Isn't the mitigation provided here > that > the attacker needs to seed the cache more often? The delay is never indefinite. The mitigation provided here is that the limit to that delay is lowered, and indeed also, that the attacker might need to seed more often to implement the attack at all. Thanks! Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
On Tue, 2021-05-11 at 18:26 +0200, libor.peltan wrote: > > May I be wrong, but I think that name, type, class and TTL are not repeated > in one RRSet with multiple RData. Not in wire format and not necessarily even > in zonefile. (?) Zone files allow you to leave some of those out on subsequent records. The wire format does not: https://datatracker.ietf.org/doc/html/rfc1035#section-4.1.3 Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of new EDNS opcode "rrserial"
On Mon, 2021-05-10 at 22:09 +0100, Tony Finch wrote: > Peter van Dijk wrote: > > Also in section 3.2, I do not think responding with the option should > > be limited to NOERROR. Specifically, I'd very much also want it to work > > for NXDOMAIN, > > Isn't the SOA record usually present in a negative response? Good point! In that case, I retract most of that and suggest the draft points out that in those cases, a serial can be extracted anyway. That said, I'm not sure that's a reason to skip including the option in the response. > and I can imagine some cases of it being useful even in SERVFAIL cases > > (at least in database-driven name servers like PowerDNS, where > > individual records inside a zone can be broken). > > Perhaps also in cases where the server has a copy of zone serial number > NNN but it has expired. +1 Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of new EDNS opcode "rrserial"
On Mon, 2021-05-10 at 12:37 -0400, Hugo Salgado wrote: > Hello everyone. Thanks for the comments, I just uploaded an unchanged > version (just to revive it) at: > https://datatracker.ietf.org/doc/draft-salgado-dnsop-RRSERIAL/ Thanks Hugo, that is useful. In section 3.2, 'the resource record of the ANSWER section' is ambiguous. The answer section can contain many resource record (s/sets). I suggest a reference to 'QNAME (original)' from RFC8499, or a careful copy of the words in that definition. Also in section 3.2, I do not think responding with the option should be limited to NOERROR. Specifically, I'd very much also want it to work for NXDOMAIN, and I can imagine some cases of it being useful even in SERVFAIL cases (at least in database-driven name servers like PowerDNS, where individual records inside a zone can be broken). > I agree RRSERIAL doesn't have much relevance in zones that don't give > serial versioning a meaning to its content. We can add a paragraph > about it, to make the applicability more clear. I agree, and I do not think this is a reason to not have this feature. > I also don't think we > should start to "deprecate" the SOA serial meaning at this point. > One can say that "modern" implementations using complex backends makes > SOA serials irrelevant, but there's certainly a use case for classic > and mainly static behavior. Just as NSID adds an "infrastructure" > identification dimension to a response, RRSERIAL adds the data > versioning dimension. +1 > And responding to the comment that having multi-queries is better, is > something that is long overdue, and would certainly make this hack > obsolete. Multi-query has not happened. I doubt it will happen. And in fact, mapping this specific use case onto it would limit implementations. I can imagine multi-query being implemented in some proxy/frontend, that sends out parallel queries to 'simpler' auths that do not even know about multi-query, and then the atomicity is gone. > Other issues that I think need more analysis is deciding whether it > makes any sense to expose RRSERIAL in resolvers. The original idea was > only in authoritatives, but it might make some sense to debug in > resolvers as well, to somehow identify the "data source" of a cached > record. In this sense, I fear an increase in cache requirements of > resolvers, which should somehow maintain the extra data; and also > in traffic and option availability for upstream auths. To expose it in resolvers, resolvers would have to set the option on all their outgoing queries, so that they can remember the serial involved in each RRset that they got. I don't think this puts a big burden on storage requirements, but adding EDNS options to all your resolver-to-auth traffic is always a gamble, finding out which auths will suddenly return SERVFAIL, or REFUSED, or just drop your query - or, in some observed cases, tell you NXDOMAIN because they're confused. Now, those auths are wrong, and should not exist, but I trust there will be some reluctance in deployments. That said, supporting this feature in resolvers does not require any changes to the protocol itself; the EDNS option, as your draft currently defines it, looks fine to me. Of course, if the document does want to support the resolver case, it should explain what that means. (Unrelated to anything above, I can see reasons to put the whole SOA in there instead of just the serial; this also reinvokes the 'why not put it in AUTHORITY or ADDITIONAL' question, but I really like the short EDNS option that does not change the processing of any RRsets from a query response.) Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
On Mon, 2021-05-10 at 16:43 +0200, Pieter Lexis wrote: > Hi Dick, > > On 5/10/21 1:02 PM, Dick Franks wrote: > > My objection is narrowly focussed on the escape mechanism, nothing > > more. Changing the delimiter is neither necessary nor relevant. > > > > I am happy to contribute the necessary words. > > If you have the words to fix this issue that would need to changes the > code but clears everything up, do it :). I would like to clarify that Pieter meant 'need no changes to the code'. :-) Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance
On Mon, 2021-05-10 at 10:55 +0200, Benno Overeinder wrote: > The draft is available here: > https://datatracker.ietf.org/doc/draft-hardaker-dnsop-nsec3-guidance/. > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. I support adoption of this draft, and am willing to review and contribute text (in fact, I have already done so at small scale). I think the draft really deserves some text on when not to use NSEC3 at all (i.e. when to pick NSEC instead) and I would be happy to contribute that too, if nobody beats me to it. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-00.txt
Hi Hugo, I still had this message flagged to look at, and your comment still applies. I noted this as https://github.com/NLnetLabs/draft-toorop-dnsop-dns-catalog-zones/issues/26 and we'll fix it in a future revision. Thanks! On Thu, 2020-06-11 at 11:08 -0400, Hugo Salgado wrote: > Hi. I've reviewed this draft and have one comment. > > In 4.3 there's no mention on the type of the RRs > for the member zones. I was expecting to find an > explicit declaration, just like there're for CLASS, > TTL and label format; and not just only as part of > the example. > > Regards, > > Hugo > > On 00:33 03/06, internet-dra...@ietf.org wrote: > > 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 > > Leo Vandewoestijne > > Filename : draft-ietf-dnsop-dns-catalog-zones-00.txt > > Pages : 11 > > Date: 2020-06-03 Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements
On Wed, 2021-04-21 at 23:47 +, Wessels, Duane wrote: > > application. Applications must be coded and configured to make use > > of this filter. > > > > While it's good to point out that this feature exists, I do not think > > mandating it makes sense - implementers and operators might have other > > preferences for handling open-but-as-yet-unused TCP connections. (Also > > the lowercase 'must' is confusing.) > > It was not intended as a requirement, but rather to note that the application > needs to do some work to utilize them. Ah! That makes a lot more sense, yes. > Hows this? > >These features are implemented as low-level socket options. >It is necessary for applications to be specifically coded and >configured to make use of them. To my non-native eyes this still smells like 'you should do this'. How about: These features are implemented as low-level socket options, and they are not activated automatically. If applications wish to use these features, they will need to make specific calls to set the right options, and administrators may need to configure the applications to make these calls. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New version of draft-ietf-dnsop-rfc7816bis after WG last call
Hello Paul, On Thu, 2021-04-15 at 23:15 +, Paul Hoffman wrote: > Everyone (but particularly resolver developers): please review the document > carefully, particularly the algorithm in Section 3, to see if it matches what > you expect. PowerDNS implementation notes: * we combined step 5 and step 6d (and call it step 5); we fall back to 'no minimisation' on anything that's not a NoError response (but the fallback might be handled by the RFC8020 code, especially if that non-NoError response was NXDOMAIN) (the default for RFC8020 is 'on signed domains only') * we use 1-1-1-3-3-.. label steps, which is not exactly what section 2.3 describes (you can find some more details at https://doc.powerdns.com/recursor/appendices/internals.html#qname-minimization ) Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements
On Mon, 2021-04-19 at 07:31 -0400, Joe Abley wrote: > NEW: > >For IPv4-connected hosts, the MTU is often the Ethernet payload >size of 1500 bytes. This means that the largest unfragmented >UDP DNS message that can be sent over IPv4 is likely 1472 bytes, >although tunnel encapsulation may reduce that maximum message >size in some cases. > >For IPv6, the situation is a little more complicated. First, >IPv6 headers are 40 bytes (versus 20 without options in IPv4). >Second, it seems as though some people have mis-interpreted >IPv6's required minimum MTU of 1280 as a required maximum. Third, >fragmentation in IPv6 can only be done by the host originating >the datagram. The need to fragment is conveyed in an ICMPv6 >"packet too big" message. The originating host indicates a >fragmented datagram with IPv6 extension headers. Unfortunately, >it is quite common for both ICMPv6 and IPv6 extension headers >to be blocked by middleboxes. According to [HUSTON] some 37% of >IPv6-capable recursive resolvers were unable to receive a >fragmented IPv6 packet. Even if the originating host does receive >a signal that fragmentation is required, the stateless nature >of the DNS protocol is such that the host does not generally >retain a copy of the message concerned and hence is unable to >fragment and re-send anyway. This note on statelessness is good, but I don't think it should be tied to IPv6. Packets get lost in IPv4 too, especially when they are big, and even if such evens trigger a report in the form of an ICMP message, the same lack-of-state problem applies. https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ even proposes setting DONTFRAG socket options, and some servers out there already send IPv4 replies with the DF bit set (the two I can verify immediately are OpenDNS, and whatever is running on the router my provider gave me, but most likely there are others too). Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements
> This message starts the Working Group Last Call for > draft-ietf-dnsop-tcp-requirements > (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/) This is a good document. One comment here: The FreeBSD, OpenBSD, and NetBSD operating systems have an "accept filter" feature ([accept_filter]) that postpones delivery of TCP connections to applications until a complete, valid request has been received. The dns_accf(9) filter ensures that a valid DNS message is received. If not, the bogus connection never reaches the application. Applications must be coded and configured to make use of this filter. While it's good to point out that this feature exists, I do not think mandating it makes sense - implementers and operators might have other preferences for handling open-but-as-yet-unused TCP connections. (Also the lowercase 'must' is confusing.) Suggested extra text: > The Linux TCP_DEFER_ACCEPT feature, while more limited in scope, can provide some of the same benefits as the BSD accept filter feature. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-svcb-https
On Fri, 2021-04-09 at 08:58 +0200, Petr Špaček wrote: > On 08. 04. 21 16:39, Ben Schwartz wrote: > > Thanks for the feedback, Petr. I think the easiest solution is to relax > > the requirement language. I've proposed a change here: > > https://github.com/MikeBishop/dns-alt-svc/pull/313 > > <https://github.com/MikeBishop/dns-alt-svc/pull/313> > > Copying the diff here: > > > - Recursive resolvers SHOULD treat the SvcParams portion of the SVCB RR > > - as opaque and SHOULD NOT try to alter their behavior based > > - on its contents. > > > > + Recursive resolvers MAY treat the SvcParams portion of the SVCB RR > > + as opaque. No part of this specification requires recursive resolvers > > + to alter their behavior based on its contents, even if the contents are > > + invalid. > > This addresses my concern, thank you! +1, thanks! Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NXDOMAIN and RFC 8020
And the 'go read this' reference is https://tools.ietf.org/html/rfc8198 On Tue, 2021-04-06 at 20:29 +0200, libor.peltan wrote: > Hi Murray, > if foo.example does not exist and DNSSEC is in place, than the resolver > actually, even with the queries "in reverse order", obtains and NSEC(3), > proving non-existence for much more. > For example, the query is bar.foo.example, and the authoritative returns an > NSEC proving that there is nothing between fa.example and fz.example. Thus, > the resolver can later deduct nonexistence not only for foo.example, but also > for fun.example and bar.fun.example, etc... > Without DNSSEC, this deduction (called "aggresive NSEC caching") is not > possible. > Cheers, > Libor > Dne 06. 04. 21 v 20:11 Murray S. Kucherawy napsal(a): > > > > This would make an ascending tree walk even for something crazy like > > "a.b.c.d.y.z.foo.example" extremely cheap as the cached NXDOMAIN for > > "foo.example" covers the entire subtree, for a caching nameserver > > implementing RFC 8020. > > > > Maybe this is discussed somewhere that I missed in the references. I'm > > happy to take a "go read this for the answer" if that's the case. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-04.txt
On Fri, 2021-03-19 at 10:42 -0400, Ben Schwartz wrote: > Does anyone have an example of test vector presentation that they like? > Perhaps it should be structured as a pair of zone files representing the same > zone, one in SVCB format and one in RFC 3597. tl;dr: +1 to that I recently implemented CSYNC in PowerDNS, and was greatly aided therein by RFC 7477 section 2.1.3, which I will quote here: === The following CSYNC RR shows an example entry for "example.com" that indicates the NS, A, and bits are set and should be processed by the parental agent for example.com. The parental agent should pull data only from a zone using a minimum SOA serial number of 66 (0x42 in hexadecimal). example.com. 3600 IN CSYNC 66 3 A NS The RDATA component of the example CSYNC RR would be encoded on the wire as follows: 0x00 0x00 0x00 0x42 (SOA Serial) 0x00 0x03 (Flags = immediate | soaminimum) 0x00 0x04 0x60 0x00 0x00 0x08 (Type Bit Map) === In my case, I could take these hex octets, sprinkle in a few backslashes, and make the test case fit *our* codebase: test-dnsrecords_cc.cc: (CASE_S(QType::CSYNC, "66 3 A NS ", "\x00\x00\x00\x42\x00\x03\x00\x04\x60\x00\x00\x08")) Ever since I've been wondering what the best format would be, though, so that vendors could exchange collections of test vectors. I already imagined OARC maintaining that collection even! I think your SVCB/3597 pairing might be that format. I know NLnetlabs and ISC have tools that can even generate the latter from the former (for supported types, of course), which makes testing and verifying implementations very easy if the RFC also shows that pair, and even allows users (and draft authors!) to do the same checks. The only thing I wonder about is whether we can combine the 3597 format with the 3 part breakdown 7477 did on the hexdump, which also is very educational. Of course, nothing prevents us from doing both the breakdown and a couple of 3597 pairings. So, +1 from me! Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS Error Reporting
On Wed, 2021-03-17 at 16:49 -0700, Brian Dickson wrote: > > > > Finally, what about an optional field for resolver operator contact info > > > (e.g. vCard or similar), so the authority operator can follow up with a > > > human if appropriate? > > > > Interesting idea, but it leads to packet bloat caused by data which are > > unnecesary vast majority of the time. > > > > Are we (as dnsop WG) not concerned with packet bloat anymore? > > This would add data on the DNS query used for sending the report. DNS queries > are generally very limited in size, typically less than 100 octets long. > Adding something like "TYPE|LENGTH|mailto:dns-ad...@example.com"; on small > query packets for reports is not likely to cause problems for anyone, > anywhere. > > So, maybe no real concern if the length is limited to some sensible value? The reporting query comes from an IP, presumably owned by the 'failing' resolver, or some upstream of it. That IP is in a WHOIS database. Am I too optimistic when I suggest that the WHOIS database can provide the contact info? Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
On Thu, 2021-03-11 at 19:11 -0800, Brian Dickson wrote: > From the status updates today, I see this draft has expired. I really like it > (and it is quite simple), and would like to see it picked up and completed > (adopted, rough consensus reached, published). > > Having reread it and the discussion, I am wondering if useful guidance can be > provided regarding the TC=1 and records added. > > If as much glue as will fit is included, but not all glue fits, add all the > glue that fits, and set TC=1. > The resolver SHOULD attempt to use the available glue, but retry over TCP if > none of the servers found via the available glue respond. This sounds like something that might be very hard to fit into the flow of at least some code bases out there. > I.e. How is TC=1 interpreted currently by different implementations, and is > THAT an issue that could/should be clarified, either in this document, or in > a separate document? Answered below for us. > Is it necessary (at all) to mention keeping the glue that fits before setting > TC=1? > I don't think so, but maybe some commentary to that effect would be helpful? When we (PowerDNS auth) set TC=1, we empty the packet, based on the (somewhat under-argued) belief that different resolvers may draw different conclusions from what is there and what is not, and emptyingthe packet avoids ambiguity. Mirroring that, if the PowerDNS Recursor receives a TC=1 response (with rcode NOERROR or NXDOMAIN), no records are harvested and the whole query is retried over TCP. Based on only our choices, it is pointless to have any content in a TC=1 response. Others may feel somewhat differently, of course! Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-01.txt
Hello, On Fri, 2021-02-19 at 13:21 -0800, cpol...@surewest.net wrote: > On 2021-02-19 18:45, Havard Eidnes wrote: > > However, "burning" a new RR just for this purpose seems to me to > > not be necessary, so I favour the scheme in 5.6 using a TXT > > record instead. > > My reading of RFC 5507 "Design Choices When Expanding the DNS" > §6 ( https://tools.ietf.org/html/rfc5507#section-6 ): > > ... of all the alternate solutions, the "obvious" approach of using > TXT Resource Records for arbitrary names is almost certainly the > worst ... > > seems to favor "burning" a new RR "just for this purpose". > While RFC 5507 is informational, it does consider the general > problem (new RR vs. TXT) in some detail. 5507 is an absolutely excellent document, that cannot be summarised by its conclusion. In this case, it turns out that most of the reasons given in the full text, leading up to the 'burn an RRtype' conclusion, do not really apply to catalog zones. We do not have wildcards, and we do not have UDP message size constraints, the zones will not be queried by random tools that might have unrelated semantics. I'm not arguing that catalog zones -should- use TXT for everything (because that would be terrible); but the firmess of 5507's conclusion does not fully apply here. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-ttl-04.txt
Hello DNSOP, with thanks to Matthijs and Paul who commented on -03: * the 'incremental signer exception' is now part of all relevant document updates * added an explanation for the upgraded requirement level On Thu, 2021-02-18 at 09:15 -0800, internet-dra...@ietf.org wrote: > 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 : NSEC and NSEC3 TTLs and NSEC Aggressive Use > Author : Peter van Dijk > Filename: draft-ietf-dnsop-nsec-ttl-04.txt > Pages : 10 > Date: 2021-02-18 > > Abstract: >Due to a combination of unfortunate wording in earlier documents, >aggressive use of NSEC and NSEC3 records may deny names far beyond >the intended lifetime of a denial. This document changes the >definition of the NSEC and NSEC3 TTL to correct that situation. This >document updates RFC 4034, RFC 4035, RFC 5155, and RFC 8198. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-ttl/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-dnsop-nsec-ttl-04.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-nsec-ttl-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-ttl-03.txt
Hello dnsop, thank you to all who responded in the WGLC thread. After the discussion I felt I had nothing to ask or add, so instead, here is a draft revision that I feel addresses everything that was said. (Matthijs, this revision changes the requirements back to MUST as that feels like it more closely matches the majority opinion voiced, but I added a section allowing for the incremental signer situation - please let me know if this is workable for you.) My understanding of the discussion is that the document failed to address various assorted vagueness, and separations between developer and operator concerns, and role differences between signers, authoritatives and resolvers/validators, in the original documents. Paul Hoffman provided a bunch of text clarifying 'what goes where' so that this document can improve that situation, thanks Paul! Changes in this version, as listed in the Document History section: * document now updates resolver behaviour in 8198 * lots of extra text to clarify what behaviour goes where (thanks Paul Hoffman) * replace 'any' with 'each' (thanks Duane) * upgraded requirement level to MUST, plus a note on incremental signers Your comments are, again, very much welcome. On Tue, 2021-02-09 at 12:17 -0800, internet-dra...@ietf.org wrote: > 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 : NSEC and NSEC3 TTLs and NSEC Aggressive Use > Author : Peter van Dijk > Filename: draft-ietf-dnsop-nsec-ttl-03.txt > Pages : 9 > Date: 2021-02-09 > > Abstract: >Due to a combination of unfortunate wording in earlier documents, >aggressive use of NSEC and NSEC3 records may deny names far beyond >the intended lifetime of a denial. This document changes the >definition of the NSEC and NSEC3 TTL to correct that situation. This >document updates RFC 4034, RFC 4035, RFC 5155, and RFC 8198. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-ttl/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-dnsop-nsec-ttl-03.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-nsec-ttl-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-nsec-ttl
Hello Michael,
On Fri, 2021-01-29 at 12:31 -0500, Michael StJohns wrote:
> On 1/29/2021 10:22 AM, Tim Wicinski wrote:
> > This starts a Working Group Last Call for draft-ietf-dnsop-nsec-ttl
> >
> > Current versions of the draft is available here:
> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-ttl/
> >
> > The Current Intended Status of this document is: Proposed Standard
> > as it will update 4034, 4035, and 5155.
> >
> Hi Tim et al -
> Sorry - I completely missed this document earlier.
> I can't support this as Standards track even though it purports to update
> standards as it doesn't actually specify an implementable protocol.
> Basically, this is dependent upon humans doing the right thing, rather than
> specifying behavior of the protocol.
The updates in this document are reflected in software patches, not
human behaviour. What am I missing?
> For each of these, I'd recommend specifying what a client does in each of the
> cases, rather than weasel wording the SHOULD with respect to the zone
> contents to turn this into an implementable protocol.
Wow, what?
> E.g. for each of these clauses add something similar to "The client
> SHOULD/MUST reduce the effective TTL for the received NSEC RR to the lesser
> of the TTL of the current SOA record, the TTL of the SOA, and the TTL of the
> NSEC RR record and MUST discard the NSEC RR when that effective TTL expires."
The client (I assume you mean a caching validating resolver) should not
do that at all. If the document suggests that to you, please help me
fix that.
Note that if we -did- wanted to write this, we couldn't - section 3.4
('No updates to RFC8198') explains why.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-ttl-02.txt
Hello, I noticed that 5155 had another occurence of the wrong text. This revision -02 updates that text too. With this, I again believe the document is ready for WGLC. Chairs? Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ On Fri, 2021-01-29 at 02:51 -0800, internet-dra...@ietf.org wrote: > 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 : NSEC(3) TTLs and NSEC Aggressive Use > Author : Peter van Dijk > Filename: draft-ietf-dnsop-nsec-ttl-02.txt > Pages : 8 > Date: 2021-01-29 > > Abstract: >Due to a combination of unfortunate wording in earlier documents, >aggressive use of NSEC(3) records may deny names far beyond the >intended lifetime of a denial. This document changes the definition >of the NSEC(3) TTL to correct that situation. This document updates >RFC 4034, RFC 4035, and RFC 5155. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-ttl/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-dnsop-nsec-ttl-02.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-nsec-ttl-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-ttl-01.txt
Hello DNSOP, inspired by success stories from other WGs, I've written up an implementation report on the IETF Trac wiki, at https://trac.ietf.org/trac/dnsop/wiki/draft-ietf-dnsop-nsec-ttl This will allow us to track implementation after document publication - when the 'Implementation Status' from the draft is gone (we usually do not publish it in the final RFC - and if we did, it would quickly be outdated). If we do this for other documents too, we can easily check how implementation is going - and if implementation is happening at all! Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-ttl-01.txt
Hello dnsop, please find below revision -01 of this document. Matt Nordhoff noticed that I upgraded the NSEC TTL requirements from 'SHOULD' to 'MUST' compared to the original texts, and pointed out that incremental signers might have a hard time honouring that 'MUST'. Matthijs Mekking (ISC/BIND) confirmed this theory. So, -01 drops the requirement level back to SHOULD, just like the original texts. I believe the document is ready for publication. Chairs, can we do a WGLC? On Sun, 2021-01-24 at 23:59 -0800, internet-dra...@ietf.org wrote: > 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 : NSEC(3) TTLs and NSEC Aggressive Use > Author : Peter van Dijk > Filename: draft-ietf-dnsop-nsec-ttl-01.txt > Pages : 8 > Date: 2021-01-24 > > Abstract: >Due to a combination of unfortunate wording in earlier documents, >aggressive use of NSEC(3) records may deny names far beyond the >intended lifetime of a denial. This document changes the definition >of the NSEC(3) TTL to correct that situation. This document updates >RFC 4034, RFC 4035, and RFC 5155. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-ttl/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-dnsop-nsec-ttl-01.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-nsec-ttl-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))
On Thu, 2021-01-21 at 18:14 -0800, Brian Dickson wrote: > Paul's proposal would still require the parent to produce and serve the > NSRRSIG. However small a change that is, it is still a change. Yes, a change in signers and auths. > When compared with the alternative I proposed, my suggestion does not require > changes on the parent side, only on the Registrar, and possibly the child > authority server, and the validating resolver. > (Reminder, my idea was: use a new DNSSEC algorithm to stuff either the child > NS set or the parent NS set into a DNSKEY record and submit that as a new DS > value via existing EPP paths for updating the DS set.) Yes, I've also informally proposed this in the past, and Fujiwara's draft is the version with signer assistance. > I think both are viable options, where the question of whether both are truly > feasible (universally, i.e. across all TLDs) is the critical issue. > If the answer to that question is "no", then choosing the path that does not > require any TLD changes (at all) would seem (to me) to be the most promising > path. There's another perspective - if TLDs do this (where 'this' is 'whatever variant that gives us signed delegation NSsets'), then a NS owner can 'enable DoT' by publishing TLSA, without having to tell all his users 'please submit this pseudo-DNSKEY record to your TLD'. This strongly argues for "let's put the pain with a few hundred TLD operators" instead of thousands of registrars, their resellers, their clients that use APIs, their clients that use webforms that do not aid them in getting things right, their NS operators that now need to provide 200% more assistance when people change operators. In short, moving this pain into the signers&auths (both of which come from only a handful of vendors!) actually makes a lot of sense to me. Many TLDs will be able to 'implement' CNSRRSIG (or some other variant) through the regular updates I trust they already do. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))
On Thu, 2020-12-10 at 15:48 -0800, Brian Dickson wrote: > > > > Compared to DiS, registrar complexity is identical (because the > > complexity is also hidden in the signer here); signer complexity is > > potentially lower. The only real complexity change vs. DiS is in the > > auths, that now need to know to serve CNSRRSIG from the parent side in > > the additional part of a delegation response. For resolvers, this vs. > > DiS is again pretty much moot. > > The CNSRRSIG would also require delegation auths (i.e. TLDs) to make changes That is what the quoted text means to convey, sorry if that was unclear! > , and I think also require EPP changes. I don't see how EPP comes into it at all. The signer signs all NSsets; the auth serves the signatures with the delegations; done. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-ttl-00.txt
Hello DNSOP, I believe this version addresses all comments posted on this list. If not, please let me know! >From the Document history Appendix: * document was adopted * various minor editorial changes * now also updates 4035 * use .example instead of .com for the example * more words on 8198 * a note on wildcards Thank you to all who supported adoption. On Wed, 2021-01-13 at 02:29 -0800, internet-dra...@ietf.org wrote: > 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 : NSEC(3) TTLs and NSEC Aggressive Use > Author : Peter van Dijk > Filename: draft-ietf-dnsop-nsec-ttl-00.txt > Pages : 7 > Date: 2021-01-13 > > Abstract: >Due to a combination of unfortunate wording in earlier documents, >aggressive use of NSEC(3) records may deny names far beyond the >intended lifetime of a denial. This document changes the definition >of the NSEC(3) TTL to correct that situation. This document updates >RFC 4034, RFC 4035, and RFC 5155. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec-ttl/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-dnsop-nsec-ttl-00.html > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new draft: 'NSEC(3) TTLs and NSEC Aggressive Use' (New Version Notification for draft-vandijk-dnsop-nsec-ttl-00.txt)
On Wed, 2021-01-13 at 10:21 +0100, Peter van Dijk wrote: > On Fri, 2021-01-08 at 11:33 +0100, Vladimír Čunát wrote: > > Well, if the client requests the proof (+dnssec), you have to include > > those NSEC*s and I'd consider it incorrect to prolong their TTL. I'd be > > surprised if someone chose that lack of +dnssec could change this TTL > > behavior, except for implementations without DNSSEC support. At least > > that's _my_ understanding of the current RFCs (even before > > DNSSEC-aggressive caching). > > Ah yes, now I get it. The impact of NSEC TTL on wildcard validity is > not really something that 8198 did, or that this document does. This > document does, of course, change that TTL for some setups. I was wrong, 8198 says this: | Once the records are validated, DNSSEC-enabled validating | | resolvers SHOULD use wildcards and NSEC/NSEC3 resource records | | to generate positive and negative responses until the | | effective TTLs or signatures for those records expire. 4035 only vaguely hints at it. So, a correct implementation of 8198 would get the TTLs right, but an implementer that only read other documents might not realise that they should only keep the wildcard around as long as the proof is valid - even though it is obvious once you think about it :-) That all said, I now no longer think we need to do a whole update/clarification thing on this, but I will add a note to my document saying that changing the NSEC TTL might affect wildcards, as you requested earlier. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new draft: 'NSEC(3) TTLs and NSEC Aggressive Use' (New Version Notification for draft-vandijk-dnsop-nsec-ttl-00.txt)
On Fri, 2021-01-08 at 11:33 +0100, Vladimír Čunát wrote: > Well, if the client requests the proof (+dnssec), you have to include > those NSEC*s and I'd consider it incorrect to prolong their TTL. I'd be > surprised if someone chose that lack of +dnssec could change this TTL > behavior, except for implementations without DNSSEC support. At least > that's _my_ understanding of the current RFCs (even before > DNSSEC-aggressive caching). Ah yes, now I get it. The impact of NSEC TTL on wildcard validity is not really something that 8198 did, or that this document does. This document does, of course, change that TTL for some setups. > > > Maybe the final text would better explicitly note such implications, but > > > that certainly can wait way past WG adoption. Also it might be confusing > > > that just by singing a zone the effective TTL of these answers would get > > > lower - assuming I got your intention right (if not, perhaps the current > > > text wasn't clear enough anyway). > > Whether signing a zone lowers the TTL on an expanded wildcard depends > > entirely on the implementation - basically my previous paragraph in this > > email. I'd say the right approach is the MIN(..) from the previous > > paragraph. > > > > However, I'm unsure what text the document should have about this. As in my > > response to Matthijs, the problem flows from 8198 but the problem is not in > > 8198. That said, we can always put more explanations in this document - > > perhaps even a Background section, and then I can shorten the Introduction > > section to only explain the core of the problem. > > I had in mind adding a simple note about this (possible?) consequence, > as I don't think it's completely obvious and it wasn't happening before > implementing this RFC. It took me a while to understand the question, but now that I get it, I have found that at least one validator implementation does not currently cap the TTL of expanded wildcards to the lowest TTL in the proof. Now I wonder if that needs to be written down explicitly, and whether that should also go into this document (which we would then retitle 'NSEC(3) TTL clarifications'?). Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new draft: 'NSEC(3) TTLs and NSEC Aggressive Use' (New Version Notification for draft-vandijk-dnsop-nsec-ttl-00.txt)
Hello Vladimir, On Sat, 2020-12-12 at 11:46 +0100, Vladimír Čunát wrote: > From resolver point of view... this implies that signed *positive* > wildcard answers will now get cached with this shorter "negative TTL", > right? These do need to deny existence of non-wildcard match, so they > need to contain NSEC*. That depends on whether a resolver caches wildcards with the TTL of the wildcard RRset, or of the NSECs proving that the wildcard expansion is valid. My suspicion is that most resolvers today do the former, and when they grow the 'aggressive NSEC for wildcards' feature, they'll take MIN(former, latter). > Maybe the final text would better explicitly note such implications, but > that certainly can wait way past WG adoption. Also it might be confusing > that just by singing a zone the effective TTL of these answers would get > lower - assuming I got your intention right (if not, perhaps the current > text wasn't clear enough anyway). Whether signing a zone lowers the TTL on an expanded wildcard depends entirely on the implementation - basically my previous paragraph in this email. I'd say the right approach is the MIN(..) from the previous paragraph. However, I'm unsure what text the document should have about this. As in my response to Matthijs, the problem flows from 8198 but the problem is not in 8198. That said, we can always put more explanations in this document - perhaps even a Background section, and then I can shorten the Introduction section to only explain the core of the problem. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new draft: 'NSEC(3) TTLs and NSEC Aggressive Use' (New Version Notification for draft-vandijk-dnsop-nsec-ttl-00.txt)
Hi Matthijs, On Fri, 2020-12-18 at 18:02 +0100, Matthijs Mekking wrote: > Hi Peter, > > I reviewed the draft and it mostly looks good. Thanks! > Some minor comments: > > 1. Perhaps instead of using ".com" as an example, use ".example" (per > RFC 2606)? Noted at https://github.com/PowerDNS/draft-dnsop-nsec-ttl/issues/3 > 2. Shouldn't this document also update some text parts from RFC 8198? Hmm. Obviously, some of the text in 8198 is wrong, but there is no action for 8198 implementers here. Noted at https://github.com/PowerDNS/draft-dnsop-nsec-ttl/issues/4 for more pondering. > 3. About this paragraph: > > Ralph Dolmans helpfully pointed out that fixing this in RFC8198 is > only possible for negative (NXDOMAIN/NoData NOERROR) responses, and > not for wildcard responses. > > I think it deserves a separate section or subsection within section 4, > and not be tucked away in the acknowledgements. > > Also this should be a bit more verbose, it took me three times to > understand what is exactly said here. > > Proposed text: > > > [RFC 8198] says: > > With DNSSEC and aggressive use of DNSSEC-validated cache, the TTL > of the NSEC/NSEC3 record and the SOA.MINIMUM field are the > authoritative statement of how quickly a name can start working > within a zone. > >Here, the SOA.MINIMUM field cannot be changed to "the minimum of the >SOA.MINIMUM field and the SOA TTL" because the resolver may not have >the SOA RRset in cache. However, if authoritative servers follow the >updates from this document, this should not make a difference, as the >TTL of the NSEC/NSEC3 record is already set to the minimum value. > > > Ralph can of course still be acknowledged for the helpful pointer. Yes, that makes sense, it is relevant background. I took your text plus something extra and put it at https://github.com/PowerDNS/draft-dnsop-nsec-ttl/pull/5 Thanks! Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))
Hello Paul, On Mon, 2020-11-30 at 15:43 +, Paul Hoffman wrote: > The more I think about draft-fujiwara-dnsop-delegation-information-signer, > the more I think that it is much more complex than what we are doing now in > DNSSEC, and therefore undesirable. My feelings are similar but not identical - the conversation already shows that the glue story will be almost impossible to implement. Next to that, I haven't figured out why we'd want to authenticate glue. However, authenticating the delegation NSset fills an obvious gap in various suggested answers to the dprive phase2 question (privacy between resolvers and authoritatives). > If the goal is "a way for a signer in a parent to sign child NS in a way that > does not affect validators that have not been updated (or don't care)", a > significantly easier solution would be a new RRtype (maybe called "CNSRRSIG") > that closely mimics RRSIG but only allows child NS for signing. An aware > signer included the CNSRRSIG in the zone, and an aware authoritative server > includes in in the Authority section when serving child NS records. An aware > resolver can use this, an unware resolver would treat it like any other > unknown RRtype that appears in the Authority section. This makes a ton of sense to me. Compared to DiS, registrar complexity is identical (because the complexity is also hidden in the signer here); signer complexity is potentially lower. The only real complexity change vs. DiS is in the auths, that now need to know to serve CNSRRSIG from the parent side in the additional part of a delegation response. For resolvers, this vs. DiS is again pretty much moot. > There are probably a few other diffs from the RRSIG definition in RFC 403x, > but they should be minor. This might make implementation more likely to be > correct for signers, servers, and resolvers. Yes, this calls for some experiments, but I suspect the outcome will be as you described above - which means no hurdles to incremental rollout. (I am not even convinced this needs to be a new type, vs. reusing RRSIG under the specific semantics you described, but a new type feels cleaner to me.) > Thoughts? +1 ! Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new draft: 'NSEC(3) TTLs and NSEC Aggressive Use' (New Version Notification for draft-vandijk-dnsop-nsec-ttl-00.txt)
Hello DNSOP, On Mon, 2020-11-23 at 21:16 +0100, Peter van Dijk wrote: > please find below my draft that updates one > sentence in 4034 and the ~same sentence in 5155. As far as I can see, > no correction to 8198 is necessary or useful. I believe this draft is non-controversial. I am inclined to see the lack of response as a lack of controversy as well. Chairs, I believe this document could go through the motions to publication quite quickly if no objections appear. Can I request a call for adoption please? Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] new draft: 'NSEC(3) TTLs and NSEC Aggressive Use' (New Version Notification for draft-vandijk-dnsop-nsec-ttl-00.txt)
Hello, in https://lists.dns-oarc.net/pipermail/dns-operations/2018-April/017420.html (and earlier messages in March on the same thread), people realised that aggressive NSEC caching might use a much longer TTL than the negative TTL intended by a zone operator. The initial idea was to correct this in an erratum to RFC 8198 (aggressive use of NSEC/NSEC3), but Ralph Dolmans pointed out to me that this would not solve the wildcard case. I did a lightning talk on the topic at OARC 29 ( https://indico.dns-oarc.net/event/29/sessions/98/#20181013), where the audience feedback, as I recall it, was agreeable to my suggestion of 'issuing operational guidance'. I have since come to the conclusion that it would be better to also fix this in software. Hence, please find below my draft that updates one sentence in 4034 and the ~same sentence in 5155. As far as I can see, no correction to 8198 is necessary or useful. Any editorial comments are welcome via GitHub (link is in the draft), private email, or this WG list. Any functional comments on the content, please post them to the WG. Thank you. (Warren, if you feel the wording of my acknowledgement lays blame with you in a way that you'd rather not see immortalised in an RFC, please let me know!) Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ Forwarded Message From: internet-dra...@ietf.org To: Peter van Dijk Subject: [EXT] New Version Notification for draft-vandijk-dnsop-nsec- ttl-00.txt Date: Mon, 23 Nov 2020 12:03:04 -0800 A new version of I-D, draft-vandijk-dnsop-nsec-ttl-00.txt has been successfully submitted by Peter van Dijk and posted to the IETF repository. Name: draft-vandijk-dnsop-nsec-ttl Revision: 00 Title: NSEC(3) TTLs and NSEC Aggressive Use Document date: 2020-11-23 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/archive/id/draft-vandijk-dnsop-nsec-ttl-00.txt Status: https://datatracker.ietf.org/doc/draft-vandijk-dnsop-nsec-ttl/ Html: https://www.ietf.org/archive/id/draft-vandijk-dnsop-nsec-ttl-00.html Htmlized: https://tools.ietf.org/html/draft-vandijk-dnsop-nsec-ttl-00 Abstract: Due to a combination of unfortunate wording in earlier documents, aggressive use of NSEC(3) records may deny names far beyond the intended lifetime of a denial. This document changes the definition of the NSEC(3) TTL to correct that situation. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Fwd: New Version Notification for draft-vandijk-dnsop-ds-digest-verbatim-00.txt]
Hello Paul, On Fri, 2020-09-25 at 17:13 -0400, Paul Wouters wrote: > I could see a use of publishing a DNSKEY at the parent in a DS record > that could be used for encrypted connections towards child nameservers. Me too! :-) > But we talked about this within the context of your other proposals, > and the view of a number of people and some large operators was that > this encryption is a per-nameserver thing, and not a per-zone thing. Lacking defined use cases and alternative proposals, I'm still considering the possible future where we have one method for each of those focuses, with different tradeoffs. > Another item not covered here we talked about before, is that child > data published in the parent MUST have cryptographic confirmation at > the child. Or else parents can coerce child data. Yes, I'm aware! I wanted to keep the -00 simple to first test for appetite in the WG. One of the DOTPIN co-authors brought up your 'child confirmation' idea for both drafts I posted this week, and in both cases, that seems to be an addition that could easily work. For this draft, in CDS or CDNSKEY; for the other draft, either by mandating 'some form of it' for anything that allocates out of the reserved range, or even by specifying right now 'odd numbers go in the parent, even numbers go in the child, and content needs to match'. However, so far it does not look like any of my drafts have gotten stuck because of -this- so I'm not inclined to put those words in yet. After adoption seems like plenty of time to discuss this. > It seems the setup of this record is geared towards a generic mechanism > of "child publishes stuff at the parent" which muddles the clear child > vs parent zone divider we have now. It would need a very strong use > case, but the other use case offered is "might be handy in the future". Yes - both drafts are 'this may prevent pain later'. I only have halfbaked ideas for what you could do with 'non-hashed parent-side publication of child data' (which both drafts provide): DoH URLs, signed delegation NS sets (which I consider a prime candidate for 'enabling TLSA in child', but that could be done DOTPIN style instead of either of these drafts), etc. > While I agree that DNS infrastructure updates have been extremely slow, > I do think in recent years it has been much better and is still > improving. So I am less concerned about anything taking 5 years again. Now if only we could apply that optimism to operator-registry communications :) Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] [Fwd: New Version Notification for draft-vandijk-dnsop-ds-digest-verbatim-00.txt]
Hello dnsop, in this new episode of 'enabling future innovations that we perhaps cannot even imagine today', please find below a link to a draft proposing a DS digest type that does no digesting at all. This allows a zone owner to publish information in the parent zone and have the parent sign that data on the owner's behalf. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ Forwarded Message From: internet-dra...@ietf.org To: Peter van Dijk Subject: [EXT] New Version Notification for draft-vandijk-dnsop-ds- digest-verbatim-00.txt Date: Fri, 25 Sep 2020 05:33:07 -0700 A new version of I-D, draft-vandijk-dnsop-ds-digest-verbatim-00.txt has been successfully submitted by Peter van Dijk and posted to the IETF repository. Name: draft-vandijk-dnsop-ds-digest-verbatim Revision: 00 Title: The VERBATIM Digest Algorithm for DS records Document date: 2020-09-25 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/id/draft-vandijk-dnsop-ds-digest-verbatim-00.txt Status: https://datatracker.ietf.org/doc/draft-vandijk-dnsop-ds-digest-verbatim/ Html: https://www.ietf.org/id/draft-vandijk-dnsop-ds-digest-verbatim-00.html Htmlized: https://tools.ietf.org/html/draft-vandijk-dnsop-ds-digest-verbatim-00 Abstract: The VERBATIM DS Digest is defined as a direct copy of the input data without any hashing. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] [Fwd: New Version Notification for draft-peetterr-dnsop-parent-side-auth-types-00.txt]
Hello dnsop,
early 2019, Manu of Facebook proposed the DSPKI record - a parent-side-
of-the-delegation record to hold a pin for authenticating child-side
DoT servers. This would be undeployable.
A few months ago, Tim April proposed NS2/NS2T, which looks like it
would clearly benefit from the ability to publish signed data on the
parent side of a delegation. This ability seems unlikely today.
Also a few months ago, myself and a few others proposed shoehorning
certificate hashes into the DS record. The shoehorning (and perhaps
some other aspects of that proposal) were not well received by
everybody.
When talking to Petr Spacek about this, he came up with the following:
-if-, long enough ago, besides DS, a range of RRtype numbers would have
been reserved with the same processing rules, i.e. these types live in
the -parent- and not on the -child-, then both DSPKI and NS2T could
become parent side records through the simple act of requesting an
IANA allocation from that special range.
Sadly, it is not five years ago today. It is today today. So, here is a
draft that requests that IANA reserves such a range. Knowledge of that
range and its DS-like handling can then end up in implementations over
time. When that has happened at some useful scale, we could do a DSPKI
experiment. NS2T could explore what benefits come from the ability to
publish in the parent. And, nobody will have to shoehorn hashed TLS
certificates into DS records.
This draft is a bit rough; I trust it, and this email, have brought the
idea across. Editorial comments are welcome via GitHub (link is in the
draft), or via the WG of course.
Looking forward to your thoughts on this.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
Forwarded Message
From: internet-dra...@ietf.org
To: Petr Spacek , Peter van Dijk <
peter.van.d...@powerdns.com>
Subject: [EXT] New Version Notification for draft-peetterr-dnsop-
parent-side-auth-types-00.txt
Date: Thu, 24 Sep 2020 10:49:03 -0700
A new version of I-D, draft-peetterr-dnsop-parent-side-auth-types-00.txt
has been successfully submitted by Peter van Dijk and posted to the
IETF repository.
Name: draft-peetterr-dnsop-parent-side-auth-types
Revision: 00
Title: Parent-side authoritative DNS records for enhanced delegation
Document date: 2020-09-24
Group: Individual Submission
Pages: 5
URL:
https://www.ietf.org/id/draft-peetterr-dnsop-parent-side-auth-types-00.txt
Status:
https://datatracker.ietf.org/doc/draft-peetterr-dnsop-parent-side-auth-types/
Html:
https://www.ietf.org/id/draft-peetterr-dnsop-parent-side-auth-types-00.html
Htmlized:
https://tools.ietf.org/html/draft-peetterr-dnsop-parent-side-auth-types-00
Abstract:
A DNS RRtype numeric range that behaves like DS is reserved. This
means: being authoritative on the parent side of a delegation; being
signed by the parent; being provided along with delegations by the
parent. If this document had become an RFC five years ago, deploying
new types (along the lines of NS2/NS2T, DSPKI or various other
imagined things like DNS ('signed delegation NS')) would be easier to
deploy and experiment with today.
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Authoritative servers announcing capabilities
Hello Paul, Puneet, On Fri, 2020-09-11 at 20:37 +, Paul Hoffman wrote: > Greetings. Puneet and I have an new draft, > <https://tools.ietf.org/html/draft-pp-dnsop-authinfo>;, that we would like > DNSOP to consider. From the abstract: > This document defines a new DNS RRtype, AUTHINFO, that is used by > authoritative servers to publish information about themselves. This > information can be useful because a recursive resolver can determine > an authoritative server's capabilities, such as whether an > authoritative server supports the EDNS(0) client subnet extension. > > The responses will be signed if the zone for which the server is > authoritative is signed, meaning that validating resolvers can get > authenticated information about the server if that would influence how they > treat responses from the server. Thank you for writing this down. I'm not sure I'm a fan yet (ECS does not need this, and the DoT-usecase that builds upon this in DPRIVE is troublesome at least until the disconnect described below is resolved), but for now I have some comments that should improve the document. In general, this document appears to suffer from a disconnect between 'information published by an auth about itself' and 'information published in a zone'. Elsewhere in the thread this appears to be leading to 'perhaps it should be EDNS instead', but I feel that that is a premature conclusion. Deciding on that would make more sense once this disconnect is resolved. 'Thus, the AUTHINFO Rdata returned from different authoritative servers for the same zone might differ.' (section 2) and 'The values in the AUTHINFO response will be protected by DNSSEC signature if the zone in which the record resides is signed.' (section 6) appear to be fundamentally incompatible claims (unless all auths for a domain are live-signing). Similarly, 'Because the record with this information can be signed with DNSSEC, it can be used to help a recursive resolver know whether to expect particular EDNS(0) [RFC6891] options in responses.' in section 1 appears to conflate EDNS protocol abilities with zone contents. 'For example, if an authoritative server is authoritative for example.com, the query could be example.com/IN/AUTHINFO, or the QNAME could be any other name for which the server is authoritative.' (section 2): 'could be any other name' feels underspecified. What other names would make sense? Please be specific. (Non-exhaustive suggestions, each with their own problems: the NS name. A special name [_authinfo.arpa].) My personal preference would be that a singular choice is made here. Anything more than that would amount to more probing code in resolvers, and resolvers do not have time for that. Expanding section '4.1 Example' to be explicit about the zone, its NSes, and the related AUTHINFO queries and responses would presumably resolve these ambiguities/incompatibilities. Other comments: 'If the QNAME in the request is for a zone for which the authoritative server is not authoritative, the response MUST be an NXDOMAIN response.' (section 2) is wrong - NXDOMAIN is an authoritative answer, so it cannot be the answer given if the server is not authoritative. REFUSED is the usual response, but I am unsure this has been codified in any document. The document does not specify when the AUTHINFO query is issued. Is this before any other conversation with the server, or can it be done opportunistically so that the information eventually appears in the cache? (The related dprive document hints at answers for this but does not provide enough rope either.) Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-01.txt
On Fri, 2020-07-31 at 00:23 +0100, Tony Finch wrote: > * should set the DONTFRAG option on responses > > * should listen for ICMP frag needed packets, and react by re-sending the > response (which is embedded in the ICMP packet) with a TC bit set Only part of the response is embedded in the ICMP packet. With some luck, enough of the query is embedded in the ICMP packet (I'm unsure about EDNS). I'm unsure it's even easy for a user space process to get that ICMP packet. That all said, this sounds like a splendid way to allow 'request spoofing' even if everybody does BCP38 (ingress filtering). The ICMP packet could come from any IP (so no spoofing protection), but the ICMP *payload* which you then treat as believable IP headers is not subject to BCP38 checking, as far as I understand. I know we have a state problem in DNS servers forgetting about a query the moment they responded to it, but I don't think scavenging that query from incoming ICMP packets is the solution. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS type work in other WG meeting
On Fri, 2020-07-24 at 20:36 -0400, Tim Wicinski wrote:
>
> Richard Barnes brought this to our attention during the SECDISPATCH meeting
> first thing Thursday morning.
>
> Some may remember an earlier version of the "GNU Name System"
>
> https://tools.ietf.org/id/draft-schanzen-gns-01.html
> https://gnunet.org/en/gns.html
>
> Here is the agenda
>
> https://www.ietf.org/proceedings/108/agenda/agenda-108-secdispatch-01.html
>
> DNS interested folks may want be interested.
And, inconveniently at the same time:
https://www.ietf.org/proceedings/108/agenda/agenda-108-anrw-05
11:05-11:30 Enabling Privacy-Aware Zone Exchanges Among
Authoritative and Recursive DNS Servers
(Nikos Kostopoulos)
11:30-11:45 Inferring the Deployment of Inbound Source
Address Validation Using DNS Resolvers
(Yevheniya Nosyk)
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
On Wed, 2020-06-03 at 19:36 -0700, internet-dra...@ietf.org wrote: > 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 : Glue In DNS Referral Responses Is Not Optional > Author : M. Andrews Mark, thank you for writing this down in a document. If you're doing an implementation status section, you can note that PowerDNS Auth is compliant since 4.2.0, or about a year ago. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones
On Mon, 2020-05-11 at 21:24 -0400, John Levine wrote: > In article > you > write: > > Please review this draft to see if you think it is suitable for adoption > > by DNSOP, and comments to the list, clearly stating your view. > > It doesn't seem like a bad idea but I'm wondering who's likely to > implement it, since that makes it much more interesting. co-author here :) PowerDNS has a PoC, external, implementation of a previous incarnation of this draft. We will certainly implement (inside or outside PowerDNS) this draft when the shape of things is sufficiently agreed on. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Consensus suggestion for EDE and the TC bit
On Thu, 2019-11-21 at 15:37 +0800, Ben Schwartz wrote: > I think we are talking about performance in a situation that (a) is so > pathological that it will almost never happen and (b) at worst, will only > slow down failure, not success. For that reason, I would avoid introducing > any additional protocol complexity in pursuit of optimization. I think our > simplest and most appealing option would be to treat EDE exactly like any > existing EDNS Option (i.e. set the TC bit). > > To be clear, we are talking only about the case where a response "fits" until > the EDE is added, after which it exceeds the limit and is truncated. If > optimizing this situation is important, I would suggest adding a requirement > to the EDE draft that EDE be the last option in OPT. Then as a client, I can > easily detect this situation, because the truncation point is in the middle > of the EDE option. The client logic then is very simple: if I don't care > about EDE, I can ignore the TC bit. Please do not write specifications that require software to receive a corrupt packet (in this case, one where the RDLEN of the last record extends beyond the end of the packet) and draw any conclusion from it other than 'this is a corrupt packet'. Also, please do not truncate packets on arbitrary byte boundaries. In other words, please always send well-formed packets that contain what they say they contain in terms of Answer/Additional/Auth counts, and the sizes of those individual records. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] FW: New Version Notification for draft-mglt-dnsop-dnssec-validator-requirements-08.txt
me supported by an authoritative server." Which authoritative server? What does it mean to 'request and monitor'? Is that anything more than requesting the DNSKEY set and looking at the algorithms used in it? We already have a deprecation mechanism for algorithms, through somewhat periodic RFCs that update https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml. Section 11, second RUN TIME REC: certainly an operator is not expected to notice -every- failed DNSSEC validation? And what does 'report' mean? Report it where? I'm looking forward to a more focused revision of the draft. I suspect that this document could be a lot shorter without losing its usefulness. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
On 8 Mar 2019, at 19:33, 神明達哉 wrote: > +1. It's very difficult for me to imagine how we can expect that two > "heterogenous off-the-shelf software" products can be interoperable > just because we have a standardized EDNS option code for opaque tags. > > For example, assume that an operator uses dnsdist as a DNS load > balancer and BIND 9 as backend servers with RRL, and the operator > wants to trust particular clients (identified by their IP addresses) > and bypass RRL for them. How can we expect off-the-shelf dnsdist and > off-the-shelf BIND 9 support this operation with the only assumption > being that both of them support edns-tags? Is there an implicit > assumption that: > - this version of off-the-shelf dnsdist happens to have a new > configuration option so it will add an edns-tag with setting bit X > when the client IP address matches a specified set of address list, > - this version of off-the-shelf BIND 9 happens to have a new > configuration option to skip RRL if an incoming request contains an > edns-tag option with bit X on > ? Yes. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
Hello Ray, On 8 Mar 2019, at 11:33, Ray Bellis wrote: On 08/03/2019 03:58, Paul Wouters wrote: If you have a specific use case, get a code point for that specific use case. Than you know for sure what the blob means and that it will be interpreted by all parties in the same standard RFC way. I have some generic use cases in mind (subject to the existing cautions about bilateral agreements, consenting adults, etc) and also a very specific use case. I have customers that want to tag a packet received by a DNS load-balancer and then on the back-end server use that tag to make decisions about the processing of that packet. Me too, and I’ve spoken to several other people who also have such needs. I bet dnsdist users would eat this up if we implemented it. They want to do that with heterogenous off-the-shelf software, which means that implementations have to agree which code point to use. This strongly suggests requesting an *assigned* code point. Please also note that the requirements for assignment of an EDNS option is "Expert Review". It does *not* require a Standards Track RFC. It's therefore none of DNSOP's business what the values of those tags are, nor what the resulting packet processing decisions will be. As far as the *protocol* is concerned, they're opaque. It's not even any of DNSOP's business how large that blob is, but the current 16-bit limit is a concession (or some might say appeasement) to the perceived privacy concerns. So while not requiring an RFC to obtain an assignment, the I-D is published for feedback on the design aspects of the option and to act as the reference specification for it. Well said! Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
On 4 Mar 2019, at 18:13, Paul Hoffman wrote: On Mar 4, 2019, at 8:27 AM, Ray Bellis wrote: This new draft describes a way for clients and servers to exchange a limited amount of information where the semantics of that information are completely unspecified, and therefore determined by bi-lateral agreement between the client and server operators. There are known cases where bespoke implementations are using experimental EDNS option values for this purpose, for example for a front-end load-balancer to tell the server whether an incoming connection arrived over TCP or UDP (c.f. my XPF draft). A goal of this draft is to assign a common EDNS code-point such that popular OSS implementations can support similar features interoperably. I have read the draft (which is thankfully succinct!) and think it makes good sense. It could be adopted by DNSOP because it directly affects DNS operations. +1 Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: (Algorithm Implementation Requirements and Usage Guidance for DNSSEC) to Proposed Standard
Hi Warren, On 4 Mar 2019, at 16:23, Warren Kumari wrote: On Thu, Feb 28, 2019 at 10:13 AM Peter van Dijk wrote: As this pertains to a section that will apparently be removed for publication, only posting it here on dnsop@ for historical reasons: So, RFC7942 (the one about "The Implementation Status" section) says that this section should contain a note asking for it to be removed (and even includes boilerplate to copy and paste) -- this document instead says "The following table contains the status of support in the open-source DNS signers and validators in the current released versions as of the time writing this document." which implies it will be left in the document. I personally think that this is good / helpful, but am not sure how the rest of the IESG will feel about this... I always found the removal a very unhelpful idea. A different draft comes to mind where the implementation section mentioned the ways in which almost every implementation, consistently, deviated from the draft, which would be very useful information to future implementors! I indeed also noticed that this draft lacked that note, but Paul Wouters replied this via Twitter: letoams: @oerdnj @Habbie ohh. well that whole section will be cut anyway before RFC :) If we do another rev based on IETF LC, I will update it <https://twitter.com/letoams/status/1101136424361955329> As of 28-Feb-2019 14:02 I see pdns-4.2.0-beta1 available for download, so I think that doing what Peter requests is fine. So, my plan is to 1: ask the authors to please swap the Y to an N as below and 2: progress the document with the hope that this section will survive the publication process. The March telechats are often really full - ADs who are leaving the IESG try and get old / stuck work finished and off their plate - and so this would likely only show up on the 2019-04-11 telechat -- so if anyone really objects to this being (attempted to be) left in, please shout. If it turns out the section is going to be removed before publication, then of course, don’t bother with the change. If the section will survive, and it is felt that this small change will hold up publication, then please also do not bother. Otherwise, if it turns out we can easily get this change in, please do. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: (Algorithm Implementation Requirements and Usage Guidance for DNSSEC) to Proposed Standard
On 13 Feb 2019, at 20:29, The IESG wrote: The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Algorithm Implementation Requirements and Usage Guidance for DNSSEC' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2019-02-27. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. As this pertains to a section that will apparently be removed for publication, only posting it here on dnsop@ for historical reasons: PowerDNS has removed all GOST support as of version 4.2, which is due to be released any day now, so please change that cell in section 6.1 to N. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?
On 7 Feb 2019, at 16:55, Ted Lemon wrote: On Feb 7, 2019, at 10:48 AM, Bob Harold wrote: If we write it down, perhaps we should also mention that other things that answer DNS queries, like load balancers, should also return proper SOA and NS records, not just A and records, for the same reasons. Are they currently returning no error/no data? Yes, many do. Others do not respond at all (i.e., timeout). Case in point: https://github.com/dns-violations/dnsflagday/issues/73 Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-song-atr-large-resp
On 6 Feb 2019, at 9:08, Mukund Sivaraman wrote:
Considering that the method is implementable without any changes at a
resolver, and that it doesn't require compatible behavior among DNS
implementations ("protocol" or best practice), I suppose it does not
matter if this draft is adopted or not as long as the idea has been
described somewhere.
While it can be implemented on an auth without changes to resolvers,
doing that would severely impact operation of all resolvers.
I think it’s important to repeat that not only do I oppose adoption -
any implementation, no matter the status of the document, will be
*actively harmful to the DNS at large*. Please do not implement this.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-song-atr-large-resp
Hello, On 18 Jan 2019, at 18:55, Benno Overeinder wrote: > We discussed this work (draft -01) in Montreal, and different opinions wrt. > adoption were expressed. In the past months, the authors pushed a draft > version -02 that addressed and resolved some of these comments. > > This starts a Call for Adoption for: > draft-song-atr-large-resp > > The draft is available here: > https://datatracker.ietf.org/doc/draft-song-atr-large-resp/ > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. The > WG accepts the document or not, but the WG chairs also expect a commitment > from the WG participants who support the document to contribute to the draft, > review, etc. > > The intended status of the draft is Experimental, but we want to ask > developers/vendors if they plan to implement it. > > This call for adoption ends: 1 February 2019 I oppose adoption. Any implementation of this draft will actively hurt the DNS and the Internet, and thus publication as an RFC will actively hurt the DNS and the Internet. The draft doubles the number of packets involved in a legitimate exchange; it more than doubles the number of packets involved in a spoofed exchange. About half of these packets are ICMP packets. Without the draft, ICMP packets are useful debugging aids, and in big numbers, indications of attacks or operational problems. With the draft, ICMP becomes another useless source of background noise. Meanwhile, we have no indication that the draft solves any existing real world problem in a useful way. Please do not adopt. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] FOSDEM 2019 DNS devroom CfP
Hello DNSOP! tl;dr Please consider submitting a presentation for the DNS devroom at FOSDEM 2019. More details: Every year, developers from all over Europe (and some from farther away) meet in Brussels to discuss Open Source software and many other topics. After a successful and packed DNS devroom (track) last year, we are happy to announce a full-day DNS devroom at FOSDEM 2019. As with last year, we hope to host talks anywhere from hardcore protocol stuff to practical sessions for programmers that are not directly involved with DNS - but may have to deal with DNS in their day to day coding - or for system administrators responsible for DNS infrastructure. The standardisation community needs developers; this is your chance to reach out to them, tell them what you are up to, and perhaps even get a couple of them on board to implement your ideas! We have been allotted a room on Sunday, 3 February 2019. We expect to schedule 30 minutes per talk, including questions, but we have some flexibility if you need more or less time. If you have something you’d like to share with (your fellow) developers, please head to pentabarf at https://penta.fosdem.org/submission/FOSDEM19. Examples of topics are measuring, monitoring, DNS libraries, anecdotes on how you’ve (ab)used the DNS, and of course any (upcoming) RFCs that have your interest. Here’s the 2018 schedule, for your inspiration: https://archive.fosdem.org/2018/schedule/track/dns/ . The deadline for submission is Saturday, 1 December 2018. If you have a FOSDEM pentabarf account from a previous year, please use that account. Reach out to dns-devroom-mana...@fosdem.org if you run into any trouble. See you there! Cheers, Peter van Dijk, Shane Kerr, Pieter Lexis, and Kees Monshouwer signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IETF 102 Hackathon: prototype implementation of draft-wessels-dns-zone-digest-02
Hello, On 19 Jul 2018, at 16:26, Shane Kerr wrote: > Someone pointed out to me that since ZONEMD is meta-data we don't really > expect it to be queried normally, and a TTL of 0 is a reasonable default. I recall a story about some resolver (Google Public DNS perhaps?) applying the lowest TTL per name, instead of per RRset. This, if true, would argue against 0. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)
On 16 Jun 2018, at 2:14, Shumon Huque wrote: Yeah, good point about side channels. Let's stick to recommending randomization! Unbound has interesting middle ground here: rrset-roundrobin: If yes, Unbound rotates RRSet order in response (the random number is taken from the query ID, for speed and thread safety). Default is no. It rotates, but you cannot predict (easily) by how much. It keeps the implementation simple but mostly avoids (as far as I can judge) the side channel. I do want to point out that the default is ‘no’, suggesting it is getting away with no ‘round robin’ at all in many deployments. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)
Hello Andrew, On 15 Jun 2018, at 19:12, Andrew Sullivan wrote: > I believe that RRsets are unordered sets by definition. So I supect > that if people are relying on the order in which they come off the > wire, they're making a mistake. This. One hundred million times, this. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] on 'when to implement' (was: Re: Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel)
On 24 Apr 2018, at 15:02, Ondřej Surý wrote: And the MR was peer-review and merged into BIND master branch with intent to backport the feature into older release branches. I don’t think it’s a useful or helpful to change the rules for existing adopted work. Nobody is changing the rules (yet - but we can dream!); some people are just being more vocal about the real need for implementation experience. We need to have a discussion on the mechanisms that would allow implementors to know when to start the implementation of existing draft. I don’t think what we need here is more ‘procedure’. Either a draft manages to get (at least one) implementer involved early - or the draft is most likely not worth pursuing. From implementors point, it makes little sense to start implementing before the protocol change is almost fully baked (aka WGLC and further), because until then the protocol might change considerably. It makes little sense to call a protocol change ‘fully baked’ if nobody has checked that implementation is even possible. So, if we require implementation report further down the road, it needs to be more clearly defined than people suddenly shouting “this is not ready” when WGLC starts. And while the attempt to implement something is certainly useful to get valuable feedback, it also imposes some costs (with undefined limit) on implementors (especially the open source implementors) and it sort of discards the whole “Proposed Standard” -> “Internet Standard” classification at global IETF level. The costs are the very best reason to demand implementation experience before calling something ‘fully baked’. If a draft has real merit, somebody will invest time/money. If it does not have merit, nobody will implement, and the draft will die the death it deserves. In other words, a draft needs to put its money where its mouth is. This way, drafts that actually help operations (this is dnsOP, after all) will get the attention they need, while other drafts may wither away - and that’s a good thing. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel
Hello Suzanne, On 6 Apr 2018, at 23:49, Suzanne Woolf wrote: We’re hearing that having an RFC will be helpful to promoting implementation, and also that this draft may not be ready to be advanced for publication because it doesn’t include implementation experience. This is something the WG needs to comment on further, because it seems substantive to me so it will have to be addressed one way or another before we advance the document— but those inputs are somewhat in disagreement. In WG context, not in draft context: I do not think these inputs are in disagreement. If a draft can find -zero- implementers that think the draft is a sufficiently good idea that they write an implementation during draft status, the draft is, most likely, a bad idea. Editors: Please take “concern about a description of current implementation status” as WGLC input, and consider what you might be able to add to the draft to address it. WG vendors/implementers: Can folks who have implemented kskroll-sentinel, or considered implementing it, please speak up on your concerns/plans? Because of privacy concerns (currently raised in section 7 of the draft quite briefly), PowerDNS will not be implementing this protocol. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel
On 5 Apr 2018, at 18:35, tjw ietf wrote: After walking through the 168 emails on this draft in the inbox, I feel we're ready to take this to WGLC. (We are aware of the two points raised my Job and Paul) Especially given that an implementation is in fact available (in Knot), why not take this opportunity to start demanding Implementation Status sections for those drafts where that requirement makes sense? Because it certainly makes sense here! Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-muks-dnsop-dns-catalog-zones-04.txt
On 10 Mar 2018, at 17:26, Mukund Sivaraman wrote: this proposal. (in that sense, I'm curious: is there other DNS developer than ISC that is interested in implementing this proposal?) Yes. PowerDNS has wanted something like this for years but we never got around to writing it down. We are grateful that ISC is now doing that :-) So far: I was told that PowerDNS has implemented a plug-in/script that provides support for catalog zones. https://github.com/powerdns/powercatz Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-04.txt
Hello dnsop, Please find below revision 04 of the XPF draft. We believe all concerns previously raised have been addressed in this version. Additionally, two implementations (both in PowerDNS products) have popped up, along with two decoders (Wireshark, and [not mentioned in -04] tcpdump). As authors we feel this is a good time to ask for adoption of the document. We’d like to ask the WG to consider adoption. Ray and myself will be present at IETF101 if you want to discuss. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ Forwarded message: From: internet-dra...@ietf.org To: Ray Bellis , Remi Gacogne , Peter van Dijk , Rémi Gacogne Subject: New Version Notification for draft-bellis-dnsop-xpf-04.txt Date: Mon, 05 Mar 2018 07:55:18 -0800 A new version of I-D, draft-bellis-dnsop-xpf-04.txt has been successfully submitted by Peter van Dijk and posted to the IETF repository. Name: draft-bellis-dnsop-xpf Revision: 04 Title: DNS X-Proxied-For Document date: 2018-03-05 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-bellis-dnsop-xpf-04.txt Status: https://datatracker.ietf.org/doc/draft-bellis-dnsop-xpf/ Htmlized: https://tools.ietf.org/html/draft-bellis-dnsop-xpf-04 Htmlized: https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-xpf-04 Diff: https://www.ietf.org/rfcdiff?url2=draft-bellis-dnsop-xpf-04 Abstract: It is becoming more commonplace to install front end proxy devices in front of DNS servers to provide (for example) load balancing or to perform transport layer conversions. This document defines a meta resource record that allows a DNS server to receive information about the client's original transport protocol parameters when supplied by trusted proxies. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] 4035 3.1.4.1 erratum? dig ds root-servers.net @X.root-servers.net
Output edited for brevity: $ dig ds root-servers.net @d.root-servers.net ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17643 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;root-servers.net. IN DS ;; AUTHORITY SECTION: root-servers.net. 360 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2017111600 14400 7200 1209600 360 $ dig ds root-servers.net @e.root-servers.net ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26972 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;root-servers.net. IN DS ;; AUTHORITY SECTION: net.172800 IN NS a.gtld-servers.net. net.172800 IN NS b.gtld-servers.net. .. .. ;; ADDITIONAL SECTION: a.gtld-servers.net. 172800 IN A 192.5.6.30 b.gtld-servers.net. 172800 IN A 192.33.14.30 .. .. When running the query in the Subject, these are the two possible outputs I have observed from various root servers (with some variation from the same letter, presumably because of dual vendor strategies). From 4035 3.1.4.1, the NODATA response should be sent when: o The name server has received a query for the DS RRset at a zone cut. o The name server is authoritative for the child zone. o The name server is not authoritative for the parent zone. o The name server does not offer recursion. Points 1, 2 and 4 are clear. It is point 3 that hurts here. The root servers are authoritative for root-servers.net. and for . , but not for net - and they know this because they can see the delegation in the root zone. It is my suspicion that 3.1.4.1 was not written with this edge case in mind, and I think that while 3.1.4.1 favours the NODATA response, the referral is much more useful. As a data point, the PowerDNS validator currently gets in trouble with the NODATA response: https://github.com/PowerDNS/pdns/issues/6138 I think an erratum to 4035 is in order, clarifying the language such that servers would return the referral in this case. I have not figured out the exact wording yet (but I will). What does dnsop think? Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Please review in terminology-bis: QNAME
On 11 Dec 2017, at 16:30, Paul Hoffman wrote: Greetings again. Some of the new terms added to the terminology-bis draft (https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/)since RFC 7719 can expose what some (but not all) people perceive as lack of clarity in RFC 1034/1035. This week, we hope you will look at the definition in the draft for "QNAME". Please review the lengthy explanation and comment on the list if you think the definition should change. +1 on the lengthy explanation. Nothing shorter could settle this thing. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] FOSDEM 2018 DNS devroom CfP
Hello DNS-enthusiasts and other developers, (the text below has also been posted at https://blog.powerdns.com/2017/11/20/fosdem-2018-dns-devroom-cfp/ and if anything changes, we'll update that post, so please check there if you have questions. Also, our apologies if you receive multiple copies of this CfP via different mailing lists.) After two successful BoF sessions at FOSDEM 2016 and 2017, FOSDEM 2018 will see a real DNS devroom! We hope to host talks anywhere from hardcore protocol stuff, to practical sessions for programmers that are not directly involved with DNS but may have to deal with DNS in their day to day coding, or system administrators responsible for DNS infrastructure. We have been allotted half a day on Sunday 4 February 2018. We expect to schedule 30 minutes per talk, including questions, but this is open to discussion. If you have something you'd like to share with your fellow developers, please head to pentabarf at https://penta.fosdem.org/submission/FOSDEM18. Examples of topics are measuring, monitoring, DNS libraries, and anecdotes on how you've (ab)used the DNS. The deadline for submission is December 8th. If you have a FOSDEM pentabarf account from a previous year, please use that account. Reach out to dns-devroom-mana...@fosdem.org if you run into any trouble. We are also looking for volunteers to help with cameras etc. Please drop us an email at dns-devroom-mana...@fosdem.org if you're interested in helping out. See you there! Cheers, Peter van Dijk, Shane Kerr, Pieter Lexis ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
