[DNSOP] [Errata Verified] RFC8552 (7068)
The following errata report has been verified for RFC8552, "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7068 -- Status: Verified Type: Editorial Reported by: Bernie Hoeneisen Date Reported: 2022-08-02 Verified by: Warren Kumari (Ops AD) (IESG) Section: 4.1.2 Original Text - | URI| _tcp | [RFC6118] | | URI| _udp | [RFC6118] | Corrected Text -- | URI| _tcp | [RFC4340] | | URI| _udp | [RFC4340] | Notes - Wrong reference. RFC6118 does not even mention "tcp" nor "udp". Note that this also has an impact to the IANA registry: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names [ Warren Kumari (Ops AD): Please also see Errata 7066, and the thread https://mailarchive.ietf.org/arch/msg/dnsop/WFMXL5dY8sniHwVtkPfcqvWk3nI/ This was added as "part of a list used to "reserve" the names of (transport) protocols, so that constructs like _25._quic.example.com could be constructed where the _name denotes the protocol and not the name of something." . IANA will update the reference. ] -- RFC8552 (draft-ietf-dnsop-attrleaf-16) -- Title : Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves Publication Date: March 2019 Author(s) : D. Crocker Category: BEST CURRENT PRACTICE Source : Domain Name System Operations Area: Operations and Management Stream : IETF Verifying Party : IESG ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] General comment about downgrades vs. setting expectations in protocol definitions
In this line of reasoning, let's remember the "herd immunity" effect. If receivers mostly respond to expectation violations by transparent fallback, an attacker on the wire has more incentive to attempt the downgrade attack. If receivers mostly "fail closed", this incentive is reduced. This is a collective security effect, not something that can be determined unilaterally by each receiver. --Ben Schwartz From: DNSOP on behalf of Edward Lewis Sent: Tuesday, January 30, 2024 1:21 PM To: dnsop@ietf.org Subject: [DNSOP] General comment about downgrades vs. setting expectations in protocol definitions !---| This Message Is From an External Sender |---! I hear talk about "downgrade attacks" frequently, across different ideas. Hearing it again in the context of DELEG, I had this thought. We often wind up mired in discussions about downgrades, what they mean, the consequences. I'd suggest, as definers of protocols, we think in terms of ensuring that receivers of messages have an expectation of something. Inside protocol rules, data may be expected and arrive, expected and not, unexpected and arrive, or unexpected and not arrive. A downgrade attack is a diagnosis of "expected and not". A protocol ought to be documented to set up the receiver's expectations and define what the receiver does when they are not met. Apologies for this generic message, when looking at the DELEG documents again, it'll be something I'll keep in mind. I.e., the proposal to define one of the flags in the DNSKEY resource record format is setting up an expectation ___ 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] General comment about downgrades vs. setting expectations in protocol definitions
I hear talk about "downgrade attacks" frequently, across different ideas. Hearing it again in the context of DELEG, I had this thought. We often wind up mired in discussions about downgrades, what they mean, the consequences. I'd suggest, as definers of protocols, we think in terms of ensuring that receivers of messages have an expectation of something. Inside protocol rules, data may be expected and arrive, expected and not, unexpected and arrive, or unexpected and not arrive. A downgrade attack is a diagnosis of "expected and not". A protocol ought to be documented to set up the receiver's expectations and define what the receiver does when they are not met. Apologies for this generic message, when looking at the DELEG documents again, it'll be something I'll keep in mind. I.e., the proposal to define one of the flags in the DNSKEY resource record format is setting up an expectation ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] DNSOP Interim 2024-01 minutes
Again thanks to mr Hoffman for minutes, here they are and uploaded in the datatracker and our git repo Thank you one and all for having great productive conversations! tim DNSOP WG Interim meeting 2024-01-30 1700 UTC Chairs: Benno Overeinder, Suzanne Woolf, Tim Wicinski Minutes taken by Paul Hoffman Only stuff said that happened at the mic is reported here Agenda: https://datatracker.ietf.org/doc/agenda-interim-2024-dnsop Materials: https://datatracker.ietf.org/meeting/interim-2024-dnsop-01/session/dnsop Intro from the chairs This interim is for bootstrapping the topic before IETF119 Presentation on state of DELEG draft, Ralf Weber https://datatracker.ietf.org/doc/draft-dnsop-deleg/ Legacy resolver compliance testing results, Roy Arends Open discussion points in the draft Viktor Dukovni: Didn't see Microsoft's resolver tested; very different in origin Found the draft more confusing than illuminating Examples are haphazard Wants reorganization Wants a motivations document; what problem are we solving Roy: Maybe split the document into different topics This document is core Another document can have all the offerings Another document that gives an introduction to the whole thing This is a -00 Ralf: Wanted to get it ready for the interim OK with splitting out motivations into a different draft Suzanne: this discussion is not about specifics in the draft Initial reflections on DELEG, Paul Wouters Open discussion: discussion and reflection on interim Suzanne: Process discussion not today Ralf: PaulW's proposal #1 didn't want to do this to prolong DELEG Can happen in parallel There are plenty of implementations that don't share names Viktor: The idea of having more records at the parent needs motivation, but seems mostly harmless Putting more records puts more pressure on resolvers under attack Warren Kumari: Process-related BoF request was for extensions IESG doesn't feel that you can have a BoF for something that doesn't exist Wants the BoF to be about DELEG itself No assumption that people have been at interim Maybe a WG-forming BoF Need to be careful that DNSOPs folks participate Thus, in OPS Scheduled right after DNSOP so that there is overlap Roy: Will talk with Warren about the BoF request Viktor: Make the draft shorter and clearer Benno: Keep contributing to the DNSOP mailing list, specific text can go into the repo Peter Thomassen: Where to discuss this? Benno: On the mailing list Suzanne: This helps identify new work that might be spun off Benno: Protocol discussion on the mailing list Ralf: People coming early to DNS-OARC next week, there is an informal room on Wednesday ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] starting in 3 minutes - dnsop WG Virtual Meeting: 2024-01-30
Dear WG, this is a reminder that the virtual meeting is about to start in 3 minutes! The agenda URL will guide you to document with links for Meetecho etc. Petr Špaček On 24. 01. 24 21:54, Benno Overeinder wrote: Dear WG, We have published an updated agenda for the interim, see https://datatracker.ietf.org/doc/agenda-interim-2024-dnsop-01-dnsop-01/ ## Agenda ### Administrivia * Agenda Bashing, Blue Sheets, etc, 5 min ### New Business * Presentation on state of DELEG draft - https://datatracker.ietf.org/doc/draft-dnsop-deleg/ - 15 minutes * Legacy resolver compliance testing results - 5 minutes * Open discussion points in the draft - 10 minutes * Initial reflections on DELEG - Paul Wouters - 15 minutes * Open discussion: discussion and reflection on interim - 10 minutes * IETF Process Time - BoF? New WG? Another hour needed at next IETF On 19/01/2024 18:13, IESG Secretary wrote: The Domain Name System Operations (dnsop) WG will hold a virtual interim meeting on 2024-01-30 from 18:00 to 19:00 Europe/Amsterdam (17:00 to 18:00 UTC). Agenda: # DNS Operations (DNSOP) Working Group ## interim-2024-dnsop-01 ### Chairs * Benno Overeinder [be...@nlnetlabs.nl](be...@nlnetlabs.nl) * Suzanne Woolf [suzworldw...@gmail.com](suzworldw...@gmail.com) * Tim Wicinski [tjw.i...@gmail.com](tjw.i...@gmail.com) ### IESG Overlord * Warren Kumari [war...@kumari.net](war...@kumari.net) ### Document Status * [Github](https://github.com/ietf-wg-dnsop/wg-materials/blob/main/dnsop-document-status.md) * [Datatracker](https://datatracker.ietf.org/wg/dnsop/documents/) * [Propose Slides](https://datatracker.ietf.org/meeting/interim-2024-dnsop-01/session/dnsop) ## Session interim-2024-dnsop-01 * Date: 30 January 2024 * Time: 17:00-18:00 UTC * [MeetEcho](https://meetings.conf.meetecho.com/interim/?group=3d47363c-d68e-46b7-aedf-094716d4d64f) * [Jabber](dn...@jabber.ietf.org) * [Zulip](https://zulip.ietf.org/#narrow/stream/dnsop) * [Minutes](https://notes.ietf.org/notes-ietf-interim-2024-dnsop-01-dnsop) ## Agenda ### Administrivia * Agenda Bashing, Blue Sheets, etc, 5 min ### New Business * Presentation on state of DELEG draft. - 15 minutes * Legacy resolver compliance testing results. - 5 minutes * Open discussion points in the draft: - 10 minutes * Open Discussiontime for discussions - 20 minutes * IETF Process Time * BoF? New WG ? Another Hour Needed at next IETF Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=3d47363c-d68e-46b7-aedf-094716d4d64f -- A calendar subscription for all dnsop meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=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 -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-dnsop-deleg-00
John On Tue, Jan 30, 2024 at 11:29 AM John Dickinson wrote: > On 30/01/2024 16:21, Joe Abley wrote: > > On 30 Jan 2024, at 15:57, Roy Arends wrote: > > >>> If an authority server is capable of loading a DELEG RRSet and > generating referral responses accordingly, it's surely also possible of > synthesising an unsigned NS set? > >> > >> I’m all in favour of synthesising NS/Glue records from DELEG, however, > this automation is a nice to have and its functionality should not be > required to implement in the draft. > > > > Yep, I'm suggesting otherwise, that perhaps it ought to be a hard > requirement to synthesise NS RRs when DELEG is present, and perhaps also > that it not be legal to include both NS and DELEG at the same owner name. > > I have a longer review in the works but just wanted to pick up on this. > > I can well imagine having DELEG RR's pointing to some DoX server that is > not the same server as the DoX unaware one the NS RR's point to for good > old DNS. The important thing is that you get the same final DNS records > whatever path leads you to them. This is why I think that DNSSEC should > be required. > > So in a SLD world I wonder if the parent and child having to be the same always works? I've had to work out odd issues with a delegated subdomain in a lab where the NS records have moved and they have no glue, etc. Sometimes, the parent wants to force behavior. Not in the TLD case, but I hope you get my line of thinking tim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-dnsop-deleg-00
On 30 Jan 2024, at 17:25, Tim Wicinski wrote: > I do feel that SVCB is/was the right way to solve having more robust DNS > records, but it also is/was the thing that may end up destroying DNS. Destroying DNS sounds like a worthy goal to be honest :-) But yes, I like the SVCB approach too. It solves all kinds of annoying problems around corner cases that are unavoidable with chains or sets of related records. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-dnsop-deleg-00
On 30/01/2024 16:21, Joe Abley wrote: On 30 Jan 2024, at 15:57, Roy Arends wrote: If an authority server is capable of loading a DELEG RRSet and generating referral responses accordingly, it's surely also possible of synthesising an unsigned NS set? I’m all in favour of synthesising NS/Glue records from DELEG, however, this automation is a nice to have and its functionality should not be required to implement in the draft. Yep, I'm suggesting otherwise, that perhaps it ought to be a hard requirement to synthesise NS RRs when DELEG is present, and perhaps also that it not be legal to include both NS and DELEG at the same owner name. I have a longer review in the works but just wanted to pick up on this. I can well imagine having DELEG RR's pointing to some DoX server that is not the same server as the DoX unaware one the NS RR's point to for good old DNS. The important thing is that you get the same final DNS records whatever path leads you to them. This is why I think that DNSSEC should be required. John -- John Dickinson Sinodun Internet Technologies Ltd. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-dnsop-deleg-00
(my vibes only) On Tue, Jan 30, 2024 at 11:21 AM Joe Abley wrote: > > > I think specifying rules about which to prefer is important. But I also > think it's worth thinking more pessimistically around what kinds of > failures will result when people get that wrong. We have already seen this > with HTTPS, using precisely the same mechanism. > > I do feel that SVCB is/was the right way to solve having more robust DNS records, but it also is/was the thing that may end up destroying DNS. tim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-dnsop-deleg-00
On 30 Jan 2024, at 15:57, Roy Arends wrote: >> Unless we are certain that there is no benefit from DELEG without DNSSEC, >> perhaps DNSSEC should not be mandatory. > > DNSSEC is not mandatory, it is recommended. I was responding to the FOR DISCUSSION in section 1.5, which I imagined referred to the overall question of what level of support for DNSSEC the document should specify. > One motivation behind DELEG is the ability to use “Aliasmode” to point to an > SVCB record elsewhere, which contains a DS record. This way, DS records in > various top level domains can be federated under a single operator. This > works solely if both the DELEG is signed and “elsewhere” is signed. Yep. But simply not overloading the same RRTYPE involved in delegation (the NS RRSet) also confers benefits, regardless of whether DNSSEC is involved or not. >> If an authority server is capable of loading a DELEG RRSet and generating >> referral responses accordingly, it's surely also possible of synthesising an >> unsigned NS set? > > I’m all in favour of synthesising NS/Glue records from DELEG, however, this > automation is a nice to have and its functionality should not be required to > implement in the draft. Yep, I'm suggesting otherwise, that perhaps it ought to be a hard requirement to synthesise NS RRs when DELEG is present, and perhaps also that it not be legal to include both NS and DELEG at the same owner name. >> Related, what to do when the ipv4hints are not the same as the corresponding >> A RRSet? > > IMHO, potential unsigned glue records from elsewhere are inferior to address > records in a signed DELEG record. If a validator supports DELEG, and has > information such as Nameserver names and name server addresses, it should > ignore glue and NS records. I think specifying rules about which to prefer is important. But I also think it's worth thinking more pessimistically around what kinds of failures will result when people get that wrong. We have already seen this with HTTPS, using precisely the same mechanism. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPComments on draft-dnsop-deleg-00.txt - section 1
Negotiation is handled via the SVCB "mandatory" mechanism: https://datatracker.ietf.org/doc/html/rfc9460#name-servicemode-rr-compatibilit Basically, extensions are ignorable by default unless they are marked mandatory. If a record has a mandatory parameter that you don't understand, you skip that record. --Ben From: DNSOP on behalf of John Levine Sent: Tuesday, January 30, 2024 10:11 AM To: dnsop@ietf.org Cc: d...@fl1ger.de Subject: Re: [DNSOP] DNSOPComments on draft-dnsop-deleg-00.txt - section 1 !---| This Message Is From an External Sender |---! It appears that Ralf Weber said: >I agree that future extensions will require code changes, but having a >record type that is extensible from the start might make it easier to >deploy new parameters then it is to do a full RRTYPE, at least that is >the hope. If the RRTYPE is extensible, how do two DNS servers negotiate which extensions they can handle? So far we have been fairly careful to add things in a way that either you do it or you don't and even that has problems we all have seen. R's, John ___ 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] draft-dnsop-deleg-00
On Tue, 30 Jan 2024, Roy Arends wrote: One motivation behind DELEG is the ability to use “Aliasmode” to point to an SVCB record elsewhere, which contains a DS record. This way, DS records in various top level domains can be federated under a single operator. This works solely if both the DELEG is signed and “elsewhere” is signed. I don't understand what you are saying here. Can you elaborate and maybe include an example? Assume these records in various top level domains at delegation points: example.com DELEG 0 a1.operator.net example.net DELEG 0 a2.operator.net example.org DELEG 0 a3.operator.net example.uk DELEG 0 a4.operator.net example.nl DELEG 0 a5.operator.net example.de DELEG 0 a6.operator.net In operator.net zone: $ORIGIN operator.net a1 SVCB . (DS="19718 13 2 8ACBB0…” ipv4hint=192.0.254.1, 192.0.254.2 ) a2 SVCB . (DS=“13284 13 2 1CBA01…” ipv4hint=192.0.254.1, 192.0.254.2 ) a3 SVCB . (DS=“60123 13 2 403832…” ipv4hint=192.0.254.1, 192.0.254.2 ) a4 SVCB . (DS=“12101 13 2 1A6692…” ipv4hint=192.0.254.1, 192.0.254.2 ) a5 SVCB . (DS=“18998 13 2 655212…” ipv4hint=192.0.254.1, 192.0.254.2 ) a6 SVCB . (DS=“34421 13 2 90ABAA…” ipv4hint=192.0.254.1, 192.0.254.2 ) This way, the “DELEG” RDATA in the top level domain for “example.$TLD” can be long-lived, administered by the registrar on behalf of the registrant. The operator can manage all the relevant configuration material in the operator.net zone. Thanks, that made it clear yes. It is an interesting feature. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPComments on draft-dnsop-deleg-00.txt - section 1
> On 30 Jan 2024, at 15:11, John Levine wrote: > > It appears that Ralf Weber said: >> I agree that future extensions will require code changes, but having a >> record type that is extensible from the start might make it easier to >> deploy new parameters then it is to do a full RRTYPE, at least that is >> the hope. > > If the RRTYPE is extensible, how do two DNS servers negotiate which > extensions they can handle? So far we have been fairly careful to > add things in a way that either you do it or you don't and even that > has problems we all have seen. There is no negotiation. If the resolver supports a subset of the available extension, great, pick one. The server side can add preference by using SvcPriority. Warmly, Roy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-dnsop-deleg-00
On 1/30/24 16:05, Paul Wouters wrote: DNSSEC is not mandatory, it is recommended. One motivation behind DELEG is the ability to use “Aliasmode” to point to an SVCB record elsewhere, which contains a DS record. This way, DS records in various top level domains can be federated under a single operator. This works solely if both the DELEG is signed and “elsewhere” is signed. I don't understand what you are saying here. Can you elaborate and maybe include an example? nohats.ca. 86400 IN NSns2.foobar.fi. nohats.ca. 86400 IN DELEG 0 _conf.ns2.foobar.fi. nohats.ca. 86400 IN RRSIG DELEG ... _conf.ns2.foobar.fi. 3600 IN SVCB . ( alpn=doq ipv4hint=192.0.2.54 dnskey="257 3 13 BdaQBzPJKqw5U..." ) _conf.ns2.foobar.fi. 3600 IN RRSIG SVCB ... The _conf.ns2.foobar.fi. ALPN and DNSKEY configuration can be reused by other delegations as well, and the operator of ns2.foobar.fi can change it as it sees fit without requiring the delegations to be updated. (Hope this is what you meant.) The whole DELEG thing can also be done without DNSSEC, but then you can't establish the chain of trust like that. (And you don't need DNSSEC when the child is insecure, so it's not a problem.) ~Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-dnsop-deleg-00
> On 30 Jan 2024, at 15:05, Paul Wouters wrote: > > On Tue, 30 Jan 2024, Roy Arends wrote: > >> DNSSEC is not mandatory, it is recommended. >> >> One motivation behind DELEG is the ability to use “Aliasmode” to point to an >> SVCB record elsewhere, which contains a DS record. This way, DS records in >> various top level domains can be federated under a single operator. This >> works solely if both the DELEG is signed and “elsewhere” is signed. > > I don't understand what you are saying here. Can you elaborate and maybe > include an example? Assume these records in various top level domains at delegation points: example.com DELEG 0 a1.operator.net example.net DELEG 0 a2.operator.net example.org DELEG 0 a3.operator.net example.uk DELEG 0 a4.operator.net example.nl DELEG 0 a5.operator.net example.de DELEG 0 a6.operator.net In operator.net zone: $ORIGIN operator.net a1 SVCB . (DS="19718 13 2 8ACBB0…” ipv4hint=192.0.254.1, 192.0.254.2 ) a2 SVCB . (DS=“13284 13 2 1CBA01…” ipv4hint=192.0.254.1, 192.0.254.2 ) a3 SVCB . (DS=“60123 13 2 403832…” ipv4hint=192.0.254.1, 192.0.254.2 ) a4 SVCB . (DS=“12101 13 2 1A6692…” ipv4hint=192.0.254.1, 192.0.254.2 ) a5 SVCB . (DS=“18998 13 2 655212…” ipv4hint=192.0.254.1, 192.0.254.2 ) a6 SVCB . (DS=“34421 13 2 90ABAA…” ipv4hint=192.0.254.1, 192.0.254.2 ) This way, the “DELEG” RDATA in the top level domain for “example.$TLD” can be long-lived, administered by the registrar on behalf of the registrant. The operator can manage all the relevant configuration material in the operator.net zone. Hope this helps Warmly Roy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Conflicting info was - Re: [Ext] Re: draft-dnsop-deleg-00
On 1/30/24, 09:57, "DNSOP on behalf of Roy Arends" wrote: >> On 30 Jan 2024, at 12:57, Joe Abley wrote: > >> Related, what to do when the ipv4hints are not the same as the > corresponding A RRSet? > >IMHO, potential unsigned glue records from elsewhere are inferior to > address records in a signed DELEG record. If a validator supports DELEG, and > has information such as Nameserver names and name server addresses, it should > ignore glue and NS records. The question of "what happens when two sources differ on information" is a good one. In "Clarifications to the DNS Specification" a trustworthiness scale is in the "Ranking data" section. (That's RFC 2181, section 5.4.1. for those that address via numbers.) Nevertheless, I've see aggressive resolvers rely on glue records when higher ranking data led to no response (query went out, no response within a set time out) or was inclusive (meaning no address resource record sets could be found). "Aggressive" meant that the resolver tried all tricks, protocol-following or not, to get an answer back to the requester. What I mean is - it would be good to give a crisp, specific prescription for this case, but history shows that implementers can be crafty. I don't know if that is better or worse for operations though. In operations it would be good if the events were predictable (meets expected behavior) but it is also good if we limit faults. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPComments on draft-dnsop-deleg-00.txt - section 1
It appears that Ralf Weber said: >I agree that future extensions will require code changes, but having a >record type that is extensible from the start might make it easier to >deploy new parameters then it is to do a full RRTYPE, at least that is >the hope. If the RRTYPE is extensible, how do two DNS servers negotiate which extensions they can handle? So far we have been fairly careful to add things in a way that either you do it or you don't and even that has problems we all have seen. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Extensible from the start - was - Re: [Ext] Re: DNSOPComments on draft-dnsop-deleg-00.txt - section 1
On 1/30/24, 01:14, "DNSOP on behalf of Ralf Weber" wrote: >... but having a >record type that is extensible from the start ... Designing in extensibility is a very good idea, ah, essential idea, but isn't a no-brainer. Start by asking and documenting: What information is needed at a DNS delegation? There's the service address of course. There's a security context to be related. And there are arguably other meta-data to include. Consensus on this answer needs to be achieved, from this we can determine whether the construct of the resource record is necessary and sufficient. Because the draft only defines DELEG via examples, I need to ask this question this way: The RDATA has three fields - Is there going to be an assumed "standard set" of keywords? (And a defined manner to know how to deal with unknown-to-the-receiver keywords.) In asking this I'm thinking of the early experience with message compression, that is was supposed to only work for the types defined in the base DNS documents [those labeled STD 13] but then compression was accidently/inappropriately added for more, which led to a mess that "Handling of Unknown DNS Resource Record (RR) Types" had to deal with. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-dnsop-deleg-00
On Tue, 30 Jan 2024, Roy Arends wrote: DNSSEC is not mandatory, it is recommended. One motivation behind DELEG is the ability to use “Aliasmode” to point to an SVCB record elsewhere, which contains a DS record. This way, DS records in various top level domains can be federated under a single operator. This works solely if both the DELEG is signed and “elsewhere” is signed. I don't understand what you are saying here. Can you elaborate and maybe include an example? Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-dnsop-deleg-00
Hi Joe, > On 30 Jan 2024, at 12:57, Joe Abley wrote: > > Hi all, > > I have read draft-dnsop-deleg-00 and have some comments. It seems premature > to offer actual text as well as commentary but I can definitely do that if > the authors would like. I am fully enthusiastic about updating delegations > and referral responses, and anything negative below should not be > accidentally interpreted as some kind of objection, because far from it. > > I wrote a vaguely similar draft to this one a while back (except not as good, > and it's expired, and nobody got particularly excited about it, which was > surely entirely fair). That draft contains a number of problem statements > that might be reusable here. The privacy motivation in particular seems > pertinent, but maybe the others too. > > https://datatracker.ietf.org/doc/html/draft-jabley-dnsop-refer-00 > > I understand the motivation for the text relating to the DNS operator not > being part of the Registry/Registrar/Registrant gang (clearly it's because > the DNS operator does not start with R, for a start) but I think the text > that is there is inadequate to cover the full breadth of that idea. There's a > neat shortcut there to put nameserver configuration in the hands of DNS > operators, but there's more to that story. I think this deserves more > thought, if it is to be mentioned in the base draft. Perhaps this means it > doesn't belong in the base draft. > > The question of whether DNSSEC might be necessary in the use case where a > delegation involves a secure transport is perhaps best thought about as a > potential downgrade attack. A secure delegation coupled with validation of > the DELEG response when it arrives is a protection against that attack. While > it seems very sensible to warn about the attack and to suggest a mitigation, > I don't think it's useful to require that DNSSEC be used. That seems like a > sure fire way to make sure DELEG is not used, for a lot of people. Unless we > are certain that there is no benefit from DELEG without DNSSEC, perhaps > DNSSEC should not be mandatory. DNSSEC is not mandatory, it is recommended. One motivation behind DELEG is the ability to use “Aliasmode” to point to an SVCB record elsewhere, which contains a DS record. This way, DS records in various top level domains can be federated under a single operator. This works solely if both the DELEG is signed and “elsewhere” is signed. > The document is not very vocal on the question of whether a parent should > install both NS and DELEG RRSets above the zone cut, or whether there is an > opportunity for nameservers to use a DELEG if present to synthesise a > conventional referral with NSes. If DELEG doesn't mask NSes then there's the > question of what to do when the instructions in both delegations are > different. The draft says DELEG should be preferred, but to me this is just > taking an existing problem of parental and child NS sets being irritatingly > different in the wild and making the problem worse. If an authority server is > capable of loading a DELEG RRSet and generating referral responses > accordingly, it's surely also possible of synthesising an unsigned NS set? I’m all in favour of synthesising NS/Glue records from DELEG, however, this automation is a nice to have and its functionality should not be required to implement in the draft. Happy to have implementors build features that do this though. > Related, what to do when the ipv4hints are not the same as the corresponding > A RRSet? IMHO, potential unsigned glue records from elsewhere are inferior to address records in a signed DELEG record. If a validator supports DELEG, and has information such as Nameserver names and name server addresses, it should ignore glue and NS records. Roy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DELEG and parent only resolution
To your last point, I've proposed some examples of how "alpn" and "tlsa" ought to work here: https://github.com/fl1ger/deleg/pull/16/files --Ben Schwartz From: DNSOP on behalf of Kazunori Fujiwara Sent: Tuesday, January 30, 2024 1:55 AM To: dnsop@ietf.org Subject: [DNSOP] DELEG and parent only resolution !---| This Message Is From an Untrusted Sender You have not previously corresponded with this sender. |---! I read draft-dnsop-deleg-00. It proposes new name resolution using only information on the parent side. In the past, the dnsop WG debated parent centric name resolution and child centric, and some people did not like parent centric. If people prefer parent-centric/parent-only name resolution, there are solutions other than DELEG, such as parent centric name resolution, distinguishing the handling of authoritative data, referrals, and glue, and adding a signature of referral/in-domain in the parent. Is anyone interested in proceeding with minor fixes that are not DELEG? Previously, I prposed draft-fujiwara-dnsop-resolver-update and draft-fujiwara-dnsop-delegation-information-signer. (They are too old and need to be updated.) Or, I would like to read complete version of draft-dnsop-deleg that have alpn and tlsa parameters. Regards, -- Kazunori Fujiwara, JPRS ___ 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] DNSOPComments on draft-dnsop-deleg-00.txt - section 1
On Jan 30, 2024, at 01:14, Ralf Weber wrote: > > > I agree that future extensions will require code changes, but having a > record type that is extensible from the start might make it easier to > deploy new parameters then it is to do a full RRTYPE, at least that is > the hope. I took a step back and proposed two alternative more generic ways to solve this that DELEG can make use of. That way, we do not need to hope we get everything right. We can, if ever needed, switch to the a new rrtype with the same resolve-at-parent property without years-long delays. One solution ensures it “comes for free along with NS”, and already works now. The other would need the “multi-qtype” but would be a more clean generic solution. I will present that later today at the dnsop interim. https://datatracker.ietf.org/meeting/interim-2024-dnsop-01/materials/slides-interim-2024-dnsop-01-sessa-initial-reflections-on-deleg-00.pdf Paul___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-dnsop-deleg-00
Hi all, I have read draft-dnsop-deleg-00 and have some comments. It seems premature to offer actual text as well as commentary but I can definitely do that if the authors would like. I am fully enthusiastic about updating delegations and referral responses, and anything negative below should not be accidentally interpreted as some kind of objection, because far from it. I wrote a vaguely similar draft to this one a while back (except not as good, and it's expired, and nobody got particularly excited about it, which was surely entirely fair). That draft contains a number of problem statements that might be reusable here. The privacy motivation in particular seems pertinent, but maybe the others too. https://datatracker.ietf.org/doc/html/draft-jabley-dnsop-refer-00 I understand the motivation for the text relating to the DNS operator not being part of the Registry/Registrar/Registrant gang (clearly it's because the DNS operator does not start with R, for a start) but I think the text that is there is inadequate to cover the full breadth of that idea. There's a neat shortcut there to put nameserver configuration in the hands of DNS operators, but there's more to that story. I think this deserves more thought, if it is to be mentioned in the base draft. Perhaps this means it doesn't belong in the base draft. The question of whether DNSSEC might be necessary in the use case where a delegation involves a secure transport is perhaps best thought about as a potential downgrade attack. A secure delegation coupled with validation of the DELEG response when it arrives is a protection against that attack. While it seems very sensible to warn about the attack and to suggest a mitigation, I don't think it's useful to require that DNSSEC be used. That seems like a sure fire way to make sure DELEG is not used, for a lot of people. Unless we are certain that there is no benefit from DELEG without DNSSEC, perhaps DNSSEC should not be mandatory. The document is not very vocal on the question of whether a parent should install both NS and DELEG RRSets above the zone cut, or whether there is an opportunity for nameservers to use a DELEG if present to synthesise a conventional referral with NSes. If DELEG doesn't mask NSes then there's the question of what to do when the instructions in both delegations are different. The draft says DELEG should be preferred, but to me this is just taking an existing problem of parental and child NS sets being irritatingly different in the wild and making the problem worse. If an authority server is capable of loading a DELEG RRSet and generating referral responses accordingly, it's surely also possible of synthesising an unsigned NS set? Related, what to do when the ipv4hints are not the same as the corresponding A RRSet? Joe___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] [Errata Verified] RFC8552 (7068)
The following errata report has been verified for RFC8552, "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7068 -- Status: Verified Type: Editorial Reported by: Bernie Hoeneisen Date Reported: 2022-08-02 Verified by: Warren Kumari (Ops AD) (IESG) Section: 4.1.2. Original Text - | URI| _tcp | [RFC6118] | | URI| _udp | [RFC6118] | Corrected Text -- | URI| _tcp | [RFC4340] | | URI| _ucp | [RFC4340] | Notes - Wrong reference. RFC6118 does not even mention "tcp" nor "udp". Note that this also has an impact to the IANA registry: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names [ Warren Kumari (Ops AD): Please also see Errata 7066, and the thread https://mailarchive.ietf.org/arch/msg/dnsop/WFMXL5dY8sniHwVtkPfcqvWk3nI/ This was added as "part of a list used to "reserve" the names of (transport) protocols, so that constructs like _25._quic.example.com could be constructed where the _name denotes the protocol and not the name of something." . IANA will update the reference. ] -- RFC8552 (draft-ietf-dnsop-attrleaf-16) -- Title : Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves Publication Date: March 2019 Author(s) : D. Crocker Category: BEST CURRENT PRACTICE Source : Domain Name System Operations Area: Operations and Management Stream : IETF Verifying Party : IESG ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2024-01-30
Wes On Mon, Jan 29, 2024 at 6:45 PM Wes Hardaker wrote: > IESG Secretary writes: > > > The Domain Name System Operations (dnsop) WG will hold a virtual > > interim meeting on 2024-01-30 from 18:00 to 19:00 Europe/Amsterdam > > (17:00 to 18:00 UTC). > > I'm sadly very day-job conflicted with this slot, but greatly look > forward to watching the replay afterward (I may try to sneak an earpiece > into my head but it's unlikely I can pull that off). > > I'll note that if we're going to go down the road of such a major > change to parent/child/resolver interactions, it is highly important we > get opinions and viewpoints from all segments of the DNS industries to > ensure this is widely deployable. Having said that, if I can't keep my > own zones in sync properly with my registry's advertised data: it's time > to do something about the problem. [yes I recognize this is not an > adequate summary of the problem space, but it's a part]. Whether this > is the right solution or not will depend on feedback from many voices. > > I think not only opinions and viewpoints, but also a way to properly express the motivation. I added a question at the end of the chairs slides "Explain to Windows Admins and R53 Admins how this helps them" which is probably out of line, but this is more working to help summarize the motivation to a larger audience. tim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2024-01-30
On Mon, Jan 29, 2024 at 3:45 PM Wes Hardaker wrote: > IESG Secretary writes: > > > The Domain Name System Operations (dnsop) WG will hold a virtual > > interim meeting on 2024-01-30 from 18:00 to 19:00 Europe/Amsterdam > > (17:00 to 18:00 UTC). > > I'm sadly very day-job conflicted with this slot, but greatly look > forward to watching the replay afterward (I may try to sneak an earpiece > into my head but it's unlikely I can pull that off). > > I'll note that if we're going to go down the road of such a major > change to parent/child/resolver interactions, it is highly important we > get opinions and viewpoints from all segments of the DNS industries to > ensure this is widely deployable. Having said that, if I can't keep my > own zones in sync properly with my registry's advertised data: it's time > to do something about the problem. [yes I recognize this is not an > adequate summary of the problem space, but it's a part]. Whether this > is the right solution or not will depend on feedback from many voices. > > Ditto, sort of. (Busy with day-job search etc.) My $0.02 is to paraphrase https://xkcd.com/1069/ (where the pick up line about putting "U" and "I" next to each other in the English language, gets trashed by a reference to orthography): If we're going to add something like DELEG, I'd very much like to see a corresponding apex record/flag on the child. It's the one opportunity to "fix" the RRR non-role that DNS operators have and the unilateral nature of parent-side NS records. (If someone can come up with a "backronym" for ATE, then the pair would be DELEG-ATE. :-) ) But seriously, having a signed parental record that can, among other things, get paired up with a signed child apex record which would confirm (or deny) the validity of a delegation to a specific nameserver, would be a very nice thing. (Permanently lame child servers would need to stand up a zone just for the denial assertion, but having resolvers obtain, use, and cache that would improve the situation for all parties.) I.e. this would facilitate revalidation (as previously proposed), except that it would handle permanently lame delegations, including the "all nameservers are lame" situation. Now that I think about this a bit more, there are problems with being able to sign a child zone that denies the legitimacy of the delegation. It might need to exist underneath the namespace of the nameserver name, e.g. with an underscore prefix. Modulo the signing and location, it would probably be sufficient for such a record to be "yes"/"no", as to whether the child thinks the delegation is legitimate. (This would basically be an anti-bootstrap record, if that description makes sense.) Of course, it would also be nice if the Registries were to take on and fix the delegation issue (including the conflicting registrar ownership and usage of host objects), but if the DNS protocol can facilitate a signed (secure) work-around, that gets DNS to the goal state sooner (a lot sooner?). The other things I'd like to see (which may already be in the draft): - Require DNSSEC if/when DELEG (and ATE) are in use - If child (ATE) is included, I'd really like the delegation confirmation to be a MUST. If you are a resolver, the scalability/stability/security of DNS depends on you respecting (validated) signals from authoritative servers, IMNSHO. - Resolver-auth signaling of understanding DELEG (probably more important for any semantic things if/when those arise), presumably via EDNS. - Client-resolver signaling too? Are there new capabilities or better security etc available if/when clients are upgraded appropriately? Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
