Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
I want this draft to move forward, but upon review I noted with concern the security section text: DNS error reporting is done without any authentication between the reporting resolver and the authoritative server of the agent domain. Authentication significantly increases the burden on the reporting resolver without any benefit to the monitoring agent, authoritative server or reporting resolver. Strong authentication (e.g. to a zone identity with DNSSEC) is probably excessive, but the current draft appears to have no defense against even trivial IP spoofing. Anyone in the world who can spoof IP addresses can impersonate a reputable resolver and pollute the error reports sent to authoritative servers. As an authoritative server operator, I would place a lot more trust in reports from reputable resolvers than from unrecognized sources. I think the draft should probably say something like: "To defend against spoofing of source IP addresses used for error reports, reporting resolvers MUST use DNS over TCP [RFC 7766], DNS COOKIE [RFC 7873], or another procedure that defeats IP address spoofing." --Ben Schwartz From: DNSOP on behalf of Benno Overeinder Sent: Thursday, June 8, 2023 5:59 AM To: DNSOP Working Group Cc: DNSOP Chairs Subject: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting !---| This Message Is From an External Sender |---! Dear DNSOP WG, The authors and the chairs feel this document has reached the stage where it's ready for Working Group Last Call. This starts a Working Group Last Call for: draft-ietf-dnsop-dns-error-reporting. Current versions of the draft is available here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/ . The Current Intended Status of this document is: Standards Track. Please review the draft and offer relevant comments. If this does not seem appropriate please speak out. If someone feels the document is *not* ready for publication, please speak out with your reasons. Supporting statements that the document is ready are also welcome. This starts a two week Working Group Last Call process, and ends on: June 22nd, 2023. Thanks, -- Benno ___ 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] DNSOPWorking Group Last call for draft-ietf-dnsop-dns-error-reporting
Roy Arends writes: > That, IMHO is already captured by the last paragraph. I did not > explicitly write a recipe of how to do that, and which servers could > be used for that :-). Could you suggest text to improve the last > paragraph without naming services? Erg. I hate it when I have to come up with text :-P How about replacing the last sentence of security considerations with: This method can be abused by intentionally deploying broken zones with agent domains that are delegated to victims. This is particularly effective when DNS requests that trigger error messages are sent through open resolvers [RFC8499] or widely distributed network monitoring systems that perform distributed queries from around the globe. Implementations SHOULD rate-limit outgoing error messages to a recipient to no more than 1 a minute. [reword as you will, of course... the last sentence subject to the largest debate] -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Current status of draft-ietf-dnsop-dnssec-validator-requirements
Hi, I have just drafted a secure transport and a security considerations section, that I believe provide sufficient guidance to a DRO. I expect to further review these sections and publish a new version very soon. As always, comments are welcome. https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/blob/master/draft-ietf-dnsop-dnssec-validator-requirements.mkd Yours, Daniel On Thu, Jun 15, 2023 at 8:00 PM Daniel Migault wrote: > Hi Christina, > > Thanks for the review and the suggestions. Please see my comments inline. > > Yours, > Daniel > > On Wed, Jun 14, 2023 at 11:56 AM Christian Huitema > wrote: > >> I know that the feedback was due last Sunday, but here comes mine >> anyhow, after looking at the latest iteration of the draft. >> >> The draft makes a number of recommendations, which seem all reasonable, >> but what struck me was the weak tie between these recommendations and >> the security considerations. > > I agree that we should reconsider that section. My initial version of the > security consideration section was in my opinion too long and I > considered it as too repetitive with the main body. I then focused on the > security where the DRO is the vector of attacks/vulnerabilities. I suppose > I have been a bit too far in that direction and this is too limitative. I > will reconsider this, and your comment on the threat model gives a good > insight on what could be added. I agree that we should add some text on the > threat models current and long term. > > What also strikes me is the absence of >> any consideration relative to secure transports such as DoT or DoQ. >> > That is correct. This is something that we did not consider and probably > have to mention. I think this will be a section on its own - and not a > security consideration. > >> >> I would love to see a document that addresses the future target, in >> which secure transports are use in most or all transactions between stub >> and recursive, or between recursive and authoritative. I think that in >> such scenarios, the threat model changes quite a bit. >> > > I tend to think that future direction might be a bit beyond the scope of > the document, but I do tend to think that a threat model discussion can be > useful for an operator. > > In the old model, we are very concerned about third parties spoofing >> responses and polluting resolver caches. In a secure transport model, >> the only parties that can spoof responses are the resolvers themselves: >> authoritative resolvers abusing their authority to add falsehoods in >> additional sections, recursive resolvers abusing the client trust to >> send false responses. >> >> I do think that DNSSEC is still useful, even in a secure transport >> world. But the focus changes. For example, if we consider that "spoofing >> by recursive server" is a threat, then having the recursive set bits to >> affirm that the response is verified is not much of a protection -- the >> emphasis should move to verification by the client. I would love to see >> this discussed. >> >> I agree that would become useful in giving insight into what threat the > DRO is addressing. > > >> -- Christian Huitema >> >> On 6/7/2023 10:38 AM, Florian Obser wrote: >> > On 2023-06-07 13:08 -04, Tim Wicinski wrote: >> >> Just a reminder we're looking for any feedback on continuing work on >> this >> >> document. The Chairs/OverLord Warren feel significant work on this >> >> document is needed, but that may not be relevant. >> > >> > The document seems to have a rather pessimistic view on running a >> > validator. It has this huge list of things that an operator has to do >> > and does not assign any importance to them - everything seems to be >> > equally important. >> > >> > If I were to read this as the person responsible for running the >> > recursive resolver at an enterprise or at an ISP I'd think: That sounds >> > like effort and incredibly fragile, it's probably best to not enable >> > validation. >> > >> > It would be nice to have an informational RFC on the topic, but I'm not >> > convinced this is it. Maybe Andrew's suggestion to split this up is the >> > way forward. Maybe have one document with minimum requirements (correct >> > time, stuff like that) and take it from there. >> > >> >> >> >> We're wrapping this feedback up this Sunday 11 June. >> >> >> >> (and Thanks Andrew for your comments) >> >> >> >> tim >> > >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Announcing the ICANN DNS Symposium 2023 and solicitation of presentation proposals
[ids2023-da-nang-3125x1771-5sep22-en.png] Dear colleagues, ICANN’s Office of the Chief Technology Officer is pleased to announce that the sixth ICANN DNS Symposium (IDS 2023) will be held on 5 September 2023 in Da Nang, Vietnam. IDS 2023 will be co-located with “A Day of DNS Abuse Discussions” (4 September), also hosted by ICANN, and OARC 41 (6-7 September), hosted by DNS-OARC. The theme for IDS 2023 is “The integration of DNS with emerging technologies”. IDS2023 will focus on the integration of DNS with emerging technologies, exploring the challenges and opportunities associated with this integration, including challenges related to security. The symposium invites researchers, developers, and operators to present on subjects including, but not limited to, blockchains, IoT, and novel uses of the DNS, such as IP-to-location translation, blocklists, and so on. We are soliciting proposals for presentations. Please send a one-paragraph description of your proposed topic to ids-propos...@icann.org by 14 August 2023. We will notify accepted speakers and publish a preliminary agenda by 18 August 2023. For more information on IDS, please visit https://www.icann.org/ids. Thank you and we hope to see you there! Matt Larson VP of Research ICANN Office of the CTO ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Early comments on https://www.ietf.org/archive/id/draft-thomassen-dnsop-generalized-dns-notify-01.txt
After a quick read of Generalized DNS Notifications, -01, I have some comments: It would be ludicrous of me to argue against the notion that event driven approaches are superior to polling approaches. However, event driven approaches require more design work which is why it is natural for polling approaches to normally lead the way until they break. In section 3, there is this phrase which caught my eye: "An increasing number of TLD registries are implementing periodic scanning for CDS and CDNSKEY records in child zones." Operators are choosing and deploying the scanning approach. Perhaps because it is the only option, nevertheless, the early deployments are scanning. At a recent event, I heard a few measurements of the scanning approach, done with skepticism regarding the ability of such an approach to scale, but none of the measurements pointed to a bottleneck. There was even an off-hand comment that perhaps scanning isn't scary at all. I don't doubt the logic that is present in section 3 leading to the conclusion that there's a need to develop an event-driven approach. In fact, I'm a fan of the logic. However, there's no data to back up the claims that the polling approach won't work. It would be good to have that included in the document to establish the need for the NOTIFY approach. And why establish the need? Deep in the nature of the DNS is the notion that parents know about children, but not vice versa. In the DNS, delegations - both name server (NS) and security (DS/DNSKEY) - to date point downward. Nothing points upward. CNAME and DNAME are query-rewriting tools, not delegation tools, I'm excluding them. The historical architecture of the DNS is hostile to the idea of an event-driven approach - that's my fear. NOTIFY, as it is in use today does not cross zones, it works only within the set of nameservers that a zone administrator has configured for a zone. "Also-notify" is a static configuration option available in implementations but being a configuration plane feature is not evident or supported in the standard protocol. NOTIFY exists in a pool of familiar servers, all participants are managed by one entity or via an out of band arrangement. It does not challenge the DNS "downward" architecture. Using NOTIFY in another context may prove to be a significant change. Perhaps the resource record format is general enough, but how a recipient would respond to the resource record would be different. This is why I'm not greatly encouraged by the observation that we already have a record defined although that helps. Using NOTIFY from a child to parent to trigger a CDS, CDNSKEY, CSYNC action makes sense, but the context is novel (for NOTIFY). The message is used to cross administrative boundaries, upward even. Mentioned earlier, in the DNS children don't talk up to the parent (easily), so a few things are needed. One is the proposed NOTIFY record to tell the child where to send the notification query. The other is figuring out how to set up a receiving server at the parent that is not a new burden on the zone administration. This latter item concerns me the most as adding more modules to operations is a burden unless this can be adequately automated, buried in code, to the point it has no operational knobs an operator needs to manage and track. (And there's always that DDoS/Firewall hole punching/traffic engineering challenge.) Using NOTIFY from one operator for a zone administration to an independent other operator (aka multi-signer) is another novel environment. In this case it is not shaped by a child to parent situation, but it exists in a potentially flat, out-of-band defined space. I usually hear of multi-signer featuring two operators, but there could be more. E.g., a TLD might decide to have a different signer for each of their half-dozen or so anycast name server contracted operators. There are quite a few design considerations for this. Another way is to classify NOTIFY today as a "1:me" protocol, from one of my elements to another element by me. From child to parent, it is "many:1" - a parent has many children (the many) with all the children trying to hit the 1 parent. Between co-operators of a zone, I'm not sure how to put that into a category of "1:1" or "1:many" or "many:1" protocol, but it's different. I suppose it's 1:1 but neither of these might be the zone administrator, which is a problem. Struggling to define the latter, here's what I'm concerned with. When you have an administrator who contracts to two, or more, operators for service and there is a fault, how is the fault handled? I.e., the error handling will need attention. NOTIFY now, when it breaks, it's all within one administration to heal. From child to parent, you could (perhaps) define fault handling in the registration agreement. But between co-operators for one zone, it's harder to manage. This puts the onus on the proto
Re: [DNSOP] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory
Hi Libor, all, On 6/22/23 11:42, libor.peltan wrote: here are my comments to draft-thomassen-dnsop-cds-consistency-03. Thank you very much! "In all cases, consistency is REQUIRED across received responses only. Nameservers that appear to be unavailable SHOULD be disregarded as if they were not part of the NS record set." I don't feel confident about the consequences of this cathegorical statement. What if you have two DNSSEC providers, one has an outage (or just network breakage between them and the polling entity), and the other one maliciously takes over by publishing new CDNSKEYs? The polling entity might re-query several times from different locations, but this is usually only performed when bootstrapping the scure delegation, not when already established. And even if, it's not clear if (when) this would be enough. I understand, on the other hand, that relying on permanently disfunctional (or lame in any meaning of that word) child NSs might be problematic. To sum this up, if this is an issue in the proposed method, it should be fixed, and if it isn't, it should be more verbosely described why. The document seems too brief in this regard. The SHOULD statement was added based on a concern Viktor voiced at one of the last IETF meetings, saying that if a nameserver is unreachable from the parent, this would permanently block DS maintenance. (A well-taken point, I think.) I would expect the combination of a nameserver not being reachable and the other party being malicious to be quite a rare event. Given the probably much more frequent "price" of blocking DS maintenance, I think this is the right trade-off. Where would you suggest to put more words about that? (Right there, or in the Security Considerations? Which words?) "CDS/CDNSKEY records at the Child zone apex MUST be fetched ... with DNSSEC validation enforced." Isn't this sentence disabling secure delegation bootstrapping? Yes, good catch! I addressed it in this commit: https://github.com/peterthomassen/draft-ietf-dnsop-cds-consistency/commit/7939107aebb4e4963367e1d7fd831d14f98dab27#diff-d3398566f77572362e657e31e035a0effbe92148ba122be28de37a177732f318 Also, I addressed all other comments received so far in response to the adoption call (commits in same repo). For convenience, see the editor's copy: https://peterthomassen.github.io/draft-ietf-dnsop-cds-consistency/ Best, Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Coming soon: WG interim meeting on the definition of "lame delegation"
On 6/21/23, 4:46 PM, "DNSOP on behalf of Robert Edmonds" wrote: >"In-bailiwick" vs. "out-of-bailiwick" I think the topic is no longer important. But I'll explain why I brought up "bailiwick" in this context. Bailiwick, according to a (non-technical/natural language dictionary, such as Merrian-Webster) means: 1) one's sphere of operations or particular area of interest. 2) the district or jurisdiction of a bailie or bailiff. When a query arrives at a nameserver, one of the early steps is to: (Copied from "Domain Concepts and Facilities" [RFC 1034], section Algorithm [4.3.2]) 2. Search the available zones for the zone which is the nearest ancestor to QNAME. If such a zone is found, go to step 3, otherwise step 4. My use of bailiwick comes from the "sphere of operations" mapping to "the available zones" in the nameserver. However, after the discussion in the interim meeting, I don't think there's any need to "replace" lame delegation with anything as the situation I've seen it used in no longer is a topic of discussion, except when we are dredging up history for the sake of history. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-cds-consistency-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft 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
Filename: draft-ietf-dnsop-cds-consistency-00.txt
Pages : 10
Date: 2023-06-22
Abstract:
Maintenance of DNS delegations requires occasional changes of the DS
and NS record sets on the parent side of the delegation. [RFC7344]
automates this for DS records by having the child publish CDS and/or
CDNSKEY records which hold the prospective DS parameters. Similarly,
CSYNC records indicate a desired update of the delegation's NS
records [RFC7477]. Parent-side entities (e.g. Registries,
Registrars) typically discover these records by periodically querying
them from the child ("polling"), before using them to update the
delegation's parameters.
This document specifies that if polling is used, 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-00.html
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] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory
Hi, here are my comments to draft-thomassen-dnsop-cds-consistency-03. "In all cases, consistency is REQUIRED across received responses only. Nameservers that appear to be unavailable SHOULD be disregarded as if they were not part of the NS record set." I don't feel confident about the consequences of this cathegorical statement. What if you have two DNSSEC providers, one has an outage (or just network breakage between them and the polling entity), and the other one maliciously takes over by publishing new CDNSKEYs? The polling entity might re-query several times from different locations, but this is usually only performed when bootstrapping the scure delegation, not when already established. And even if, it's not clear if (when) this would be enough. I understand, on the other hand, that relying on permanently disfunctional (or lame in any meaning of that word) child NSs might be problematic. To sum this up, if this is an issue in the proposed method, it should be fixed, and if it isn't, it should be more verbosely described why. The document seems too brief in this regard. "CDS/CDNSKEY records at the Child zone apex MUST be fetched ... with DNSSEC validation enforced." Isn't this sentence disabling secure delegation bootstrapping? Thanks, Libor Dne 21. 06. 23 v 15:52 Tim Wicinski napsal(a): All The call for adoption period for this draft wrapped up this morning. While we saw several strong comments and issues raised, we also saw the working group wishing to adopt this work and working on it. We consider this passed. Thanks all, and we will work with the authors to itemize the list of larger issues thanks tim On Wed, Jun 7, 2023 at 11:52 AM Tim Wicinski wrote: All, We've had this document in DNSOP for a bit and Peter has presented three different meetings. When I went back and looked at the minutes, the feedback was good. But when the chairs and Warren discussed it, we had confused ourselves on this document, which is our bad. We decided to stop confusing ourselves and let the working group help us out. What I did was to pull the comments on this document from the minutes of the meetings and include them below to make it easier to remember what was said. This starts a Call for Adoption for draft-thomassen-dnsop-cds-consistency The draft is available here: https://datatracker.ietf.org/doc/draft-thomassen-dnsop-cds-consistency/ Please review this draft to see if you think it is suitable for adoption by DNSOP, and send any comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends: 21 June 2023 Thanks, tim wicinski For DNSOP co-chairs Minutes from past meetings on "Consistency for CDS/CDNSKEY and CSYNC is Mandatory" 114 Mark: CDS records are no different than any others One NS might be down, which would stop the Peter: This is telling the parent how to act when faced with inconsistent information Viktor: There might be hidden masters Don't want to get stuck Peter: Wording could be changed to allow servers down Ben: There is a missing time constant When do I recheck if I get an inconsistent set? Peter: 7344 doesn't put any time limit Ben: Should suggest some time to retry when there is an inconstancy 115 Wes: Supports this Likes mandating checking everywhere Ralf: Supports this Can't ask "all" servers in anycast What if you don't get a response Peter: Ask each provider Is willing to add in wording about non responses Paul Wouters: This wasn't in CSYNC, our bug Viktor: Concern was hidden masters and nameservers that are gone and are never going to come back 116 Viktor: Corner case: if someone is moving to a host that doesn't do DNSSEC Peter: Could add a way to turn off DNSSEC on transfer Johan Stenstram: Breaks the logic that "if it is signed, it is good" Doesn't like "if this is really important" Let's not go there Authoritative servers are proxies for the registrant Out of sync is reflection on the registrant: business issues Wes: CSYNC was for keeping DNS up and running CSYNC can't fix the business problems Peter: Agrees that one signature should be OK Other parts of the spec also suggest asking multiple places ___ 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] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory
On 6/21/23 17:04, Peter Thomassen wrote: The existing documents lack any words on where specifically to query for CDS/CDNSKEY, and also what to do in case of inconsistencies. Section 3.1 says: [...] Does that clarify the issue? To avoid leaving this "hanging open": After an off-list chat with Matthijs, I realize I had misread the above, and there is actually no question -- his point was just that existing documents (current RFCs) lack certain guidance which the draft now clarifies. Peter ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
