Re: [DNSOP] Followup One Week Working Group Last Call for draft-ietf-dnsop-avoid-fragmentation
I see nothing wrong with the current version (-15), and as I posted before, I consider it a nice reference for DNS fragmentation. (I'm a bit late, but at least for the record.) --Vladimir ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-bellis-dnsop-qdcount-is-one-01.txt
I would even rather see a recommendation that firewalls and middleboxes don't do any kind of DNS packet handling. Why should they? DNS traffic is for DNS servers and they are the most capable entity for handling them, including FORMERR responses on wrongly formatted queries. Libor Dne 29. 09. 23 v 0:08 Robert Edmonds napsal(a): Hi, I noticed that Section 4 of the draft states: Firewalls that process DNS messages in order to eliminate unwanted traffic SHOULD treat messages with OPCODE = 0 and QDCOUNT > 1 as malformed traffic. See Section 4 of [RFC8906] for further guidance. However, I couldn't find the guidance in Section 4 of RFC 8906 being referred to. Most of that section is actually about misbehavior in firewalls in response to well-formed traffic, not correct behavior in response to malformed traffic. The most relevant text seems to be: Firewalls and load balancers should not drop DNS packets that they don't understand. They should either pass the packets or generate an appropriate error response. […] However, there may be times when a nameserver mishandles messages with a particular flag, EDNS option, EDNS version field, opcode, type or class field, or combination thereof to the point where the integrity of the nameserver is compromised. Firewalls should offer the ability to selectively reject messages using an appropriately constructed response based on all these fields while awaiting a fix from the nameserver vendor. Returning FORMERR or REFUSED are two potential error codes to return. If I understand correctly, the QDCOUNT is a field, not a flag, so it would not be included in the list of "a particular flag, EDNS option, EDNS version field, opcode, type or class field, or combination thereof" described here. Even if QDCOUNT were included in this list, I can't think of an example where QDCOUNT > 1 would compromise the integrity of a nameserver. One could also imagine a *valid*, non-malformed combination of query parameters that could result in the integrity of a nameserver being compromised, so this paragraph isn't solely about malformed traffic. So I'm having difficulty understanding how exactly to apply this section when reading it alongside the draft. If the intention of Section 4 of this draft is to allow firewalls to meddle with OPCODE = 0, QDCOUNT > 1 as a general, ongoing deployment posture rather than as a temporary workaround "while awaiting a fix from the nameserver vendor", it would seem to go a bit beyond the narrow guidance in Section 4 of RFC 8906. Also, I think the phrase "to eliminate unwanted traffic" is vague. How would a firewall eliminate unwanted traffic? May it drop OPCODE = 0, QDCOUNT > 1? May it synthesize a FORMERR response? If it synthesizes a FORMERR response, should those responses be rate-limited in case the sender's source address is spoofed? Thanks! Joe Abley wrote: Hi all, This version mainly incorporates feedback from the room at the last meeting and relate to document clarity; the advice is unchanged. Joe On 28 Sep 2023, at 15:21, internet-dra...@ietf.org wrote: Internet-Draft draft-bellis-dnsop-qdcount-is-one-01.txt is now available. It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. Title: In the DNS, QDCOUNT is (usually) One Authors: Ray Bellis Joe Abley Name:draft-bellis-dnsop-qdcount-is-one-01.txt Pages: 7 Dates: 2023-09-28 Abstract: This document clarifies the allowable values of the QDCOUNT parameter in DNS messages with OPCODE = 0 (QUERY) and specifies the required behaviour when values that are not allowed are encountered. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-bellis-dnsop-qdcount-is-one/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-qdcount-is-one-01 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-bellis-dnsop-qdcount-is-one-01 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ 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] I-D Action: draft-bellis-dnsop-qdcount-is-one-01.txt
Op 2 okt 2023 om 11:04 heeft libor.peltan het volgende geschreven: > I would even rather see a recommendation that firewalls and middleboxes > don't do any kind of DNS packet handling. Why should they? DNS traffic is for > DNS servers and they are the most capable entity for handling them, including > FORMERR responses on wrongly formatted queries. Given that firewalls and middleboxes that do DNS packet handling are widely deployed and, in fact, best current practice amongst some groups of operators, I think any crusade in that direction would be better to describe in a different document. There are a whole pile of considerations around whether it's useful to make such a recommendation that are well outside the scope of this one. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Followup One Week Working Group Last Call for draft-ietf-dnsop-avoid-fragmentation
On 29. 09. 23 9:15, Peter van Dijk wrote: 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. I agree. -- Petr Špaček Internet Systems Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-cds-consistency-04.txt
Internet-Draft draft-ietf-dnsop-cds-consistency-04.txt is now available. It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. Title: Consistency for CDS/CDNSKEY and CSYNC is Mandatory Author: Peter Thomassen Name:draft-ietf-dnsop-cds-consistency-04.txt Pages: 13 Dates: 2023-10-02 Abstract: Maintenance of DNS delegations requires occasional changes of the DS and NS record sets on the parent side of the delegation. RFC 7344 automates this for DS records by having the child publish CDS and/or CDNSKEY records which hold the prospective DS parameters. Similarly, RFC 7477 specifies CSYNC records to indicate a desired update of the delegation's NS (and glue) records. Parent-side entities (e.g. Registries, Registrars) typically discover these records by querying them from the child, and then use them to update the parent-side RRsets of the delegation accordingly. This document specifies that when performing such queries, parent- side entities MUST ensure that updates triggered via CDS/CDNSKEY and CSYNC records are consistent across the child's authoritative nameservers, before taking any action based on these records. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-cds-consistency/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dnsop-cds-consistency-04.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-cds-consistency-04 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Dnsdir early review of draft-ietf-dnsop-cds-consistency-03
Hi David, I've merged the below changes into the draft, now available on the datatracker as -04. Thanks, Peter On 9/7/23 18:52, Peter Thomassen wrote: Hi David, First of all, thanks for the review! The changes made in response to it (plus a few minor editorial changes I found useful) are recorded here: https://github.com/peterthomassen/draft-ietf-dnsop-cds-consistency/pull/4 I'd appreciate if you can let me know if you agree with them, so I can merge them. -- Further comments inline. On 8/30/23 15:58, David Blacka via Datatracker wrote: From a specification-purity point of view, the concept of multiple providers is actually not needed or relevant to this draft. Nameservers could be out of sync for a variety of reasons. This draft could be written without a single mention of multi-provider (multi-homed?) or multi-signer situations and be shorter and perhaps clearer. Although, it might be important to point out that there are more reasons than just being out-of-sync from a single primary source. On the other hand, knowing that multiple provider setups exist is a strong motivator for this specification. Without considering multiple provider setups, we are prone to imagining that all setups are synced from a single source, and all deviation is temporal and temporary. Exactly -- in multi-provider setup, the source is diverse. What's more: before joining a multi-signer constellation, each party has a different set of DNSKEYs, and they'll need to converge on a merged set that has everyone's relevant keys (namely, those KSKs that will later be referenced via DS records, but no cross-provider ZSKs), before publishing corresponding CDS/CDNSKEY RRsets to update the delegation's DS RRset. There's a lot of potential for error here, particularly when it's not automated, or when automation software is new and hasn't yet stood the test of time (as is expected to be the case). It was in this context that this draft was conceived, and I think it's a much stronger motivator than merely being out-of-sync by replication lag (which would only cause benign DS flapping unless other things are broken, too). I'd thus like to keep mention of this in the Introduction and Security Considerations. -- The third occurrence of "multi-signer" is in the appendix describing the various failure modes. I hoped that would be enlightening, but I don't mind dropping it. Is that what you are proposing? If the draft is not recast to just not directly mention multi-homing/multi-provider/multi-signing setups, it should define the term near the start of the draft. I would prefer using "multi-provider" because I believe it is both clearer and less encumbered with other meanings in nearby subjects (like networking), and perhaps covers more situations than "multi-signer". I agree with your sentiments about multi-homing, and I've changed them to "multi-provider". "Multi-provider" emphasizes the redundancy aspect; the DNSSEC status of the domain is not relevant. (For example, github.com has a non-DNSSEC multi-provider setup between NS1 and AWS.) "Multi-signer", OTOH, describes the special case of multiple signing entities, which in turn contains the special case of glitch-free provider change (which isn't about redundancy, but about continuity of operation). I therefore think there is reason to keep these two terms (but "multi-homing" can be dropped). The relevant paragraph in the Introduction now says: [...] adverse consequences can arise in conjunction with the multi-signer scenarios laid out in [RFC8901], both when deployed temporarily (during a provider change) and permanently (in a redundant multi-provider setup). I also added definitions to the Terminology section: Multi-provider setup: A constellation where several providers independently operate authoritative DNS service for a domain, usually for purposes of redundancy. This includes setups both with and without DNSSEC. Multi-signer setup: A multi-provider setup for a DNSSEC-enabled domain with multiple independent signing entities [RFC8901]. Such a setup may be permanent (for redundancy) or temporary (for continuity of DNSSEC operation while changing the provider of a domain that normally uses a single one). Does this address your concern? My last major concern is with section 2.2, CSYNC. RFC 7477 has many rules that a parental agent must consider before accepting a CSYNC update. It is unclear how those rules interact with the rules specified in section 2.2. I think what is meant is this: Each parent-side nameserver is queried for the CSYNC RRset and the synced (NS, A, ) RRsets, and that unless all of the CSYNC type map bits and sync data match, syncing must be aborted. I think some discussion of how this interacts with the existing rules is warranted. For example, the type bitmap indicates "A", but the nameservers are not at/below the dele
Re: [DNSOP] I-D Action: draft-ietf-dnsop-cds-consistency-04.txt
Dear DNSOP, This revision has changes in response to David Blacka's Dnsdir review. Changelog: * Clean up "multi-homing" and define "multi-provider"/"multi-signer" * Clarify that existing CSYNC NS and glue processing rules remain in place * Minor editorial changes Thanks, Peter On 10/2/23 13:33, internet-dra...@ietf.org wrote: Internet-Draft draft-ietf-dnsop-cds-consistency-04.txt is now available. It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. Title: Consistency for CDS/CDNSKEY and CSYNC is Mandatory Author: Peter Thomassen Name:draft-ietf-dnsop-cds-consistency-04.txt Pages: 13 Dates: 2023-10-02 Abstract: Maintenance of DNS delegations requires occasional changes of the DS and NS record sets on the parent side of the delegation. RFC 7344 automates this for DS records by having the child publish CDS and/or CDNSKEY records which hold the prospective DS parameters. Similarly, RFC 7477 specifies CSYNC records to indicate a desired update of the delegation's NS (and glue) records. Parent-side entities (e.g. Registries, Registrars) typically discover these records by querying them from the child, and then use them to update the parent-side RRsets of the delegation accordingly. This document specifies that when performing such queries, parent- side entities MUST ensure that updates triggered via CDS/CDNSKEY and CSYNC records are consistent across the child's authoritative nameservers, before taking any action based on these records. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-cds-consistency/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dnsop-cds-consistency-04.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-cds-consistency-04 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Publication has been requested for draft-ietf-dnsop-zoneversion-04
Tim Wicinski has requested publication of draft-ietf-dnsop-zoneversion-04 as Informational on behalf of the DNSOP working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bootstrapping-06.txt
Internet-Draft draft-ietf-dnsop-dnssec-bootstrapping-06.txt is now available. It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. Title: Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator Authors: Peter Thomassen Nils Wisiol Name:draft-ietf-dnsop-dnssec-bootstrapping-06.txt Pages: 17 Dates: 2023-10-02 Abstract: This document introduces an in-band method for DNS operators to publish arbitrary information about the zones they are authoritative for, in an authenticated fashion and on a per-zone basis. The mechanism allows managed DNS operators to securely announce DNSSEC key parameters for zones under their management, including for zones that are not currently securely delegated. Whenever DS records are absent for a zone's delegation, this signal enables the parent's registry or registrar to cryptographically validate the CDS/CDNSKEY records found at the child's apex. The parent can then provision DS records for the delegation without resorting to out-of-band validation or weaker types of cross-checks such as "Accept after Delay". This document deprecates the DS enrollment methods described in Section 3 of RFC 8078 in favor of Section 4 of this document, and also updates RFC 7344. [ Ed note: This document is being collaborated on at https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/ (https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/). The authors gratefully accept pull requests. ] The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dnsop-dnssec-bootstrapping-06.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-dnssec-bootstrapping-06 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping
On 9/19/23 21:48, Tim Wicinski wrote:
This Document will update 7344 and 8078 if approved.
The Document updates brings up something I wanted to raise.
Peter and I chatted about some simple nits (remove references from the
abstract),
but I wasn't sure if the sections updating older documents was formal enough.
DNSOP has produced a few documents recently that update previous work
(8767, 8020 and 9077 come to mind), and we are advice on that.
(I may very well be overthinking this, which is what I told Peter)
Thank you for suggesting this.
We've added a section on these RFC updates. It reads as follows (the first
paragraph was just moved up from another section, and the second is a
clarification):
2. Updates to RFCs
The DS enrollment methods described in Section 3 of [RFC8078] are
deprecated and SHOULD NOT be used. Child DNS Operators and Parental
Agents who wish to use CDS/CDNSKEY records for initial DS enrollment
SHOULD instead support the authentication protocol described in
Section 4 of this document.
In order to facilitate publication of signaling records for the
purpose of DNSSEC bootstrapping (see Section 4.1), the first bullet
("Location") of [RFC7344] Section 4.1 is removed.
Best,
Peter
--
https://desec.io/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bootstrapping-06.txt
Dear DNSOP, This revision - addresses editorial feedback from Secdir review (circulated on this list earlier); - improves the description of RFC updates, as suggested by Tim in his WGLC message; - fixes a nit in the abstract which Tim had found. Thanks, Nils & Peter On 10/2/23 23:56, internet-dra...@ietf.org wrote: Internet-Draft draft-ietf-dnsop-dnssec-bootstrapping-06.txt is now available. It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. Title: Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator Authors: Peter Thomassen Nils Wisiol Name:draft-ietf-dnsop-dnssec-bootstrapping-06.txt Pages: 17 Dates: 2023-10-02 Abstract: This document introduces an in-band method for DNS operators to publish arbitrary information about the zones they are authoritative for, in an authenticated fashion and on a per-zone basis. The mechanism allows managed DNS operators to securely announce DNSSEC key parameters for zones under their management, including for zones that are not currently securely delegated. Whenever DS records are absent for a zone's delegation, this signal enables the parent's registry or registrar to cryptographically validate the CDS/CDNSKEY records found at the child's apex. The parent can then provision DS records for the delegation without resorting to out-of-band validation or weaker types of cross-checks such as "Accept after Delay". This document deprecates the DS enrollment methods described in Section 3 of RFC 8078 in favor of Section 4 of this document, and also updates RFC 7344. [ Ed note: This document is being collaborated on at https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/ (https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/). The authors gratefully accept pull requests. ] The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dnsop-dnssec-bootstrapping-06.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-dnssec-bootstrapping-06 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
