Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)
Hi John, 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. not really. First of all, in-addr.arpa. zone is normal part of DNS tree and various authoritative (depends for which zone) servers answer with proper delegations on it. Sure, 9.10.in-addr.arpa. is already an NXDOMAIN (according to auth servers for 10.in-addr.arpa. , but none others!) since 10.0.0.0/8 is a private address space. On the other hand, onion. zone does not exist in DNS, therefore, the root servers (authoritative for ".") answer such queries as NXDOMAIN, whereas all other authoritative servers (for example, authoritative for zone example.com.) answer it with REFUSED, because it's out of their scope. The requirement that all authoritative servers must answer onion. (or any subdomains) with NXDOMAIN does not make sense: 1) all (AFAIK) auth server implementations to date do not comply 2) would be an unnecessary exceptional behavior, possibly confusing things 3) would be probably in conflict with other DNS RFCs 4) it's not clear how such answers would be DNSSEC'ed I suggest to remove any specific errcode (NXDOMAIN, REFUSED) mentions from such requirement. In the future, those errcodes and their names may be altered. I quite like the Peter's original proposal, though any wording can always be slightly improved. I don't dare to suggest any wording though. Libor ___ 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 26/11/2021 12.32, Petr Špaček wrote: You are right right, I did not consider "crack names which do not exist yet" scenario and focused only on dictionary reuse across zones. Do you have specific proposals for draft text? No, I don't have any ideas for improvements. The current salt section reads nice to me. --Vladimir ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)
libor.peltan wrote on 2021-11-30 01:11: ... I suggest to remove any specific errcode (NXDOMAIN, REFUSED) mentions from such requirement. In the future, those errcodes and their names may be altered. I quite like the Peter's original proposal, though any wording can always be slightly improved. I don't dare to suggest any wording though. a query for example.onion or even "onion" has no business being sent to an authority server to which this domain has not been delegated. so there is a right answer and it is generally not NXDOMAIN since that would be a knowledge signal (end to end) and the server can have no knowledge. obviously the root servers have and can signal such knowledge so NXDOMAIN would be the right answer from them. the right answer is likewise not REFUSED since that's a policy signal and we won't be asking that server implementers hard code "onion" or other special-use names, nor that server operators configure such names. there are too many servers, and the list of special-use domains will change over time. a policy signal for special-use names cannot scale. this also rules out "don't answer at all" which is also a policy signal. for any non-root server, an RD=0 question for example.onion should be answered with SERVFAIL. this is a condition signal, and the condition is "since i'm hearing this query, someone thinks i'm holding a delegation, and i'm not, so i might be lame for some zone, so the server (me, this authority server) has failed." vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)
Peter van Dijk wrote:
> 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.
If the goal is to avoid mandating extra code paths in typical
authoritative servers, I would suggest something like the following
which narrowly answers only the questions asked in 6761 ("Are developers
of authoritative domain name servers expected to make their
implementations recognize these names as special and treat them
differently? If so, how?"):
Original Text
-
5. Authoritative DNS Servers: Authoritative servers MUST respond to
queries for .onion with NXDOMAIN.
Corrected Text
--
5. Authoritative DNS Servers: Authoritative servers SHOULD NOT
recognize .onion names as special and MUST NOT treat queries for
.onion names differently from other queries.
Splitting the "recognize ... treat" conjunction between "SHOULD NOT"
and "MUST NOT" would, for instance, allow an authoritative server to
log a warning message if an operator intentionally configured an
"onion." zone in the server.
A slight expansion of the text might read:
Corrected Text
--
5. Authoritative DNS Servers: Authoritative servers SHOULD NOT
recognize .onion names as special and MUST NOT treat queries for
.onion names differently from other queries. By default,
authoritative servers MUST NOT respond authoritatively to
queries for .onion names.
The "By default" qualifier covers the case of a non-default
configuration (such as being configured to serve the root zone) where an
authoritative server would need to respond authoritatively for .onion
names.
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] How Slack didn't turn on DNSSEC
This blog post has been making the rounds. Since it is about a sequence of DNS operational failures, it seems somewhat relevant here. https://slack.engineering/what-happened-during-slacks-dnssec-rollout/ tl;dr first try was rolled back due to what turned out to be an unrelated failure at some ISP second try was rolled back when they found they had a CNAME at a zone apex, which they had never noticed until it caused DNSSEC validation errors. third try was rolled back when they found random-looking failures that they eventually tracked down to bugs in Amazon's Route 53 DNS server. They had a wildcard with A but not records. When someone did an query, the response was wrong and said there were no records at all, not just no records. This caused failures at 8.8.8.8 clients since Google does aggressive NSEC, not at 1.1.1.1 because Cloudflare doesn't. They also got some bad advice, e.g., yes the .COM zone adds and deletes records very quickly, but that doesn't mean you can unpublish a DS and just turn off DNSSEC because its TTL is a day. Their tooling somehow didn't let them republish the DNSKEY at the zone apex that matched the DS, only a new one that didn't. It is clear from the blog post that this is a fairly sophisticated group of ops people, who had a reasonable test plan, a bunch of test points set up in dnsviz and so forth. Neither of these bugs seem very exotic, and could have been caught by routine tests. Can or should we offer advice on how to do this better, sort of like RFC 8901 but one level of DNS expertise down? R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)
Hi Paul, for any non-root server, an RD=0 question for example.onion should be answered with SERVFAIL. this is a condition signal, and the condition is "since i'm hearing this query, someone thinks i'm holding a delegation, and i'm not, so i might be lame for some zone, so the server (me, this authority server) has failed." from what I've observed so far, there seem to be a consensus among the authoritative servers out there :) They all answer out-of-bailiwick queries with REFUSED. I haven't met any that would say SERVFAIL or NOTAUTH or anything else. If you propose to normatively change this, with the idea that it would make more sense, then OK, but dunno if it has any benefit. $ kdig @d.in-addr-servers.arpa. nonexistent-tld. +nordflag +noall +header ;; ->>HEADER<<- opcode: QUERY; status: REFUSED; id: 2834 ;; Flags: qr; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0 $ kdig @a.ns.nic.cz. nonexistent-tld. +nordflag +noall +header ;; ->>HEADER<<- opcode: QUERY; status: REFUSED; id: 63681 ;; Flags: qr; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0 $ kdig @a0.org.afilias-nst.info. nonexistent-tld. +nordflag +noall +header ;; ->>HEADER<<- opcode: QUERY; status: REFUSED; id: 45946 ;; Flags: qr; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0 If you propose that onion. TLD (non-existing) and its subtree shall be an exception (for very all auth servers) and answered differently than other non-existent TLDs, then OK, but I simply don't like the idea. Libor ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] RFC 9157 on Revised IANA Considerations for DNSSEC
A new Request for Comments is now available in online RFC libraries. RFC 9157 Title: Revised IANA Considerations for DNSSEC Author: P. Hoffman Status: Standards Track Stream: IETF Date: November 2021 Mailbox:paul.hoff...@icann.org Pages: 5 Updates:RFC 5155, RFC 6014, RFC 8624 I-D Tag:draft-ietf-dnsop-dnssec-iana-cons-05.txt URL:https://www.rfc-editor.org/info/rfc9157 DOI:10.17487/RFC9157 This document changes the review requirements needed to get DNSSEC algorithms and resource records added to IANA registries. It updates RFC 6014 to include hash algorithms for Delegation Signer (DS) records and NextSECure version 3 (NSEC3) parameters (for Hashed Authenticated Denial of Existence). It also updates RFCs 5155 and 6014, which have requirements for DNSSEC algorithms, and updates RFC 8624 to clarify the implementation recommendation related to the algorithms described in RFCs that are not on the standards track. The rationale for these changes is to bring the requirements for DS records and hash algorithms used in NSEC3 in line with the requirements for all other DNSSEC algorithms. This document is a product of the Domain Name System Operations Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)
I don’t see how any answer from an authoritative server other than REFUSED really makes sense for a domain for which that server is not authoritative. It hasn’t failed. It’s been asked a bogus question. It doesn’t make sense for it to theorize that it might be misconfigured. On Tue, Nov 30, 2021 at 15:06 libor.peltan wrote: > Hi Paul, > > > > for any non-root server, an RD=0 question for example.onion should be > > answered with SERVFAIL. this is a condition signal, and the condition > > is "since i'm hearing this query, someone thinks i'm holding a > > delegation, and i'm not, so i might be lame for some zone, so the > > server (me, this authority server) has failed." > > > from what I've observed so far, there seem to be a consensus among the > authoritative servers out there :) They all answer out-of-bailiwick > queries with REFUSED. I haven't met any that would say SERVFAIL or > NOTAUTH or anything else. If you propose to normatively change this, > with the idea that it would make more sense, then OK, but dunno if it > has any benefit. > > $ kdig @d.in-addr-servers.arpa. nonexistent-tld. +nordflag +noall +header > ;; ->>HEADER<<- opcode: QUERY; status: REFUSED; id: 2834 > ;; Flags: qr; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0 > $ kdig @a.ns.nic.cz. nonexistent-tld. +nordflag +noall +header > ;; ->>HEADER<<- opcode: QUERY; status: REFUSED; id: 63681 > ;; Flags: qr; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0 > $ kdig @a0.org.afilias-nst.info. nonexistent-tld. +nordflag +noall +header > ;; ->>HEADER<<- opcode: QUERY; status: REFUSED; id: 45946 > ;; Flags: qr; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0 > > If you propose that onion. TLD (non-existing) and its subtree shall be > an exception (for very all auth servers) and answered differently than > other non-existent TLDs, then OK, but I simply don't like the idea. > > Libor > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)
Ted Lemon wrote on 2021-11-30 17:04: I don’t see how any answer from an authoritative server other than REFUSED really makes sense for a domain for which that server is not authoritative. It hasn’t failed. It’s been asked a bogus question. It doesn’t make sense for it to theorize that it might be misconfigured. i only use REFUSED if the same question from some other query source (by IP) or signed differently (with TSIG or SIG(0)) could possibly work. for out-of-authority requests, the server must fail to answer. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)
Authoritative servers should take NO SPECIAL BEHAVIOUR for .onion. The default behaviour of an authoritative server is fine be it REFUSED, NOTAUTH, NXDOMAIN (when they have a copy of the root zone) or a referral to the root. Recursive servers are a different kettle of fish. Mark > On 1 Dec 2021, at 12:10, Paul Vixie wrote: > > > > Ted Lemon wrote on 2021-11-30 17:04: >> I don’t see how any answer from an authoritative server other than REFUSED >> really makes sense for a domain for which that server is not authoritative. >> It hasn’t failed. It’s been asked a bogus question. It doesn’t make sense >> for it to theorize that it might be misconfigured. > > i only use REFUSED if the same question from some other query source (by IP) > or signed differently (with TSIG or SIG(0)) could possibly work. for > out-of-authority requests, the server must fail to answer. > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] How Slack didn't turn on DNSSEC
> On 30 Nov 2021, at 1:38 pm, John Levine wrote: > > Can or should we offer advice on how to do this better, sort of like > RFC 8901 but one level of DNS expertise down? The main advice that comes to mind is to use a DNS hosting provider with a proven (multi-year) record of doing DNSSEC reliably. If the DNS hosting provider where Cloudflare, Google, OVH, one.com, TransIP, ... the implementation would have been correct. Clearly Route 53 wasn't quite ready for prime time. It is not clear how we can help customers know which providers have solid implementations. I don't know of any mainstream certification programs that would do the job. -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] How Slack didn't turn on DNSSEC
>It is clear from the blog post that this is a fairly sophisticated >group of ops people, who had a reasonable test plan, a bunch of test >points set up in dnsviz and so forth. Neither of these bugs seem >very exotic, and could have been caught by routine tests. It not clear to whether or not they did ZSK and KSK key rollovers on test zones and on minor zones. If they didn't, thats a good way to get in trouble later on. The main lesson learned from this incident seems to be to always create a test zone with content identical to that of the main zone and fully test that zone. A common lesson, also not mentioned, is to have low TTLs for stuff you control. It would not have helped with the DS record. But the discussion about the ZSK being lost would have been helped with a low TTL in the DNSKEY RR set. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] How Slack didn't turn on DNSSEC
Add tests to DNSVIZ to catch this sort of error. There is an open issue for this. -- Mark Andrews > On 1 Dec 2021, at 05:38, John Levine wrote: > > This blog post has been making the rounds. Since it is about a > sequence of DNS operational failures, it seems somewhat relevant here. > > https://slack.engineering/what-happened-during-slacks-dnssec-rollout/ > > tl;dr first try was rolled back due to what turned out to be an unrelated > failure at some ISP > > second try was rolled back when they found they had a CNAME at a zone > apex, which they had never noticed until it caused DNSSEC validation > errors. > > third try was rolled back when they found random-looking failures that > they eventually tracked down to bugs in Amazon's Route 53 DNS server. > They had a wildcard with A but not records. When someone did an > query, the response was wrong and said there were no records at > all, not just no records. This caused failures at 8.8.8.8 clients > since Google does aggressive NSEC, not at 1.1.1.1 because Cloudflare > doesn't. > > They also got some bad advice, e.g., yes the .COM zone adds and > deletes records very quickly, but that doesn't mean you can unpublish > a DS and just turn off DNSSEC because its TTL is a day. Their tooling > somehow didn't let them republish the DNSKEY at the zone apex that > matched the DS, only a new one that didn't. > > It is clear from the blog post that this is a fairly sophisticated > group of ops people, who had a reasonable test plan, a bunch of test > points set up in dnsviz and so forth. Neither of these bugs seem > very exotic, and could have been caught by routine tests. > > Can or should we offer advice on how to do this better, sort of like > RFC 8901 but one level of DNS expertise down? > > 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
