[DNSOP] The DNSOP WG has placed draft-arends-dns-error-reporting in state "Call For Adoption By WG Issued"
The DNSOP WG has placed draft-arends-dns-error-reporting in state Call For Adoption By WG Issued (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-arends-dns-error-reporting/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NXDOMAIN and RFC 8020
>>> I think this is another point in favor of doing QNAME minimization. >>> RFC7816 (technically experimental, but recommended.) >>> >>> It kind of makes the query order moot; the resolver looks up the shorter >>> name first even while resolving the longer name. >>> >> >> Is there any data or even a hint of how widely that experiment has been >> deployed or implemented? >> > > It's on by default in (recent versions of) a number of popular open source > DNS resolver implementations (BIND, Unbound, Knot). And PowerDNS Recursor, see https://doc.powerdns.com/recursor/settings.html#qname-minimization Steinar Haug, AS2116 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NXDOMAIN and RFC 8020
On Tue, 6 Apr 2021, Andrew Sullivan wrote: In a somewhat different world where we used RRTYPEs rather than _tag names, we could do tree walks a lot more efficiently. I guess we're now in the world-record running for "somewhat" doing the most amount of work in a sentence? Hey, I'm the guy who wrote the DNS extension language so the web crudware that manages your DNS can automatically handle new RRTYPEs. It's even part of perl's Net::DNS but it otherwise hasn't caught on. Bummer. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY 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] Call for Adoption: draft-arends-dns-error-reporting
On Apr 6, 2021, at 2:07 PM, Benno Overeinder wrote: > > With the IETF 110 DNSOP meeting, the draft DNS Error Reporting > (draft-arends-dns-error-reporting) is presented by Roy Arends. > > In the session, the (virtual) room was asked for adoption of the document or > raise objections. On the mic there was general support for adoption. > > Now we will start a period of two weeks for the call for adoption of > draft-arends-dns-error-reporting on the mailing list. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-arends-dns-error-reporting/ > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and 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: 20 April 2021 I support the adoption of this document. Beyond the main use cases in the document (reporting DNSSEC problems), it is very likely we can use it in current DPRIVE work to report encrypted DNS problems. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NXDOMAIN and RFC 8020
On Tue, Apr 06, 2021 at 05:41:10PM -0400, John Levine wrote: In a somewhat different world where we used RRTYPEs rather than _tag names, we could do tree walks a lot more efficiently. I guess we're now in the world-record running for "somewhat" doing the most amount of work in a sentence? A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NXDOMAIN and RFC 8020
_dmarc.newjersey.sales.bigcorp.wtf _dmarc.sales.bigcorp.wtf _dmarc.bigcorp.wtf Sure, but if I query "_dmarc.newjersey.sales.bigcorp.wtf" and I get back an NXDOMAIN for "sales.bigcorp.wtf", I can eliminate at least one query, But you won't, you'll get back an answer for the name you looked up. You could do a seprate check first for sales.bigcorp.wtf but as I said I don't think that will usually win. It is my impression that the domain name tree is pretty flat, and if you limited a tree walk to four or five levels, that would catch every real DMARC record. Also, if your DNS cache is synthesizing NXDOMAIN results either under a higher NXDOMAIN (RFC 8020) or using DNSSEC (RFC 8198) those queries will be pretty cheap to haandle since they won't cause any upstream queries, so you might as well just do the tree walk. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY 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] NXDOMAIN and RFC 8020
On Tue, Apr 6, 2021 at 2:41 PM John Levine wrote: > In this application, no, because it's not doing a strict tree walk: > > _dmarc.newjersey.sales.bigcorp.wtf > _dmarc.sales.bigcorp.wtf > _dmarc.bigcorp.wtf > > The _dmarc tag means that none of the names is an ancestor of any of > the others. It could also look at, e.g., sales.bigcorp.wtf and see if > it has an NXDOMAIN and prune names below that, but I don't think that > approach is likely to win overall. Sure, but if I query "_dmarc.newjersey.sales.bigcorp.wtf" and I get back an NXDOMAIN for "sales.bigcorp.wtf", I can eliminate at least one query, because I know right away that the second one in your list isn't there either. Extend that out to a name with a dozen or more labels in it and you're getting somewhere. -MSK ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NXDOMAIN and RFC 8020
On Tue, Apr 6, 2021 at 12:51 PM Shumon Huque wrote: > > On Tue, Apr 6, 2021 at 3:03 PM Murray S. Kucherawy > wrote: >> >> On Tue, Apr 6, 2021 at 11:48 AM Shumon Huque wrote: >>> >>> Without DNSSEC, there is no current way to provide an indication about the >>> longest ancestor of the name that did exist. With DNSSEC, the NSEC or NSEC3 >>> records in the response can do this (as well as providing cryptographic >>> proof of this assertion with their signatures). >> >> >> Thanks, this (and the others) is helpful. >> >> Focusing on "no current way", could the process described in RFC 8020 >> theoretically be amended to do so? It's fine if the answer is "no", but I'd >> love to understand why if that's the case. > > > I suspect the most common answer to your question will be "No, just deploy > DNSSEC". I'm sure one could devise a new protocol enhancement that an > authoritative server could use to convey this information, but I'm not sure > it is worth complicating the protocol to do so. > > Also, even with 8020, there have been concerns raised that resolvers > implementing it, could be vulnerable to spoofing adversaries easily pruning > entire subtrees from their caches (rather than having to spoof many > individual names). Unbound, for example, implements 8020 only for signed > zones. Murray, an organization we both know very well, do not implement ENT/RFC8020 for instance... In the case of DNSSEC you get proper coverage with NSEC even if at best you use White (RFC4470) and Black (https://tools.ietf.org/html/draft-valsorda-dnsop-black-lies-00) lies. Manu ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NXDOMAIN and RFC 8020
It appears that Murray S. Kucherawy said: >-=-=-=-=-=- > >I'm wondering something about tree walks, which John Levine asked about in >November, as it's a topic of interest to the evolution of DMARC. > >I've read RFC 8020 which says an NXDOMAIN cached for "foo.example" also >covers later queries for "bar.foo.example". Makes sense. > >Can this be used (or maybe amended) to cover the queries if they come in >the reverse order? In this application, no, because it's not doing a strict tree walk: _dmarc.newjersey.sales.bigcorp.wtf _dmarc.sales.bigcorp.wtf _dmarc.bigcorp.wtf The _dmarc tag means that none of the names is an ancestor of any of the others. It could also look at, e.g., sales.bigcorp.wtf and see if it has an NXDOMAIN and prune names below that, but I don't think that approach is likely to win overall. In a somewhat different world where we used RRTYPEs rather than _tag names, we could do tree walks a lot more efficiently. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NXDOMAIN and RFC 8020
On Tue, Apr 6, 2021 at 5:16 PM Murray S. Kucherawy wrote: > On Tue, Apr 6, 2021 at 12:56 PM Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > >> I think this is another point in favor of doing QNAME minimization. >> RFC7816 (technically experimental, but recommended.) >> >> It kind of makes the query order moot; the resolver looks up the shorter >> name first even while resolving the longer name. >> > > Is there any data or even a hint of how widely that experiment has been > deployed or implemented? > It's on by default in (recent versions of) a number of popular open source DNS resolver implementations (BIND, Unbound, Knot). Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NXDOMAIN and RFC 8020
On Tue, Apr 6, 2021 at 12:56 PM Brian Dickson wrote: > I think this is another point in favor of doing QNAME minimization. > RFC7816 (technically experimental, but recommended.) > > It kind of makes the query order moot; the resolver looks up the shorter > name first even while resolving the longer name. > Is there any data or even a hint of how widely that experiment has been deployed or implemented? -MSK ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Call for Adoption: draft-arends-dns-error-reporting
With the IETF 110 DNSOP meeting, the draft DNS Error Reporting (draft-arends-dns-error-reporting) is presented by Roy Arends. In the session, the (virtual) room was asked for adoption of the document or raise objections. On the mic there was general support for adoption. Now we will start a period of two weeks for the call for adoption of draft-arends-dns-error-reporting on the mailing list. The draft is available here: https://datatracker.ietf.org/doc/draft-arends-dns-error-reporting/ Please review this draft to see if you think it is suitable for adoption by DNSOP, and 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: 20 April 2021 Thanks, -- Benno DNSOP co-chair ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] using type65 for https with a non-default port
Hiya, On 06/04/2021 21:00, Ben Schwartz wrote: Here's a proposal to add an example as you suggest: https://github.com/MikeBishop/dns-alt-svc/pull/311/files LGTM, thanks, S. On Sat, Apr 3, 2021 at 2:44 PM Stephen Farrell wrote: On 03/04/2021 18:07, Ben Schwartz wrote: It's supposed to be _8410._https.foo.example.com, qtype=65 Thanks. That'd work for me. Probably no harm to add an example or explicit statement to that effect. Cheers, S. On Sat, Apr 3, 2021 at 12:55 PM Stephen Farrell < stephen.farr...@cs.tcd.ie> wrote: Hiya, I had a quick look at the draft I'm not sure if I know for sure what qname/qtype is supposed to be used for e.g. https://foo.eample.com:8410/ - can anyone say off the top of their head? The options I can imagine are: qname: foo.example.com, qytpe: type65 qname: _8410._https.foo.example.com, qytpe: type64 I guess some other combos might also exist but I'm not quite sure which to query nor which to publish. Thanks, S. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop OpenPGP_0x5AB2FAF17B172BEA.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NXDOMAIN and RFC 8020
On Tue, Apr 6, 2021 at 11:11 AM Murray S. Kucherawy wrote: > I'm wondering something about tree walks, which John Levine asked about in > November, as it's a topic of interest to the evolution of DMARC. > > I've read RFC 8020 which says an NXDOMAIN cached for "foo.example" also > covers later queries for "bar.foo.example". Makes sense. > > Can this be used (or maybe amended) to cover the queries if they come in > the reverse order? For instance, if "bar.foo.example" arrives first, but > the authoritative server can determine that the entire "foo.example" tree > doesn't exist, could it reply with an NXDOMAIN for the question plus a > cacheable indication about the entire tree instead of just the name that > was in the question? > I think this is another point in favor of doing QNAME minimization. RFC7816 (technically experimental, but recommended.) It kind of makes the query order moot; the resolver looks up the shorter name first even while resolving the longer name. Should be handled by the resolver, so maybe tangential to DMARC (other than maybe being an included reference and recommendation within any DMARC draft/RFC). Brian > > This would make an ascending tree walk even for something crazy like > "a.b.c.d.y.z.foo.example" extremely cheap as the cached NXDOMAIN for > "foo.example" covers the entire subtree, for a caching nameserver > implementing RFC 8020. > > Maybe this is discussed somewhere that I missed in the references. I'm > happy to take a "go read this for the answer" if that's the case. > > Thanks, > > -MSK > ___ > 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] NXDOMAIN and RFC 8020
On Tue, Apr 6, 2021 at 3:03 PM Murray S. Kucherawy wrote: > On Tue, Apr 6, 2021 at 11:48 AM Shumon Huque wrote: > >> Without DNSSEC, there is no current way to provide an indication about >> the longest ancestor of the name that did exist. With DNSSEC, the NSEC or >> NSEC3 records in the response can do this (as well as providing >> cryptographic proof of this assertion with their signatures). >> > > Thanks, this (and the others) is helpful. > > Focusing on "no current way", could the process described in RFC 8020 > theoretically be amended to do so? It's fine if the answer is "no", but > I'd love to understand why if that's the case. > I suspect the most common answer to your question will be "No, just deploy DNSSEC". I'm sure one could devise a new protocol enhancement that an authoritative server could use to convey this information, but I'm not sure it is worth complicating the protocol to do so. Also, even with 8020, there have been concerns raised that resolvers implementing it, could be vulnerable to spoofing adversaries easily pruning entire subtrees from their caches (rather than having to spoof many individual names). Unbound, for example, implements 8020 only for signed zones. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NXDOMAIN and RFC 8020
On Tue, Apr 6, 2021 at 11:48 AM Shumon Huque wrote: > Without DNSSEC, there is no current way to provide an indication about the > longest ancestor of the name that did exist. With DNSSEC, the NSEC or NSEC3 > records in the response can do this (as well as providing cryptographic > proof of this assertion with their signatures). > Thanks, this (and the others) is helpful. Focusing on "no current way", could the process described in RFC 8020 theoretically be amended to do so? It's fine if the answer is "no", but I'd love to understand why if that's the case. -MSK ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] ECS and SVCB
Thanks to everyone who provided input into the draft text for ECS with SVCB on Github. The current proposed text is: > The EDNS Client Subnet option (ECS, [RFC7871]) allows recursive resolvers to request IP addresses that are suitable for a particular client IP range. SVCB records may contain IP addresses (in ipv*hint SvcParams), or direct users to a subnet-specific TargetName, so recursive resolvers SHOULD include the same ECS option in SVCB queries as in A/ queries. > > According to Section 7.3.1 of [RFC7871], "Any records from [the Additional section] MUST NOT be tied to a network". Accordingly, resolvers SHOULD treat any records in the Additional section as having SOURCE PREFIX-LENGTH zero and SCOPE PREFIX-LENGTH as specified in the ECS option, and MAY cache them on this basis. Authoritative servers MUST omit such records if they are not suitable for use by any stub resolvers that set SOURCE PREFIX-LENGTH to zero. This will cause the resolver to perform a followup query that can receive properly tailored ECS. (This is similar to the usage of CNAME with ECS discussed in [RFC7871] Section 7.2.1.) > > Authoritative servers that omit Additional records can avoid the added latency of a followup query by following the advice in Section 10.2. If anyone would like changes to this text, please let me know. On Wed, Mar 24, 2021 at 5:19 PM Ben Schwartz wrote: > In the course of WGLC for SVCB, a few people have highlighted nontrivial > interactions between SVCB and EDNS Client Subnet (ECS). To clear this up, > the authors are considering [1] adding a section explaining how SVCB and > ECS should interact, for entities that are trying to do both. > > Please review if you have an interest in these topics. > > Thanks, > Ben Schwartz > > [1] > https://github.com/MikeBishop/dns-alt-svc/pull/308/files?short_path=3500257#diff-3500257c8185942fb80e67b6128f73e7807ad42cdbeee3caf923c376e899235f > smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NXDOMAIN and RFC 8020
On Tue, Apr 6, 2021 at 2:11 PM Murray S. Kucherawy wrote: > I'm wondering something about tree walks, which John Levine asked about in > November, as it's a topic of interest to the evolution of DMARC. > > I've read RFC 8020 which says an NXDOMAIN cached for "foo.example" also > covers later queries for "bar.foo.example". Makes sense. > > Can this be used (or maybe amended) to cover the queries if they come in > the reverse order? For instance, if "bar.foo.example" arrives first, but > the authoritative server can determine that the entire "foo.example" tree > doesn't exist, could it reply with an NXDOMAIN for the question plus a > cacheable indication about the entire tree instead of just the name that > was in the question? > Yes, it can answer NXDOMAIN. Without DNSSEC, there is no current way to provide an indication about the longest ancestor of the name that did exist. With DNSSEC, the NSEC or NSEC3 records in the response can do this (as well as providing cryptographic proof of this assertion with their signatures). As mentioned by others, RFC8198 (which can be considered a superset of 8020 for signed zones) extends the semantics by allowing resolvers to infer non-existence not only below the name, but for all names that fall in the NSEC/NSEC3 spans. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NXDOMAIN and RFC 8020
And the 'go read this' reference is https://tools.ietf.org/html/rfc8198 On Tue, 2021-04-06 at 20:29 +0200, libor.peltan wrote: > Hi Murray, > if foo.example does not exist and DNSSEC is in place, than the resolver > actually, even with the queries "in reverse order", obtains and NSEC(3), > proving non-existence for much more. > For example, the query is bar.foo.example, and the authoritative returns an > NSEC proving that there is nothing between fa.example and fz.example. Thus, > the resolver can later deduct nonexistence not only for foo.example, but also > for fun.example and bar.fun.example, etc... > Without DNSSEC, this deduction (called "aggresive NSEC caching") is not > possible. > Cheers, > Libor > Dne 06. 04. 21 v 20:11 Murray S. Kucherawy napsal(a): > > > > This would make an ascending tree walk even for something crazy like > > "a.b.c.d.y.z.foo.example" extremely cheap as the cached NXDOMAIN for > > "foo.example" covers the entire subtree, for a caching nameserver > > implementing RFC 8020. > > > > Maybe this is discussed somewhere that I missed in the references. I'm > > happy to take a "go read this for the answer" if that's the case. 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] NXDOMAIN and RFC 8020
Hi Murray, if foo.example does not exist and DNSSEC is in place, than the resolver actually, even with the queries "in reverse order", obtains and NSEC(3), proving non-existence for much more. For example, the query is bar.foo.example, and the authoritative returns an NSEC proving that there is nothing between fa.example and fz.example. Thus, the resolver can later deduct nonexistence not only for foo.example, but also for fun.example and bar.fun.example, etc... Without DNSSEC, this deduction (called "aggresive NSEC caching") is not possible. Cheers, Libor Dne 06. 04. 21 v 20:11 Murray S. Kucherawy napsal(a): I'm wondering something about tree walks, which John Levine asked about in November, as it's a topic of interest to the evolution of DMARC. I've read RFC 8020 which says an NXDOMAIN cached for "foo.example" also covers later queries for "bar.foo.example". Makes sense. Can this be used (or maybe amended) to cover the queries if they come in the reverse order? For instance, if "bar.foo.example" arrives first, but the authoritative server can determine that the entire "foo.example" tree doesn't exist, could it reply with an NXDOMAIN for the question plus a cacheable indication about the entire tree instead of just the name that was in the question? This would make an ascending tree walk even for something crazy like "a.b.c.d.y.z.foo.example" extremely cheap as the cached NXDOMAIN for "foo.example" covers the entire subtree, for a caching nameserver implementing RFC 8020. Maybe this is discussed somewhere that I missed in the references. I'm happy to take a "go read this for the answer" if that's the case. Thanks, -MSK ___ 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] NXDOMAIN and RFC 8020
I'm wondering something about tree walks, which John Levine asked about in November, as it's a topic of interest to the evolution of DMARC. I've read RFC 8020 which says an NXDOMAIN cached for "foo.example" also covers later queries for "bar.foo.example". Makes sense. Can this be used (or maybe amended) to cover the queries if they come in the reverse order? For instance, if "bar.foo.example" arrives first, but the authoritative server can determine that the entire "foo.example" tree doesn't exist, could it reply with an NXDOMAIN for the question plus a cacheable indication about the entire tree instead of just the name that was in the question? This would make an ascending tree walk even for something crazy like "a.b.c.d.y.z.foo.example" extremely cheap as the cached NXDOMAIN for "foo.example" covers the entire subtree, for a caching nameserver implementing RFC 8020. Maybe this is discussed somewhere that I missed in the references. I'm happy to take a "go read this for the answer" if that's the case. Thanks, -MSK ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
