Re: [DNSOP] Lars Eggert's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)
Hi, thanks for the detailed response. I have a few comments below, and I've trimmed everything from this reply where I agree with the resolution you proposed in your response. On 2021-11-30, at 1:53, Wessels, Duane wrote: >> Section 4.2. , paragraph 3, discuss: >>> Since host memory for TCP state is a finite resource, DNS clients and >>> servers MUST actively manage their connections. Applications that do >>> not actively manage their connections can encounter resource >>> exhaustion leading to denial of service. For DNS, as in other >>> protocols, there is a tradeoff between keeping connections open for >>> potential future use and the need to free up resources for new >>> connections that will arrive. >> >> For it to contain a MUST-level requirement, this section needs to give a lot >> more concrete guidance on what it means to "actively" manage connections. >> Most >> operating systems by default impose some application limits that usually >> effectively prevent DOS or other resource exhaustion issues. Is the intent >> here >> that DNS implementations need to do more? If so, what? > > I can easily be convinced that SHOULD is more appropriate than MUST here. I think that would be better, esp. for clients and because the "actively manage" term is still unclear to me - it seems to mean "must implement (some of) the limits below"? > I dont necessarily agree that operating systems alone do a very good job > of preventing DOS conditions. It is possible that Im not up-to-date on > the latest and greatest in terms of operating system features, but I think > historically applications have fared better when they manage their own > connections. For example, can we realistically expect the OS to know which > idle connections should be closed? The OS will certainly try to close sufficient connections under DDoS to remain operational. But if an application wants to see connections closed according to a certain policy - and DNS servers probably would - they need to actively engage. Maybe that's the rationale here? (Also, Linux and other major OSs these days handle very large numbers of TCP connections just fine, I think I recall seeing numbers up to a million for Linux (assuming sufficiently beefy hardware). And deployments that needs to handle such connection counts would normally load-balance into a server cluster anyway. So I remain a bit unconvinced that the limits described in this doc are all that important. But that's just a comment and I'm certainly not going to block the document over this.) >> Section 3. , paragraph 1, comment: >>> 3. DNS over TCP Requirements >> >> While the history preceding this section is interesting for context, I think >> moving this section up would increase readability significantly. > > Okay with me. I would like to hear from the Chairs. I'm OK with whatever resolution they prefer. >> Section 4.2. , paragraph 3, comment: >>> DNS server software MAY provide a configurable limit on the number of >>> established connections per source IP address or subnet. This can be >>> used to ensure that a single or small set of users cannot consume all >>> TCP resources and deny service to other users. Operators SHOULD >>> ensure this limit is configured appropriately, based on their number >>> and diversity of users. >> >> This limit only begins to establish fairness once the overall number of >> permitted connections is reached. Until that point, it possibly limits client >> performance without any benefit. > > I suppose this depends on how it is implemented and there are lessons to be > learned from the world of IP QOS. > > I surveyed open source DNS server code and their developers and found that > only > one implements this limit and ships with no limit by default. > > Perhaps this current (updated) paragraph is better: > > DNS server software MAY provide a configurable limit on the number of > established connections per source IP address or subnet. This can be > used to ensure that a single or small set of users cannot consume all > TCP resources and deny service to other users. Note, however, that > if this limit is enabled, it possibly limits client performance while > leaving some TCP resources unutilized. Operators SHOULD be aware of > these tradeoffs and ensure this limit, if configured, is set > appropriately based on the number and diversity of their users, and > whether users connect from unique IP addresses or through a shared > Network Address Translator [RFC3022]. > >> Section 4.2. , paragraph 3, comment: >>> DNS server software SHOULD provide a configurable timeout for idle >>> TCP connections. For very busy name servers this might be set to a >>> low value, such as a few seconds. For less busy servers it might be >>> set to a higher value, such as tens of seconds. >> >> Ditto. > > In this case all of the open source implementations I surveyed have this > limit enabled by default. It might
Re: [DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt
On 11/5/21 1:07 AM, Paul Wouters wrote: In general, the problem is that we need to make it easier for the DNS hoster to enable DNSSEC when their customers are non-technical. I think this draft does properly extend RFC 8078 and even think this document could deprecate the "Accept after wait" method. I took a shot at that in -03. However, I do think it should still impose a minimum length of publication before accepting, so that mistakes similar to the recent slack.com outage can be prevented. So change "accept after wait" to "verify, then accept after wait". Sure. The draft currently says in Section 3.2: | If the above steps succeed without error, the CDS/CDNSKEY records are | successfully validated, and the Parental Agent can proceed with the | publication of the DS record set under the precautions described in | [RFC8078], Section 5. ... and there, it says: | A parent SHOULD [...] ensure | that the zone validates correctly if the parent publishes the DS | record. A parent zone might also consider sending an email to its | contact addresses to give the child zone a warning that security will | be enabled after a certain amount of wait time -- thus allowing a | child administrator to cancel the request. I think that from a technical perspective, that covers the policy you're proposing. Or did you really mean to *impose* a minimum delay, as in: it is forbidden to deploy more quickly? Another approach would be to re-state explicitly what's in RFC 8078 Section 5 (but I don't know if text duplication between RFCs is welcome?). Best, Peter ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-03.txt
Dear DNSOP,
This draft introduces automatic bootstrapping of DNSSEC delegations. The
previous version has been presented at IETF 112, and the new version
incorporates the feedback gathered there (and on this list before the meeting).
Changes (taken from Appendix, with additional notes):
- Clarified importance of record cleanup by moving paragraph up.
# this is Section 4.1
- Pointed out limitations.
# this is (new) Section 3.4
- Replace [RFC8078] Section 3 with our Section 3.2.
# It was proposed to deprecate RFC 8078 Section 3.3 ("Accept after Delay").
Replacing all of Section 3 is one way of doing this. Of course, we can limit the update
to Section 3.3.
- Changed _boot label to _dsauth.
# based on a proposal to switch to _dsbootstrap, but I like _dsauth better :-)
- Removed hashing of Child name components in Signaling Names.
# as discussed at the meeting
- Editorial changes.
Looking forward to the next steps!
Thanks,
Peter
Forwarded Message
Subject: New Version Notification for
draft-thomassen-dnsop-dnssec-bootstrapping-03.txt
Date: Mon, 29 Nov 2021 15:57:25 -0800
From: internet-dra...@ietf.org
To: Nils Wisiol , Peter Thomassen
A new version of I-D, draft-thomassen-dnsop-dnssec-bootstrapping-03.txt
has been successfully submitted by Peter Thomassen and posted to the
IETF repository.
Name: draft-thomassen-dnsop-dnssec-bootstrapping
Revision: 03
Title: Automatic DNSSEC Bootstrapping using Authenticated Signals from
the Zone's Operator
Document date: 2021-11-29
Group: Individual Submission
Pages: 14
URL:
https://www.ietf.org/archive/id/draft-thomassen-dnsop-dnssec-bootstrapping-03.txt
Status:
https://datatracker.ietf.org/doc/draft-thomassen-dnsop-dnssec-bootstrapping/
Html:
https://www.ietf.org/archive/id/draft-thomassen-dnsop-dnssec-bootstrapping-03.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-dnssec-bootstrapping
Diff:
https://www.ietf.org/rfcdiff?url2=draft-thomassen-dnsop-dnssec-bootstrapping-03
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" ([RFC8078]).
This document updates [RFC8078] and replaces its Section 3 with
Section 3.2 of this document.
[ Ed note: Text inside square brackets ([]) is additional background
information, answers to frequently asked questions, general musings,
etc. They will be removed before publication. This document is
being collaborated on at https://github.com/desec-io/draft-thomassen-
dnsop-dnssec-bootstrapping/ (https://github.com/desec-io/draft-
thomassen-dnsop-dnssec-bootstrapping/). The most recent version of
the document, open issues, etc. should all be available there. The
authors gratefully accept pull requests. ]
The IETF Secretariat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Lars Eggert's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)
> On Oct 26, 2021, at 4:35 AM, Lars Eggert via Datatracker > wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > Lars Eggert has entered the following ballot position for > draft-ietf-dnsop-dns-tcp-requirements-13: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://secure-web.cisco.com/1kXvipN4VaKHO3AYxNHSk3_n8uHuI5gukOoaWs_9cG3yENUfEij_EahsVifsuqDvJ87tOMzqfsQvSNVDrlS_-uD93gYFrH-W0nErz-3dDIJpel5Zl7MmuWBdfniJzujsocAV1lsSsYtX8awWBkQ8eb_GhRen4BPENNuz1f9DU8scOGmh_6XvDTl2h2Ut3BN2YuNmDbmfWLYWKn2ljBjy70M3-N-vnFroRv7U3a3Kq-iNDmhKR53kaMlSwzI1NM_rK/https%3A%2F%2Fwww.ietf.org%2Fblog%2Fhandling-iesg-ballot-positions%2F > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://secure-web.cisco.com/1V7ehlyVXKiQcvhjjSAc0dm4x7jce6oRNiVmeJVwrJmYfNJTQCXozSCiVsTTDTMA31OsPaLi5ktIBX_1SJTMwPOMjHkyejN20CFahmTm4V-mFwr3n3zhznbcttOwt49mZNQ24MwFa4SFXIhHivGRuI65YKsZUQDdEJj2ORiTP9kCyMMSw6uGu5eE_JQtlH1M3Q7rqSm33c6SaE0h2NlmjlKGPa6zzXngPE8McI90Hbd47Q3rc4CuANJZLqNdhgNwu/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dnsop-dns-tcp-requirements%2F > > > > -- > DISCUSS: > -- > > Section 4.2. , paragraph 3, discuss: >> Since host memory for TCP state is a finite resource, DNS clients and >> servers MUST actively manage their connections. Applications that do >> not actively manage their connections can encounter resource >> exhaustion leading to denial of service. For DNS, as in other >> protocols, there is a tradeoff between keeping connections open for >> potential future use and the need to free up resources for new >> connections that will arrive. > > For it to contain a MUST-level requirement, this section needs to give a lot > more concrete guidance on what it means to "actively" manage connections. Most > operating systems by default impose some application limits that usually > effectively prevent DOS or other resource exhaustion issues. Is the intent > here > that DNS implementations need to do more? If so, what? I can easily be convinced that SHOULD is more appropriate than MUST here. I dont necessarily agree that operating systems alone do a very good job of preventing DOS conditions. It is possible that Im not up-to-date on the latest and greatest in terms of operating system features, but I think historically applications have fared better when they manage their own connections. For example, can we realistically expect the OS to know which idle connections should be closed? > > > -- > COMMENT: > -- > > Section 2.4. , paragraph 1, comment: >> 2.4. Fragmentation and Truncation > > Fragmentation and IP fragments getting dropped is one reason for needing more > retries with EDNS(0). But IIRC, a larger contributing factor is that EDNS(0) > doesn't detect or recover from loss of any UDP packets making up the overall > message. That means that a normal packet loss (due to congestion or other > reasons) amplifies into loss of the entire DNS message. This new paragraph has been added: Note that a receiver is unable to differentiate between packets lost due to congestion and packets (fragments) intentionally dropped by firewalls or middleboxes. Over network paths with non-trival amounts of packet loss, larger, fragmented DNS responses are more likely to never arrive and time out compared to smaller, unfragmented responses. Clients might be misled into retrying queries with different EDNS(0) UDP packet size values for the wrong reason. > > Section 3. , paragraph 1, comment: >> 3. DNS over TCP Requirements > > While the history preceding this section is interesting for context, I think > moving this section up would increase readability significantly. Okay with me. I would like to hear from the Chairs. > > Section 4.2. , paragraph 3, comment: >> DNS server software SHOULD provide a configurable limit on the total >> number of established TCP connections. If the limit is reached, the >> application is expected to either close existing (idle) connections >> or refuse new connections. Operators SHOULD ensure the limit is >> configured appropriately for their particular situation. > > Again, the OS generally already imposes limits. Why recommend that DNS > implementations self-impose other (lower?) limits? Perhaps the below text is better? It is directed more to operators (the
Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)
5. Authoritative DNS Servers: Authoritative servers MUST respond to queries for .onion with NXDOMAIN. I think this text is correct. The whole point of .onion and other special use domain names is that they are resolved outside of the DNS. RFC 6761 says they should be caught at a recursive server if not earlier. If a query for a special use name, whether it's foo.onion or 7.8.9.10.in-addr.arpa, leaks to an authoritative server, NXDOMAIN is the right answer. R's, John Corrected Text -- 5. Authoritative DNS Servers: Authoritative servers MUST respond non-authoritatively to queries for names in .onion. The original text for 5 and 6 is conflicting. A name server cannot respond with NXDOMAIN (which is an authoritative answer) without having a zone configured to serve that NXDOMAIN from. Clearly the intent of the text is that clients will not find authoritative answers to .onion queries anywhere in the DNS. The corrected text does not describe what to return though. I guess the text implies REFUSED, but perhaps the WG reasoned this was not good as it would lead to more queries to other servers or instances of the authoritative server set? Yes, it implies REFUSED. I was unsure REFUSED was standardised, or whether it is still a convention that almost all auths happen to follow. REFUSED would indeed lead to resolvers trying other auths (although that seems a bit theoretical - where did the resolver even come up with the idea to ask a bunch of auths about .onion names?). I also now realise that the root servers do not honour my new text, and their behaviour -is- correct, so perhaps: 5. Authoritative DNS Servers: Authoritative servers (other than the root servers) MUST respond non-authoritatively to queries for names in .onion. Yes, the root servers respond with an authoritative name error for QNAMEs under .ONION. For them to do otherwise would arguably break the commitment they have made many times to serve precisely the root zone provided to them by the IANA. I do see the problem that the proposed erratum is trying to address. However, I don't see much difference between clients of a resolver receiving a non-authoritative name error (e.g. a negative response from a root server that has been cached) vs. an authoritative name error (e.g. a negative response from a resolver that has been configured to answer in such a fashion). And I don't really see the point in any RFC suggesting that they can MUST operators into acting in any particular way, regardless of whether the servers they administer are acting as recursive or authoritative. The idea of modifying the protocol to accommodate namespaces outside the DNS is causing me to throw up in my mouth a bit, to be honest. Perhaps the DNS could just concentrate on being the DNS and other namespaces can fight their own battles? Joe Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)
On 29 Nov 2021, at 14:56, Paul Hoffman wrote: > On Nov 29, 2021, at 11:48 AM, Joe Abley wrote: >> The idea of modifying the protocol to accommodate namespaces outside the DNS >> is causing me to throw up in my mouth a bit, to be honest. Perhaps the DNS >> could just concentrate on being the DNS and other namespaces can fight their >> own battles? > > This bit of wrong text originates with RFC 6761: > 5. Authoritative DNS Servers: > > Are developers of authoritative domain name servers expected to > make their implementations recognize these names as special and > treat them differently? If so, how? > > [...] > > #5 explicitly talks about expectations on developers of authoritative *DNS* > servers dealing with names that are not in the DNS. In retrospect, this was > probably a mistake. (In retrospect, that mistake was probably caused by > exhaustion from the discussion.) > > Despite the nausea-inducing of Peter's suggestion, I think folks here need to > deal with it, if for no other reason than RFC 6761 still being a standard. 6761 surely doesn't require any particular answers to those questions, thoug; it just requires the respective issues to be considered. Perhaps an alternative approach in this case is to update the answer to (5) to be "no" and update the answer to (6) accordingly? Joe signature.asc Description: Message signed with OpenPGP ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)
On Nov 29, 2021, at 11:48 AM, Joe Abley wrote: > The idea of modifying the protocol to accommodate namespaces outside the DNS > is causing me to throw up in my mouth a bit, to be honest. Perhaps the DNS > could just concentrate on being the DNS and other namespaces can fight their > own battles? This bit of wrong text originates with RFC 6761: 5. Authoritative DNS Servers: Are developers of authoritative domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how? 6. DNS Server Operators: Does this reserved Special-Use Domain Name have any potential impact on DNS server operators? If they try to configure their authoritative DNS server as authoritative for this reserved name, will compliant name server software reject it as invalid? Do DNS server operators need to know about that and understand why? Even if the name server software doesn't prevent them from using this reserved name, are there other ways that it may not work as expected, of which the DNS server operator should be aware? #5 explicitly talks about expectations on developers of authoritative *DNS* servers dealing with names that are not in the DNS. In retrospect, this was probably a mistake. (In retrospect, that mistake was probably caused by exhaustion from the discussion.) Despite the nausea-inducing of Peter's suggestion, I think folks here need to deal with it, if for no other reason than RFC 6761 still being a standard. --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] Re: [Technical Errata Reported] RFC7686 (6761)
On Mon, 29 Nov 2021, Peter van Dijk wrote: The corrected text does not describe what to return though. I guess the text implies REFUSED, but perhaps the WG reasoned this was not good as it would lead to more queries to other servers or instances of the authoritative server set? Yes, it implies REFUSED. I was unsure REFUSED was standardised, or whether it is still a convention that almost all auths happen to follow. REFUSED would indeed lead to resolvers trying other auths (although that seems a bit theoretical - where did the resolver even come up with the idea to ask a bunch of auths about .onion names?). Right, But it is not different for different domains. Note though that for example .com nameservers return NOERROR and .ca nameservers return REFUSED but the difference in behaviour is the same for any non-existing TLD (eg not "onion" specific). I also now realise that the root servers do not honour my new text, and their behaviour -is- correct, so perhaps: 5. Authoritative DNS Servers: Authoritative servers (other than the root servers) MUST respond non-authoritatively to queries for names in .onion. That is I guess because we are talking about the "real authoritative servers" versus "a random not for the root authoritative nameserver". Maybe the term "authoritative nameserver" in this context is not the best to use ? So I agree the Original text has an issue. I haven't been convinced yet the suggested solution is the right one. After all, we are talking about "special domains", so perhaps it does warrant an NXDOMAIN despite that normally being used only within an authoritative context. I don't think we should be prescribing extra code paths in authoritative servers in this document, and I think non-authoritative NXDOMAINs would be very confusing. In particular, resolvers would not believe them anyway. Well, proper resolvers would never these servers. Perhaps it should say "authoritative servers for the root MUST return NXDOMAIN". All other authoritative servers should not have the .onion site configured as authoritative zone, and should handle the query as they do for other domains they are not configured for" ? But that's kinda wordy. I'm sure others can do better. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)
Hi Peter, On 29 Nov 2021, at 14:25, Peter van Dijk wrote: > On Mon, 2021-11-29 at 14:16 -0500, Paul Wouters wrote: >> On Mon, 29 Nov 2021, RFC Errata System wrote: >> >>> Original Text >>> - >>> 5. Authoritative DNS Servers: Authoritative servers MUST respond to >>> queries for .onion with NXDOMAIN. >>> Corrected Text >>> -- >>> 5. Authoritative DNS Servers: Authoritative servers MUST respond >>> non-authoritatively to >>> queries for names in .onion. >>> The original text for 5 and 6 is conflicting. A name server cannot respond >>> with NXDOMAIN (which is an authoritative answer) without having a zone >>> configured to serve that NXDOMAIN from. Clearly the intent of the text is >>> that clients will not find authoritative answers to .onion queries anywhere >>> in the DNS. >> >> The corrected text does not describe what to return though. I guess the >> text implies REFUSED, but perhaps the WG reasoned this was not good as >> it would lead to more queries to other servers or instances of the >> authoritative server set? > > Yes, it implies REFUSED. I was unsure REFUSED was standardised, or > whether it is still a convention that almost all auths happen to > follow. REFUSED would indeed lead to resolvers trying other auths > (although that seems a bit theoretical - where did the resolver even > come up with the idea to ask a bunch of auths about .onion names?). > > I also now realise that the root servers do not honour my new text, and > their behaviour -is- correct, so perhaps: > > 5. Authoritative DNS Servers: Authoritative servers (other than the > root servers) MUST respond non-authoritatively to queries for names in > .onion. Yes, the root servers respond with an authoritative name error for QNAMEs under .ONION. For them to do otherwise would arguably break the commitment they have made many times to serve precisely the root zone provided to them by the IANA. I do see the problem that the proposed erratum is trying to address. However, I don't see much difference between clients of a resolver receiving a non-authoritative name error (e.g. a negative response from a root server that has been cached) vs. an authoritative name error (e.g. a negative response from a resolver that has been configured to answer in such a fashion). And I don't really see the point in any RFC suggesting that they can MUST operators into acting in any particular way, regardless of whether the servers they administer are acting as recursive or authoritative. The idea of modifying the protocol to accommodate namespaces outside the DNS is causing me to throw up in my mouth a bit, to be honest. Perhaps the DNS could just concentrate on being the DNS and other namespaces can fight their own battles? Joe___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)
On Mon, 2021-11-29 at 14:16 -0500, Paul Wouters wrote: > On Mon, 29 Nov 2021, RFC Errata System wrote: > > > Original Text > > - > > 5. Authoritative DNS Servers: Authoritative servers MUST respond to > > queries for .onion with NXDOMAIN. > > Corrected Text > > -- > > 5. Authoritative DNS Servers: Authoritative servers MUST respond > > non-authoritatively to > > queries for names in .onion. > > The original text for 5 and 6 is conflicting. A name server cannot respond > > with NXDOMAIN (which is an authoritative answer) without having a zone > > configured to serve that NXDOMAIN from. Clearly the intent of the text is > > that clients will not find authoritative answers to .onion queries anywhere > > in the DNS. > > The corrected text does not describe what to return though. I guess the > text implies REFUSED, but perhaps the WG reasoned this was not good as > it would lead to more queries to other servers or instances of the > authoritative server set? Yes, it implies REFUSED. I was unsure REFUSED was standardised, or whether it is still a convention that almost all auths happen to follow. REFUSED would indeed lead to resolvers trying other auths (although that seems a bit theoretical - where did the resolver even come up with the idea to ask a bunch of auths about .onion names?). I also now realise that the root servers do not honour my new text, and their behaviour -is- correct, so perhaps: 5. Authoritative DNS Servers: Authoritative servers (other than the root servers) MUST respond non-authoritatively to queries for names in .onion. ? > So I agree the Original text has an issue. I haven't been convinced yet > the suggested solution is the right one. After all, we are talking about > "special domains", so perhaps it does warrant an NXDOMAIN despite that > normally being used only within an authoritative context. I don't think we should be prescribing extra code paths in authoritative servers in this document, and I think non-authoritative NXDOMAINs would be very confusing. In particular, resolvers would not believe them anyway. That all said, I can certainly see that other texts than my suggestion could make sense. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Technical Errata Reported] RFC7686 (6761)
On Mon, 29 Nov 2021, RFC Errata System wrote: Original Text - 5. Authoritative DNS Servers: Authoritative servers MUST respond to queries for .onion with NXDOMAIN. Corrected Text -- 5. Authoritative DNS Servers: Authoritative servers MUST respond non-authoritatively to queries for names in .onion. The original text for 5 and 6 is conflicting. A name server cannot respond with NXDOMAIN (which is an authoritative answer) without having a zone configured to serve that NXDOMAIN from. Clearly the intent of the text is that clients will not find authoritative answers to .onion queries anywhere in the DNS. The corrected text does not describe what to return though. I guess the text implies REFUSED, but perhaps the WG reasoned this was not good as it would lead to more queries to other servers or instances of the authoritative server set? So I agree the Original text has an issue. I haven't been convinced yet the suggested solution is the right one. After all, we are talking about "special domains", so perhaps it does warrant an NXDOMAIN despite that normally being used only within an authoritative context. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] [Technical Errata Reported] RFC7686 (6761)
The following errata report has been submitted for RFC7686, "The ".onion" Special-Use Domain Name". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6761 -- Type: Technical Reported by: Peter van Dijk Section: 2 Original Text - 5. Authoritative DNS Servers: Authoritative servers MUST respond to queries for .onion with NXDOMAIN. 6. DNS Server Operators: Operators MUST NOT configure an authoritative DNS server to answer queries for .onion. If they do so, client software is likely to ignore any results (see above). Corrected Text -- 5. Authoritative DNS Servers: Authoritative servers MUST respond non-authoritatively to queries for names in .onion. 6. DNS Server Operators: Operators MUST NOT configure an authoritative DNS server to answer authoritatively to queries for names in .onion. If they do so, client software is likely to ignore any results (see above). Notes - The original text for 5 and 6 is conflicting. A name server cannot respond with NXDOMAIN (which is an authoritative answer) without having a zone configured to serve that NXDOMAIN from. Clearly the intent of the text is that clients will not find authoritative answers to .onion queries anywhere in the DNS. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC7686 (draft-ietf-dnsop-onion-tld-01) -- Title : The ".onion" Special-Use Domain Name Publication Date: October 2015 Author(s) : J. Appelbaum, A. Muffett Category: PROPOSED STANDARD 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] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt
On 27. 11. 21 7:12, Viktor Dukhovni wrote: On Fri, Nov 26, 2021 at 12:32:19PM +0100, Petr Špaček wrote: Also, when we are theorizing, we can also consider that resalting thwarts simple correlation: After a resalt attacker cannot tell if a set of names has changed or not. With a constant salt attacker can detect new and removed names by their hash. (I'm not sure it is useful information without cracking the hashes.) Actually, no. If one has previously been mostly successful at cracking extant names in a zone, rehashing of a small set (much smaller than the full dictionary one use) of known names is rather quick. So old names can be quickly identified even after a salt change. Leaving just the hashes of new names. To be clear: I was talking about attacker who does not cracked the zone. You are right that rehashing know names is very cheap. Mind you, for cracking the new names, one would still rehash the entire dictionary when the salt changes, the number of new names to check is not a scaling factor in the cost. Just a table join. So periodic resalting does raise the cost of ongoing tracking of a zone's content, if that's the sort of thing one cares enough about. Rarely worth it, but mostly harmless if the salt is not too long and rotated say on each ZSK rollover. Plus all the mess with large zone transfers, which often can cause issues, especially when done in huge batches (like rotating ZSK/salt shared for 100 000 zones on a shared hosting.) -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
> On 29 Nov 2021, at 7:55 am, Michael Bauland wrote: > >> The iteration count distribution for the TLDs is presently: >> # TLDs NSEC3 iterations >> -- >> 147 0 >> 458 1 >> 1 2 >> 14 3 >> 112 5 >> 4 8 >> 545 10 >> 29 12 >> 1 13 >> 1 15 >> 1 17 >> 6 20 >> 2 25 >> The outliers above 10 are: >> ccTLDs: bn de dk pl sg ua xn--clchc0ea0b2g2a9gcd xn--yfro4i67o >> gTLDs: alstom barcelona bauhaus bcn cat erni eurovision eus firmdale gal >> gdn >>gmx ifm lacaixa madrid man mango nrw quebec radio ruhr sap scot >> seat >>sport swiss whoswho xn--55qw42g xn--80asehdb xn--80aswg >> xn--mgbab2bd >>xn--zfr164b > > We see your argument and have now adjusted our configurations accordingly. > All TLDs run by CORE Association and Knipp (i.e., almost all from the gTLDs > list above) have now reduced their NSEC3 iteration count to 0. Nice! Thanks. Indeed I see now only 12 TLDs with more than 10 iterations: ccTLDs: bn de dk pl sg ua xn--clchc0ea0b2g2a9gcd xn--yfro4i67o gTLDs: firmdale gdn xn--55qw42g xn--zfr164b The new distribution is: 175 0 396 1 1 2 14 3 113 5 3 8 607 10 1 12 1 13 1 15 1 17 6 20 2 25 Which seems to also suggest that 62 TLDs got moved from 1 to 10. :-( Perhaps a change of platform... Having whoever manages the 607 to switch to 0 would be a good next milestone... -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
Hi Viktor, hi all, thanks for making us aware of the NSEC3 iteration count topic. On 08.11.2021 18:29, Viktor Dukhovni wrote: On 8 Nov 2021, at 6:07 am, Petr Špaček wrote: TL;DR I say we should go for 0 and acknowledge in the text we are not there yet. This means reaching out to the TLD operators again... They were quite cooperative ~6 months back, but I wouldn't want to take them for granted and keep asking for multiple further rounds of changes. So whatever target ends up in the final document should be something they'd be willing to adopt as a final "issue closed" update. The iteration count distribution for the TLDs is presently: # TLDs NSEC3 iterations -- 147 0 458 1 1 2 14 3 112 5 4 8 545 10 29 12 1 13 1 15 1 17 6 20 2 25 The outliers above 10 are: ccTLDs: bn de dk pl sg ua xn--clchc0ea0b2g2a9gcd xn--yfro4i67o gTLDs: alstom barcelona bauhaus bcn cat erni eurovision eus firmdale gal gdn gmx ifm lacaixa madrid man mango nrw quebec radio ruhr sap scot seat sport swiss whoswho xn--55qw42g xn--80asehdb xn--80aswg xn--mgbab2bd xn--zfr164b We see your argument and have now adjusted our configurations accordingly. All TLDs run by CORE Association and Knipp (i.e., almost all from the gTLDs list above) have now reduced their NSEC3 iteration count to 0. Best regards, Michael -- | | | knipp |Knipp Medien und Kommunikation GmbH ---Technologiepark Martin-Schmeisser-Weg 9 44227 Dortmund Germany Dipl.-Informatiker Fon:+49 231 9703-0 Fax:+49 231 9703-200 Dr. Michael Bauland SIP:michael.baul...@knipp.de Software DevelopmentE-mail: michael.baul...@knipp.de Register Court: Amtsgericht Dortmund, HRB 13728 Chief Executive Officers: Dietmar Knipp, Elmar Knipp ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Doodle poll for DNSOP WG interim in December 2021
Hi all, Don't forget to fill in the Doodle before the end of Wednesday, 1 December. Thanks! On 23/11/2021 23:03, Benno Overeinder wrote: Dear DNSOP WG, We are planning our third DNSOP WG interim meeting in December, in week 49 or week 50. The draft DNS Terminology is the main topic on the agenda for the interim meeting: - https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/ Please fill in the Doodle poll to settle on a day and time: - https://doodle.com/poll/wt45258fyhw7ppst?utm_source=poll_medium=link The options for the time slots are PST friendly. We will close the Doodle poll at the end of Wednesday, 1 December. Best regards, Suzanne, Tim and 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
