Re: [DNSOP] [Ext] Re: signing parent-side NS (was: Re: Updating RFC 7344 for cross-NS consistency)
On 28. 07. 22 22:05, Edward Lewis wrote: On 7/26/22, 3:05 PM, "DNSOP on behalf of Petr Špaček" wrote: Interesting history lesson, thank you. Can you elaborate on > therefore only one can be signed. please? What is the reasoning behind it? There were a few iterations in the development of DNSSEC. RFC 4033-4035 are the third iteration. Part of the "reason" is that the DNSSEC definition evolved over a period of years. In the first two iterations, the rules for signing (or not) the cut points were set. NS and glue, carrying information "reported" to the parent were not "from" the parent, hence not signed. The NSEC (and later NSEC3) record did indicate the presence/absence of a zone cut as the presence of the cut was determined by the parent. This design was deemed to be the most backwards-compatible approach (anticipating it would be a very long road to adoption). FWIW, these iterations toyed with having a key set from the child up or something from the parent sent down, none it worked. The DS record was added in the third(?maybe the count is different to others) iteration. Although it contains a hash of what is reported to it by the child it is signed. This is in some sense historically inconsistent. It was felt that the signature here was needed, there had to be some signed statement from the parent to an iterator as it left for the child. Given the DS was "new" there was no backwards compatibility to be maintained, although having this record be authoritative above the cut (well, so was the NSEC/3) was new - yet only seen when "doing" DNSSEC. There was never any sympathy for signing the parent-side NS set at the time. It wouldn't add to the security goals of DNSSEC and potentially lead to confusing case - when the NS sets are out of alignment, which happens when name servers are changed (or where someone makes a mistake). The decision to leave the parent-side NS set unsigned was never completely accepted, there were many thoughts on "fixing" the delegation in the DNS. But doing so was thought to be too disruptive the current running system. Thank you for detailed response! I will continue my quest to understand reasoning behind the current protocol and ask a bit more. By any chance, do you remember in what iteration the DO=1 in query was introduced? I wonder what sort of disruption was anticipated/feared. In hindsight is seems that DO=1 requirement for "new" behavior (like, say, adding RRSIG to delegations sent from the parent zone) could be enough. Thank you for your time. -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation
On 28 Jul 2022, at 13:19, Joe Abley wrote: On Jul 28, 2022, at 12:24, Andrew McConachie wrote: PMTUD doesn’t work through NAT That's a very definitive statement considering that there's no useful standard for NAT. If there's actual research on this to demonstrate that, pragmatically speaking, no implementations use the payload of a type 3 code 4 ICMP message to identify a translated target for the packet I would like to read it, because that sounds interesting. The document makes the claim that PMTUD “remains widely undeployed due to security issues.” My contention is that it has little to do with security and more to do with the current structure of the Internet. We don’t need a useful standard for NAT to recognize that most implementations break PMTUD, and that those implementations of NAT are deployed enough to make PMTUD significantly broken. Firewalls break PMTUD as well, and I guess that’s a security thing, but currently the sentence reads like operators don’t deploy PMTUD in favor of security and I don’t think that’s true. Currently, DNS is known to be the largest user of IP fragmentation. Compared to what? I would just drop this sentence because it doesn’t add anything to the document and it’s trying to make a point that doesn’t need to be made. I'd also like to see a citation for this one if there has been a study. I agree that it's probably the most familiar example of fragmentation for an audience mainly preoccupied with the DNS, but that's probably not a helpful observation :-) Before I was interested in the DNS I worked for an ethernet switch vendor for 8 years, and I often find the way MTU gets talked about in IETF documents simply weird. RFC 791 introduces the term "maximum transmission unit" to be the maximum size of a datagram, not the maximum size of a frame whose payload is a datagram. The maximum sized datagram that can be transmitted through the next network is called the maximum transmission unit (MTU). MTU is a measurement of maximum frame size for a network segment starting at Layer 2. I have also heard MTU used in that way. I have always assumed it was just sloppy writing. There may be prior use of the phrase that I'm not aware of (prior to 1981) but even if that's the case I think it's reasonable to use the IETF definition of the phrase in the IETF. I think Ethernet was not standardised until the publication of IEEE 802.3 in 1983. I also think the original specification did not anticipate switches but described a multi-access network with a broader collision domain. So perhaps it's reasonable to say that the IETF use of MTU pre-dates Ethernet switch vendors' usage, since it pre-dates Ethernet switches, since it pre-dates Ethernet. Ok. But the text still isn’t clear on how many bytes are assumed to be consumed by layer-2 protocols. We don’t need to have a super tight definition of MTU to progress this document. Implementors just need to know how big of packets they can transmit. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation
Hi Andrew, On Jul 29, 2022, at 11:14, Andrew McConachie wrote: > We don’t need a useful standard for NAT to recognize that most > implementations break PMTUD, and that those implementations of NAT are > deployed enough to make PMTUD significantly broken. I was really just suggesting that some measurement to support the assertion might be nice. >> So perhaps it's reasonable to say that the IETF use of MTU pre-dates >> Ethernet switch vendors' usage, since it pre-dates Ethernet switches, since >> it pre-dates Ethernet. > > Ok. But the text still isn’t clear on how many bytes are assumed to be > consumed by layer-2 protocols. I think the point is that it's not necessary to know that. > We don’t need to have a super tight definition of MTU to progress this > document. Implementors just need to know how big of packets they can transmit. The answer to that question for any particular interface (attached to any layer-2 network) is "that interface's MTU". Joe ___ 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] 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] [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
[DNSOP] Please review draft-ietf-dnsop-avoid-fragmentation
Dear intarea WG, dnsop WG is working on a document to avoid IP fragmentation in DNS. Now, the draft is on Working Group Last call in dnsop WG (until August 16). The draft attempt to advance the goals of RFC 8900 IP Fragmentation Considered Fragile. (Section 5.1 Domain Name System (DNS)) As one of the co-authors of the draft, I would like advices from intarea because there may be inadequate descriptions related to path MTU discovery and DF bit / IPV6_DONTFRAG. Fragmentation Avoidance in DNS https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ (1) About DF bit, IPV6DONTFRAG | 1. Introduction | | This document proposes to set IP_DONTFRAG / IPV6_DONTFRAG in DNS/UDP | messages in order to avoid IP fragmentation, and describes how to | avoid packet losses due to IP_DONTFRAG / IPV6_DONTFRAG. | 2. Terminology | | IP_DONTFRAG option is not defined by any RFCs. It is similar to | IPV6_DONTFRAG option defined in [RFC3542]. IP_DONTFRAG option is | used on BSD systems to set the Don't Fragment bit [RFC0791] when | sending IPv4 packets. On Linux systems this is done via | IP_MTU_DISCOVER and IP_PMTUDISC_DO. | 3.1. Recommendations for UDP responders | | * UDP responders SHOULD send DNS responses with IP_DONTFRAG / | IPV6_DONTFRAG [RFC3542] options. (2) about path MTU discovery | 2. Terminology | | "Path MTU" is the minimum link MTU of all the links in a path between | a source node and a destination node. (Quoted from [RFC8201]) | | In this document, the term "Path MTU discovery" includes Classical | Path MTU discovery [RFC1191], [RFC8201], Packetization Layer Path MTU | discovery [RFC8899] and as well as similar methods. | 3.2. Recommendations for UDP requestors | | * UDP requestors MAY probe to discover the real MTU value per | destination. (Path MTU discovery per destionation) Then, | calculate their maximum DNS/UDP payload size as the reported path | MTU minus IPv4/IPv6 header size (20 or 40) minus UDP header size | (8). If the path MTU discovery failed or is impossible, use the | default maximum DNS/UDP payload size 1400. Regards -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-dnssec-bcp-02.txt
On Jul 28, 2022, at 2:49 PM, Chris Box wrote:
> Proposed text for the last line:
> means version 3 of the protocol initially defined in {{RFC4033}},
> {{RFC4034}}, and {{RFC4035}}.
>
> Is this better?
Yes, definitely. Incorporated.
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
___
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 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. 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. > 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. Done. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] The DO bit - was Re: [Ext] Re: signing parent-side NS (was: Re: Updating RFC 7344 for cross-NS consistency)
On 7/29/22, 3:53 AM, "Petr Špaček" wrote: >By any chance, do you remember in what iteration the DO=1 in query was >introduced? I wonder what sort of disruption was anticipated/feared. > >In hindsight is seems that DO=1 requirement for "new" behavior (like, >say, adding RRSIG to delegations sent from the parent zone) could be > enough. There was a specific incident, I don't recall the year, but it was in a later iteration. DNSSEC's code development was carried out by a small contractor to the US government, physically located in a farm-like setting about an hour's drive from any city (providing a sense of isolation). With the company's willingness to take on technical risk, DNSSEC had progressed to the point where we decided to put it into production, signing our corporate zone. Everything seemed to be fine. No one was able to verify the signatures as there were no trust anchor points set, but the records would be included in responses. On the third(*) day, one of the principal investigators (project leads) realized she hadn't been getting mail from the government contracting offices (who were paying for DNSSEC and other projects). It seemed no other principal investigator had received mail either. A call went to the contracting offices, it was discovered that the government's name servers were rejecting our DNSSEC-signed responses. The mail they needed to send us was "dropping on the floor" at their end. All involved were highly sympathetic to the situation, so we initially rolled back, mail resumed, and the DO bit was invented (and eventually documented in https://www.rfc-editor.org/rfc/rfc3225.html). * Well, I recall "3" being the number of days. It was definitely between 1 and 5... ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] The DO bit - was Re: [Ext] Re: signing parent-side NS (was: Re: Updating RFC 7344 for cross-NS consistency)
Interesting history, I would have expected (and have taught) that this was by design to not disrupt systems with new data unless we knew they were ready for it. I didn’t realize we first tried to do it without that Paul Sent using a virtual keyboard on a phone > On Jul 29, 2022, at 10:06, Edward Lewis wrote: > > On 7/29/22, 3:53 AM, "Petr Špaček" wrote: >> By any chance, do you remember in what iteration the DO=1 in query was >> introduced? I wonder what sort of disruption was anticipated/feared. >> >> In hindsight is seems that DO=1 requirement for "new" behavior (like, >> say, adding RRSIG to delegations sent from the parent zone) could be >> enough. > > There was a specific incident, I don't recall the year, but it was in a later > iteration. > > DNSSEC's code development was carried out by a small contractor to the US > government, physically located in a farm-like setting about an hour's drive > from any city (providing a sense of isolation). With the company's > willingness to take on technical risk, DNSSEC had progressed to the point > where we decided to put it into production, signing our corporate zone. > > Everything seemed to be fine. No one was able to verify the signatures as > there were no trust anchor points set, but the records would be included in > responses. > > On the third(*) day, one of the principal investigators (project leads) > realized she hadn't been getting mail from the government contracting offices > (who were paying for DNSSEC and other projects). It seemed no other > principal investigator had received mail either. A call went to the > contracting offices, it was discovered that the government's name servers > were rejecting our DNSSEC-signed responses. The mail they needed to send us > was "dropping on the floor" at their end. > > All involved were highly sympathetic to the situation, so we initially rolled > back, mail resumed, and the DO bit was invented (and eventually documented in > https://www.rfc-editor.org/rfc/rfc3225.html). > > * Well, I recall "3" being the number of days. It was definitely between 1 > and 5... > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: signing parent-side NS (was: Re: Updating RFC 7344 for cross-NS consistency)
Hi, On Jul 29, 2022, at 12:53 AM, Petr Špaček wrote: > By any chance, do you remember in what iteration the DO=1 in query was > introduced? Mid- to late 2000/early 2001, after the 2nd iteration (using Ed’s terminology), but before the third. > I wonder what sort of disruption was anticipated/feared. IIRC, there were some resolvers that reacted poorly to receiving unanticipated RRs in response to a “normal” query and there were some concerns about the amount of bandwidth signed authoritative servers would consume with useless information, particularly at the earliest stages of deployment (this was the early 2000s after all). The idea was for a resolver to signal its willingness to receive and process DNSSEC-related responses to as to avoid flooding DNSSEC-unaware resolvers with stuff they had no clue about. > In hindsight is seems that DO=1 requirement for "new" behavior (like, say, > adding RRSIG to delegations sent from the parent zone) could be enough. At some point, biting the bullet and introducing actual feature negotiation into DNS may be warranted... Regards, -drc signature.asc Description: Message signed with OpenPGP ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] The DO bit - was Re: [Ext] Re: signing parent-side NS (was: Re: Updating RFC 7344 for cross-NS consistency)
On Jul 29, 2022, at 16:49, Paul Wouters wrote: > Interesting history, > > I would have expected (and have taught) that this was by design to not > disrupt systems with new data unless we knew they were ready for it. I didn’t > realize we first tried to do it without that By the time we got to signing the root zone (surely much, much later than Ed's anecdote) there was some hope that we could deploy DNSSEC RRs into the root zone whenever we felt like it, since clients that didn't explicitly want DNSSEC RRs in their responses wouldn't set DO=1, there would be no RRSIGs etc in responses they received, and hence they would be immune from any unintended consequences. Of course by then DNSSEC had been well and truly implemented in the most deployed resolver implementations and it had become clear that such resolvers needed to set DO=1 on all upstream queries regardless of whether validation was turned on locally so that downstream validators could be supported. So in practice pretty much every query received by authoritative servers already had DO=1. The need to be careful remained and this led to the idea of the DURZ, so that the effect of large responses could be isolated and assessed independently of the need to validate signatures. I remember David Conrad in particular being very sad about the ubiquity of DO=1, more so even than he already was about DNSSEC in general. Or maybe DRC's sadness just seemed more pronounced because he had to deal with me as an employee. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
