Re: [DNSOP] draft-hardaker-dnsop-must-not-sha1
So you are ready to replace SHA1 in NSEC3 and do a second algorithm renumber which is what is required to actually get rid of SHA1 or do you mean retire RSA-SHA1. People are much too imprecise in the terminology. -- Mark Andrews > On 13 Aug 2022, at 18:50, Jim Reid wrote: > > Wes, I'm all for killing SHA1. Though the mechanism might need a rethink. We > probably should have a simpler way to add/remove DNSSEC crypto algorithms. > IIRC Paul Hoffman explained the problem a year or so ago when new code points > were needed for the latest GOST algorithms: something about that could only > be done with the overkill of a Standards Track RFC. Maybe that could get > fixed and SHA1 could be its first victim? > > As for the I-D, I think it should also say validating resolvers MUST NOT use > SHA1-flavoured RRtypes for validation. ie Give SHA1 two shots to the head, > just to be sure. :-) > > ___ > 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] On ALT-TLD, GNS, and namespaces...
> On 15 Aug 2022, at 00:57, Paul Wouters wrote: > > On Aug 14, 2022, at 09:16, Stephen Farrell wrote: >> >> >> but otherwise stuff works fine even if it can sometimes be >> confusing as to how kerberos realms and DNS domains do or >> don't map to one another. > > But that’s because foo.example in DNS maps to FOO.EXAMPLE in Kerberos in most > deployments. > > let’s say I get COCA-COLA.COM, that’s quite a different situation. Then you will have a problem if you run up against anyone else using COCA-COLA.COM as a realm name. I also expect that if you are anyone other than the Coca-Cola Company and run up against the Coca-Cola Company you will be forced to rename your realm. Kerberos doesn’t have a naming authority but to use it in a federated manner there needs to be an authority. Most users of Kerberos use the DNS namespace as that authority. > We can have all the clever mappings for DNS to support alternative backend > systems, but in the end the real issue is that “issued names” in the DNS > world won’t map to alternative owners. The only way to guarantee that is to > carve out some strings. But it will be unpopular strings because the popular > ones are taken or reserved. > > Paul > > ___ > 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] [Ext] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt
Well anyone using RedHat Enterprise Linux 9 / Oracle Linux 9 already has RSASHA1 / NSEC3RSASHA1 disabled. BIND will automatically disable these algorithms as of the September releases if they are not supported by the crypto provider. So it will no longer require named.conf changes. -- Mark Andrews > On 18 Aug 2022, at 08:45, Viktor Dukhovni wrote: > > On Tue, Aug 16, 2022 at 02:55:35PM +, Paul Hoffman wrote: > >> Another way to look at this is not from all signed delegations >> anywhere, but for web sites that are most popular. Using the Tranco >> list, choosing from the top 100,000 names, 6,389 are signed; of those, >> 349 sign with algorithm 5 or 7. Thus, for the popular sites, the >> percentage is closer to 5%, not 1%. > > While I'm not impressed by the significance of the last ~900k of the > Tranco list, indeed there is some concentration of deprecated DNSSEC > algorithms closer to the top of the list, among the top 10k we see > the domains below my sig. > > How realistic is it to prod these to migrate? The DHS folks had > recently put out an RFP for managed DNS service, not only for the .GOV > registry, but also for operation of the delegated domains, and > presumably at some point many of the .GOV slowpokes might move to a > managed service with more modern keys, ... This will likely take > a couple of years (if not delayed or cancelled). > > As for the rest, not clear what would cause them to switch, and how hard > we should try. There hasn't been much downward momentum in algorithm 5 > and 7 use after the initial 93% decline at major hosting providers. > > [ Even transip.nl, who've migrated all their customers, haven't yet > migrated their own domain. Cobbler's children and all that... ] > > -- >Viktor. > > paypal.com 77 > comcast.net 145 > cdc.gov 179 > ietf.org 473 > yandex.com 548 > paloaltonetworks.com 633 > xfinity.com 646 > va.gov 650 > nist.gov 664 > service-now.com 842 > comcast.com 901 > cmu.edu 939 > uchicago.edu 991 > ed.gov 999 > uk.com 1065 > census.gov 1108 > sec.gov 1148 > senate.gov 1176 > icann.org 1333 > accenture.com 1369 > centralnic.net 1433 > archives.gov 1489 > tamu.edu 1542 > uspto.gov 1565 > treasury.gov 1584 > fcc.gov 1638 > us.com 1671 > paypal.me 1918 > pitt.edu 1998 > eu.com 2648 > hud.gov 2668 > defense.gov 2806 > mass.gov 2923 > eia.gov 2946 > federalregister.gov 2996 > cms.gov 3030 > filezilla-project.org 3168 > lsu.edu 3204 > nsf.gov 3292 > imperial.ac.uk 3434 > maryland.gov 3537 > tn.gov 3667 > transip.nl 3962 > supremecourt.gov 4113 > us.org 4305 > ky.gov 4382 > gao.gov 4583 > lbl.gov 4598 > medicare.gov 4633 > handle.net 4699 > ustc.edu.cn 4706 > paypalobjects.com 5051 > d-net.pro 5119 > healthcare.gov 5123 > consumerfinance.gov 5458 > tznic.or.tz 6065 > ru.com 6243 > planalto.gov.br 6366 > kh.edu.tw 6652 > ga.gov 6658 > uib.no 6738 > umbc.edu 6869 > hrsa.gov 7076 > k8.com.br 7217 > paypalinc.com 7314 > nrel.gov 7599 > uniregistry.info 7608 > llnl.gov 7663 > export.gov 7833 > ic.ac.uk 7890 > treas.gov 8072 > upf.edu 8217 > concordia.ca 8258 > nga.gov 8366 > in.net 8431 > nau.edu 8480 > ulisboa.pt 8650 > comcastbusiness.net 8769 > bea.gov 9250 > uscg.mil 9579 > szu.edu.cn 9745 > nsa.gov 9862 > uniregistry.net 9974 > > ___ > 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] Use of CNAMEs for NS Records
CNAMEs cannot be installed as glue which makes @ SOA . . 0 0 0 0 0 @ NS ns1 ns1 CNAME host host A 1.2.3.4 problematic. Also named refuses to follow NS records that refer to CNAMEs as they can’t be used reliably and no we are not going to try and make them work in the cases where they could potentially. Manage your delegations correctly. Named will also refuse to load a zone if it detected NS referring to a CNAME. I just wish other vendors would do the same thing. Similarly stop loading zones with CNAME at the apex, or CNAME and other data generally. Resolvers shouldn’t have to put up with that sort of garbage. Nor should resolver developers have to deal with bug reports caused by different responses depending upon cached content. STD 13 said not to allow CNAME and other data. > On 23 Aug 2022, at 23:00, Tobias Fiebig > wrote: > > Heho, >> Vladimír Čunát wrote: >> I believe that's a wrong approach in principle and risky in practice. > > Oh, i am fully with you on this one; I just try to make sure I did not miss a > development that outdated RFC2181. > > Context: I am currently dealing with academic reviewers claiming that not > using CNAMEs for NS is, quote, "[...] by the spec, [..] true, [but] also > commonly ignored in practice. This is trivial to demonstrate with a test > domain and queries against major public DNS resolvers." This statement refers > to me/'us' excluding all NS records that are CNAME instead of A/ in a > work looking at delegation issues (which is not broken delegation in > general), while citing RFC2181 Sec 10.3 as the reason for doing so. This is > what prompted me to dig into it in the first place as I will have to make an > argument why we are not considering CNAME NS as a source for potentially > successful resolution in the future. > > I would personally argue "RFC says no" still holds, and I think you already > gave me another good argument to make why exclusion of CNAME NS is valid in > our case. > > With best regards, > Tobias > > > _______ > 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] [Editorial Errata Reported] RFC8749 (7131)
The word ‘deleted’ does not appear in RFC8749. The errata makes no sense. I suggest that this errata is REJECTED. -- Mark Andrews > On 14 Sep 2022, at 06:30, RFC Errata System wrote: > > The following errata report has been submitted for RFC8749, > "Moving DNSSEC Lookaside Validation (DLV) to Historic Status". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7131 > > -- > Type: Editorial > Reported by: an > > Section: 8749 > > Original Text > - > deleted > > Corrected Text > -- > deleted one > > Notes > - > off rfc > > 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. > > -- > RFC8749 (draft-ietf-dnsop-obsolete-dlv-02) > -- > Title : Moving DNSSEC Lookaside Validation (DLV) to Historic > Status > Publication Date: March 2020 > Author(s) : W. Mekking, D. Mahoney > 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-momoka-v6ops-ipv6-only-resolver-00.txt
While we (ISC) have been working on this for years <https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/2166>, this is yet another example of why DNS64 should be made historic. This is requesting even more support to work around problems introduced by DN64, a poorly thought out, supposedly short term hack. It is NOT needed with 464XLAT, DS-Lite and other transition technologies where the IP stack maps from IPv4 to IPv6 or the CPE maps from IPv4 to IPv6. Additionally this is an indication the BCP91 is now out of date. Best current practice has been to operate dual stack servers for many years now. Mark > On 7 Oct 2022, at 16:12, Momoka Yamamoto wrote: > > Hello, > > I have submitted an informational draft that describes resolvers performing > IPv4 to IPv6 translation to send queries to IPv4-only authoritative servers. > We thought it would be beneficial to document that we can operate a resolver > with only an IPv6 address if we utilize the NAT64. > Despite that it is stated in BCP91 [RFC3901], "every recursive name server > SHOULD be either IPv4-only or dual stack." > > Since this is more related to IPv6/IPv4 translation I have submitted the > draft to the v6ops wg, > but because this is DNS related I would very much appreciate it if I could > have comments from the dnsop list as well. > > Momoka. Y > > -- Forwarded message - > From: > Date: Thu, Oct 6, 2022 at 2:17 AM > Subject: New Version Notification for > draft-momoka-v6ops-ipv6-only-resolver-00.txt > To: Momoka Yamamoto , Toyota Yasunobu > > > > > A new version of I-D, draft-momoka-v6ops-ipv6-only-resolver-00.txt > has been successfully submitted by Momoka Yamamoto and posted to the > IETF repository. > > Name: draft-momoka-v6ops-ipv6-only-resolver > Revision: 00 > Title: IPv6 only iterative resolver utilising NAT64 > Document date: 2022-10-05 > Group: Individual Submission > Pages: 9 > URL: > https://www.ietf.org/archive/id/draft-momoka-v6ops-ipv6-only-resolver-00.txt > Status: > https://datatracker.ietf.org/doc/draft-momoka-v6ops-ipv6-only-resolver/ > Html: > https://www.ietf.org/archive/id/draft-momoka-v6ops-ipv6-only-resolver-00.html > Htmlized: > https://datatracker.ietf.org/doc/html/draft-momoka-v6ops-ipv6-only-resolver > > > Abstract: >By performing IPv4 to IPv6 translation, IPv6-only iterative resolvers >can operate in an IPv6-only environment. When a specific DNS zone is >only served by an IPv4-only authoritative server, the iterative >resolver will translate the IPv4 address to IPv6 to access the >authoritative server's IPv4 address via NAT64. This mechanism allows >IPv6-only iterative resolvers to initiate communications to IPv4-only >authoritative servers. > > > > > The IETF Secretariat > > > ___ > 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] [v6ops] New Version Notification for draft-momoka-v6ops-ipv6-only-resolver-00.txt
> On 9 Oct 2022, at 04:58, Momoka Yamamoto wrote: > > > re: Mark Andrews 's comments > > this is yet another example of why DNS64 should be made historic. > > This is requesting even more support to work around problems introduced by > > DN64, a poorly thought out, supposedly short term hack. > > We did not write this draft thinking DNS64 has a problem. I didn’t think you did but it highlights the problems with DNS64. DNS64 does not work with address literals. > We thought that IPv6-only iterative resolvers not existing because of > IPv4-only authoritative servers is a problem, and wanted a way to solve it > from the resolver side and not only from the network side (e.g. using > 464XLAT). Why do you think that promoting this niche fix is better that promoting that OS’s support 464XLAT, DS-Lite at the OS level? The later fixes the issues for every application on the node. We have well specified signalling for when a node to bring up 464XLAT, MAP-E, MAP-T, DS-Lite. We should be encouraging nodes to do just that when the signalling is present. We should be encouraging CPE router vendors to support copying the signalling from the ISP side to the internal side similar to how they do with DNS recursive server signalling by default except when configured not to. If a node can’t attach to an IPv6-only network and use the transition mechanism offered without applications have to know anything about it then it is deficient. DNS servers are an application in this context. The IETF should be trying to winnow down the number of transition mechanisms that vendors need to support. Less is actually more here and unfortunately we have not done a good job of pushing back on excessive choice. Mark > On Fri, Oct 7, 2022 at 2:47 PM Mark Andrews wrote: > While we (ISC) have been working on this for years > <https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/2166>, this is > yet another example of why DNS64 should be made historic. This > is requesting even more support to work around problems introduced by DN64, a > poorly thought out, supposedly short term hack. > > It is NOT needed with 464XLAT, DS-Lite and other transition technologies > where the IP stack maps > from IPv4 to IPv6 or the CPE maps from IPv4 to IPv6. > > Additionally this is an indication the BCP91 is now out of date. Best > current practice has been > to operate dual stack servers for many years now. > > Mark > > > On 7 Oct 2022, at 16:12, Momoka Yamamoto wrote: > > > > Hello, > > > > I have submitted an informational draft that describes resolvers performing > > IPv4 to IPv6 translation to send queries to IPv4-only authoritative servers. > > We thought it would be beneficial to document that we can operate a > > resolver with only an IPv6 address if we utilize the NAT64. > > Despite that it is stated in BCP91 [RFC3901], "every recursive name server > > SHOULD be either IPv4-only or dual stack." > > > > Since this is more related to IPv6/IPv4 translation I have submitted the > > draft to the v6ops wg, > > but because this is DNS related I would very much appreciate it if I could > > have comments from the dnsop list as well. > > > > Momoka. Y > > > > -- Forwarded message - > > From: > > Date: Thu, Oct 6, 2022 at 2:17 AM > > Subject: New Version Notification for > > draft-momoka-v6ops-ipv6-only-resolver-00.txt > > To: Momoka Yamamoto , Toyota Yasunobu > > > > > > > > > > A new version of I-D, draft-momoka-v6ops-ipv6-only-resolver-00.txt > > has been successfully submitted by Momoka Yamamoto and posted to the > > IETF repository. > > > > Name: draft-momoka-v6ops-ipv6-only-resolver > > Revision: 00 > > Title: IPv6 only iterative resolver utilising NAT64 > > Document date: 2022-10-05 > > Group: Individual Submission > > Pages: 9 > > URL: > > https://www.ietf.org/archive/id/draft-momoka-v6ops-ipv6-only-resolver-00.txt > > Status: > > https://datatracker.ietf.org/doc/draft-momoka-v6ops-ipv6-only-resolver/ > > Html: > > https://www.ietf.org/archive/id/draft-momoka-v6ops-ipv6-only-resolver-00.html > > Htmlized: > > https://datatracker.ietf.org/doc/html/draft-momoka-v6ops-ipv6-only-resolver > > > > > > Abstract: > >By performing IPv4 to IPv6 translation, IPv6-only iterative resolvers > >can operate in an IPv6-only environment. When a specific DNS zone is > >only served by an IPv4-only authoritative server, the iterative > >resolver will transla
Re: [DNSOP] [BEHAVE] [v6ops] New Version Notification for draft-momoka-v6ops-ipv6-only-resolver-00.txt
> On 17 Oct 2022, at 08:57, Geoff Huston wrote: > > > >> On 17 Oct 2022, at 7:53 am, Michael Richardson wrote: >> I think that's because >> recursive nameserves effectively have always done an equivalent to "happy >> eyeballs", so the risk is low. >> > > > That certainly was not the case in 2015: > https://www.potaroo.net/presentations/2015-10-04-dns-dual-stack.pdf > > I have not seen a large scale measurement since then but I suspect that > nothing has changed. i.e.: > recursive resolvers do not do the equivalent of happy eyeballs behaviour. BIND doesn’t race queries but it does bias the selection of IPv6 servers over IPv4 servers. This went into BIND 9.11.0. The CHANGES note was dated 2015-09-28. 4222. [func] Bias IPv6 servers when selecting the next server to query. [RT #40836] -- 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
[DNSOP] .alt filtering in recursive servers
Filtering .alt in recursive servers should be a MUST NOT. Mirror zones (copies of the root zone) and aggressive negative caching will reduce the traffic to the root and not break downstream validating clients. AS112 is not needed. -- 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] .alt filtering in recursive servers
> On 8 Nov 2022, at 10:56, Peter Thomassen wrote: > > > > On 11/8/22 10:33, Mark Andrews wrote: >> Filtering .alt in recursive servers should be a MUST NOT. > > Whenever SHOULD or MUST (NOT) is used, or we're making a promise for the > indefinite future, or we're (in the case of NXDOMAIN synthesis) altering > behavior from the client's perspective (by precluding a DoE from the root), > then the document should be on Standards Track, not Informational. I was saying “do not do anything special” in recursive servers for .alt. A modern recursive server does QNAME minimisation. It may be doing NXDOMAIN means NXDOMAIN (in BIND this is qname-minimisation strict). It does DNSSEC validation. It does aggressive negative caching. It may be configured as a mirror for the root zone. When you query for alt you get enough information in the response from the root with aggressive negative caching to answer every other query for *.alt for 10800 seconds. % dig +dnssec alt ; <<>> DiG 9.19.6-dev <<>> +dnssec alt ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8597 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; COOKIE: 39041e1bfde7b212facacc52636a39c4ff7818022e6dc01e (good) ;; QUESTION SECTION: ;alt. IN A ;; AUTHORITY SECTION: . 10800 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2022110800 1800 900 604800 86400 . 10800 IN RRSIG SOA 8 0 86400 2022112105 2022110804 18733 . AS0aswPnUf8/YdZE/Xeub17fLCWmp/OJXvqrH1+qcYN4WD0TV6mVS1Uc mrTeVGp52anSqxkzxfUQaPyiF1Clxnx1wGtncsNkDJpKX9fPdbMmMsk+ wm/URiOpwzCQC7nlcUESraWo5WW4Z1olGWMLK7mBA260GT/FmZq5wVtv 9WRKmyZGTPz6ETG9wb1k2WXstLUWuB/snlcyi7VZHpCvcOdK1ebiPkET BJY/0FMeWpEncR5KsK27mNTyXucjic04jj9h8LOew+SwA32LWKZg5cgn XT3Pssj1imKEUcSIM2Dl3I/G0z4FOYhvImqDkbiYEWVkB+OoAr9RvKGs T5cv8g== . 10800 IN RRSIG NSEC 8 0 86400 2022112105 2022110804 18733 . lG9D6KVTMh09Iu7SWWR+c2b8bOyi5xe+6PoD9u0kBOMOa0SdS4/Tm9z0 nRM1dV2zc1bdYHLSyOyb5CmdCvYO0dxpLPxpJIXope/cxDwUZaOG3zq/ kPqgBGTjJZSddFYYuSPxXhjBpoF1YFy3PzjfFMS0QytIX+pmbqvqTtg+ vgFr1sZHr8COiWcNQ2MYMqN81+nKmGyX9oCXFJO9bASXEfaSDCJf5979 Pg8yXWBrNpA+IoFbplkJhnqi+ApSmjH4t19xgh49kxbusm8GZImGimH9 QLFlpbUZ6yP1R/gOwMxkKfjfFyScvzWmuI4viFSKOZFlRXGF7xSKeBpy OHCgWg== . 10800 IN NSECaaa. NS SOA RRSIG NSEC DNSKEY alstom. 10800 IN RRSIG NSEC 8 1 86400 2022112105 2022110804 18733 . WORaA7GTkm3H7nB4x+32UfhmgxelNotpoVBf95eV1QptzGBTZiFebDz2 /aYogXYhV7gd1w9hAZjOW2qtsISR21qD9zTyHoG7JUty21UQfkLrm5QX 8X2EtVxD9+CmrI/+bJ2p91gEpEGvIcA6uslBKAoNuXFF6xZ/OqdtyIuV xYnJuYJHoFqC1rEk/ZbjS49UraLNpgkvPZGPpAVVzsussItT7lC2SECf WBOiY3ElxotTvD18rkn6EhQasuxiVxUP2uUiTxlJWYui4O6c6D37BuGL iXZoLOfRztesm+ISptOM+soTutN1NxHQZnXsoRYYTSOWhB0lsEQWSNBp IOJckw== alstom. 10800 IN NSECam. NS DS RRSIG NSEC ;; Query time: 190 msec ;; SERVER: 2001:67c:370:229::7#53(2001:67c:370:229::7) (UDP) ;; WHEN: Tue Nov 08 11:13:08 WET 2022 ;; MSG SIZE rcvd: 1049 % The alternative is that the recursive server maps ‘whatever.alt/QTYPE’ to ‘alt/DS’ when iterating then returns the result of that query to the client with the original QNAME and QTYPE. It can use the cached result of ‘alt/DS’ until it times out. > ~Peter > > -- > https://desec.io/ > > _______ > 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] .alt filtering in recursive servers
> On 11 Nov 2022, at 09:48, Wessels, Duane > wrote: > > I find the latest alt-tld draft to be inconsistent when it first > says “[alt names] should not be looked up in a DNS context” and > "DNS stub and recursive resolvers do not need to look them up in > the DNS context” but then later "Caching DNS servers will treat > [alt names] just as they would any other name whose TLD does not > appear in the global DNS root.” Since caching servers lookup names > with non existent TLDs in the DNS, then of course alt names will > also be looked up in the DNS context. > > I'm also struck how radically different the special use considerations > for .onion (RFC 7868) and .alt are. onion has multiple MUST-level > requirements for not leaking queries into the global DNS. > > IMO we should write requirements to describe the behavior we want. > Even though we know from experience that not all implementations > will adhere to the requirements it is appropriate to say that alt names > MUST NOT or (at least SHOULD NOT) not leak. > > And even if we don't end up with strong anti-leaking requirements, > then we should at least openly acknowledge that leaked queries > will happen (i.e., to root name servers). > > Lastly, I'd like to see the special use considerations for .alt > formatted more like the examples given in that RFC 6761 and the one > in RFC 7686. > > I’d like to propose this new/updated text for the alt-tld draft: > > == > > 1. Users: Human users might or might not recognize that names > in the .alt pseudo-TLD are special. > > 2. Application Software: Applications that use alternative > namespaces in .alt MUST have their own processing > rules for their own names, probably in specialized resolver > APIs, libraries, and/or application software. > > 3. Name Resolution APIs and Libraries: Resolvers MUST NOT resolve > .alt names in a DNS context. They MAY respond to > queries for such names with NXDOMAIN. > > 4. Caching DNS Servers: Caching servers MUST [or SHOULD] NOT > attempt to resolve .alt names in the global DNS root. They > MAY respond to queries for such names with NXDOMAIN [or > REFUSED?]. Caching servers MUST NOT intercept DO=1 queries as the client will not be able to validate such responses. The caching recursive server MAY synthesise a provable NXDOMAIN response as per RFC 8198. Caching servers SHOULD perform QNAME minimisation as per RFC 7816 for the .alt namespace by default. Querying for alt/DS or alt/NS will achieve this without leaking the query type. > 5. Authoritative DNS Servers: Authoritative servers MUST respond to > queries for .alt names with NXDOMAIN. > > 6. DNS Server Operators: Operators MUST NOT configure an > authoritative DNS server to answer queries for .alt. > > 7. DNS Registries/Registrars: Registries and Registrars MUST > NOT register .alt names because .alt will not exist in the > global DNS root. All such requests MUST be denied. > > Note that despite the requirements given here, it is generally expected > that queries for .alt names will "leak" into the global DNS. The root > name servers [RFC 7720?] will receive leaked queries and respond with > NXDOMAIN. Techniques such as qname minimization, aggressive NSEC caching, > and root-on-loopback can reduce the amount of leaked queries received by > root name servers. > > == > > DW > > > ___ > 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] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-00)
> On 30 Nov 2022, at 00:07, Joe Abley wrote: > > On Tuesday, November 29th, 2022 at 13:37, Peter Thomassen > wrote: > >> At the IETF a few weeks back, Johan and I felt a sudden >> enlightenment when it occurred to us that the same approach >> could be used to reduce scanning cost for CDS/CSYNC scans and >> the like, while maintaining low update latency. In fact, the >> NOTIFY spec already does allow sending NOTIFY message of other >> types. So, we not use that for hinting beyond SOA? > > I have wondered aloud about reusing NOTIFY for other purposes in the past > too. In fact I seem to remember a certain tall Swede referring to > draft-jabley-dnsop-dns-flush as abolutely the worst idea he had ever heard > of, a review which I continue to wear as a badge of pride. > > One question occurs to me after reading your draft: you suggest in a couple > of places that it's easy for a nameserver that is authoritative for a child > zone to know the name of the parent zone. How? > > For example, if a nameserver serves the zone a.b.c.d.child, how does it > determine whether the parent zone is the root, a, a.b, a.b.c or a.b.c.d? It > needs to know in order to find the SRV (or whatever) records that point to > the appropriate NOTIFY targets in the case where the parent zone operator > signals the target. Does it send multiple queries? Does it confirm the > existence of a zone cut in each case by looking for secure delegations or SOA > RRs or both? It seems important to get this right. Remove the left most label and query for the SOA record. If you get a SOA record back in the answer you have the parent zone. If you get a CNAME back remove one more label and repeat. If you get a NODATA response look in the authority section for the negative cache SOA record. If it is not present remove one label and repeat. nsupdate has been doing this for 2 decades now to determine the enclosing zone for UPDATE requests. There is absolutely no reason why authoritative servers can’t make such queries all by themselves. They already make queries to obtain the address of nameservers to determine where to send NOTIFY messages. > Separately, it might be worth specifying that all NOTIFY targets obtained > through the DNS MUST be subject to DNSSEC validation and that the DNS > responses involved must be verifiably secure. I can't immediately think of an > exploit that would derive from the ability for a third party to receive such > NOTIFY messages but it seems entirely plausible that there is one. > > In the case of conventional use of NOTIFY it's common for the NOTIFY/*XFR > graph to involve servers other than those published in NS sets. In some cases > it is desirable for the identity of those NOTIFY targets not to be published, > e.g. since they refer to internal infrastructure and are not intended to be > used/abused by others. Have you thought about whether there are any similar > considerations for these new uses of NOTIFY? I guess one answer is that (just > like conventional NOTIFY) local policy could override the SRV-published > (NS-published) targets. > > > Joe > > ___ > 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] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-00)
If we are going to send NOTIFY messages just send signed UPDATE messages. I described how to do this securely about a decade ago now. https://datatracker.ietf.org/doc/html/draft-andrews-dnsop-update-parent-zones-04 NOTIFY messages are just going to have to be relayed to the registrar in exactly the same way as UPDATE messages needed to be relayed to the registrar in the above draft. The registrar still performs the EPP update. > On 29 Nov 2022, at 23:37, Peter Thomassen wrote: > > Dear DNSOP, > > Changes in CDS/CDNSKEY, CSYNC, and other records related to delegation > maintenance are usually detected through scheduled scans run by the consuming > party (e.g. top-level domain registry), incurring an uncomfortable trade-off > between scanning cost and update latency. > > A similar problem exists when scheduling zone transfers, where it has been > solved using the well-known DNS NOTIFY mechanism ([RFC1996]) which enables > primaries to nudge secondaries when there's a zone update, allowing the > latter to initiate an out-of-order zone transfer and reset the serial check > timer. > > At the IETF a few weeks back, Johan and I felt a sudden enlightenment when it > occurred to us that the same approach could be used to reduce scanning cost > for CDS/CSYNC scans and the like, while maintaining low update latency. In > fact, the NOTIFY spec already does allow sending NOTIFY message of other > types. So, we not use that for hinting beyond SOA? > > We wrote up a draft, and if you'd like to read how one could make this work, > feel free to take a look: > --> > https://datatracker.ietf.org/doc/draft-thomassen-dnsop-generalized-dns-notify/ > > There is also an application in multi-signer setups, where Viktor had brought > up the problem of ZSK rollovers by one signer, and how the others would know > about that. That's not as well fleshed-out yet, but we figured it shouldn't > keep us from circulating the initial idea. > > Best, > Peter > > > Forwarded Message > Subject: New Version Notification for > draft-thomassen-dnsop-generalized-dns-notify-00.txt > Date: Mon, 28 Nov 2022 13:10:10 -0800 > From: internet-dra...@ietf.org > To: Johan Stenstam , Peter Thomassen > > > > A new version of I-D, draft-thomassen-dnsop-generalized-dns-notify-00.txt > has been successfully submitted by Peter Thomassen and posted to the > IETF repository. > > Name: draft-thomassen-dnsop-generalized-dns-notify > Revision: 00 > Title:Generalized DNS Notifications > Document date:2022-11-28 > Group:Individual Submission > Pages:13 > URL: > https://www.ietf.org/archive/id/draft-thomassen-dnsop-generalized-dns-notify-00.txt > Status: > https://datatracker.ietf.org/doc/draft-thomassen-dnsop-generalized-dns-notify/ > Html: > https://www.ietf.org/archive/id/draft-thomassen-dnsop-generalized-dns-notify-00.html > Htmlized: > https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-generalized-dns-notify > > > Abstract: > Changes in CDS/CDNSKEY, CSYNC, and other records related to > delegation maintenance are usually detected through scheduled scans > run by the consuming party (e.g. top-level domain registry), > incurring an uncomfortable trade-off between scanning cost and update > latency. > > A similar problem exists when scheduling zone transfers, and has been > solved using the well-known DNS NOTIFY mechanism ([RFC1996]). This > mechanism enables a primary nameserver to proactively inform > secondaries about zone changes, allowing the secondary to initiate an > ad-hoc transfer independently of when the next SOA check would be > due. > > This document extends the use of DNS NOTIFY beyond conventional zone > transfer hints, bringing the benefits of ad-hoc notifications to DNS > delegation maintenance in general. Use cases include DNSSEC key > rollovers hints via NOTIFY(CDS) and NOTIFY(DNSKEY), and quicker > changes to a delegation's NS record set via NOTIFY(CSYNC). > > TO BE REMOVED: This document is being collaborated on in Github at: > https://github.com/peterthomassen/draft-thomassen-dnsop-generalized- > dns-notify (https://github.com/peterthomassen/draft-thomassen-dnsop- > generalized-dns-notify). The most recent working version of the > document, open issues, etc. should all be available there. The > authors (gratefully) accept pull requests. > > > > > The IETF Secretariat > > > __
Re: [DNSOP] I-D Action: draft-homburg-dnsop-codcp-00.txt
> On 12 Jan 2023, at 00:26, Philip Homburg wrote: > > In your letter dated Tue, 10 Jan 2023 11:33:57 -0500 (EST) you wrote: >>> However, such a setup leaves the application with no control over >>> which transport the proxy uses. >> >> Why should the application have control over this? > > The following is just a thought, I didn't implement it. > > With local DNS proxies that use encrypted transports there can be a bit of > a bootstrap problem is a system boots without any sense of the current time. Or DNSSEC is is use. > What might happen is that a NTP client tries to lookup pool.ntp.org. If > DNS resolution goes through a proxy that tries to use an encrypted transport, > then the proxy may fail because the time is wrong. The NTP client doesn't > get any answers so it can't set the clock and the system doesn't boot. > > In that case, if the NTP client would request DNS resolution over Do53 for > its initinal lookup of pool.ntp.org, then the proxy can return a DNS reply > and the system can boot normally. > > > _______ > 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] QDCOUNT > 1 (a modest proposal)
Additionally it was predicated on caches not having the concept of a negative cache "The difficulty is that the presence of one RR type in a cache doesn't convey any information about the other because the query which acquired the cached information might have used a QTYPE of MF, MD, or MAILA (which matched both).” We have negative caches today. It’s also not like we don’t know how to signal that QDCOUNT > 1 is not supported (return FORMERR) or signal that it is supported (e.g. EDNS=1). The hardest thing is the broken servers that don’t return FORMERR correctly making it hard to determine what they actually support. Clients can retry with individual queries if they get FORMERR returned. The only part of RFC 1035 that actually mentions a value is 4.1.2 and no it doesn’t prohibit other values. "4.1.2. Question section format The question section is used to carry the "question" in most queries, i.e., the parameters that define what is being asked. The section contains QDCOUNT (usually 1) entries, each of the following format: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / QNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QTYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QCLASS| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: QNAME a domain name represented as a sequence of labels, where each label consists of a length octet followed by that number of octets. The domain name terminates with the zero length octet for the null label of the root. Note that this field may be an odd number of octets; no padding is used. QTYPE a two octet code which specifies the type of the query. The values for this field include all codes valid for a TYPE field, together with some more general codes which can match more than one type of RR. QCLASS a two octet code that specifies the class of the query. For example, the QCLASS field is IN for the Internet." > On 16 Feb 2023, at 14:08, Ted Lemon wrote: > > Again, it does not say that explicitly. Your interpretation is valid but not > the only possible reading of the test you quoted. It’s certainly not how I > read it. > > On Wed, 15 Feb 2023 at 20:33, Masataka Ohta > wrote: > Ted Lemon wrote: > > > I'm not seeing the place in RFC 1034 where it explicitly specifics any > > value at all for QDCOUNT. Can you point to it? > > See my second mail of the thread. > > Masataka Ohta > ___ > 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] QDCOUNT > 1 (a modest proposal)
It advises against a new QTYPE that returns multiples types and gives the reasoning behind the decision. That is not the same as prohibiting QDCOUNT > 1. > On 16 Feb 2023, at 15:27, Masataka Ohta > wrote: > > Ted Lemon wrote: > >> Again, it does not say that explicitly. > > Wrong. > > Masataka Ohta > > ___ > 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] QDCOUNT > 1 (a modest proposal)
> On 16 Feb 2023, at 15:40, Masataka Ohta > wrote: > > Mark Andrews wrote: > >> The only part of RFC 1035 that actually mentions a value is 4.1.2 and no >> it doesn’t prohibit other values. > > No, of course. See my second mail of the thread. > > Masataka Ohta Your second message describes a standard query. > 1034: > >3.7.1. Standard queries > >A standard query specifies a target domain name (QNAME), query type >(QTYPE), and query class (QCLASS) and asks for RRs which match. > > which *DID* not preclude inverse queries with QDCOUNT=0 and responses > to them with QDCOUNT>1 as is stated in 1035: > >When the response to an inverse query contains one or more QNAMEs, > > Anyway, w.r.t. letency, it is meaningless to have standard > queries with QDCOUNT>1. > > Masataka Ohta It does not prohibit extended query forms be they a different QDCOUNT for QUERY, a new opcode which supports multiple queries. If the server only support standard queries for opcode QUERY and receives a request with QDCOUNT != 1 there are error codes in STD13 to indicate that the request is not understood. Mark -- 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] I-D Action: draft-ietf-dnsop-domain-verification-techniques-01.txt
Did you really intend to make the message hard to read? Really "font-size:small”? Really grey instead of black "color:#33”? Please fix your MUA settings or choose a different MUA that actually has sane settings. Hi folks, we (finally) pu= blished a new version of the domain verification techniques draft, now as i= ntended-BCP. We've had some feedback from providers but would love for = folks=C2=A0to review, especially people who would actually use it.On = Thu, 16 Feb 2023 at 11:15, <mailto:internet-dra...@ietf.org";>= internet-dra...@ietf.org> wrote: > On 17 Feb 2023, at 06:20, Shivan Kaul Sahib wrote: > > Hi folks, we (finally) published a new version of the domain verification > techniques draft, now as intended-BCP. We've had some feedback from providers > but would love for folks to review, especially people who would actually use > it. > > On Thu, 16 Feb 2023 at 11:15, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the IETF. > > Title : Domain Verification Techniques using DNS > Authors : Shivan Sahib > Shumon Huque > Paul Wouters > Filename: draft-ietf-dnsop-domain-verification-techniques-01.txt > Pages : 11 > Date: 2023-02-16 > > Abstract: >Many services on the Internet need to verify ownership or control of >a domain in the Domain Name System (DNS). This verification is often >done by requesting a specific DNS record to be visible in the domain. >There are a variety of techniques in use today, with different pros >and cons. This document proposes some practices to avoid known >problems. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-dnsop-domain-verification-techniques-01.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-domain-verification-techniques-01 > > > 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 > ___ > 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] Updated: Compact Denial of Existence
> On 6 Mar 2023, at 04:20, Peter Thomassen wrote:
>
> 2.) As for the "NXNAME" rrtype, I'd like to propose using rrtype 0 (the NULL
> type). So far it only has meaning for "type covered" fields in signature
> records such as SIG(0) (RFC 2931). There appears to be no collision with
> usage in the NSEC type bitmap, and IMHO it appears to be a very natural meta
> type fit. ("This is NULL, There Really Is Nothing Underneath.")
NULL is type 10. This was assigned in RFC 1035.
--
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] Updated: Compact Denial of Existence
> On 8 Mar 2023, at 11:16, Evan Hunt wrote: > > On Tue, Mar 07, 2023 at 11:15:55AM +0100, Peter Thomassen wrote: >> Oops, touché! I stand corrected. Thanks, Mark. >> >> What I meant is rrtype 0. I used the wrong mnemonic.* > > IMHO, you're almost definitely correct that NULL (type 10) would be safe to > use for this. Type 0, thought, would not - it's used internally by name > servers in ways that could be pretty difficult to untangle. NULL would also be difficult to use as they can exist in the wild. > I would lean toward using a newly allocated type code, though, because I'm > 100% sure that wouldn't cause any conflict with existing implementations, > and I'm only 99.7% sure that NULL wouldn't. > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. -- 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] Updated: Compact Denial of Existence
John it won’t work with chained validators. -- Mark Andrews > On 15 Mar 2023, at 07:59, John Levine wrote: > > It appears that Peter Thomassen said: >> So I take it that when the EDNS signal is there, compact DoE responses get >> an NXDOMAIN code. >> >> In case the EDNS flag is not set, does the nameserver return (a) the compact >> proof (with sentinel in >> the type map) is sent, but with a NOERROR code, or (b) a classical proof (no >> sentinel), but with an >> NXDOMAIN code? > > It would return a RFC 4470 white lie, which does the same thing but is > larger since it needs two NSEC and two RRSIG records, one for the name > and one to show there's no wildcard. > > I wouldn't try to get any more clever. Just use an EDNS0 code in the > query to say compact results are OK. I'd like to use the same code to > say this result is really NXDOMAIN, but those aren't signed, so I > think we do need to assign a metatype to go in the signed NSEC. > > R's, > John > > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Meet the Root Zone Algorithm Rollover Design Team @ IETF 116
Is this JST? > On 28 Mar 2023, at 11:15, James Mitchell wrote: > > Hello, > The Root Zone Algorithm Rollover Study Design Team is hosting a public > session at IETF 116 and invites you to join. > Date: 29 March, 13:00 – 14:00 > Room: G301 > Remote: > https://icann.zoom.us/j/94974160556?pwd=eUdOVUFUWi9yZ3FtVVFrbTFJWDFmUT09 > [icann.zoom.us] > The team's goal is to develop a plan for changing the cryptographic > algorithm used for the DNS root key signing and zone signing keys. The team > has been meeting since early 2023 and many members are here at the IETF to > progress this work. We’ll share an update on the progress and challenges that > we face. We look forward to your questions and insight. > Don’t worry if you are unable to make the session; the plan will be put to > public comment. Follow the ksk-rollover mailing list for updates and > announcements. > Thanks, > James Mitchell > IANA > ___ > 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] Meaning of lame delegation
> On 7 Apr 2023, at 07:13, Havard Eidnes wrote: > >> What I'm trying to suggest (resolver perspective), is that >> questions of responsibility, ... are not something a resolver >> can or should attempt to determine. All one can attempt to do >> is classify query responses. > > Yes, I agree, as far as a recursive resolver is concerned. > > However, talking about a "delegation being lame" also revolves > around the domain owner responsibilities, but have the "resolver- > detected" behaviour as background. > >>> Hmm, in the response to >>> >>> dig @ns4.bpldns.com. lzd.jshsos.ksyunv5.com. >>> >>> I think the only real problem is the absence of the "aa" flag in the >>> response, especially since you get it in the response to >>> >>> dig @ns4.bpldns.com. lzd.jshsos.ksyunv5.com. a >> >> Well, one would, in fact, expect a delegation to be a non-authoritative >> answer: > > Yes, but one would presume that before any of the two above > queries were sent, the recursive resolver already have cached the > delegation for jshsos.ksyunv5.com. > > Therefore, posting a question about a name in that zone to one of > the name servers supposedly serving that zone would be expected > to elicit an authoritative response, and not a non-authoritative > delegation response. Therefore, in this instance, the "lameness" > would apparently depend on the queried-for RR type -- the "A" > query response looks ~fine (save for the EDNS0 mis-handling), > while the "", "NS" or "SOA" ones do not. This sort of behaviour happens when you have a front end (load balancer) that intercepts some queries and answers them but leaves the rest of the queries to a complete nameserver that is not configured to serve the zones that where delegated to it. This is almost certainly a misconfigured F5 box. The backend is serving ksyunv5.com <http://ksyunv5.com/>. There is a good chance that the backend is running BIND but it could be any full implementation. It needed to have been configured to serve jshsos.ksyunv5.com <http://jshsos.ksyunv5.com/> as that is the delegation that was followed to reach it. In this case the parent and child are operated by the same entity. Yes, we (ISC) have complained many times to F5 about this broken behaviour. >>> This smells of a "roll your own" DNS name server implementation which >>> doesn't even correctly implement the required minimum of the DNS >>> standards. >>> >>> Clearly, the name lzd.jshsos.ksyunv5.com exists in the DNS name space >>> (ref. the "a" response), and the name server being queried here should >>> obviously be authoritative for the jshsos.ksyunv5.com zone, so the >>> "aa" flag should be set in the reply to the "" query. >> >> Definitely, but that's extrinsic knowledge that the resolver can't infer >> from just the current query response. > > Well, yes and no, ref. above -- the resolver should already have > the knowledge about the supposed name servers for the zone via > the actual delegation from the parent zone, and getting a non-AA > response from one of the delegated-to name servers would indicate > a problem, and would in my book earn the "lame" label. > >>> If I'm not terribly mistaken, this sort of mis-behaviour is all too >>> common among the CDN crowd, and I dearly wish we could stomp it out. >> >> Shall we? Please lead the way! > > A couple of questions: Do we have a spec of what a minimally > conformant publishing name server needs to implement? Yes. STD 13 (RFC 1034 and RFC 1035). RFC 1033 should also be read. Those 3 RFCs where designed to be read together. Part of the problem is that F5 isn’t trying to produce minimal nameserver. They are producing a box that intercepts queries and punts the rest to a box that does implement a full nameserver and when there is a configuration error you get answers like that. Now RFC 1033 has "COMPLAINTS These are the suggested steps you should take if you are having problems that you believe are caused by someone else's name server: 1. Complain privately to the responsible person for the domain. You can find their mailing address in the SOA record for the domain. 2. Complain publicly to the responsible person for the domain. 3. Ask the NIC for the administrative person responsible for the domain. Complain. You can also find domain contacts on the NIC in the file NETINFO:DOMAIN-CONTACTS.TXT 4. Complain to the parent domain authorities. 5. Ask the parent authorities to excommunicate the domain.” As an in
Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue
the trade-off remains >>>> unclear. >>> >>> >>> I would support this as well. >>> >>> In my anecdotal experience as an operator, I routinely encounter mismatches >>> in sibling glue and child zone NS sets that appear to be due to the glue >>> being forgotten. My assumption is that, because it's not necessary to >>> operate, when operators fail to update it they don't receive any kind of >>> signal that something is wrong. >>> >>> Viktor's numbers are pretty clear data, though, so nobody should need my >>> anecdotes to be convinced. While sibling glue may be a useful optimisation >>> in some cases, given how poorly maintained it is it seems to cause more >>> problems than it solves. >>> >> >> I'd like to remind folks that the scope of this draft when it was adopted by >> the working group was very narrow. Mainly to say that 'required' glue must >> set TC=1 if it doesn't fit into the DNS response payload. That required >> talking about other types of non-mandatory glue like sibling, but has not >> proposed to change authoritative server behavior in those areas. >> >> If folks want to deprecate sibling glue entirely, it would be best to write >> another draft saying that and see if we can get consensus on that. >> >> Shumon. >> >> ___ >> 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 -- 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] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue
Somehow saying MUST include a SOA record in the negative response isn’t enough. 3 - Negative Answers from Authoritative Servers Name servers authoritative for a zone MUST include the SOA record of the zone in the authority section of the response when reporting an NXDOMAIN or indicating that no data of the requested type exists. This is required so that the response may be cached. The TTL of this record is set from the minimum of the MINIMUM field of the SOA record and the TTL of the SOA itself, and indicates how long a resolver may cache the negative answer. The TTL SIG record associated with the SOA record should also be trimmed in line with the SOA's TTL. If the containing zone is signed [RFC2065] the SOA and appropriate NXT and SIG records MUST be added. 6 - Negative answers from the cache When a server, in answering a query, encounters a cached negative response it MUST add the cached SOA record to the authority section of the response with the TTL decremented by the amount of time it was stored in the cache. This allows the NXDOMAIN / NODATA response to time out correctly. > On 15 Apr 2023, at 10:48, Puneet Sood wrote: > > Also the following section (2.2.1 - Special Handling of No Data) > suggests sending type 2 instead of type 1 responses but is silent > about type 3 responses. > > On Fri, Apr 14, 2023 at 8:46 PM Puneet Sood wrote: >> >> On Fri, Apr 14, 2023 at 8:26 PM Mark Andrews wrote: >>> >>> RFC 2038 already says add the SOA so negative answers can be cached. The >>> other responses >>> where to show what was out there so that they where not misinterpreted. >> I believe you are referring to this sentence? Quote: "The authority >> section will contain an SOA record, or there will be no NS records >> there." >> >> That is not how I interpreted those lines. My understanding of the >> part after the "or" is that a response with an empty ANSWER and AUTH >> section also indicates NODATA (as confirmed by response type 3). >> >>> I doubt saying >>> don’t do those old forms will make any difference. Everything out there >>> has had 25 years >>> to comply. >> I understand updating the specs by itself does not fix compliance. >> However clarifying that "or" would be useful. >> >>> >>>> On 15 Apr 2023, at 09:06, Puneet Sood >>>> wrote: >>>> >>>> On the topic of authoritative server behavior as seen in the DNS >>>> responses, a few areas for improvement below (not touching DNSSEC). >>>> This is written from the perspective of a resolver using the auth >>>> responses to answer user queries. >>>> >>>> * responding correctly to requests with certain flags, EDNS options. >>>> This is covered well by RFC 8906. Now we wait for compliance. >>>> >>>> * proper glue >>>> This I-D clarifies the need to supply *all the glue* and to set TC=1 >>>> correctly. Improve the specification for what to do with sibling or >>>> cyclic glue. Ideally recommend against publishing and/or depending on >>>> cyclic, sibling glue. >>>> >>>> * NODATA responses >>>> RFC 2308 section 2.2 - No Data >>>> [https://www.rfc-editor.org/rfc/rfc2308#section-2.2] describes three >>>> different ways an NS response could indicate NODATA. Types 1 and 2 >>>> include a SOA record which is helpful in determining TTLs and start of >>>> the zone cut (this matters when the same auth server is authoritative >>>> for consecutive labels in a qname). Type 3 with no SOA while usable by >>>> resolvers is not very helpful. >>>> >>>> Tightening of the specification to require type 1 or 2 responses for >>>> NODATA will be beneficial (drop type 3). >>>> >>>> In addition two additional types of responses appear to show up in the >>>> wild. Tightening the spec likely won't help here. >>>> Type 4. SOA in Answer section >>>> Non-compliant but a resolver can kind of figure this out and use it to >>>> generate a NODATA answer. >>>> >>>> Implementation note: Viktor has done work on this topic so we should >>>> have some data to share in a few weeks. >>>> >>>> Type 5. NS RRs for the zone in question (no SOA) (type 1 w/o the SOA :() >>>> Generally treated as LAME. >>>> >>>> Questions for the working group: >>>> Is there interest in updating existing specifications around glue and >>>> NODATA responses? >>&
Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue
At this stage I think the only way to force this is to drop negative responses without SOA records present. To have the lookups fail and that requires buy in by the large recursive server operators. Similarly add an unknown EDNS option (pick a value between 1000 and 1999) to every QUERY until 1 Jan 2025 and if it comes back FORMERR with an OPT record present, drop the response. 10 years after cleaning up the EDNS specification we still have .5% of servers not updated. BIND is effectively doing this with DNS COOKIE but it is painful when people say “but the lookup works with large recursive server”. > On 15 Apr 2023, at 11:01, Mark Andrews wrote: > > Somehow saying MUST include a SOA record in the negative response > isn’t enough. > > 3 - Negative Answers from Authoritative Servers > > Name servers authoritative for a zone MUST include the SOA record of > the zone in the authority section of the response when reporting an > NXDOMAIN or indicating that no data of the requested type exists. > This is required so that the response may be cached. The TTL of this > record is set from the minimum of the MINIMUM field of the SOA record > and the TTL of the SOA itself, and indicates how long a resolver may > cache the negative answer. The TTL SIG record associated with the > SOA record should also be trimmed in line with the SOA's TTL. > > If the containing zone is signed [RFC2065] the SOA and appropriate > NXT and SIG records MUST be added. > > 6 - Negative answers from the cache > > When a server, in answering a query, encounters a cached negative > response it MUST add the cached SOA record to the authority section > of the response with the TTL decremented by the amount of time it was > stored in the cache. This allows the NXDOMAIN / NODATA response to > time out correctly. > >> On 15 Apr 2023, at 10:48, Puneet Sood wrote: >> >> Also the following section (2.2.1 - Special Handling of No Data) >> suggests sending type 2 instead of type 1 responses but is silent >> about type 3 responses. >> >> On Fri, Apr 14, 2023 at 8:46 PM Puneet Sood wrote: >>> >>> On Fri, Apr 14, 2023 at 8:26 PM Mark Andrews wrote: >>>> >>>> RFC 2038 already says add the SOA so negative answers can be cached. The >>>> other responses >>>> where to show what was out there so that they where not misinterpreted. >>> I believe you are referring to this sentence? Quote: "The authority >>> section will contain an SOA record, or there will be no NS records >>> there." >>> >>> That is not how I interpreted those lines. My understanding of the >>> part after the "or" is that a response with an empty ANSWER and AUTH >>> section also indicates NODATA (as confirmed by response type 3). >>> >>>> I doubt saying >>>> don’t do those old forms will make any difference. Everything out there >>>> has had 25 years >>>> to comply. >>> I understand updating the specs by itself does not fix compliance. >>> However clarifying that "or" would be useful. >>> >>>> >>>>> On 15 Apr 2023, at 09:06, Puneet Sood >>>>> wrote: >>>>> >>>>> On the topic of authoritative server behavior as seen in the DNS >>>>> responses, a few areas for improvement below (not touching DNSSEC). >>>>> This is written from the perspective of a resolver using the auth >>>>> responses to answer user queries. >>>>> >>>>> * responding correctly to requests with certain flags, EDNS options. >>>>> This is covered well by RFC 8906. Now we wait for compliance. >>>>> >>>>> * proper glue >>>>> This I-D clarifies the need to supply *all the glue* and to set TC=1 >>>>> correctly. Improve the specification for what to do with sibling or >>>>> cyclic glue. Ideally recommend against publishing and/or depending on >>>>> cyclic, sibling glue. >>>>> >>>>> * NODATA responses >>>>> RFC 2308 section 2.2 - No Data >>>>> [https://www.rfc-editor.org/rfc/rfc2308#section-2.2] describes three >>>>> different ways an NS response could indicate NODATA. Types 1 and 2 >>>>> include a SOA record which is helpful in determining TTLs and start of >>>>> the zone cut (this matters when the same auth server is authoritative >>>>> for consecutive labels in a qname). Type 3 with no SOA while usable by >>>>> resolvers is not very helpful. >>>>
Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition
> On 5 May 2023, at 03:01, Warren Kumari wrote: > > > > > > On Thu, May 04, 2023 at 5:07 AM, Mark Delany wrote: > On 03May23, Edward Lewis apparently wrote: > Was any "lame" situation defined which wasn't the result of a bad > configuration? > The difference between observing a symptom and diagnosing a cause is great. I > say this to caution against tying the "why it is" with > "what it is." > This is a good point. > I confess my perspective is that of the DNS admin/serving side focussed on > "why it is" whereas lameness is most often observed as a "what it is" from > the resolution/client-side perspective. To use your useful terms. > I have one last question. Regardless of whether we agree precisely on what > "lame" means, what is the call to action when a zone or its name servers are > declared lame? > > There doesn't need to be a call to action — I can say "my car squeals when > going round a corner" - "squeals" is a way to describe the noise, and it's > just an observation, just like "a-random-test-domain.net is a lame > delegation". I own both "a-random-test-domain.net" and "my car" - unless the > squealing / lameness impacts you, I don't think that there (or needs to be) > is a call to action on either. > > And how is that different from any other form of miscreant auth behaviour > such as inconsistency? > > Well, for one thing, it's not always "miscreant auth behavior" (by which I'm > assuming you mean misbehavior by the auth server / auth server operator). > > As an example, it's quite common for people to register a domain and point > the DNS at some nameservers which they don't control, and have no > relationship with. This is not "miscreant auth behaviour" by the auth > operator - they were not involved, and also have no realistic way to deal > with the issue. > > If we did want to have a call to action" we could publish something saying > that pointing a domain at a name server that isn't "yours" is uncool, but I > don't really know how effective this would be… Pointing a NS record at a nameserver that doesn’t serve the zone with the intention of causing DoS traffic at it is a criminal act in most jurisdictions (intentional financial harm or some such). Aiding and a abetting a criminal act is also a criminal act. Not having a process to remove NS records pointing at servers that don’t serve the zone could be seen as aiding and abetting. This is not to say that all cases of NS records that point at servers that don’t serve a zone are criminal acts but just treating it as “uncool” is uncool. > W > > > > I mean if "lame" is a precious historical term that warrants considered > clarification, surely it has a very specific value that we can all act on, > right? So what is that very specific value? > Mark. > ___ > 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 -- 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] [Ext] WGLC rfc8499bis one week extension for lame delegation definition
What named logged as a lame server for a zone was what could be demonstrated to be lame (broken) from a single response when performing the resolution process (i.e. not configured to be serving the zone). It was intended to provide information to the operator of the recursive server that something was broken with the zones involved in looking up an answer to a query made to that server with the possible hope that someone would report the issue so that it could be fixed. “lame server” was never intended to exclude other ways things could be configured such that an answer from the zone was not returned. With load balancers that needs to be extended to “not fully/correctly configured to be serving the zone”, with firewalls blocking the port “not fully/correctly configured to be effectively serving the zone”. Mark > On 5 May 2023, at 10:34, George Michaelson wrote: > > When people talk about "lame" they're in a sentence with a subject > (the DNS), and an object(ive) -But there isn't a single parse. Sorry, > but the declarative "this is what it means" seems to me to be failing, > hard. > > The subject(s) are the zone(s) that are lame? thats one case. the > other case, is the subject is the NS which is listed as authoritative > but isn't serving. OK so you can qualify "lameness" to "the zone is > lame" or "the zone has some lame NS" or "this NS is lame for the zone" > -But they have different subjects and objects. what is "this" in each > case? different. > > And not serving has (at least) two forms: you respond to 53 but reply > incoherently if at all about the zone, and you aren't even responsive > on 53. I can believe there are more. > > The objective is to fix it. You are either talking to the parent zone > delegates to get something changed in the parent zone, or to the zone > NS admin to get something changed at the NS, or to network technicians > about why something along the path isn't working for you. So thats 3 > cases at least. > > Yet, we all seem to call this "lame" for some purposes. At least 2x > who talked to, at least 2x forms, and at least 2x subjects but one > Objective: -- fix it. > > I don't think we've cohered on a meaning. I respect Paul Vixies intent > in giving clear origination of the term to Mark, but I do not agree > the term means now what he said decades ago, its clear we don't (in > this mail thread) really have a unitary meaning. If we did we wouldn't > be here. > > I don't see how a single paragraph statement without OR ... alternates > is going to cover what people patently have been saying "is lame" for > some time, not aligning to a single meaning. > > I liked the proposed paragraph because it had the ".. or not at all" > -And yet some people seem determined to say thats the "wrong" bit on > the definition. > > ___ > 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] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]
ond to particular names and particular addresses (including nameserver > names and nameserver addresses) are not always the same. Private namespaces > exist that avoid collisions with the nominally-public namespace by making the > same companyname.com domain exist in both, but implementing each very > differently. This is valid and good advice, even (e.g. compared to squatting > on .HOME or .CORP). Should those domains be suppressed simply because they > are not intended for use by the general public? Well if the public side of a delegation is getting answers from the private version of the zone there is a problem that needs to be addressed. > My personal opinion on all of this is that there is already direct commercial > pressure for delegations to be healthy when they matter. Services that depend > on the DNS (or things reached by the DNS) that people care about generally > have incentives to keep their ducks lined up (incentives like revenue, > customer retention, being elected again). Things in the DNS that aren't > well-paired with incentives like that might well break more often, but if a > delegation breaks in the forest and there's nobody present to argue about > whether the delegation is strictly lame or not, does anybody need to care? They ALL matter. Broken delegations get used by bad actors to cause additional load on recursive servers and on authoritative that are being referred to incorrectly. > To look at it another way, why would we give authority to a third party to > break our domains just because they are not fully-informed about how we are > using them? > And lastly, even if a delegation is genuinely broken and useless for all the > world, and nobody cares enough to fix it, what harm does it do? What is the > motivation to find a fix? A dribble of extra traffic relating to a > mainly-unused domain to a nameserver that is already over-provisioned doesn't > seem very compelling. > > Even if I thought this was a problem that needed a solution, I don't think > the solution is likely to be easy. The technical aspects are the easiest > part, and those are already difficult. Perhaps we can just become comfortable > with the idea that at any time the DNS contains bits that work and bits that > don't work, and that is just the way of things. > > Joe > > > ___ > 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] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]
> On 9 May 2023, at 03:13, John Levine wrote: > > It appears that Kim Davies said: >> With that said, I think the root zone is probably not an instructive >> use case for the broader question. Unlike typical zones, at the root it >> can be said every delegation is to critical Internet infrastructure and >> therefore the calculus around process complexity and efficiency would be >> weighted differently. > > Oh, I completely agree. My point was just that even in the root which is > small and you > would hope would change slowly, it's still a challenge to track what's lame. It’s not a challenge to track what is lame. It’s dead simple. You just have to look. Getting it addressed is the challenge. https://ednscomp.isc.org/compliance/tld-fullreport.txt has been generated daily for the last 5 years and the broken behaviours have stood out like sore thumbs the entire time. It only takes a couple of minutes to generate that report and that isn’t trying to go as fast as possible. > R's, > John > > ___ > 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] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]
> On 12 May 2023, at 11:35, John Levine wrote: > > It appears that Mark Andrews said: >>> Oh, I completely agree. My point was just that even in the root which is >>> small and you >>> would hope would change slowly, it's still a challenge to track what's lame. >> >> It’s not a challenge to track what is lame. It’s dead simple. You just >> have to look. Getting >> it addressed is the challenge. > > Yeah, that's a better way to put it. But the main point still stands, > that it would be a signficant operational change to insist that all > delegated NS be active when delegated, and even moreso to insist that > they continue to be active. No, it is not a “significant” change. It should just be a minor extension of the existing requirement to keep the NS and glue records consistent. Even if it was you just introduce it with a soft start. Just start checking the delegations of every TLD like zone then report the broken servers publicly and email the contacts for the delegation. The tools for checking already exist. RFC 4034, 4.2.2. As the last installation step, the delegation NS RRs and glue RRs necessary to make the delegation effective should be added to the parent zone. The administrators of both zones should insure that the NS and glue RRs which mark both sides of the cut are consistent and remain so. > Back in the 1990s when you registered names by email, NetSol checked > that your NS were active before accepting them, but that was back when > it was normal for the back and forth for registering a name to take a > week. > > R's, > John -- 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] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]
> On 12 May 2023, at 12:09, John R Levine wrote: > >>> Yeah, that's a better way to put it. But the main point still stands, >>> that it would be a signficant operational change to insist that all >>> delegated NS be active when delegated, and even moreso to insist that >>> they continue to be active. >> >> No, it is not a “significant” change. It should just be a minor extension >> of the existing requirement to keep the NS and glue records consistent. >> >> Even if it was you just introduce it with a soft start. Just start checking >> the delegations of every TLD like zone then report the broken servers >> publicly and email the contacts for the delegation. The tools for checking >> already exist. > > Well, OK, you do that, half the emails bounce, half of what's delivered is > reported as spam, and the third half are ignored. Now what? In practice it isn’t quite as bad as that. Require registrars to refuse renewals until the issues are addressed. This is no different to not getting your car’s registration renewed until it has past its safety inspection. Mark > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly -- 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] Incompatibility with indicating client support for EDE (draft-ietf-dnsop-structured-dns-error)
> On 23 May 2023, at 02:20, Tommy Pauly > wrote: > > Hello DNSOP, > > In draft-ietf-dnsop-structured-dns-error, there’s a description of how > clients should indicate that they understand extended DNS errors (EDE) by > sending an empty EDE option. > > https://www.ietf.org/archive/id/draft-ietf-dnsop-structured-dns-error-02.html#name-client-generating-request > > This is something that makes a lot of sense to me, and provides a great way > to indicate that a client would prefer to receive proper blocked/filtered > errors (with possible extra text) as opposed to a forged answer. > > However, in testing this out, I’m seeing inconsistent compatibility with some > public resolvers. I was testing enabling this for encrypted resolvers only, > and I see the following behavior for a sampling of resolvers using DoH: > > 1.1.1.1 - NOERROR, works fine! > 9.9.9.9 - NOERROR, works fine! > 8.8.8.8 - FORMERR on all responses > dns.adguard-dns.com - SERVFAIL on all responses > > Do we think that this should be allowed in queries (and thus this is a bug in > resolvers like 8.8.8.8 or AdGuard)? Or is there a problem with the approach > this document is suggesting? RFC 8914 left whether EDE in requests was permitted or not undefined. I can see an EDE implementation making the option parser return FORMERR if the EDE option length was less than 2 and applying that to both requests and responses. RFC 8914 really should have said that EDE in requests should be ignored and then there would have been a possibility on extending behaviour based on adding EDE to a request. We are already 10 years into trying to fix unknown EDNS option behaviour and are still getting FORMERR on unknown EDNS options in requests. If the working group want to allow extending EDE by adding it to a request is should obsolete RFC 8914 now with RFC8914bis that specifies that EDE in requests are to be ignored. At the moment draft-ietf-dnsop-structured-dns-error-02 really should use another EDNS option code point. It really is not backwards compatible with EDE the way it is currently specified. > Best, > Tommy > ___ > 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] Incompatibility with indicating client support for EDE (draft-ietf-dnsop-structured-dns-error)
> On 23 May 2023, at 17:11, Petr Špaček wrote: > > On 23. 05. 23 7:03, Ralf Weber wrote: >> Moin! >> On 23 May 2023, at 4:44, Tommy Pauly wrote: >>> Thanks, Mark. >>> >>> For what it's worth, I just ran two other tests, and for both of these >>> cases, all of the resolvers I tried did accept the request: >>> - Choose a new EDNS option code point (I just tested 50, randomly) >>> - Use EDE but set the length to 2 and the error to 0 (other error), rather >>> than a length of 0 >> I don’t think we need a new code point. Just having a valid opt record >> without a further option will work as RFC8914 states: >> The Extended DNS Error (EDE) option can be included in any response >> (SERVFAIL, NXDOMAIN, REFUSED, even NOERROR, etc.) to a query that includes >> an OPT pseudo-RR [RFC6891]. This document includes a set of initial >> codepoints but is extensible via the IANA registry defined and created in >> Section 5.2. >> and as the mechanism in draft-ietf-dnsop-structured-dns-error just defines a >> special format for the EDE EXTRA-TEXT field the most backward compatible >> solution IMHO is just to rely on the mechanism defined in RFC8914, and not >> to define any special handling. >> So I would propose 5.1 to be: >> When generating a DNS query, the client includes the OPT pseudo-RR [RFC6891] >> to elicit the Extended DNS Error option in the DNS response. > > I agree. Sending empty EDE in requests seems superfluous to me. The point of adding it to the request is to signal that that client will do the filtering. Even if signalling is removed the current text is incompatible with EDE. Read it in “perverse” mode (client will be stupid). > -- > Petr Špaček > Internet Systems Consortium > > ___ > 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] Roman Danyliw's No Objection on draft-ietf-dnsop-glue-is-not-optional-08: (with COMMENT)
> On 12 Jun 2023, at 23:12, Shumon Huque wrote: > > Thank you Roman for your review. > > On Wed, Jun 7, 2023 at 11:02 PM Roman Danyliw via Datatracker > wrote: > > ** Consider if RFC2119 keywords are appropriate in the abstract > > We will lower case the term. > ** Section 2.4. Machine produced tool output is provided in this section > (from > dig). Please formally cite what generated it. > > Good suggestion. I'm not sure what the formal citation for the dig tool is. > So let's ask our co-author from ISC. > > Mark (Andrews) - is there a reference we can cite? dig from BIND 9 https://www.isc.org/bind/ > > Shumon. > > ___ > 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] With multi-algo DS, what to do if an RRSIG is missing?
The rules are there to ensure that if the resolver see an algorithm it supports then it can validate the response. If you fail to follow the rules answers won’t ALWAYS validate. If there is one level of validation happening the validator should recover by trying other servers. If you have chained validators all bets are off as you can cache a set that the next validator in the chain can’t validate successfully. The resolver can check that the set of DNSKEY algorithms found in the DS set safely. It was the DNSKEY algorithms that don’t work in a loosely coherent database. There are timing constraints between DS and DNSKEY that allow determination of what the zone is signed with that are impossible to achieve with DNSKEY alone unless you pre publish signatures. -- Mark Andrews > On 4 Jul 2023, at 04:25, Peter Thomassen wrote: > > Dear DNSOP, > > It's well-known that DNSSEC multi-signer setups are problematic when > providers want to sign with different algorithms. > > In a hypothetical scenario where signing requirements would be relaxed, I > have a very specific question about how resolvers should behave. Apologies > for the length of the message, and thank you for reading it. > > > To lay out the problem fully, here's an appetizer from the spec. RFC 6840 > Section 5.11 says (emphasizing a point from RFC 4035 Section 2.2): > > > A signed zone MUST include a DNSKEY for each algorithm present in > the zone's DS RRset and expected trust anchors for the zone. The > zone MUST also be signed with each algorithm (though not each key) > present in the DNSKEY RRset. [...] > > This requirement applies to servers, not validators. Validators > SHOULD accept any single valid path. They SHOULD NOT insist that all > algorithms signaled in the DS RRset work, [...] > > > > The second rule is not contentious. It basically says that validators SHOULD > NOT apply a "logical AND" on algorithms offered by the DS record set; > instead, "logical OR" is encouraged. There was an issue with this in Unbound, > but that's been solved ages ago. (Well,* ...) > > > However, the first rule is incompatible with certain use cases. In > particular, it is not possible to have the same zone served by several > operators, each signing with their own key and choice of algorithm. > > A special case of this is the glitch-free transfer of a domain name from one > DNS provider to another, while retaining DNSSEC validation. During the > transition, a multi-signer phase will be in effect, and if the old and new > provider don't support overlapping sets of algorithms, you'll run into the > aforementioned problem. > > For the sake of argument, let's replace the first rule by something like: > > Independent of the number of signing algorithms appearing in it, the > DS RRset MUST reference at least one DNSKEY that signs theDNSKEY > RRset. Other RRsets MUST be signed with at least one DNSKEY whose > algorithm appears in the DS RRset. > > More casually, "it's sufficient to sign with one algorithm from DS, as long > as it allows for authenticating along some valid path". > > (Note that from the resolver perspective, this is compatible with rule 2, as > long as all announced algorithms are supported.) > > > Next, consider that Red Hat turned off SHA-1-based signing algorithms in Red > Hat Enterprise Linux 9 and related distributions. As this is a system-wide > policy, it affects validation of DNSSEC algorithms 5 and 7 in resolvers. In > response, Unbound [1], Knot Resolver [2] and PowerDNS Recursor [3] all have > implemented ways to detect whether these algorithms work, and disable them if > not supported. > > That works great for zones that use algorithm 5 or 7 *only*: corresponding DS > records will be dropped from consideration, and as nothing is left, the zone > is treated as insure. > > > Now, assume a multi-signer setup of, say, algorithms 7 and 13. This is not an > uncommon transition (ietf.org did it last month, except that they went > unsigned). In such a scenario, a resolver on Red Hat would only consider the > algo 13 DS records. > > Under the relaxed RRSIG presence rule, it would be fine to serve signatures > of *one* algorithm only (either 7 or 13). If only 7 is served, my > understanding is that this would lead to SERVFAIL, because signatures are > missing for the only supported algorithm. There is no valid path. > > This situation looks exactly like a double-algorithm setup where an on-wire > attacker stripped RRSIGs for algorithm 13 so they can mess with the response > (knowing that 7 is not going to get validated). -
Re: [DNSOP] With multi-algo DS, what to do if an RRSIG is missing?
a downgrade-to-insecure attack? > > 4.) In fact, how would the resolver distinguish this from a > downgrade-to-insecure attack? It can’t. > 5.) If the authoritative server can't know what the resolver supports, how > could it ever be safe, by not sending RRSIGs for all algorithms, to introduce > the confusion of question (4)? It isn’t. > It is sometimes noted that Rule 1 above (signer requirement) and Rule 2 > (validator requirement) are contradictory. I'd like to point out that the > questions raised here have nothing to do with rule 2: Validators should > accept *any* valid path. This rule stands regardless of whether any > signatures missing or not. Rule one is about ensuring that the data is produced for the validator. > The issue is whether there's a supported path, and a safe response when a > valid path is lacking although one could expect one based on DS. This is not > about compatibility of the rules (rule 2 is compatible with anything), but > about which signer requirement makes sense. (Does the signer know enough > about the validator to decide which algorithms can be advertised but then > their signatures left off, because another advertised algorithm is surely > supported?) > > > Also note that the algorithms in this example (7 and 13) are both "MUST > implement" on the validator side, RFC 8624 Section 3.1. Some say that "MUST > implement" is different from "MUST support". > > 6.) Is "MUST implement" different from "MUST support"? > - e.g.: "we implemented but don't support usage for some reason" MUST implement is about providing an interoperable path that leads to secure. An operator is free to no use that path. > 7.) When defining which algorithm(s) to return signatures for, should that > requirement depend on any "MUST implement" requirements for the involved > algorithms? > - If so, why? (Is it practical? See algorithm 7.) > - If not, why not? > > 8.) If a resolver supports one of the algorithms offered via DS, is it > correct that (barring CD flag) it MUST NOT, under any circumstances, return > insecure data? It must not return unvalidated data. You can support the algorithms but not have a trust path. > Thanks, > Peter > > * Unbound's "harden-algo-downgrade" setting [4] recovers the "logical AND" > behavior. Google reveals a bunch of places using it [5-11], especially on > devices like Raspberry Pi (Pihole etc.). > > [1]: https://github.com/NLnetLabs/unbound/pull/660 > [2]: > https://gitlab.nic.cz/knot/knot-dns/-/commit/b0c6f0709aeab17e6db3dadc85d335848f5d681e > [3]: > https://docs.powerdns.com/recursor/settings.html#dnssec-disabled-algorithms > [4]: > https://nlnetlabs.nl/documentation/unbound/unbound.conf/#harden-algo-downgrade > [5]: https://www.google.com/search?q=%22harden-algo-downgrade:+yes%22 > [6]: https://forums.gentoo.org/viewtopic-p-8563219.html > [7]: > https://www.reddit.com/r/pihole/comments/11gm11r/unbound_doesnt_resolve_technology_tld/ > [8]: > https://forum.manjaro.org/t/pacman-mirrors-fasttrack-adding-slow-or-invalid-entries-to-mirrorlist/75348 > [9]: https://emeraldonion.org/2017/12/03/dns-for-tor.html > [10]: > https://blacklab.net/set-up-pi-hole-as-truly-self-contained-dns-resolver/ > [11]: https://dietpi.com/forum/t/problems-with-unbound/6503 > > -- > https://desec.io/ > > ___ > 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] [v6ops] WG call for adoption: draft-momoka-v6ops-ipv6-only-resolver-01
I’ll repeat that it is a bad idea to make this an RFC. I’m saying this despite adding this to named. It is perpetuating DNS64 which does not work with DNSSEC. It sends the wrong signal that DNS64 is a good protocol to deploy when we know that it breaks lots of things. The better solution would be to improve the automatic installation of 464XLAT (RFC6877) support in nodes. There is already a RA PREF64 option (RFC8781) to signal that NAT64 is available on the network and that works for all applications on the node, not just the nameserver. Similarly for DS-Lite. Linux has https://github.com/toreanderson/clatd FreeBSD has 464XLAT support built in since FreeBSD 11.3 While CLAT is not everywhere there yet it is definitely on the way. https://blog.apnic.net/2022/11/21/deploying-ipv6-mostly-access-networks/ I really don’t know why we are just not saying if you want to run a DNS64 server behind a IPv6 only link install CLAT support if it is not already available. > On 6 Jul 2023, at 01:12, Tim Wicinski wrote: > > Momoka > > Thanks for making DNSOP aware of this. We encourage anyone with comments on > the document adoption to reach out. > > Everything I've heard and read on this work (wearing no hats) is that this is > good work and should be adopted. > > thanks > tim > > > > On Tue, Jul 4, 2023 at 5:15 AM Momoka Yamamoto wrote: > Dear dnsop wg > cc:v6ops wg > > My name is Momoka, the author of the draft-momoka-v6ops-ipv6-only-resolver. > This draft, which has already been introduced to the V6OPS Working Group, > aims to address a pertinent operational issue: facilitating the transport of > query packets from an IPv6-only iterative resolver to an IPv4-only > authoritative DNS server. > > In light of some suggestions in V6OPS and considering the overlapping > interests, I am introducing this draft to the DNSOP Working Group. Its core > proposition lies in the mechanics of transporting query packets rather than > the alteration of the DNS protocol behavior, but the operational context > undoubtedly makes this draft relevant to both groups. > > Here are links to the draft and the ongoing discussions in V6OPS: > > 1. Draft: > https://datatracker.ietf.org/doc/draft-momoka-v6ops-ipv6-only-resolver/ > 2. V6OPS Thread: > https://mailarchive.ietf.org/arch/msg/v6ops/uNrPNbeUtA_D0xzqLfq5dNQ85OY/ > > > Currently, there is an adoption call in V6OPS for this draft set to end on > July 10, 2023. Your opinion, input, and suggestions will be highly valued as > we explore and progress this topic. I look forward to fruitful and > enlightening discussions. > > Best regards, > > Momoka Yamamoto > momoka@gmail.com > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ > v6ops mailing list > v6...@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- 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] [v6ops] WG call for adoption: draft-momoka-v6ops-ipv6-only-resolver-01
> On 6 Jul 2023, at 12:32, Ted Lemon wrote: > > It’s not a problem to validate before translating if you’re a full service > resolver. Ted you are missing the point. It is impossible to *reliably* run a validating client behind a DNS64 server. DNS64 uses CD in a manner that is *incompatible* with DNSSEC. Sure as long as the DNS64 server *always* gets good answers you can “get away with it” but once you don’t things break. In DNSSEC CD=1 is for when the recursive validating resolver has bad time / trust anchors CD=0 is ensures the cache returns answers that can validate as secure (the server is supposed to try multiple sources as it is required to “treat as never having arrived” responses that don’t validate) “Always send CD=1” is stupid advice. I tried to prevent it being published in the first place. If the DNS64 server happens to lock onto a bad source of data or is losing the race with spoofed responses the client will never get anything that validates as secure as: CD=1 the bad data is passed through or returned from the cache. CD=0 the DNS64 server produces responses that don’t validate. Anything that further promotes the use of a BROKEN protocol should not be published. Mark > Op wo 5 jul 2023 om 21:10 schreef Mark Andrews > I’ll repeat that it is a bad idea to make this an RFC. I’m saying this > despite adding > this to named. > > It is perpetuating DNS64 which does not work with DNSSEC. It sends the wrong > signal > that DNS64 is a good protocol to deploy when we know that it breaks lots of > things. > > The better solution would be to improve the automatic installation of 464XLAT > (RFC6877) > support in nodes. There is already a RA PREF64 option (RFC8781) to signal > that NAT64 is > available on the network and that works for all applications on the node, not > just the > nameserver. > > Similarly for DS-Lite. > > Linux has https://github.com/toreanderson/clatd > FreeBSD has 464XLAT support built in since FreeBSD 11.3 > > While CLAT is not everywhere there yet it is definitely on the way. > https://blog.apnic.net/2022/11/21/deploying-ipv6-mostly-access-networks/ > > I really don’t know why we are just not saying if you want to run a DNS64 > server behind > a IPv6 only link install CLAT support if it is not already available. > > > > On 6 Jul 2023, at 01:12, Tim Wicinski wrote: > > > > Momoka > > > > Thanks for making DNSOP aware of this. We encourage anyone with comments > > on the document adoption to reach out. > > > > Everything I've heard and read on this work (wearing no hats) is that this > > is good work and should be adopted. > > > > thanks > > tim > > > > > > > > On Tue, Jul 4, 2023 at 5:15 AM Momoka Yamamoto wrote: > > Dear dnsop wg > > cc:v6ops wg > > > > My name is Momoka, the author of the draft-momoka-v6ops-ipv6-only-resolver. > > This draft, which has already been introduced to the V6OPS Working Group, > > aims to address a pertinent operational issue: facilitating the transport > > of query packets from an IPv6-only iterative resolver to an IPv4-only > > authoritative DNS server. > > > > In light of some suggestions in V6OPS and considering the overlapping > > interests, I am introducing this draft to the DNSOP Working Group. Its core > > proposition lies in the mechanics of transporting query packets rather than > > the alteration of the DNS protocol behavior, but the operational context > > undoubtedly makes this draft relevant to both groups. > > > > Here are links to the draft and the ongoing discussions in V6OPS: > > > > 1. Draft: > > https://datatracker.ietf.org/doc/draft-momoka-v6ops-ipv6-only-resolver/ > > 2. V6OPS Thread: > > https://mailarchive.ietf.org/arch/msg/v6ops/uNrPNbeUtA_D0xzqLfq5dNQ85OY/ > > > > > > Currently, there is an adoption call in V6OPS for this draft set to end on > > July 10, 2023. Your opinion, input, and suggestions will be highly valued > > as we explore and progress this topic. I look forward to fruitful and > > enlightening discussions. > > > > Best regards, > > > > Momoka Yamamoto > > momoka@gmail.com > > ___ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > _______ > > v6ops mailing list > > v6...@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > ___ > v6ops mailing list > v6...@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- 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] [v6ops] WG call for adoption: draft-momoka-v6ops-ipv6-only-resolver-01
> On 6 Jul 2023, at 21:09, Vasilenko Eduard wrote: > > Hi all, > The goal to improve DNSSEC adoption is good. > The goal to improve IPv6 adoptions is good too. > It looks like here goals contradict (for technical reasons). > But if you would pay attention that DNS64 is already massively adopted by > *ALL* carriers, The carriers could turn off DNS64 today and just serve an appropriately populated ipv4only.arpa zone and 99.9% of customers wouldn’t notice the difference. All the phones shipping today support 464XLAT. The vast majority of the existing phones also support 464XLAT. When you get away from carriers to wireline ISPs DS-Lite, MAP-* are also in use. They don’t actually break access to the IPv4 internet like DNS64 does. Even then just having the CPE support DS-Lite, MAP-*, 464XLAT is enough for ISPs to turn off IPv4 and go IPv6 only in the access network. The applications running in this environment also require IPv4 literal support more than phones do. There is lots more custom code here in this space that has never been made IPv6 aware. DNS64 is actually a BAD fit. This is also where you do find name servers in use. > Then the harm for DNSSEC is already done and non-reversible (this battle was > lost many years ago). No, it isn’t irreversible. Just about every cell phone that is shipping supports 464XLAT and that DOES NOT require DNS64. It just requires being able to get the PREF64. > Hence, please do not harm additionally for IPv6 adoption. The use of DNS64 is actually doing harm for IPv6 adaption as it DOES NOT WORK FOR ALL APPLICATIONS. There are plenty of IPv4AAS that do work FOR ALL APPLICATIONS and they can actually be deployed in parallel. All this draft is doing is demonstrating why DNS64 is a bad solution. If it had worked this wouldn’t be being proposed. It is making all the same assumptions that where made initially for DNS64 and guess what? The world decided that DNS64 WAS NOT ENOUGH. We have 464XLAT support on just about every cell phone. We have 464XLAT support in modern desktop boxes. If the box you want to run the DNS64 nameserver on doesn’t support 464XLAT install one that does. Mark > Please, adopt Momoka's draft at least somewhere (I am not sure v6ops or > dnsop). > Eduard > -Original Message- > From: v6ops [mailto:v6ops-boun...@ietf.org] On Behalf Of Mark Andrews > Sent: Thursday, July 6, 2023 7:48 AM > To: Ted Lemon ; dnsop ; list > > Subject: Re: [v6ops] [DNSOP] WG call for adoption: > draft-momoka-v6ops-ipv6-only-resolver-01 > > > >> On 6 Jul 2023, at 12:32, Ted Lemon wrote: >> >> It’s not a problem to validate before translating if you’re a full service >> resolver. > > Ted you are missing the point. It is impossible to *reliably* run a > validating client behind a DNS64 server. DNS64 uses CD in a manner that is > *incompatible* with DNSSEC. > Sure as long as the DNS64 server *always* gets good answers you can “get away > with it” > but once you don’t things break. > > In DNSSEC > CD=1 is for when the recursive validating resolver has bad time / trust > anchors > CD=0 is ensures the cache returns answers that can validate as secure (the > server is supposed to try multiple sources as it is required to “treat as > never having arrived” > responses that don’t validate) > > “Always send CD=1” is stupid advice. I tried to prevent it being published > in the first place. > > If the DNS64 server happens to lock onto a bad source of data or is losing > the race with spoofed responses the client will never get anything that > validates as secure as: > CD=1 the bad data is passed through or returned from the cache. > CD=0 the DNS64 server produces responses that don’t validate. > > Anything that further promotes the use of a BROKEN protocol should not be > published. > > Mark > >> Op wo 5 jul 2023 om 21:10 schreef Mark Andrews I’ll >> repeat that it is a bad idea to make this an RFC. I’m saying this >> despite adding this to named. >> >> It is perpetuating DNS64 which does not work with DNSSEC. It sends >> the wrong signal that DNS64 is a good protocol to deploy when we know that >> it breaks lots of things. >> >> The better solution would be to improve the automatic installation of >> 464XLAT (RFC6877) support in nodes. There is already a RA PREF64 >> option (RFC8781) to signal that NAT64 is available on the network and >> that works for all applications on the node, not just the nameserver. >> >> Similarly for DS-Lite. >> >> Linux has https://github.com/toreanderson/clatd >> FreeBSD has 464XLAT support built in since FreeBSD 11.3 >> >> While CLAT is not everywhere there yet it is def
Re: [DNSOP] [v6ops] WG call for adoption: draft-momoka-v6ops-ipv6-only-resolver-01
Well don’t put an IPv4 stack on the device. Use mapped addresses over IPV6 sockets and map those addresses to the PREF64 prefix in use in the stack. -- Mark Andrews > On 8 Jul 2023, at 05:20, Ted Lemon wrote: > > > John, that's simply not an option on networks that only support IPv6 (most > especially 6lowpan). We really don't want to have to put an IPv4 stack in a > constrained device. So this solution isn't going to work. In practice, these > devices will generally just rely on a resolver that probably /does/ have IPv4 > access, but a solution that assumes that all endpoints have IPv4 stacks is > not a good solution. > >> On Fri, Jul 7, 2023 at 2:08 PM John Levine wrote: >> It appears that Vasilenko Eduard said: >> >-=-=-=-=-=- >> >1. 464XLAT is indeed an alternative, but a bad one: it means that the >> >client should have a local IPv4 subnet. >> >The DNS resolver should prepare the packet in IPv4 format, then fetch it to >> >the CLAT engine where it would be translated to IPv6. >> >> I'm with Mark here. If you want to talk to IPv4 devices, it makes a >> lot more sense for your local router or device to give you an RFC1918 >> network which then lets you use the real far end IPv4 addresses and >> signed DNS records, than to require every bit of addresss management >> and DNSSEC code to do special hacks to try and peer through the other side >> of the NAT. >> >> 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [v6ops] DNS64/Thread RE: WG call for adoption: draft-momoka-v6ops-ipv6-only-resolver-01
I think the issue is that NAT64 is being used to reach internal IPv4 addresses (e.g. RFC 1918) so the traffic needs to go through a NAT64 that can reach those addresses. > On 10 Jul 2023, at 17:32, mohamed.boucad...@orange.com wrote: > > Hi Gert, > > Please see inline. > > Cheers, > Med > >> -Message d'origine- >> De : Gert Doering >> Envoyé : lundi 10 juillet 2023 08:53 >> À : BOUCADAIR Mohamed INNOV/NET >> Cc : Ted Lemon ; v6...@ietf.org; Xipengxiao >> ; dnsop >> Objet : Re: [v6ops] DNS64/Thread RE: [DNSOP] WG call for adoption: >> draft-momoka-v6ops-ipv6-only-resolver-01 >> >> Hi, >> >> On Fri, Jul 07, 2023 at 01:19:38PM +, >> mohamed.boucad...@orange.com wrote: >>> For your last point: problems may arise if a distinct pref64 is >> used >>> by the upstream DNS64 than the one used locally. Unless I???m >>> mistaken, we currently don???t have a solution to detect >> mismatches >>> between what is used by a local NAT64 and an upstream DNS64 let >> alone >>> whether an upstream resolver is also performing DNS64. I used to >> have >>> a proposal for this: >>> >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F >> data >>> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-boucadair-dnsop-prefix64- >> 02&data >>> >> =05%7C01%7Cmohamed.boucadair%40orange.com%7C156480ca56e144dd3c7708 >> db81 >>> >> 125189%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63824568789974 >> 8586 >>> >> %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT >> iI6I >>> >> k1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7hwX%2Bwnur4AnRNpe9LCY >> lWNR >>> jDC5Sk%2BCnzSpTZNmqi0%3D&reserved=0 >> >> I would assume that it just does not matter if there are two NAT64 >> boxes available, with different prefixes. Depending on which >> prefix you use for the IPv6 synthesis, your packets will use one >> or the other to be translated - which is actually one of the >> brilliant aspects of NAT64, that it does not need to be in the >> "non NAT" packet flow. > > [Med] Yes, but not sure this is relevant to the point above. > >> >> Same for "having two DNS64 in sequence" - while unusual, it will >> still work. > > [Med] I'm afraid not. Failure will be observed if there are no on-path NAT64 > that uses the prefix used by these DNS64. > > The first DNS64 to see the IPv4-only reply will do >> synthesisis, the second DNS64 will see an IPv6 answer, and won't >> have to do anything except "forward". If they agree on the NAT64 >> prefix, packets will use the same NAT64 gateway in any case, if >> not, see above. >> >> Gert Doering >>-- NetMaster >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard, >> Michael Emmer >> Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner- >> Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > ___ > v6ops mailing list > v6...@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- 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] draft-dnsop-dnssec-extension-pkix on IETF117 dnsop agenda?
> On 17 Jul 2023, at 05:53, Viktor Dukhovni wrote: > > On Sun, Jul 16, 2023 at 03:06:35PM -0400, Viktor Dukhovni wrote: >> I see that draft-dnsop-dnssec-extension-pkix is included on the IETF117 >> dnsop agenda. >> >>https://datatracker.ietf.org/doc/draft-dnsop-dnssec-extension-pkix/ >> >> I haven't seen prior discussion of this item on the list, and, >> personally, rather suspect it unlikely to gain meaningful support from >> the WG and see adoption. >> >> Would it possible to defer discussion of this document to such time as >> some evidence of support emerges, and in the meantime use the timeslot >> for more realistically productive proposals? > > I should perhaps have stated the technical criteria on which I consider > the proposal non-viable. To whit: > >- The proposed protocol lacks all downgrade resistance. >- Without a signed delegation from the parent, the existence of the > zone apex CERT MRs and associated RRSIGs is trivially denied by > an on-path attacker. >- This protocol adds failure modes (CERTs and RRSIGs are available, > but don't match), without adding any security. > > Since the point of DNSSEC is to thwart active attacks, and the protocol > in the proposed draft offers no such protection, I consider it > non-viable. > > There are other substantial issues, but the above is sufficient to stop > looking for more reasons why this is a dead-end. > > -- >Viktor. > > _______ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop I concur. This is a horribly flawed proposal. Mark -- 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] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt
> On 18 Jul 2023, at 08:10, David Conrad wrote: > > Paul, > > On Jul 17, 2023, at 12:52 PM, Paul Vixie > wrote: >>> If the stability of anybody's infrastructure depends on people choosing a >>> particular transport, I would suggest they might have reason to be worried. >>> Simply hoping that people don't start using TCP in a significant way is >>> putting your stability in a lot of other peoples' hands. >> also -1. state has mass. avoiding it will remain worthwhile. > > > “Please Friendly Malicious Actor, do not send too many TCP DNS requests as it > might overwhelm my infrastructure”? > > Joe is (correctly, IMHO) pointing out that given there is a need to support > TCP-based DNS queries (see RFC 7766), prudent engineering would suggest you > need to prepare for attacks against that infrastructure. As such arguing > “state has mass” appears to miss the point. And most servers will never see a DoS attack. TCP also puts much more load on recursive servers. It slows down the resolution process. DOT and DOH put even more load on recursive and authoritative servers. I saw servers the other day that where answering UDP in ms but TCP was taking 10s of seconds to answer. They appear to have fixed whatever the issue was but it still happened. > Regards, > -drc > > _______ > 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] what could we do with 15 unused bits of QDCOUNT?
> On 27 Jul 2023, at 09:20, Brian Dickson wrote: > > > > On Wed, Jul 26, 2023 at 4:12 PM George Michaelson wrote: > if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in > the header. > > What would be interesting uses of the flow-label? Oh wait.. that's > right, nobody really knows at scale how to use flow-label either. > > I tend to "use it for 15 bits of signalling" because there are a lot > of things I wish were signalled from client to server. > > "I am new code" > "I am at least not ancient code" > "I'm the same as that other guy you saw over " > "I like TCP and want to do a persisting session" > "tell me if you are doing a|b|c|d" > "I like chocolate and want a pony" > > maybe the truth is, we've got 15 bits of zero in the header forever, amen. > > (I deliberately didn't put this in the draft- post from Ray so as not > to pollute an objective discussion of what it is or is not the value > proposition) > > clue-stick hits welcome. Avoid the stomach. > > 15 bits of entropy would maybe be a good use, particularly for short QNAMEs > (and with QNAME minimization, that definitely applies to root and TLD > queries). > That would augment or compensate for fewer bits available for 0x20 entropy. Or root and TLD servers could just deploy DNS COOKIE. There is no reason for them not to deploy DNS COOKIE today other than vendors not implementing it. Time for vendors to pull their fingers out. DNS COOKIE is standards track. It is a security fix. Deploy it. > > Brian > ___ > 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] what could we do with 15 unused bits of QDCOUNT?
Please no. If we really want to stop fragmentation attacks just use well known TSIG. This doesn’t require new code. It just requires configuration. > On 28 Jul 2023, at 02:50, Brian Dickson wrote: > > Top-reply (since there are already a bunch of threaded replies that might > benefit from this): > Queries are small, and have room in the first packet for EDNS (and often the > resulting size will still be < 576). > Idea: > EDNS "signal" + bits -> tells server the client knows about the new meaning > of the 15 bits of QCOUNT, and is sending its client-side version of what > those bits are. > I.e. the bits are NOT changed from zero in the header in the query, only in > the reply and only if the server understands this EDNS option. > IFF a server understands this EDNS parameter, it responds with the > corresponding EDNS parameter (possibly without bits, either same EDNS > parameter or a sibling parameter), and sets the 15 bits per whatever the > rules are. > Reason: > Putting bits in the header (when mutually understood and agreed upon) ensures > they are in the first portion of the response, even if the response gets > fragmented. E.g. for entropy, this is an important feature, to protect > against things like "fragmentation considered poisonous". > > Brian > > > On Wed, Jul 26, 2023 at 4:12 PM George Michaelson wrote: > if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in > the header. > > What would be interesting uses of the flow-label? Oh wait.. that's > right, nobody really knows at scale how to use flow-label either. > > I tend to "use it for 15 bits of signalling" because there are a lot > of things I wish were signalled from client to server. > > "I am new code" > "I am at least not ancient code" > "I'm the same as that other guy you saw over " > "I like TCP and want to do a persisting session" > "tell me if you are doing a|b|c|d" > "I like chocolate and want a pony" > > maybe the truth is, we've got 15 bits of zero in the header forever, amen. > > (I deliberately didn't put this in the draft- post from Ray so as not > to pollute an objective discussion of what it is or is not the value > proposition) > > clue-stick hits welcome. Avoid the stomach. > > -G > > _______ > 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 -- 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] [Ext] Compact DoE sentinel choice
> On 8 Aug 2023, at 10:58, Shumon Huque wrote: > > On Wed, Jul 26, 2023 at 11:05 PM Edward Lewis wrote: > On 7/24/23, 1:55 PM, "DNSOP on behalf of Viktor Dukhovni" > wrote: > >2. That said, there are multiple ways to *distinguish* ENT vs. NXDOMAIN > >responses: > > > >a. Sentinel RTYPE for NXDOMAIN with just NSEC + RRSIG for ENT. > >b. Sentinel RTYPE for ENT with just NSEC + RRSIG for NXDOMAIN. > >c. Distinct sentinel RTYPEs for both ENTs and NXDOMAIN. > > > >Presently, the draft is proposing option "a". My point is that with "a" > >we get a response that is promising the existence of an RRset for a name > >that does not exist: > > Launching off this observation (and realizing there's a whole thread > following it), I wanted to register some discomfort with this approach. > > The definition of DNSSEC in RFC 4035 contains this paragraph: > > # An NSEC record (and its associated RRSIG RRset) MUST NOT be the only > # RRset at any particular owner name. That is, the signing process > # MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not > # the owner name of any RRset before the zone was signed. The main > # reasons for this are a desire for namespace consistency between > # signed and unsigned versions of the same zone and a desire to reduce > # the risk of response inconsistency in security oblivious recursive > # name servers. > > What is most significant in that text is the "desire for namespace > consistency between signed and unsigned versions of the same zone". With > this proposal providing an answer that says "yes the name exists but it > doesn't have what you want" contradicts the unsigned response that would > indicate NXDOMAIN, there is an inconsistency in what is seen in the signed > and unsigned zone. > > Note: I'm not trying to say "we have to stick to the old rules", I'm trying > to look at the environment in which the DNSSEC was born and how we went from > concept to reality (then). > > Hi Ed, > > It might be time to revise the spec to remove this constraint, which I > personally don't find very compelling. And besides, as a practical matter, > resolvers in the field don't appear to enforce this constraint in any way > that I can detect. > > Compact DoE, and RFC4470 already appear to violate it for ENT responses. And > it was (arguably) already violated by pre-computed NSEC3 (5155), where an > empty non-terminal name (or rather the hash of it) does solely own an NSEC3 > record. You can’t query for NSEC3 records. NSEC3 names do not prevent wildcard matches nor are NSEC3 records or their RRSIGs returned for * queries at the hashed name. They are pure metadata. NSEC3 records and their RRSIGs exist in their own namespace. > Shumon. > > ___ > 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] [Ext] Compact DoE sentinel choice
> On 8 Aug 2023, at 11:27, Shumon Huque wrote: > > On Mon, Aug 7, 2023 at 9:20 PM Mark Andrews wrote: > > You can’t query for NSEC3 records. NSEC3 names do not prevent wildcard > matches nor are NSEC3 records or their RRSIGs returned for * queries at the > hashed name. They are pure metadata. NSEC3 records and their RRSIGs exist > in their own namespace. > > I'm well aware. > > My comment was specifically related to the constraint that NSEC records > cannot be the sole record type owned by a domain name. That constraint was in > 4035 though, and perhaps cannot even be extrapolated to NSEC3. The different namespaces preclude there being such a record additionally it is noted that NSEC3 will never appear in the types bit map. Similarly RRSIG can’t appear by itself. o The Type Bit Maps field of every NSEC3 RR in a signed zone MUST indicate the presence of all types present at the original owner name, except for the types solely contributed by an NSEC3 RR itself. Note that this means that the NSEC3 type itself will never be present in the Type Bit Maps. > Shumon. > -- 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] Paul Wouters' Yes on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)
> On 7 Sep 2023, at 13:56, Paul Wouters via Datatracker > wrote: > > Paul Wouters has entered the following ballot position for > draft-ietf-dnsop-caching-resolution-failures-07: Yes > > 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://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-caching-resolution-failures/ > > > > -- > COMMENT: > -- > > Thanks for this document and my apologies for being involved/related to two > of the five outages you described :-) > > >Consistent with [RFC2308], resolution failures MUST NOT be cached >for longer than 5 minutes. > > If an expired RRSIG has a TTL of 3600, what should happen? The resolution > failed because the signature is no longer valid but the individual > components of this validation failure are all successful lookups of RRs that > are now in the cache. Wouldn't this result in a resolution failure of > 3600? How would an implementation limit this to 5 minutes? By deleting > the RRSIG from its cache within 5 minutes, overriding its TTL? The server shouldn’t be caching the RRset and it’s RRSIGs unless they validate successfully. This is a requirement of DNSSEC. This is also why recursive servers need to validate responses so that garbage is not cached. > If so, is there value stating this in the document? > > >also known as 'lame' > > I thought the WG agreed the definition of 'lame' was not agreed upon and > the term is no longer being favoured for use. Why not just remove this part? > >To prevent such unnecessary DNS traffic, security-aware resolvers >MUST cache DNSSEC validation failures, with some restrictions. > > What are these "some restrictions" ? > > > > ___ > 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] Question regarding RFC 7793
Please make a understandable request. -- Mark Andrews > On 16 Sep 2023, at 05:24, Von Johnson wrote: > > > Please help me return this to normal > ___ > 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] Automated delegation management via DDNS
Just picking one of these emails.
What’s all the FUD here about?
There is *nothing* new here. CPE boxes have done UPDATE to change their
addresses to *non authoritative* servers using UPDATE for at least a decade
now. DYN DNS did this. The updates used TSIG for authentication. Mac also
does this. There is a SRV prefix registered for finding the update server.
Apple registered SRV prefixes at least twice for this _dns-update._tcp,
_dns-update._udp in 2019 and there where earlier ones which I can’t find on the
current IANA website.
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=dns
This one may be a re-registration. They have also registered a one using TLS.
Using SIG(0) to update delegations has been part of the protocol since the RFC
2931 was published. The reason UPDATE has a ZONE section is to allow parent
zones to be updated. NS and glue records initially. DS once it came into
existence.
Having a update policy that allows you to update the name derived from the key
name and its children is also straight forward. The obvious one is a one to
one mapping. It was so obvious that we just implement it approximately 2
decades ago. The original policy set had “self”. We added sub domains of the
key a little later. We added record count restrictions by type later still.
commit 6e373c502584f9292e964378411d296c8259026b
Author: Mark Andrews
Date: Thu Feb 16 01:34:24 2006 +
1983. [func] Two new update policies. "selfsub" and "selfwild".
[RT #12895]
Now the only thing here is to formalise what has been supported for DECADES now
by saying everyone should JUST DO IT.
I wrote a draft in 2013
https://www.ietf.org/archive/id/draft-andrews-dnsop-update-parent-zones-04.txt
about how to do this. It used TSIG but SIG(0) works just as well. Nothing
proposed then was new.
--
Mark Andrews
> On 26 Oct 2023, at 04:21, Johan Stenstam
> wrote:
>
>
>
>> On 25 Oct 2023, at 18:58, Joe Abley wrote:
>>
>> On 25 Oct 2023, at 18:46, Johan Stenstam
>> wrote:
>>
>>> I agree. But it is bad to design a system where the key CANNOT be rolled.
>>
>> I agree. I was just expressing doubt that you can find a single automated
>> mechanism that is appropriate to use in all possible compromise scenarios.
>>
>> For a hopefully rare event that might need careful handling, perhaps a good
>> manual plan is actually better.
>
> I agree with this also.
>
> And that functionality is already there. If you’re using BIND9 it is your
> decision, in the update-policy {} section, whether to allow dynamic updates
> to update the key (i.e. roll the key) or only update NS, glue and DS RRsets.
> My own code does the same. And in most cases manual fallback in case of a key
> compromise is likely the best option.
>
> Johan
>
>
> ___
> 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] [Editorial Errata Reported] RFC8906 (7689)
'flag: do’ is just the way ‘dig’ displays ‘DO=1’ in the EDNS flags. I would leave this as editorial. I would accept this but I doubt there will ever be a reissue. If this editorial change is made there are other instances that would need changes. > On 27 Oct 2023, at 12:11, Rebecca VanRheenen wrote: > > Hi Warren, > > We are unable to verify this erratum that the submitter marked as editorial. > Please note that we have changed the “Type” of the following errata > report to “Technical”. As Stream Approver, please review and set the > Status and Type accordingly (see the definitions at > https://www.rfc-editor.org/errata-definitions/). > > You may review the report at: > https://www.rfc-editor.org/errata/eid7689 > > Please see https://www.rfc-editor.org/how-to-verify/ for further > information on how to verify errata reports. > > Further information on errata can be found at: > https://www.rfc-editor.org/errata.php. > > Thank you. > > RFC Editor/rv > > > > >> On Oct 26, 2023, at 3:30 PM, RFC Errata System >> wrote: >> >> The following errata report has been submitted for RFC8906, >> "A Common Operational Problem in DNS Servers: Failure to Communicate". >> >> -- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid7689 >> >> -- >> Type: Editorial >> Reported by: Josh Soref >> >> Section: 8.2.8 >> >> Original Text >> - >> expect: DO=1 to be present if an RRSIG is in the response >> >> >> Corrected Text >> -- >> expect: flag: do to be present if ... >> >> Notes >> - >> The same section has `expect: flag: aa to be present`, and when running the >> suggested command, no `DO=1` is shown, which makes the advice unhelpful. >> >> Sample command: >> ``` >> $ dig +nocookie +edns=0 +noad +norec +dnssec soa $zone @$server >> >> ; <<>> DiG 9.16.44-Debian <<>> +nocookie +edns +noad +norec +dnssec soa >> powerdns.com @2600:3c03::f03c:91ff:fe55:e54d >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 45268 >> ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags: do; udp: 1232 >> ;; QUESTION SECTION: >> ;powerdns.com. IN SOA >> >> ;; Query time: 0 msec >> ;; SERVER: 2600:3c03::f03c:91ff:fe55:e54d#53(2600:3c03::f03c:91ff:fe55:e54d) >> ;; WHEN: Thu Oct 26 22:26:44 UTC 2023 >> ;; MSG SIZE rcvd: 41 >> ``` >> >> Instructions: >> - >> This erratum is currently posted as "Reported". (If it is spam, it >> will be removed shortly by the RFC Production Center.) Please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> will log in to change the status and edit the report, if necessary. >> >> ---------- >> RFC8906 (draft-ietf-dnsop-no-response-issue-23) >> -- >> Title : A Common Operational Problem in DNS Servers: Failure >> to Communicate >> Publication Date: September 2020 >> Author(s) : M. Andrews, R. Bellis >> Category: BEST CURRENT PRACTICE >> Source : Domain Name System Operations >> Area: Operations and Management >> Stream : IETF >> Verifying Party : IESG >> -- 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] [Maprg] MAPRG Agenda for IETF-118
I suspect most of the DNS people will be at ADD. Mark > On 6 Nov 2023, at 18:24, Mirja Kuehlewind > wrote: > > Hi DNS people! > > We have some interesting DNS related talks MAPRG on DNSSEC misbehavior and > Transparent Forwarders. > > Please join the session on Wednesday morning! > > Mirja > > On 06.11.23, 08:19, "Maprg on behalf of Mirja Kuehlewind" > mailto:maprg-boun...@irtf.org> on behalf of > mirja.kuehlewind=40ericsson@dmarc.ietf.org > <mailto:40ericsson@dmarc.ietf.org>> wrote: > > > Hi all, > > > please find your agenda below and here: > > > https://datatracker.ietf.org/meeting/118/materials/agenda-118-maprg-04 > <https://datatracker.ietf.org/meeting/118/materials/agenda-118-maprg-04> > > > We have a great number of really interesting talks on e.g. QUIC, DNS, IPv6, > as usually, but also one talk on tracking through tags! > > > See you all (in-person or remote) at the session on Wednesday morning! > > > Mirja & Dave > > > -- > # IRTF maprg agenda for IETF-118 (Prague) > > > Date: Wednesday, 8 November 2023, Session I 0930-1130 > Full client with Video: > https://meetecho.ietf.org/conference/?group=maprg&short=maprg&item=1 > > <https://meetecho.ietf.org/conference/?group=maprg&short=maprg&item=1<br>;> > Room: Congress Hall 2 > IRTF Note Well: > https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-05354f2d0f0ed852&q=1&e=1354aa29-d843-42fc-b4ff-49c1392f75f5&u=https%3A%2F%2Firtf.org%2Fpolicies%2Firtf-note-well-2019-11.pdf > > <https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-05354f2d0f0ed852&q=1&e=1354aa29-d843-42fc-b4ff-49c1392f75f5&u=https%3A%2F%2Firtf.org%2Fpolicies%2Firtf-note-well-2019-11.pdf<br>;> > > > ## Agenda > > > ### Overview and Status - Mirja/Dave (5 min) > > > ### QUIC(k) Enough in the Long Run? Sustained Throughput Performance of QUIC > Implementations - Roland Bless (10 mins) > > > ### Dissecting Performance of Production QUIC - Theo Benson (10 mins) > > > ### Using the Spin Bit and ECN with QUIC: Adoption and Challenges in the Wild > - Ike Kunze, Constantin Sander (15 mins) > > > ### Characterizing open DNS resolver misbehavior for DNSSEC queries - > Sudheesh Singanamalla (remote) (15 mins) > > > ### Transparent Forwarders: An Unnoticed Component of the Open DNS > Infrastructure - Maynard Koch (10 mins) > > > ### RoVista: Measuring and Analyzing the Route Origin Validation (ROV) in > RPKI - Weitong Li (remote) (15 mins) > > > ### Adaptive Address Family Selection for Latency-Sensitive Applications on > Dual-stack Hosts - Maxime Piraux (10 mins) > > > ### IPv6 Hitlist - Johannes Zirngibl (10 mins) > > > ### I Tag, You Tag, Everybody Tags! - Yasir Zaki (remote) (10 mins) > > > > > ___ > Maprg mailing list > ma...@irtf.org <mailto:ma...@irtf.org> > https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-59fe69e8caa22cd0&q=1&e=1354aa29-d843-42fc-b4ff-49c1392f75f5&u=https%3A%2F%2Fmailman.irtf.org%2Fmailman%2Flistinfo%2Fmaprg > > <https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-59fe69e8caa22cd0&q=1&e=1354aa29-d843-42fc-b4ff-49c1392f75f5&u=https%3A%2F%2Fmailman.irtf.org%2Fmailman%2Flistinfo%2Fmaprg> > > > > ___ > 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] NOTIFY: How to locate the target
> On 9 Nov 2023, at 22:11, John R Levine wrote: > > On Thu, 9 Nov 2023, Joe Abley wrote: >>> Apropos Joe's message, the child could hypothetically try and send the >>> NOTIFTY to the parent SOA, e.g. a.gtld-servers.net for .com or .net. But >>> those are clouds of anycast servers and even if you can get that to work, >>> they belong to the registry while the notify needs go go to the registrar >>> so it can update the registry via EPP. >> >> I don't agree that it's impossible to use an anycast target for this, any >> more than it's impossible to distribute any service using anycast. > > I don't think it's impossible either, but it's swatting a fly with a > motorcycle. As far as I know the anycast mirrors do not feed stuff in > realtime back to their primaries and this would be quite a change, not to > mention needing non-standard hacks to their DNS servers. (That's "reverse > anycast".) Named at least will forward UPDATE to the primary servers. It’s off by default because it hides the source address and UPDATE may be restricted by IP address but it works with both TSIG and SIG(0). This is standards defined behaviour. TSIG was designed to support this. SIG(0) requires a bit more care as the QID is coved by the SIG(0). Adding forwarding of NOTIFY(CDS), NOTIFY(CDNSKEY) would be trivial. Directing it to another “server" would also be trivial. So to be clear, reverse anycast exists today for UPDATE. It has existed for as long as UPDATE has existed. >> As far as communication with registrars goes, the registry operator is >> actually ideally placed to relay general messages to registrars. I'm not >> sure why this is being discounted. They already do so for other purposes. > > At that other I* organization we were led to understand that registrars get > unhappy when the registry interacts directly with their customers. If we can > get the registrars and registries to go for it, registry forwarding is fine > with me, but I don't think it would be a good idea to specify it unless we > are confident that people are willing to do it. > > Re stealth, the place you send the NOTIFY is in practice going to be a server > that just does the update stuff, not a public or stealth DNS server. > > 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 -- 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] RFC7477 typo?
It’s stopping the serial changing too fast. -- Mark Andrews > On 2 Dec 2023, at 06:43, Warren Kumari wrote: > > > > Dear DNSOP (and Wes), > > I was wading through my mailbox and realized that I hadn't seen any > discussion of this. > > > I'm quite sure that 2^16 is not a typo (there is quite a lot of text around > this section), but I cannot really figure out / remember what exactly the > threat model here is. > > Here are the relevant paragraphs: > Sec 2.1.1.1. The SOA Serial Field: > "Although Section 3.2 of [RFC1982] describes how to properly implement >a less-than comparison operation with SOA serial numbers that may >wrap beyond the 32-bit value in both the SOA record and the CSYNC >record, it is important that a child using the soaminimum flag must >not increment its SOA serial number value more than 2^16 within the >period of time that a parent might wait between polling the child for >the CSYNC record." > > Sec 5. Security Considerations > "To ensure that an older CSYNC record making use of the soaminimum >flag cannot be replayed to revert values, the SOA serial number MUST >NOT be incremented by more than 2^16 during the lifetime of the >signature window of the associated RRSIGs signing the SOA and CSYNC >records. Note that this is independent of whether or not the >increment causes the 2^32 bit serial number field to wrap." > > > I can (mostly) understand why the SOA must not fully wrap (2^32) or probably > even 1/2 wrap (2^31), but what bad thing would happen if it incremented by > e.g 2^24? > > It might just be that 2^16 was sufficiently far from 2^32 that it was viewed > as "conservative even with much slop", but that feels somewhat like a cop-out… > > Can someone help me understand? > W > > > > On Thu, Nov 09, 2023 at 1:45 PM, Bob Harold wrote: >> https://datatracker.ietf.org/doc/html/rfc7477#section-5 >> section 5. Security Considerations >> last paragraph >> >> "the SOA serial number MUST NOT be incremented by more than 2^16" >> >> 2^16 is a very small fraction of the 2^32 serial number space. It seems >> that half of the 2^32 would be sufficient, which is 2^31 (not 2^16). Is >> that a typo, or is there a reason for the small range? >> >> -- >> Bob Harold >> >> ___ >> 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 mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC7477 typo?
It an educated guess that should prevent a undetected rollover occurring. -- Mark Andrews > On 2 Dec 2023, at 08:29, Warren Kumari wrote: > > > > > > >> On Fri, Dec 01, 2023 at 4:03 PM, Mark Andrews wrote: >> It’s stopping the serial changing too fast. > > > > Well, yeah, obviously, but what is "too fast"? Why is 2^16 OK but 2^20 or > 2^30 or 2^18.365 not? > > W > > >> >> -- >> Mark Andrews >> >>>> On 2 Dec 2023, at 06:43, Warren Kumari wrote: >>>> >>> >>> Dear DNSOP (and Wes), >>> >>> I was wading through my mailbox and realized that I hadn't seen any >>> discussion of this. >>> >>> >>> I'm quite sure that 2^16 is not a typo (there is quite a lot of text around >>> this section), but I cannot really figure out / remember what exactly the >>> threat model here is. >>> >>> Here are the relevant paragraphs: >>> Sec 2.1.1.1. The SOA Serial Field: >>> "Although Section 3.2 of [RFC1982] describes how to properly implement >>>a less-than comparison operation with SOA serial numbers that may >>>wrap beyond the 32-bit value in both the SOA record and the CSYNC >>>record, it is important that a child using the soaminimum flag must >>>not increment its SOA serial number value more than 2^16 within the >>>period of time that a parent might wait between polling the child for >>>the CSYNC record." >>> >>> Sec 5. Security Considerations >>> "To ensure that an older CSYNC record making use of the soaminimum >>>flag cannot be replayed to revert values, the SOA serial number MUST >>>NOT be incremented by more than 2^16 during the lifetime of the >>>signature window of the associated RRSIGs signing the SOA and CSYNC >>>records. Note that this is independent of whether or not the >>>increment causes the 2^32 bit serial number field to wrap." >>> >>> >>> I can (mostly) understand why the SOA must not fully wrap (2^32) or >>> probably even 1/2 wrap (2^31), but what bad thing would happen if it >>> incremented by e.g 2^24? >>> >>> It might just be that 2^16 was sufficiently far from 2^32 that it was >>> viewed as "conservative even with much slop", but that feels somewhat like >>> a cop-out… >>> >>> Can someone help me understand? >>> W >>> >>> >>> >>>> On Thu, Nov 09, 2023 at 1:45 PM, Bob Harold wrote: >>>> https://datatracker.ietf.org/doc/html/rfc7477#section-5 >>>> section 5. Security Considerations >>>> last paragraph >>>> >>>> "the SOA serial number MUST NOT be incremented by more than 2^16" >>>> >>>> 2^16 is a very small fraction of the 2^32 serial number space. It seems >>>> that half of the 2^32 would be sufficient, which is 2^31 (not 2^16). Is >>>> that a typo, or is there a reason for the small range? >>>> >>>> -- >>>> Bob Harold >>>> >>>> ___ >>>> 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 mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Errata 7689 against RFC 8906, "A Common Operational Problem in DNS Servers: Failure to Communicate"
> On 16 Jan 2024, at 10:13, Paul Wouters wrote:
>
> On Mon, 15 Jan 2024, Warren Kumari wrote:
>
>> dig +nocookie +edns=0 +noad +norec +dnssec soa $zone @$server
>> expect: status: NOERROR
>> expect: the SOA record to be present in the answer section
>> expect: an OPT record to be present in the additional section
>> expect: DO=1 to be present if an RRSIG is in the response
>> expect: EDNS Version 0 in response
>> expect: flag: aa to be present
>> The actual output from dig goeth thus:
>> dig +nocookie +edns=0 +noad +norec +dnssec soa ietf.org
>> @jill.ns.cloudflare.com.
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20613
>> ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags: do; udp: 1232
>> Seeing as the document says you should "expect: flag: aa to be present", it
>> does seem like it would be better if it also said: "expect: flag: do to be
>> present if an RRSIG is in the response", as that is more inline with what
>> someone writing a test would see.
>
> It's not really in the flags: section, but in the EDNS0 flags section.
>
> It should already really use the plural for flag, eg:expect: flags: to
> contain "aa".
>
> What's more confusing here I think is the example dig command using
> "@$server". I think what was meant was an authoritative server, but the
> errata
> reporter ran it against a public resolver (an instance of 1.1.1.1),
> which returned him a Refused (when I try that against 1.1.1. I get
> ServFail)
>
> Warren ran his example of ietd.org against an authoritative server,
> because he knew using "no recursion" at a recursor makes no sense :)
>
>> This seems like a fairly simple clarification / place where things could
>> have been worded better, but I don't think that it rises to the level of a
>> "Verified" errata, but it's also not wrong, so my proposed resolution is:
>> Accept the errata as Editorial, Hold for Document Update.
>> ("Hold for Document Update - The erratum is not a necessary update to the
>> RFC. However, any future update of the document might consider it and
>> determine
>> whether it merits including in an update." — from:
>> https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/
>> )
>> Can anyone not live with this? Please speak up by Jan 29th, otherwise I'll
>> do what's above.
>
> That seems fine with me. Maybe mention that "@$server" refers to an
> authoritative server, and not a recursive server, as well ?
See section 8
>
> Paul
>
> ___
> 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] Dnsdir early review of draft-ietf-dnsop-qdcount-is-one-01
Really, cancel culture. It’s a couple of lines of code in a nameserver to support QCOUNT=0. It will take more time debating this than it took to implement support for QCOUNT=0. > On 19 Jan 2024, at 00:22, Joe Abley wrote: > > On 18 Jan 2024, at 13:42, Petr Špaček wrote: > >> The only piece missing to make it *perfect* is "MUST use QDCOUNT=1", or in >> other words, banning QDCOUNT=0 usage with DNS COOKIES. It's unnecessary >> complexity. > > I think these are two different suggestions: > > (1) Update the cookies spec to require QDCOUNT = 1 too > > (2) Apply a definitive restriction on QDCOUNT for all future opcodes, > imagined or otherwise. > > I would prefer (1) to happen in a different document if is to be done, since > there are cookies-specific conservations to be discussed and I don't think it > would make the current document clearer to go through them all here. There > are also different operational considerations based on what currently does or > doesn't happen in the wild. > > I'm not sure what I think about (2), at least partly because I'm always wary > about predicting the future. > > > Joe > _______ > 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] AD Review of draft-ietf-dnsop-rfc8109bis
> On 1 Feb 2024, at 06:38, Warren Kumari wrote: > > Hi there, authors (and WG), > > Thank you for this document — I have some questions / comments before I can > progress it. > > Firstly, the (presumably) easy one: > The document says: > "This document, when published, obsoletes RFC 8109." - can you add something > along the lines of "Section 1.1 contains a list of changes from RFC 8109" or > similar…. > > Now the harder one… > Sec 4.2: > "If some root server addresses are omitted from the Additional section, there > is no expectation that the TC bit in the response will be set to 1. At the > time that this document is written, many of the root servers are not setting > the TC bit when omitting addresses from the Additional section. Root server address are NOT glue. Glue only appears in a referral. The response to "dig NS ." is not a referral. Glue is added RFC 1034 4.3.2. Algorithm Step 3b. Root server addresses are added at Step 6. Step 3b [Paragraph one omitted] Copy the NS RRs for the subzone into the authority section of the reply. Put whatever addresses are available into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache. Go to step 4. vs Step 6 Using local data only, attempt to add other RRs which may be useful to the additional section of the query. Exit. This is why the root servers need to have a local copy of root-servers.net. It’s the data source for those address records. > Note that [RFC9471] updates [RFC1035] with respect to the use of the TC bit. > It says "If message size constraints prevent the inclusion of all glue > records for in-domain name servers, the server must set the TC (Truncated) > flag to inform the client that the response is incomplete and that the client > should use another transport to retrieve the full response." " > > IMO, this text is confusing…. > It sounds like it is saying "RFC9471 says you must set TC if you truncate the > glue. The root server folk are ignoring RFC9471, bad root server folk…" > > I have read the discussion in the WGLC ( inc > https://mailarchive.ietf.org/arch/msg/dnsop/wtjuoVqkKmww988Hyq2QDq_nKpA/ and > am assuming it was rewritten as "If some root server addresses are omitted > from the Additional section…".), but I don't really think that really > addresses my concern — it's easy to miss the subtleties and the "all glue > records" vs "some addresses" bit is tricky. > > It's also true that "At the time that this document is written, many of the > root servers are not setting the TC bit when omitting addresses from the > Additional section." — RFC9471 was only published at the end of September, > there is an open BIND bug to update this behavior (I think! - > https://gitlab.isc.org/isc-projects/bind9/-/issues/4540 ), and is planned to > change in 9.19.x (I think!) > > So, while what it written is all technically correct[0], the tone feels > weird. I think that some of this is because ot the timing of when this and > RFC9471 were written. > > RFC8109 was published 7 years ago, and I'm hoping that rfc8109bis will > survive at least that long. > > I don't know how we address my concern, but it feels like, in e.g 6 years, > this text will have aged poorly... > Can you see about some more massaging of this text? > > W > [0]: The best kind of correct…. > > > ___ > 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] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis
There is nothing to prevent us saying that responses to priming queries SHOULD/MUST set TC if all of the addresses of the root servers won’t fit in the response or that the root server address should be looked up as if they are glue in the root zone. The rules in RFC 1034 don’t handle priming queries well in a number of ways. 1) all the addresses should be returned or TC should be set. 2) the address of the root servers should be looked up as glue in the root zone if not found elsewhere 3) the addresses of the root servers should be included as glue in the root zone if not otherwise there. -- Mark Andrews > On 2 Feb 2024, at 06:15, Wessels, Duane > wrote: > > > >>> On Jan 31, 2024, at 5:57 PM, Paul Hoffman wrote: >>> >>> As Mark just clarified. This isn't glue, so perhaps the text just needs >>> updating. >> >> The current text is: >> >> If some root server addresses are omitted from the Additional section, >> there is no expectation that the TC bit in the >> response will be set to 1. At the time that this document is written, many >> of the >> root servers are not setting the TC bit when omitting addresses from the >> Additional section. >> >> Note that updates with >> respect to the use of the TC bit. >> It says "If message size constraints prevent the inclusion of all glue >> records for in-domain name servers, >> the server must set the TC (Truncated) flag to inform the client that the >> response is incomplete >> and that the client should use another transport to retrieve the full >> response." >> >> Maybe we should add to the second paragraph: >> >> Note, however, the root server addresses are not glue records, so setting >> the TC bit in truncated responses from >> the root servers is not required by RFC 9471. >> >> Does this solve your and Warren's issues? > > > I have to confess that “root server addresses are not glue records” is a very > subtle point that was lost on me, and > maybe lost on a lot of us, as evidenced by this discussion. > > I’m not particularly comfortable with the terseness of the statement above. > The terminology RFC doesn’t really help here because it doesn’t provide a > definition of what glue is glue or what is not glue. It just references > semi-conflicting statements in other RFCs. > > So I think if 8109bis is going to make the statement that root server > addresses are not glue, it deserves more explanation of why that is the case. > > I also worry that it creates a new problem, which is what sort of truncation > policy applies to a priming response? If RFC 9471 does not apply, does RFC > 2181 Section 9 apply? Is a priming response with zero root server IP > addresses acceptable? > > DW > > > ___ > 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] AD Review of draft-ietf-dnsop-rfc8109bis
> On 7 Feb 2024, at 09:57, Brian Dickson wrote: > > > > On Thu, Feb 1, 2024 at 12:03 PM Mark Andrews wrote: > There is nothing to prevent us saying that responses to priming queries > SHOULD/MUST set TC if all of the addresses of the root servers won’t fit in > the response or that the root server address should be looked up as if they > are glue in the root zone. The rules in RFC 1034 don’t handle priming queries > well in a number of ways. > > 1) all the addresses should be returned or TC should be set. > 2) the address of the root servers should be looked up as glue in the root > zone if not found elsewhere > 3) the addresses of the root servers should be included as glue in the root > zone if not otherwise there. > > > I just (finally) gave this a second look/thought. > > I think Mark A's assertion/summary isn't quite 100% correct, based on the > following particular details: > - The concept of a DNS zone (from classic 103[345] RFCs) is a contiguous > portion of the DNS tree. > - The root server names are underneath 'root-servers.net'. > - There is a delegation to 'net' from the root zone. > - The servers themselves (as identified by their IP addresses) are > authoritative for both '.' (root zone) and 'root-servers.net' > - Thus, it is NOT the case that responses from the "root servers" to queries > don't require the TC bit to be set if the entire set of authoritative A/ > records does not fit in the Additional section. > - A careful parsing/analysis would suggest instead, that the A/ records > are in fact in-bailiwick (or whatever we call it these days) from the > 'root-servers.net' zone. > - As such, if the entire set of A/ records does not fit, there are two > alternative approaches: > - Set TC > - Add a referral to the 'net' zone with its glue (not 100% sure this is > correct, but that's what I think would need to happen to satisfy > resolvability of the NS names to A/ addresses). > > Apologies if my analysis is wrong or the terminology is wrong or the > suggested referral is incorrect... > > Brian RFC 1034 really doesn’t handle "priming queries" well. ‘dig ns . @$rootserver’, in the general case, will not return address records for the servers as they are not part of the data above the bottom of zone cuts. This has always been the case even when the server where known by their original names as they where in delegated name spaces. It just happened to work because the implementations where buggy and leaked GLUE or just obscured addresses into ANSWERS rather than only returning GLUE in DELEGATIONS as is specified. This leaking has been cleanup in most implementations. The current work around to get addresses in the additional section, with the Internet's root servers, is to also server root-servers.net but that doesn’t ensure that all the addresses are returned and doesn’t result in TC=1 being set. Applying the same work around to the pre root-servers.net root zone would have required the root servers serving 13(?) other zones to get the address records. Now I think we want the priming response to indicate when the additional section couldn’t fit the address records in (i.e. set TC=1). It may also be useful for the general NS query case. I also think that we need a mechanism other than serving additional zones to supply the address records (e.g. add addresses records to the root zone for the root and have the root servers retrieve them). Both of these things require protocol CHANGES. Setting TC=1 shouldn’t cause problems for resolvers as they should all be expecting it for any query they make. The root NS RRset could be bigger than 500 bytes and the resolvers should handle that. There may be some broken ones that don’t. Mark > -- > Mark Andrews > > > On 2 Feb 2024, at 06:15, Wessels, Duane > > wrote: > > > > > > > >>> On Jan 31, 2024, at 5:57 PM, Paul Hoffman wrote: > >>> > >>> As Mark just clarified. This isn't glue, so perhaps the text just needs > >>> updating. > >> > >> The current text is: > >> > >> If some root server addresses are omitted from the Additional section, > >> there is no expectation that the TC bit in the > >> response will be set to 1. At the time that this document is written, many > >> of the > >> root servers are not setting the TC bit when omitting addresses from the > >> Additional section. > >> > >> Note that updates > >> with respect to the use of the TC bit. > >> It says "If message size constraints prevent the inclusion
Re: [DNSOP] About key tags
The primary use of the key tag is to select the correct key to validate the signature from multiple keys. -- Mark Andrews > On 10 Feb 2024, at 12:38, Wellington, Brian > wrote: > > > >> On Feb 8, 2024, at 6:41 AM, Edward Lewis wrote: >> >> ... >> >> When DNSSEC was designed, the possibility of tags colliding was known. The >> validation process was defined to expect that a tag might lead to a >> non-singleton set of keys. When it came to key management, and the practice >> of storing keys in files named K--.public was >> derived, the lone developer of DNSSEC code (at the time) sidestepped the >> odds that key tags would collide by deleting the work done when creating a >> new key pair if the file to be used already existed. This side-stepping >> practice was never added to a standards document. (BTW, the reason for the >> "K" in the filename was that we developed the protocol using a test root >> zone, meaning the would be ".". A filename starting with "." is >> hidden in the OS systems we used then, so we needed a prefix.) > > This is a mischaracterization of history. > > Yes, dnssec-keygen would regenerate a key upon tag collision. This seemed > like a reasonable thing to do. > > The behavior was never added into any standards document because it has > nothing to do with the standard. The standards documents don’t describe how > keys are stored, nor any tooling around their generation. If an > implementation chooses to avoid generating keys which have the same key tag, > that is an implementation issue, and doesn’t in any way make it noncompliant > with the specification. There was no reason at the time why allowing for the > generation of colliding keys would be useful, and I believe that’s still the > case. The fact that no one’s updated the tools to allow this in almost 25 > years is probably significant. > > If an implementation doesn’t support multiple keys with the same key tag when > validating, that would be noncompliant. That was not the case, though. > > Brian___ > 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] About key tags
> On 13 Feb 2024, at 00:56, Edward Lewis wrote: > > On 2/9/24, 22:05, "Mark Andrews" wrote: > >> The primary use of the key tag is to select the correct key to validate the >> signature from multiple keys. > > Yes - which is great if 1) you need to pare down the potential set of keys > into something you can handle (like, from 10's to 3) and 2) if you have > somewhat to request only those keys. > > Operators generally only publish 2 keys outside of rolls, 3 when rolling the > ZSK or the KSK, maybe more if they aren't optimizing. There's no need to > specify a subset. I say this with complete highsight. I would still argue that there is still a need even if there is only 2 keys. Verification is expensive. It always has been. > And, in the DNSSEC protocol, there's never been a way to request the DNSKEY > resource record set (to validate something) that includes 'but only those > key(s) with key tag ABCDE. So, subsetting doesn't help the response size > issue. > > My reason for raising this is...not to deprecate key tags as they exist > today, it's not worth it, but to avoid designing something like them in the > future. We don't need them, and they have contributed operational issues > and, reportedly, one significant outage. -- 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] [Last-Call] Tsvart telechat review of draft-ietf-dnsop-dns-error-reporting-07
> On 15 Feb 2024, at 03:03, Paul Wouters wrote: > > On Wed, 14 Feb 2024, Roy Arends wrote: > >>>> It is recommended that the client (the resolver) sets the DNS COOKIE. The >>>> benefit of using cookies is for the client. It is to make sure that the >>>> response is genuine. >>> Does it? Not for an on-path attacker that sees the COOKIE in the clear. >>> So what attack does this really counter? >> >> Ah, no, apologies, it doesn’t. (I’ll blame this on my DNSSEC muscle memory). >> I should know better. I’ll try again: >> >> There is text in the document that specifies what the monitoring agent >> should do if cookies are not used: >> >> Section 6.3: >> >> The monitoring agent SHOULD respond to queries received over UDP that >> have no DNS COOKIE set with a response that has the truncation bit >> (TC bit) set to challenge the resolver to re-query over TCP. > > So it is not the benefit of the client/resolver, but the benefit of the > monitoring agent getting some more confidence the report is not spoofed. > Maybe make that more explicit in the text? > >>> This sounds more like an attempt for a mechanism for the monitoring agent >>> to determine that the incoming report is not send from a spoofed address, >>> but it wouldn't work like that. Setting the TC would work, provided the >>> client comes back. Or if the monitoring agent would demand a COOKIE >>> before answering (even if the answer is not the actual data the resolver >>> wants anyway). If the monitoring agent requests a COOKIE, it would force >>> the resolver to resend with the COOKIE, proving it is not just a spoofed >>> packet. But that would always result in double the load to the >>> monitoring agent. >> >> A cookie may be set due to an earlier transaction, no? > > Which earlier transaction? If "er.otherdomain.example" is > used for receiving only failure reports? I guess NS queries for > "otherdomain.example" could trigger those. I am not sure what the current > practise of DNS COOKIES is. Do responders only request it when they see > their answer would be bigger than the question, or will they always > ask for it? Can it be enabled per-domain, so you enable it "always" > only for the error reporting zone? > > I can also see the case where resolvers might not want to invest in TCP > connections for error reporting, and might decide to not report errors at > all in such cases. So I am not sure the DNS COOKIES and/or TC strategy is > the right one, unless it would only trigger after receiving repetitive > reports. But if the reports are repetitive, no need to tell clients to > come back with TCP, since you presumable already know the error they > are wanting to report. I feel I am missing some guidance here. > > Perhaps this can be further explored in an Operational Considerations > section? You can respond with BADCOOKIE if there isn’t a server cookie. Still much cheaper than TCP. named’s 'require-server-cookie yes;’ does this. All nameservers that implement DNSCOOKIE should handle this as part of their recursive query handling. ``` % dig +showbadcookie +qr soa . ; <<>> DiG 9.19.20-dev <<>> +showbadcookie +qr soa . ;; global options: +cmd ;; Sending: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48594 ;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 287badf367f9a396 ;; QUESTION SECTION: ;. IN SOA ;; QUERY SIZE: 40 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: BADCOOKIE, id: 48594 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 287badf367f9a396010065cd4b21b108c8b316f0d5cc (good) ;; QUESTION SECTION: ;. IN SOA ;; Query time: 2 msec ;; SERVER: ::1#53(::1) (UDP) ;; WHEN: Thu Feb 15 10:22:09 AEDT 2024 ;; MSG SIZE rcvd: 56 ;; BADCOOKIE, retrying. ;; Sending: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47057 ;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 287badf367f9a396010065cd4b21b108c8b316f0d5cc ;; QUESTION SECTION: ;. IN SOA ;; QUERY SIZE: 56 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47057 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 287badf367f9a396010065cd4b21b108c8b316f0d5cc (good) ;; QUESTION SECTION: ;. IN SOA ;; ANSWER SECTION: . 426 IN SOA a.root-servers.net. nstld.verisign-grs.com. 202
Re: [DNSOP] [Last-Call] Tsvart telechat review of draft-ietf-dnsop-dns-error-reporting-07
The RRL code also sends BADCOOKIE if there isn’t a server cookie instead of setting TC=1. > On 15 Feb 2024, at 10:27, Mark Andrews wrote: > > > >> On 15 Feb 2024, at 03:03, Paul Wouters wrote: >> >> On Wed, 14 Feb 2024, Roy Arends wrote: >> >>>>> It is recommended that the client (the resolver) sets the DNS COOKIE. The >>>>> benefit of using cookies is for the client. It is to make sure that the >>>>> response is genuine. >>>> Does it? Not for an on-path attacker that sees the COOKIE in the clear. >>>> So what attack does this really counter? >>> >>> Ah, no, apologies, it doesn’t. (I’ll blame this on my DNSSEC muscle >>> memory). I should know better. I’ll try again: >>> >>> There is text in the document that specifies what the monitoring agent >>> should do if cookies are not used: >>> >>> Section 6.3: >>> >>> The monitoring agent SHOULD respond to queries received over UDP that >>> have no DNS COOKIE set with a response that has the truncation bit >>> (TC bit) set to challenge the resolver to re-query over TCP. >> >> So it is not the benefit of the client/resolver, but the benefit of the >> monitoring agent getting some more confidence the report is not spoofed. >> Maybe make that more explicit in the text? >> >>>> This sounds more like an attempt for a mechanism for the monitoring agent >>>> to determine that the incoming report is not send from a spoofed address, >>>> but it wouldn't work like that. Setting the TC would work, provided the >>>> client comes back. Or if the monitoring agent would demand a COOKIE >>>> before answering (even if the answer is not the actual data the resolver >>>> wants anyway). If the monitoring agent requests a COOKIE, it would force >>>> the resolver to resend with the COOKIE, proving it is not just a spoofed >>>> packet. But that would always result in double the load to the >>>> monitoring agent. >>> >>> A cookie may be set due to an earlier transaction, no? >> >> Which earlier transaction? If "er.otherdomain.example" is >> used for receiving only failure reports? I guess NS queries for >> "otherdomain.example" could trigger those. I am not sure what the current >> practise of DNS COOKIES is. Do responders only request it when they see >> their answer would be bigger than the question, or will they always >> ask for it? Can it be enabled per-domain, so you enable it "always" >> only for the error reporting zone? >> >> I can also see the case where resolvers might not want to invest in TCP >> connections for error reporting, and might decide to not report errors at >> all in such cases. So I am not sure the DNS COOKIES and/or TC strategy is >> the right one, unless it would only trigger after receiving repetitive >> reports. But if the reports are repetitive, no need to tell clients to >> come back with TCP, since you presumable already know the error they >> are wanting to report. I feel I am missing some guidance here. >> >> Perhaps this can be further explored in an Operational Considerations >> section? > > You can respond with BADCOOKIE if there isn’t a server cookie. Still much > cheaper than TCP. named’s 'require-server-cookie yes;’ does this. All > nameservers that implement DNSCOOKIE should handle this as part of their > recursive query handling. > > > ``` > % dig +showbadcookie +qr soa . > > ; <<>> DiG 9.19.20-dev <<>> +showbadcookie +qr soa . > ;; global options: +cmd > ;; Sending: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48594 > ;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1232 > ; COOKIE: 287badf367f9a396 > ;; QUESTION SECTION: > ;. IN SOA > > ;; QUERY SIZE: 40 > > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: BADCOOKIE, id: 48594 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1232 > ; COOKIE: 287badf367f9a396010065cd4b21b108c8b316f0d5cc (good) > ;; QUESTION SECTION: > ;. IN SOA > > ;; Query time: 2 msec > ;; SERVER: ::1#53(::1) (UDP) > ;; WHEN: Thu Feb 15 10:22:09 AEDT 2024 > ;; MSG SIZE rcvd: 56 > > ;; BADCOOKIE, retrying. > ;; Sending: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47057 > ;; flags: rd ad; QUERY: 1, ANSWER
Re: [DNSOP] [Ext] About key tags
But we can state that they should be avoided when generating new DNSKEYs. BIND has been avoiding key tag collisions for 2 decades now when generating new keys. Multi-signers all have to have the current published DNSKEY RRset which includes *all* DNSKEYs as part of their publication process. Key generation just needs to avoid key tag collisions with this set of DNSKEYs. The broker can reject new duplicate key tags if they happen to occur at the combining stage forcing a new key generation. Unless multi-signers synchronise DNSKEY generation the later should be a rare event. > On 16 Feb 2024, at 07:53, Bob Harold wrote: > > I don't think we can completely avoid tag collisions in a multi-signer > situation. They could detect and correct a collision, but due to the long > TTL's in many TLD's, that could take 24 hours. So I think resolvers should > allow for at least a few collisions and not fail on the first one. > > -- > Bob Harold > > > On Thu, Feb 15, 2024 at 3:39 PM Ralf Weber wrote: > Moin! > > On 15 Feb 2024, at 11:35, Paul Hoffman wrote: > > Resolvers can already have policies that don't allow them; that has been > > true for 20 years. There is nothing stopping any resolver from saying "I > > found a keytag collision so I'm not going to validate". Fortunately, we're > > seeing resolvers instead saying "I'll bound the amount of work I do when I > > see colliding keytags". > > I don’t know which resolver had key tag collision limits for 20 years, but am > happy to be educated. Anyway outlawing key tag collisions was and IMHO still > is on the table. It’s just that we didn’t want to break anything immediately. > > > > Compare that to "we're going to change a 20-year-old spec, wait for years > > for the changes to be implemented, and only then change the way validators > > work". The current situation is much more sustainable. > > We have had in recent history a lot of drafts that even were implemented > before they became RFC and had much larger failure ratios. I see no reason to > not immediately implement and RFC that says key tag collisions are not > allowed. > > So long > -Ralf > ——- > Ralf Weber > > ___ > 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 -- 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] [Ext] About key tags
The problem with key tag collisions is that you turn verify operations from 1 per RRset to 1.5 per RRset for a two RRSIGS with the same tag and algorithm. You can figure out the average number of verify operations with 3, 4 etc. Those extra verify operations are completely avoidable by rejecting a new key which would cause a key tag collision. Generating a new key is not hard to do. Adding a check against the common key store is not hard to do in a multi-signer scenario. It can be completely automated. Request the set of in use tags. Generate a new key that doesn’t collide. Try to reserve the new key tag. Repeat if necessary. We could even use the DNS and UPDATE to do that. Records with tuples of algorithm, tag and operator. Grab the current RRset. Add it as a prerequisite with a update for the new tag. -- Mark Andrews > On 17 Feb 2024, at 05:47, Paul Wouters wrote: > > On Feb 16, 2024, at 12:17, Petr Špaček wrote: >> >> >> It does not handle collisions in any special way. It simply does not >> validate and the resolver has no way to tell if the crypto thingy is wrong >> or if it just tried a wrong key. Any such failure is counted towards >> fail-budget (1 allowed). > > So a key tag collision with a sha1 to sha2 rollover with dual signing on a > rhel/centos box with sha1 disabled leads to servfail instead of insecure > answer ? Should I file a bug for that ? > > Paul > ___ > 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] Detecting, regeneration and avoidance was Re: [Ext] About key tags
> On 21 Feb 2024, at 01:58, Edward Lewis wrote: > > That’s where I’m heading as well… > 1) Benign collisions aren’t major headaches, except perhaps for the key > manager (because rare events are headaches) > 2) Validator resource consumption is a general issue, not tied to key tag > collisions Validator resource consumption (CPU) *is* is tied to tags. Without tags the cost of verification increases and the number of cache misses that can be handled decreases as the number of keys per algorithm increase. A tag collisions undoes the value of the tag for the keys that collide. 1 -> 1 2 -> 1.5 3 -> 2 4 -> 2.5 > My kicking this off was not the KeyTrap issue, a report of a potential > maliciously abused vulnerability. My kickoff was the report that a TLD “went > down in DNSSEC” because they published the wrong key in a key tag collision > set. That’s why I keep raising the key management angle. > From: Ted Lemon > Date: Tuesday, February 20, 2024 at 09:48 > To: Edward Lewis > Cc: Mark Andrews , Paul Wouters , > "dnsop@ietf.org" > Subject: Re: [DNSOP] Detecting, regeneration and avoidance was Re: [Ext] > About key tags > Sorry, I did not mean that the attack isn't a serious problem. I mean that > insisting that there be no key hash collisions in a verification attempt is > not as hard a problem as you were suggesting. The main issue is that it would > require a flag day, but the number of affected zones in the wild is probably > small enough that this could be managed. My point was that the keying and > signing of large, sensitive zones should not be an impediment to having it be > the rule that key hash collisions aren't allowed. Like, I'm not saying there > aren't problems, but this is not an insurmountable problem. > On Tue, Feb 20, 2024 at 9:41 AM Edward Lewis wrote: >> >> >> From: Ted Lemon >> Date: Tuesday, February 20, 2024 at 09:05 >> To: Edward Lewis >> Cc: Mark Andrews , Paul Wouters , >> "dnsop@ietf.org" >> Subject: Re: [DNSOP] Detecting, regeneration and avoidance was Re: [Ext] >> About key tags >> >This seems like an implementation detail. >> I don’t want to brush this off that quickly. >> >The random likelihood of the root and com key hashes colliding seems >> pretty small. >> This is very true - in nature. The scare raise here is that someone may >> intentionally concoct a situation, intending to cause havoc. I do have a >> dose of skepticism when use case is discovered academically as opposed to >> being seen in operational packet flows, but that doesn’t mean the >> vulnerability is irrelevant. Probably there are lots of holes remaining in >> the protocol design, not yet discovered, so long as they aren’t being they >> aren’t operationally impactful. >> The KeyTrap issue is resource consumption/depletion attack and it mentions >> key tag collisions as an ingredient, which is driving the urgency of this >> discussion. My read of the paper is that, at heart, this is a general >> resource exhaustion problem which stems from the agility of the DNS protocol >> to find an answer no matter how hard it is to find. Key tag collisions help >> in hiding intent of a malicious configuration by lowering the number of >> signature records needed. >> >And while com is rather large, computes aren't as expensive as they were >> when y'all invented the ritual. I suspect that if you just always pick two >> keys and sign the zones twice, this problem becomes so improbable that we >> never have to fall back to actually re-doing the ceremony. But if we did >> have to fall back once in a blue moon and re-do the ceremony, that might be >> quite a bit cheaper than allowing key hash collisions in situations where >> it's actually a problem. I think it would be completely reasonable to insist >> that if there is a key collision between e.g. com and fugue.com [fugue.com], >> that fugue.com [fugue.com] could be obligated to regenerate its key rather >> than com. >> In validation, key tag collisions are a problem when there is malicious >> intent and no more than a nuisance in a benign collision. >> If an operator had two active ZSKs, there would be two signatures and two >> keys. With non-colliding key tags, it would be easier to line them up - and >> recall the rule that it only takes one successful operation to declare >> success. With a collision, there’s a 50% chance of a misalignment at first, >> which is what leads to the 1.5 signature verification operations per >> instance comes from. Given the low pro
Re: [DNSOP] DNS Grease?
> On 27 Feb 2024, at 15:53, George Michaelson wrote: > > Not in any way to stop this specific draft, I wonder if this is a more > general principle of exercising code points which are not marked > "never to be used" and should also be raised cross-area, or in another > place? > > Maybe the best path is to get this proved here, and then embrace-extend. Sure there are a lot of places where this should be done. This is going to cover DNS. > I tend not to what-if the downsides, but I can imagine there would be > an initially high rate of failure which causes log flows, threat > analysis feeds and some consequent damage. That would have to be a > "lesson learned" and then we pass through to a better understanding of > which bits in a header are mutable and should not be tested as fixed > value fields. Ednscomp.isc.org, as is mentioned in the draft, has been testing this for years now. You don’t need to speculate. You can go view the behaviour patterns. > Nice, small draft. > > -G > On Tue, Feb 27, 2024 at 10:29 AM Shumon Huque wrote: >> >> Hi folks, >> >> Mark Andrews and I have submitted a new draft on 'Greasing Protocol >> Extension Points in the DNS'. >> >>https://www.ietf.org/archive/id/draft-huque-dnsop-grease-00.html >> >>(datatracker link: >> https://datatracker.ietf.org/doc/draft-huque-dnsop-grease/ ) >> >> We'd like to see if there is interest in working on this. On list and >> in-person (IETF119/Brisbane) discussion welcome. >> >> Shumon (and Mark). >> >> ___ >> 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 -- 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] DNS Grease?
Yep, we are in a much better position than we were in 2019. Most failures are well < 1% when talking to authoritative servers. Broken firewall defaults have been fixed and mostly deployed. > On 27 Feb 2024, at 16:41, George Michaelson wrote: > > so yet again, I voice things which show my ignorance, not yours. I > thank you for the gentle clue-stick hit, it was educational. > > -G > > On Tue, Feb 27, 2024 at 12:24 PM Shumon Huque wrote: >> >> On Tue, Feb 27, 2024 at 12:01 AM Mark Andrews wrote: >>> >>> >>>> On 27 Feb 2024, at 15:53, George Michaelson wrote: >>>> >>>> Not in any way to stop this specific draft, I wonder if this is a more >>>> general principle of exercising code points which are not marked >>>> "never to be used" and should also be raised cross-area, or in another >>>> place? >>>> >>>> Maybe the best path is to get this proved here, and then embrace-extend. >>> >>> Sure there are a lot of places where this should be done. This is going >>> to cover DNS. >> >> >> Yup, and although Mark and I have been mulling this for DNS for a number >> of years now, the general principle has also been discussed elsewhere (see >> the references to greasing) and RFC 8701 describes greasing for TLS. >> >> We should track that work too, but this draft can focus on the DNS use case. >> >> Shumon. >> -- 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] [Ext] About key tags
> On 28 Feb 2024, at 05:50, Peter Thomassen wrote: > > > > On 2/15/24 22:53, Mark Andrews wrote: >> But we can state that they should be avoided when generating new DNSKEYs. >> BIND has been avoiding key tag collisions for 2 decades now when generating >> new keys. Multi-signers all have to have the current published DNSKEY RRset >> which includes *all* DNSKEYs as part of their publication process. > Multi-signer peers do not need to publish each other's KSKs. A DNSKEY > response only needs to contain the KSK suitable for validating the response > RRset itself (i.e., the responding peer's KSK), and any ZSKs/CSKs that may be > needed for validation of other responses. > > Multi-signers thus aren't necessarily aware of keytag collisions across KSKs. Which is why I also suggested an automated keytag broker based on DNS UPDATE. If you are doing completely offline keys you just need to write done the tag and run the check manually using existing tooling like nsupdate. That handles generation of keys months in advance of publication/use in the DNS. > When using DS provisioning automation via CDS/CDNKSEY, they'll have to > exchange each other's KSKs for publishing a joint C* RRset (as in > draft-thomassen-dnsop-mske). The collision could be detected then, but using > C* automation is not required. > > Best, > Peter -- 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] [Ext] About key tags
> On 28 Feb 2024, at 05:52, Peter Thomassen wrote: > > > > On 2/16/24 17:19, Jim Reid wrote: >>> If a zone's signatures and keys are constructed and published in such a way >>> that it causes indigestion in validators, and as a consequence validators >>> fail to return responses for data in that zone, that's a self-inflicted >>> problem and the zone administrator surely has every incentive to fix the >>> problem. If the tools the zone administrator is using make the problem hard >>> to make, then so much the better. >> If validators can also make this problem hard to make, that’s so much the >> better too. That should give signers a strong incentive to fix their >> self-inflicted problem and stop hurting validating resolvers. > With (some) validators returning SERVFAIL when encountering a keytag > collision, any operator adding a DNSKEY (e.g., for rollover) will, in roughly > 2^-16 of cases, break their zone without notice. > > It's not clear to me how one would characterize such validator policy as > "mak[ing] this problem hard to make". > > It rather seems like inviting instability, then telling the signer "well, you > knew...! Or should have, at least." > > I don't see in what way that's better than what we have with the current > fixes, which successfully address the problem and (AFAICS) don't need to be > touched again. The current “fixes” still leave validators more vulnerable to cpu exhaustion attacks than eliminating colliding key tags in the signer does. This is a protocol bug that leads to cpu exhaustion. We, the IETF, have a duty to fix this at the protocol level. Vendors of signers then have a duty to fix this in their products. It that requires writing new tools to co-ordinate in the multi-signer scenario then so be it. I write the last as a vendor that would need to write such a tool. We have spent time bringing down the number of iterations in NSEC3 records due to CPU exhaustion. What is the difference with fixing this with DNSKEYs? Is it "I don’t want to touch my code”? > Best, > Peter > > ___ > 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] [Ext] About key tags
> On 28 Feb 2024, at 09:09, John Levine wrote: > > It appears that Mark Andrews said: >> The current “fixes” still leave validators more vulnerable to cpu exhaustion >> attacks than eliminating colliding key tags in the signer does. This is a >> protocol bug that leads to >> cpu exhaustion. We, the IETF, have a duty to fix this at the protocol >> level. > > I'm having trouble understanding how this is fundamentally different > from CNAME loops, or NS sets with silly numbers of NS or A records. > > The kind of load is different but in each case the client needs to > limit the amount of work it's willing to do. We can forbid it in the > protocol but unless you have better contacts at the Protocol Police > than I do, people will do it anyway. If you forbid in the protocol the tools will be fixed to prevent it occurring when signing and the validators don’t have to be prepared to play trial and error when there are duplicate tags in a DNSKEY RRset. It’s trivially easy to create a DNSKEY RRset with duplicate key tags that will validate. It trivially easy to create RRSIGs with a key tag that matches those duplicate key tags that don’t verify. We know that attackers regularly succeed in getting records to be looked up without direct access to the resolver. If you have an open resolver it is even easier. Colliding key tags are a force multiplier when trying to DoS a validating resolver. Mark > R's, > John > > PS: Try looking up 1.2.3.4.contacts.abuse.net. -- 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] [Ext] About key tags
> On 28 Feb 2024, at 09:58, John R Levine wrote: > >>> The kind of load is different but in each case the client needs to >>> limit the amount of work it's willing to do. We can forbid it in the >>> protocol but unless you have better contacts at the Protocol Police >>> than I do, people will do it anyway. >> >> If you forbid in the protocol the tools will be fixed to prevent it >> occurring when signing and the validators don’t have to be prepared >> to play trial and error when there are duplicate tags in a DNSKEY >> RRset. ... > > That's all true, but people will publish them anyway, so the tools need to > defend against them no matter what the protocol says. Based on what I've > seen, pairs of colliding tags appear innocently, larger numbers don't, so you > set the limit in the single digits. > > Is it really so much harder to write code that allows, say, three signatures > and three IDs than code that only allows one? As I hardly need point out, > the process cost of changing the protocol is high, and it will take > approximately forever for the long tail to notice. It’s not the complexity of the validator we are worried about. The number of crypto verifications per second is really low on all hardware. Being able to stop validating on the first failure rather than having to continue because the attacker has constructed a colliding key tag rrset is beneficial to getting good put trough in the presence of a DoS attack. As for the long tail we already have vendors that are doing what we are requesting to be formalised for years. Additionally this is in a component of the system that even if it isn’t updated in unlikely to generate DNSKEY rrsets with collisions. Most DNSKEY rrset don’t have more than 4 keys at any one time per algorithm. Also DNSSEC tooling is constantly being improved in terms of additional automation which encourages upgrades for anyone that is signing their zones. DNS server and with them the associated tooling do get upgraded regularly. We have the graphs to prove that. Upgrading software is a regular occurrence. I would put the time between publication of new signing rules and relying on them when validating at 2-3 years looking at the correction efforts that have already been done in the DNS in the past. > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly -- 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] [Ext] About key tags
> On 29 Feb 2024, at 07:59, Edward Lewis wrote: > > On 2/27/24, 17:09, "DNSOP on behalf of John Levine" on behalf of jo...@taugh.com> wrote: > >> The kind of load is different but in each case the client needs to >> limit the amount of work it's willing to do. We can forbid it in the >> protocol but unless you have better contacts at the Protocol Police >> than I do, people will do it anyway. > > I side with John Levine's line of reasoning, that the solution is defending > against taking on too much work (in this case, the validator caps it's effort > - in whatever way is appropriate). It would be futile to prevent key tag > collisions from happening via a protocol change as a malicious actor is not > bounded by specifications. > > If it is forbidden in the protocol, it might still happen. Ed, your reasoning is off. The point of forbidding is to allow the validator to safely stop as soon as possible when it is under attack. > ___ > 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] [Ext] About key tags
> On 29 Feb 2024, at 08:22, Shumon Huque wrote: > > On Wed, Feb 28, 2024 at 3:59 PM Edward Lewis wrote: > On 2/27/24, 17:09, "DNSOP on behalf of John Levine" on behalf of jo...@taugh.com> wrote: > > >The kind of load is different but in each case the client needs to > >limit the amount of work it's willing to do. We can forbid it in the > >protocol but unless you have better contacts at the Protocol Police > >than I do, people will do it anyway. > > I side with John Levine's line of reasoning, that the solution is defending > against taking on too much work (in this case, the validator caps it's effort > - in whatever way is appropriate). It would be futile to prevent key tag > collisions from happening via a protocol change as a malicious actor is not > bounded by specifications. > > If it is forbidden in the protocol, it might still happen. > > Yeah, as you might guess from my past messages on this thread, I am of the > same opinion. There is a general principle about limiting work that resolvers > need to follow, and this recent attack (like many others before it) exploited > resolvers that failed to sensibly do that. The novel thing in KeyTrap is that > it exploited a failure to bound cryptographic work, but the same principle > applies. > > Here's my minor restatement of the resolver's top priority from RFC 1034: > > Bound the amount of work (e.g. packets sent, parallel processes > started, computations performed, time spent) so that a request > can't get into an infinite loop, start off a chain reaction or > unreasonably lengthy sequence of tasks, requests or queries, > EVEN IF SOMEONE HAS INCORRECTLY OR MALICIOUSLY > CONFIGURED SOME DATA. > > In the parenthetical examples of bounding work, I've added "computations > performed" and "time spent". > > And in the uppercased "EVEN IF" phrase, I've added "MALICIOUS CONFIGURED". > > I think the specific case of keytag collisions does deserve some special > thought though. Even if resolvers limit the number of collisions, it's in a > zone owner's interest to not have them at all. Colliding keytags in the > DNSKEY RRset means imposing additional unnecessary signature verification > work on resolvers for verifying every signed RRset in the response. And for > efficiency reasons, a zone owner should want to have their answers accepted > by validating resolvers with the minimum amount of work (and no unnecessary > work). > > Banning keytag collisions outright today would not be a good idea - we risk > rendering some sights unresolvable through no fault of their own. DNSSEC > already has plenty of detractors, and we don't want to give them more > ammunition by creating problems in the ecosystem that can be easily avoided. > I think writing a BCP telling folks how to avoid collisions would make sense > though (and yes, it needs to cover the multi-signer case too). > > Shumon. Sorry this is fuzzy reasoning. A BCP will never get to the state where the validator can actually stop on a single error. The ONLY way to do that is to update the protocol and then wait a while before relying on the new rules in the validator. We did this with EDNS (RFC 6891, April 2013) when we tightened up the unknown option behaviour (unspecified -> specified). The hardest part is getting vendors to fix their products. That was the most important work in 2019. After that there was a very rapid reduction in broken servers out there. It is not impossible to do. Mark > ___ > 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] [Ext] About key tags
> On 29 Feb 2024, at 08:44, John R Levine wrote: > > On Thu, 29 Feb 2024, Mark Andrews wrote: >>> If it is forbidden in the protocol, it might still happen. >> >> Ed, your reasoning is off. The point of forbidding is to allow the >> validator to safely stop as soon as possible when it is under attack. > > We're going in circles here. You want to stop at 2 some time in the future > after we've changed the spec. Ed and Shumon and I want to stop at, say, 10, > right now. I've never written a DNSSEC validator so I don't know how > different those are in practice but I'd be surprised if it were very much. No, I want to stop after a single failure. Stopping after multiple failures is a stop gap until we can get the specification fixed, a period for the updated signers to be deployed and a effort to get the known colliding key tag zones fixed. > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly -- 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] [Ext] About key tags and collision numbers
> On 29 Feb 2024, at 09:23, John R Levine wrote: > > On Wed, 28 Feb 2024, Shumon Huque wrote: >> Banning keytag collisions outright today would not be a good idea - we risk >> rendering some sights unresolvable through no fault of their own. DNSSEC >> already has plenty of detractors, and we don't want to give them more >> ammunition by creating problems in the ecosystem that can be easily >> avoided. I think writing a BCP telling folks how to avoid collisions would >> make sense though (and yes, it needs to cover the multi-signer case too). > > The multisigner case is a database update problem which is surprisingly hard > to get right. Either you need locked updates which are slow and subject to > hanging, or you need to detect collisions and retry, which has its own > problems (BTDT). DNSSEC doesn’t need instantaneous key generation. Every step, including DNSKEY generation, has to support that stage being stalled today for DNSSEC to work. Machines can be without power. Links between servers can be down. If you don’t account at every stage for potentially stalling DNSSEC breaks. Good key management requires checking multiple servers to where they are up to and stalling the process until everything is in the expected conditions. Single signers today prevent duplicate key tags by regenerating keys on collision. We can do the same thing with multi-signers. There are a number of methods to do this. There is the DNS UPDATE method (requires communicating with a broker). There is dividing up the TAG space between providers (lots more keys thrown away which is why I rejected it when I initially thought of it, also requires enforcement at they publication stage). Pick your poison. > If we can live with small numbers of collisions, the whole problem is a lot > more tractable. > > Too bad there's no room for grease in DNSKEYs. If you were allowed to add a > byte or two of noise, you could constrain the range of the key IDs you > generated, which would let you partition the ID space among multiple signers. > That would be (other than the grease kludge) an elegant way out. > > R's, > John > > _______ > 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] [Ext] About key tags
You don’t perform a verify if the time window is invalid. The same as you don’t perform a verify if the tag doesn’t match. Mind you it’s completely pointless to have multiple time ranges. The RRset and it’s signatures travel as pairs. All the key rollover rules depend on that. -- Mark Andrews > On 2 Mar 2024, at 06:43, John R Levine wrote: > > >> >>> Remember that the keytags are just a hint to limit the number of keys >>> you need to check for each signature. If I have a zone with 300 >>> signatures per key, it's still going to take a while to check them all >>> even with no duplicate tags. It won't be as bad as the quadratic >>> keytrap but it'll still be annoying. >> >> If key tags are unique, then a validator can just discard anything that >> has multiple signatures with the same key tag. > > No, that's not how it works. The signatures might have different time ranges > or otherwise be different but still plausibly valid. Please review RFCs 4034 > and 4035. > > R's, > John > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Do we need new draft that recommends number limits ?
> On 13 Mar 2024, at 03:46, John Levine wrote: > > It appears that Paul Vixie said: >> -=-=-=-=-=- >> <> >> I think it would be better to compile them all into one draft.>> > > I agree a draft describing the places where DNS evaluators > should set limits would be a good idea. > > I am considerably less enthusastic about specific limits, since > the use of the DNS has evolved a lot and some things that may > bave seemed excessive back in the day are now routine. > > The obvious example is CNAME chains. In 1034/1035 the only use > contemplated for CNAME was temporary forwarding when a host name > changed, and for that use, chained CNAMEs made no sense. Now they > delegate authority to different points of control in many different > ways. For applications like CDNs, you need two or three link CNAME > chains and nobody appears to find that a problem. Actually it is a problem. It results in lots of additional lookups. That in turn results in amplification bug reports being reported from universities looking for the latest way to abuse the DNS to launch DoS attacks. And it is not 3 CNAMEs, you are looking at 5+ CNAMEs today. From a recent pcap CNAME .Clump..aa-rt.sharepoint.com., CNAME Z.Farm..aa-rt.sharepoint.com., CNAME L.Farm.BB.sharepointonline.com.akadns.net., CNAME AAA.farm.RRR.aa-rt.sharepoint.com.dual-spo-0005.spo-msedge.net., CNAME .spo-msedge.net If you reduce the number of supported CNAMES you get “but it works with Google” thrown back at you when in reality there isn’t a need for most of this. All of the CNAMES could be done in the background rather than polluting caches with chains of CNAMES. > R's, > John > > _______ > 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] DNS Grease?
> On 25 Apr 2024, at 07:59, Brian Dickson wrote: > > > > On Wed, Apr 24, 2024 at 2:28 PM David Schinazi > wrote: > If I understand your proposal correctly, this would require the receiver to > support this new EDNS option in order to properly remove values that the > sender thought were unused but that the receiver did not. Such a requirement > on receivers makes it impossible for the sender to know it can safely GREASE, > because the sender has no way of knowing that the receiver supports this new > EDNS option. In general, the idea behind GREASE is that any sender can use it > without requiring any changes on the receiver. > > Not exactly, at least I don't think so. David is correct. It is to test default behaviour to currently unused code points. Receivers shouldn’t have to do anything special. > -- > 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 > ___ > 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 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] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
> On 30 Apr 2024, at 06:00, Paul Wouters wrote: > > On Mon, 29 Apr 2024, Philip Homburg wrote: > >> As far as I know there is no second pre-image attack on SHA1, and there >> will not be one in the foreseeable future. > > Correct. > >> So if we deprecate SHA1 for validators, and assuming validators will follow >> this advice, and some platforms already stopped validating SHA1, then there >> may be zones that are mostly secure today that become insecure or bogus >> when we are done with the draft. > > The advise is split between producing SHA1 signatures and consuming SHA1 > signatures, and those timings do not have to be identical. > > That said, a number of OSes have already forced the issue by failing > SHA1 as cryptographic operation (RHEL, CentOS, Fedora, maybe more). So > right now, if you run DNSSEC with SHA1 (which includes NSEC3 using > SHA1), your validator might already return it as an insecure zone. They DO NOT disable SHA1. They disable RSASHA1. The distinction is important. NSEC3 works fine on them. > I think a MUST NOT for signing with SHA1 is a no-brainer. The timing for > MAY on validation should be relatively short (eg 0-2 years?) > > For NSEC3 requiring SHA1, that will depend a bit on whether DNS > validators have rewritten their code to allow the use of SHA1 on > those systems where it is disabled for "cryptographic reasons". I'm > not up to date on it, but my suggestion on adding SHA2 for NSEC3 so > far is not well received. Getting a list of the main resolvers (services > and software) and whether they properly support NSEC3 w SHA1 would > be helpful in making such decisions. > > Paul > > _______ > 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] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
One got servfail because validators where not aware that support was ripped away underneath it. Validators started to get errors that where totally unexpected. Performing runtime testing of algorithm support addressed that by allowing the validator to skip the unsupported algorithm. -- Mark Andrews > On 1 May 2024, at 00:04, Paul Wouters wrote: > On Tue, 30 Apr 2024, Philip Homburg wrote: > >>> The advise is split between producing SHA1 signatures and consuming SHA1 >>> signatures, and those timings do not have to be identical. >>> That said, a number of OSes have already forced the issue by failing >>> SHA1 as cryptographic operation (RHEL, CentOS, Fedora, maybe more). So >>> right now, if you run DNSSEC with SHA1 (which includes NSEC3 using >>> SHA1), your validator might already return it as an insecure zone. >>> I think a MUST NOT for signing with SHA1 is a no-brainer. The timing for >>> MAY on validation should be relatively short (eg 0-2 years?) >> >> What worries me about the draft is the security section. I can understand >> the desire to get rid of old crypto, but as far as I can tell >> this draft will mostly decrease security. > > It will also prevent ServFails when the system crypto SHA1 for > authentication and signature purposes is blocked, and the DNS software > sees this as a failure and returns BOGUS. I am not sure how many DNS > implementations are now probing SHA1 and on failure put it in the > "unsupported algorithm" class, to serve it as insecure instead of bogus. > > This issue did hit RHEL,CentOS, Fedora. > >> We can accept as given that it is easy to find collisions for SHA1. However, >> a second pre-image attack is way off in the future. > > I'm not too concerned about that. > >> Looking at the signer part, this is not great either. Moving away from SHA1 >> requires an algorithm roll-over. DNSSEC is already quite fragile and >> algorithm >> rolls are worse. So there is a failure risk that is too big ignore. > > Yes, this fragility is why there are still zones using SHA1 at all. But > I think software and DNS services have no matured to the point where it > is save to do. Eg bind, opendnssec, knot. > >> This draft requires zones that do not have a collision risk to move to a >> different algorithm, at a significant risk, but there is no increase in >> security. So that part is also a net negative for security. > > Staying at SHA1 incurs the above risk of SHA1 leading to Bogus/ServFail. > >> So it seems that we are asked to adopt a draft that will mostly reduce >> security, not increase it. > > It prevents zone outages. > >> There might be other arguments for adopting the draft, such a Redhat not >> validating signatures with SHA1 anymore. But those arguments are not >> mentioned in the draft. > > I guess these considerations can be added to the draft if the WG wants? > >> And if some companies from one country want to shoot themselves in the foot, >> does the rest of the world have to follow? > > The IETF and its cryptographic policies are a careful interworking > between market forces, reality and desire. Moving to fast leads to RFCs > being ignored. Moving too slow means RFCs do not encourage > modernization. Every other protocol has left SHA1 behind. It's time for > DNS to follow suit. It's had its "exemption" for a few years already. > > Paul > > ___ > 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] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
The validators where not returning BOGUS. They where returning unknown error. Both errors resulted in servfail. Once we knew what RH had done one could go from compile time testing of support to runtime testing of support. The DNSSEC RFC’s already told developers how to handle this. RSASHA1 is just treated as any other unsupported algorithm if there is not runtime support. Unfortunately there isn’t an easy test. You have to attempt to verify a known good signature. -- Mark Andrews > On 1 May 2024, at 00:41, Mark Andrews wrote: > > One got servfail because validators where not aware that support was ripped > away underneath it. Validators started to get errors that where totally > unexpected. Performing runtime testing of algorithm support addressed that by > allowing the validator to skip the unsupported algorithm. > -- > Mark Andrews > >> On 1 May 2024, at 00:04, Paul Wouters wrote: >> On Tue, 30 Apr 2024, Philip Homburg wrote: >> >>>> The advise is split between producing SHA1 signatures and consuming SHA1 >>>> signatures, and those timings do not have to be identical. >>>> That said, a number of OSes have already forced the issue by failing >>>> SHA1 as cryptographic operation (RHEL, CentOS, Fedora, maybe more). So >>>> right now, if you run DNSSEC with SHA1 (which includes NSEC3 using >>>> SHA1), your validator might already return it as an insecure zone. >>>> I think a MUST NOT for signing with SHA1 is a no-brainer. The timing for >>>> MAY on validation should be relatively short (eg 0-2 years?) >>> >>> What worries me about the draft is the security section. I can understand >>> the desire to get rid of old crypto, but as far as I can tell >>> this draft will mostly decrease security. >> >> It will also prevent ServFails when the system crypto SHA1 for >> authentication and signature purposes is blocked, and the DNS software >> sees this as a failure and returns BOGUS. I am not sure how many DNS >> implementations are now probing SHA1 and on failure put it in the >> "unsupported algorithm" class, to serve it as insecure instead of bogus. >> >> This issue did hit RHEL,CentOS, Fedora. >> >>> We can accept as given that it is easy to find collisions for SHA1. However, >>> a second pre-image attack is way off in the future. >> >> I'm not too concerned about that. >> >>> Looking at the signer part, this is not great either. Moving away from SHA1 >>> requires an algorithm roll-over. DNSSEC is already quite fragile and >>> algorithm >>> rolls are worse. So there is a failure risk that is too big ignore. >> >> Yes, this fragility is why there are still zones using SHA1 at all. But >> I think software and DNS services have no matured to the point where it >> is save to do. Eg bind, opendnssec, knot. >> >>> This draft requires zones that do not have a collision risk to move to a >>> different algorithm, at a significant risk, but there is no increase in >>> security. So that part is also a net negative for security. >> >> Staying at SHA1 incurs the above risk of SHA1 leading to Bogus/ServFail. >> >>> So it seems that we are asked to adopt a draft that will mostly reduce >>> security, not increase it. >> >> It prevents zone outages. >> >>> There might be other arguments for adopting the draft, such a Redhat not >>> validating signatures with SHA1 anymore. But those arguments are not >>> mentioned in the draft. >> >> I guess these considerations can be added to the draft if the WG wants? >> >>> And if some companies from one country want to shoot themselves in the foot, >>> does the rest of the world have to follow? >> >> The IETF and its cryptographic policies are a careful interworking >> between market forces, reality and desire. Moving to fast leads to RFCs >> being ignored. Moving too slow means RFCs do not encourage >> modernization. Every other protocol has left SHA1 behind. It's time for >> DNS to follow suit. It's had its "exemption" for a few years already. >> >> Paul >> >> ___ >> 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] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
And that doesn’t fail in RH with the tighter crypto. -- Mark Andrews > On 1 May 2024, at 00:46, Paul Wouters wrote: > > On Wed, 1 May 2024, Mark Andrews wrote: > >> One got servfail because validators where not aware that support was ripped >> away underneath it. Validators started to get errors that where totally >> unexpected. Performing runtime testing of algorithm support addressed that >> by allowing the validator to skip the unsupported algorithm. > > The runtime check for SHA1 helped put RSA-SHA1 / NSEC3-RSA-SHA1 into the > "unsupported" category, but RSA-SHA256 with NSEC3 still uses SHA1 > for hashing the QNAME, and while not cryptogrpahic use, still had > problems in practise. I don't remember the full details, but I think > it related to wildcard proofs of non-existence of some kind, leading > to validation failures. > > Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
If we go ahead with this these two sentences Validating resolvers MUST treat RRSIG records created from DNSKEY records using these algorithms as insecure. If no other RRSIG records of accepted cryptographic algorithms are available, the validating resolver MUST consider the associated resource records as Bogus. need to be replaced with Validating resolvers MUST treat RRSIG records created from DNSKEY records using these algorithms as an unsupported algorithm. If no other RRSIG records of accepted cryptographic algorithms are available, the validating resolver MUST consider the associated resource records as Insecure. -- 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
[DNSOP] Re: [Ext] Re: Paul Wouters' Discuss on draft-ietf-dnsop-zoneversion-08: (with DISCUSS and COMMENT)
If the zone is not loaded you don’t have a zone version. Retuning an empty zone version just looks you have a broken EDNS implementation. It doesn’t provide real information. -- Mark Andrews > On 19 Jun 2024, at 05:25, Paul Wouters > wrote: > > > >> On Tue, Jun 18, 2024 at 2:01 PM Wessels, Duane >> wrote: >> >> >> > On Jun 18, 2024, at 10:49 AM, Paul Hoffman wrote: >> > >> > Responding to one bit of Duane's response. >> > >> > On Jun 18, 2024, at 10:40, Wessels, Duane >> > wrote: >> > >> >>> What should an authoritative nameserver return as zone version if it is >> >>> configured as authoritative nameserver but can't get the zone version (eg >> >>> because "no permission to read file") One way would be to allow it to >> >>> return >> >>> a zero length for ANY type and define that as an error condition. >> >> >> >> I think the authors will need to discuss how to handle error conditions >> >> like this >> >> and get back to you. >> > >> > PaulW's DISCUSS on this topic doesn't make sense. If a server is >> > authoritative for a zone, it has know the version of the zone: the zone is >> > incomplete without its version. If the server doesn't know the version, it >> > should not be answering any queries for that zone at all. > > I gave a bad example. Image a database backend, but the backend is > temporarily down. It will return ServFail but what would you put into the > zone version? > >> >> Yes, perhaps. The one example I could think of is if the server was >> configured to be authoritative for a zone, but is unable to load the zone >> data either via network or disk. >> >> A server could just omit any zone version in this (rare?) case. The only >> reason to do something other than that would be for the server to indicate >> it supports zone versioning but not at that moment for that zone. > > I guess either omit or a zero length zone version would work for me. > > Paul > ___ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Wallet is not implementable.
Turning off escape processing prevents turning off multi line processing. -- Mark Andrews ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: Wallet is not implementable.
I was meaning to send a more meaningful message. WALLET has the following paragraph that should have prevented it being approved because multi-line continuation can be anywhere in a record and there is no way actually write a zone file parser and also do the requested behaviour. "None of the characters in either the or are special. For example, a backslash character (U+005C) does not act as an escape character of any sort.” Note the opening ‘(‘ occurs before the type is defined so one can’t event disable multi-line parsing after processing the type is specified. % cat multi-line.db @ ( SOA . . 0 0 0 0 0 ) @ NS . % named-checkzone -D example multi-line.db multi-line.db:1: no TTL specified; using SOA MINTTL instead zone example/IN: loaded serial 0 example. 0 IN SOA . . 0 0 0 0 0 example. 0 IN NS . OK % Now the specification of WALLET doesn’t disallow ‘)’ as a currency identifier. I know people don’t like having to deal with escape processing but that isn’t actually negotiable. Mark > On 23 Jun 2024, at 12:57, Mark Andrews wrote: > > Turning off escape processing prevents turning off multi line processing. > > > > -- > Mark Andrews > > ___ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org -- 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 To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171
An obvious correction “LTP--v6” -> “LTP-v6” For IPN why isn’t the wire format two network 64 bit integers? That is 16 bytes. Also 2^64-1 is 20 characters so 2 64-bit numbers separated by “." is 41 characters. It’s not clear where then 21 comes from. Limit CLA characters to Letter Digit Hyphen rather than the full ASCII range. Mark > On 25 Jun 2024, at 08:19, Scott Johnson wrote: > > Hi All, > > After reading the recent discussion about WALLET, I am hesitant to jump into > the fray here, but this plainly is the correct group to help me get my logic > and syntax right, so here goes: > > I submitted requests to IANA for IPN and CLA RRTYPEs, these representing the > missing datasets necessary to make a BP overlay network connection from data > found by DNS queries. > > For those not familiar, BP is a store and forward mechanism generally used in > high latency situations where there does not exist constant end-to-end > connectivity. It was designed for deep space networking, however has network > segments and application uses which overlay the terrestrial Internet. There > will arise similar use cases on the Moon (in the reasonably near future) and > Mars whereby low latency, constant connectivity exists, thereby making use of > DNS in these situations viable. > > My Expert Reviewer asked for an i-d, to clarify the requests, and that said > i-d be sent to this list for review. > > Please find the approptiate draft here: > https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/ > > Relevant IANA requests: > https://tools.iana.org/public-view/viewticket/1364843 > https://tools.iana.org/public-view/viewticket/1364844 > > I have the BP community also reviewing this, but they are generally in > agreement as to use. > > Thanks, > Scott M. Johnson > Spacely Packets, LLC > > _______ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org -- 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 To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171
> On 25 Jun 2024, at 10:32, Scott Johnson wrote: > > Hi Mark, > > On Tue, 25 Jun 2024, Mark Andrews wrote: > >> An obvious correction “LTP--v6” -> “LTP-v6” > > Aha! Good eye. > >> >> For IPN why isn’t the wire format two network 64 bit integers? That is 16 >> bytes. Also 2^64-1 is 20 characters so 2 64-bit numbers separated by “." is >> 41 characters. It’s not clear where then 21 comes from. > > EID is the basic unit of IPN naming, which is indeed two 64 bit integers > separated by a ".". We are seeking to represent only the node-nbr component > of an EID, as the service-nbr component is loosely analagous to a UDP or TCP > port, for which there is one publicly defined service in the registry, and a > collection of space agencies who lay claim to another chunk of them: > https://www.iana.org/assignments/bundle/bundle.xhtml#cbhe-service-numbers > As such, there is no gain in including the second 64-bit integer, > representing service-nbr in the DNS records, and indeed, a loss of utility on > the application level. > > The node-nbr component is presently, under RFC7116, a 64 bit unsigned > integer. There is a draft from the DTN WG currently making it's way through > the IESG which will amend the IPN naming scheme. Perhaps I should add it to > normative references? > https://datatracker.ietf.org/doc/draft-ietf-dtn-ipn-update/ > > In effect it splits the node-nbr component into two-32 bit integers; > Allocator Identifier and Node Number in the "Three-Element Scheme-Specific > Encoding" of Section 6.1.2 over the above. Section 6.1.1 describes the > "Two-Element Scheme-Specific Encoding" method which retains the use of a > single 64-bit integer. Thus, a single 64 bit integer (20 characters) or two > 32-bit integers (10 characters each) delimited by a "." > makes 21 characters maximum. This preserves forwards compatibility with the > proposed amended scheme, and does no harm if the scheme fails to achieve > standardization. Or just 8 bytes on the wire with both possible input formats described. Machines using the records will just be converting ASCII values to a 64 bit integer. We may as well transmit it as that. Input validation will need to do the conversion anyway to ensure both fields will fit into 32 bits in the “.” separated case and 64 bits in the single value case. Length along is not sufficient to prevent undetected overflows. The only thing you need to determine is which format is the initial canonical presentation format. That can be changed with a later update if needed. >> Limit CLA characters to Letter Digit Hyphen rather than the full ASCII range. > > It is possible for a node to support multiple CLAs on the same IP address and > node number. Will this change allow multiple, comma delimited values to be > expressed in the CLA record? If so, can you point me to an example so I can > get the verbiage of the draft right? If not, what do you recommend (in > addition to my defining that in the draft)? I like the idea of limiting the > usable characters. Personally I would just use a TXT record wire format with the additional constraint that the values are restricted to Letter, Digits and interior Hyphens. The input format matches the TXT record with the above character value constraints. The canonical presentation form is space separated, unquoted, unescaped ASCII. This allow for long records to be split over multiple lines. Descriptive comments in the zone file. This take one extra octet over using comma separated values. e.g. example inputs @ CLA ( TCP-V4 ; TCP over IPv4 TCP-V6 ) ; TCP over IPv6 @ CLA “TCP-V4” TCP-V6 Wire 06 ’T’ ‘C’ ‘P’ ‘-‘ ‘V’ ‘4’ 06 ’T’ ‘C’ ‘P’ ‘-‘ ‘V’ ‘6’ Canonical presentation @ CLA TCP-V4 TCP-V6 > Thanks, > Scott > >> >> Mark >> >>> On 25 Jun 2024, at 08:19, Scott Johnson wrote: >>> >>> Hi All, >>> >>> After reading the recent discussion about WALLET, I am hesitant to jump >>> into the fray here, but this plainly is the correct group to help me get my >>> logic and syntax right, so here goes: >>> >>> I submitted requests to IANA for IPN and CLA RRTYPEs, these representing >>> the missing datasets necessary to make a BP overlay network connection from >>> data found by DNS queries. >>> >>> For those not familiar, BP is a store and forward mechanism generally used >>> in high latency situations where there does not exist constant end-to-end >>> connectivity. It was designed for deep space networking, however has >>> network segments and application uses which overlay the terrestrial >&g
[DNSOP] Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171
Made the IPN description more specific. Wire format encoding shall be an unsigned 64-bit integer in network order. Presentation format, for these resource records are either a 64 bit unsigned decimal integer, or two 32 bit unsigned decimal integers delimited by a period with the most significant 32 bits first and least significant 32 bits last. Values are not to be zero padded. > On 25 Jun 2024, at 15:22, Scott Johnson wrote: > > Hi Scott, > > Wire format of 64 bit unsigned integer it is for IPN. > Updated draft (03) incorporating all changes posted at: > https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/ > > Let me know if you see anything else, Mark, and thanks! > > > ScottJ > > > On Mon, 24 Jun 2024, sburleig...@gmail.com wrote: > >> I've lost lock on the ipn-scheme RFC, but my own assessment is that always >> sending a single 64-bit unsigned integer would be fine. The application >> receiving the resource can figure out whether or not it wants to condense >> the value by representing it as two 32-bit integers in ASCII with leading >> zeroes suppressed and a period between the two. Internally it's always going >> to be a 64-bitunsigned integer, from which a 32-bit "allocator" number can >> be obtained by simply shifting 32 bits to the right; if the result is zero >> then we're looking at an old-style IPN node number. >> >> Scott >> >> -Original Message- >> From: Scott Johnson >> Sent: Monday, June 24, 2024 8:26 PM >> To: Mark Andrews ; sburleig...@gmail.com >> Cc: dnsop >> Subject: Re: [DNSOP] IPN and CLA RRTYPEs to support Bundle Protocol RFC9171 >> >> Hi Mark, >> >> >> On Tue, 25 Jun 2024, Mark Andrews wrote: >> >>> >>> >>>> On 25 Jun 2024, at 10:32, Scott Johnson wrote: >>>> >>>> Hi Mark, >>>> >>>> On Tue, 25 Jun 2024, Mark Andrews wrote: >>>> >>>>> An obvious correction “LTP--v6” -> “LTP-v6” >>>> >>>> Aha! Good eye. >>>> >>>>> >>>>> For IPN why isn’t the wire format two network 64 bit integers? That is >>>>> 16 bytes. Also 2^64-1 is 20 characters so 2 64-bit numbers separated by >>>>> “." is 41 characters. It’s not clear where then 21 comes from. >>>> >>>> EID is the basic unit of IPN naming, which is indeed two 64 bit integers >>>> separated by a ".". We are seeking to represent only the node-nbr >>>> component of an EID, as the service-nbr component is loosely analagous to >>>> a UDP or TCP port, for which there is one publicly defined service in the >>>> registry, and a collection of space agencies who lay claim to another >>>> chunk of them: >>>> https://www.iana.org/assignments/bundle/bundle.xhtml#cbhe-service-num >>>> bers As such, there is no gain in including the second 64-bit >>>> integer, representing service-nbr in the DNS records, and indeed, a loss >>>> of utility on the application level. >>>> >>>> The node-nbr component is presently, under RFC7116, a 64 bit unsigned >>>> integer. There is a draft from the DTN WG currently making it's way >>>> through the IESG which will amend the IPN naming scheme. Perhaps I should >>>> add it to normative references? >>>> https://datatracker.ietf.org/doc/draft-ietf-dtn-ipn-update/ >>>> >>>> In effect it splits the node-nbr component into two-32 bit integers; >>>> Allocator Identifier and Node Number in the "Three-Element Scheme-Specific >>>> Encoding" of Section 6.1.2 over the above. Section 6.1.1 describes the >>>> "Two-Element Scheme-Specific Encoding" method which retains the use of a >>>> single 64-bit integer. Thus, a single 64 bit integer (20 characters) or >>>> two 32-bit integers (10 characters each) delimited by a "." >>>> makes 21 characters maximum. This preserves forwards compatibility with >>>> the proposed amended scheme, and does no harm if the scheme fails to >>>> achieve standardization. >>> >>> Or just 8 bytes on the wire with both possible input formats described. >>> Machines using the records will just be converting ASCII values to a >>> 64 bit integer. We may as well transmit it as that. Input validation >>> will need to do the conversion anyway to ensure both fields will fit
[DNSOP] Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171
> On 25 Jun 2024, at 16:36, Scott Johnson wrote: > > Hi Mark, > > Noted and changed. Good stuff, thanks. Updated draft (04) at datatracker > using that verbiage: > https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/ > > Is it appropriate to add an acknowledgments section or co-authors at this > point? I’m not fussed either way. > As well, should I be asking for WG adoption (DNSOP or DTN WG), or as an > Informational document, is Individual submission sufficient? I’ll leave that for the chairs to answer. > Thanks, > ScottJ > > > On Tue, 25 Jun 2024, Mark Andrews wrote: > >> Made the IPN description more specific. >> >> >> Wire format encoding shall >> be an unsigned 64-bit integer in network order. Presentation format, for >> these >> resource records are either a 64 bit unsigned decimal integer, or two 32 bit >> unsigned decimal integers delimited by a period with the most significant 32 >> bits >> first and least significant 32 bits last. Values are not to be zero padded. >> >>> On 25 Jun 2024, at 15:22, Scott Johnson wrote: >>> >>> Hi Scott, >>> >>> Wire format of 64 bit unsigned integer it is for IPN. >>> Updated draft (03) incorporating all changes posted at: >>> https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/ >>> >>> Let me know if you see anything else, Mark, and thanks! >>> >>> >>> ScottJ >>> >>> >>> On Mon, 24 Jun 2024, sburleig...@gmail.com wrote: >>> >>>> I've lost lock on the ipn-scheme RFC, but my own assessment is that always >>>> sending a single 64-bit unsigned integer would be fine. The application >>>> receiving the resource can figure out whether or not it wants to condense >>>> the value by representing it as two 32-bit integers in ASCII with leading >>>> zeroes suppressed and a period between the two. Internally it's always >>>> going to be a 64-bitunsigned integer, from which a 32-bit "allocator" >>>> number can be obtained by simply shifting 32 bits to the right; if the >>>> result is zero then we're looking at an old-style IPN node number. >>>> >>>> Scott >>>> >>>> -Original Message- >>>> From: Scott Johnson >>>> Sent: Monday, June 24, 2024 8:26 PM >>>> To: Mark Andrews ; sburleig...@gmail.com >>>> Cc: dnsop >>>> Subject: Re: [DNSOP] IPN and CLA RRTYPEs to support Bundle Protocol RFC9171 >>>> >>>> Hi Mark, >>>> >>>> >>>> On Tue, 25 Jun 2024, Mark Andrews wrote: >>>> >>>>> >>>>> >>>>>> On 25 Jun 2024, at 10:32, Scott Johnson wrote: >>>>>> >>>>>> Hi Mark, >>>>>> >>>>>> On Tue, 25 Jun 2024, Mark Andrews wrote: >>>>>> >>>>>>> An obvious correction “LTP--v6” -> “LTP-v6” >>>>>> >>>>>> Aha! Good eye. >>>>>> >>>>>>> >>>>>>> For IPN why isn’t the wire format two network 64 bit integers? That is >>>>>>> 16 bytes. Also 2^64-1 is 20 characters so 2 64-bit numbers separated >>>>>>> by “." is 41 characters. It’s not clear where then 21 comes from. >>>>>> >>>>>> EID is the basic unit of IPN naming, which is indeed two 64 bit integers >>>>>> separated by a ".". We are seeking to represent only the node-nbr >>>>>> component of an EID, as the service-nbr component is loosely analagous >>>>>> to a UDP or TCP port, for which there is one publicly defined service in >>>>>> the registry, and a collection of space agencies who lay claim to >>>>>> another chunk of them: >>>>>> https://www.iana.org/assignments/bundle/bundle.xhtml#cbhe-service-num >>>>>> bers As such, there is no gain in including the second 64-bit >>>>>> integer, representing service-nbr in the DNS records, and indeed, a loss >>>>>> of utility on the application level. >>>>>> >>>>>> The node-nbr component is presently, under RFC7116, a 64 bit unsigned >>>>>> integer. There is a draft from the DTN WG currently making it's way >>>>>> through the IESG which will amend
[DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171
> On 27 Jun 2024, at 03:11, Rick Taylor wrote: > > Hi Scott, > > Thanks for the updated doc. I've been thinking through what I understand is > your use-case, and I wonder whether new RRTYPEs is really the right way to > go. As I see it, the less one has to update the DNS infrastructure of the > Internet the better, so would this alternative mechanism work for you?: Adding a new RRTYPE requires zero infrastructure upgrades. It’s a database entry at IANA. Every DNS server on the planet should handle these transparently. That was required by RFC 1034 and RFC 1035. You can even add them to zones before the parsing software is updated using unknown type representation (RFC 3597) which was one thing that was missing from RFC 1035 that would have made adding new types easier. Nameservers and stub resolvers were always required to treat unknown records as opaque objects. This doesn’t mean that there weren’t mis-implementations of the standards which failed to handle unknown types correctly but there have been 78 types added since RFC 1034 and RFC 1035. That’s 2-3 per year. Nameserver developers know how to add new record types quickly. Mark -- 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 To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [v6ops] [EXTERNAL] New Version Notification for draft-jens-7050-secure-channel-00.txt
> On 27 Jun 2024, at 06:51, Ole Trøan > wrote: > > > >> On 26 Jun 2024, at 22:47, Brian Candler wrote: >> >> On 26/06/2024 21:26, Ole Trøan wrote: >>> I would still like the option of having an IPv6 only host. (Which 464XLAT >>> doesn’t give). >> That depends what you mean by "IPv6 only host". Do you mean it only has an >> IPv6 address on its external interface? Or do you want to disable the IPv4 >> stack entirely in the kernel? > > Yes, no ipv4 stack at all. >> >> >> The CLAT-in-libc approach gives an interesting middle ground, where the >> application can still ask to open an AF_INET socket, but this gets >> translated to AF_INET6 before it hits the kernel. Of course, it would be >> good to see running code first. > Agree, that would be quite neat. If there is no IPv4 stack then a CLAT is not needed. Only address mapping is needed. socket(PF_INET,…) should fail with EAFNOSUPPORT. CLAT in libc is only needed to support IPv4 only applications and for there to be no IPv4 stack these do not exist by definition. Dual stack applications don’t need CLAT. Add a flag to getaddrinfo to say to use PREF64 when looking for addresses and don’t return IPv4 addresses if a PREF64 address is present and AI_ADDRCONFIG is set. One could also fallback to looking at ipv4-only.arpa if that flag is set. Run address literals though getaddrinfo. > Cheers > Ole > _______ > v6ops mailing list -- v6...@ietf.org > To unsubscribe send an email to v6ops-le...@ietf.org -- 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 To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171
> On 27 Jun 2024, at 09:57, Scott Johnson wrote:
>
> Hi Rick,
>
> On Wed, 26 Jun 2024, Rick Taylor wrote:
>
>> Hi Scott,
>>
>> I would ask one change please. The wire format for ipn EID is well
>> documented in RFC9171, and updated in the forthcoming ipn-update. Please can
>> you use the CBOR encoding?
>
>
> 4.2.5.1.2 of RFC9171 indeed documents ipn EID well:
> "Encoding considerations:
> For transmission as a BP endpoint ID, the scheme-specific part of a URI of
> the ipn scheme SHALL be represented as a CBOR array comprising two items. The
> first item of this array SHALL be the EID's node number (a number that
> identifies the node) represented as a CBOR unsigned integer. The second item
> of this array SHALL be the EID's service number (a number that identifies
> some application service) represented as a CBOR unsigned integer. For all
> other purposes, URIs of the ipn scheme are encoded exclusively in US-ASCII
> characters."
>
> The key point is in the first sentence; "For transmission as a BP endpoint
> ID..." As has been previously noted, no EID is being transmitted, only the
> (node-nbr) component. I initially considered this to read that we were
> restricted to US-ASCII only, but when I realized that these encoding
> standards only apply to fully formed URIs, it made sense that unsigned 64-bit
> integer was acceptable for RR look-up wire encoding of (node-nbr), since no
> BPA would be using this representation in an actual bundle.
>
> Regarding draft-ietf-dtn-ipn-update, it appears that the wire format
> described fully and precisely complies with Two-Element Scheme-Specific
> Encoding in section 6.1.1.
>
> I broached the possibility of CBOR in discussion on DNSOP before DTN was
> CCed, making the above point to Scott Burleigh. Our conclusion there, along
> with Mark Andrews, was that the current verbiage is the current best course
> of action. I have no personal objection to wire format for the IPN RRTYPE
> being CBOR, if ScottB and Mark agree that there is gain to be had over using
> 64-bit unsigned int.
>
> That said, it is unclear if appropriate CBOR functions/libraries already
> exist/are used inside nameserver implementations. If not, that could
> substantially delay deployment, and/or add burden to implementers. There is
> an active draft which specifically treats CBOR encoding of RRs (
> https://datatracker.ietf.org/doc/draft-lenders-dns-cbor section 3.2.1), but
> that document is still an Individual Draft at this point as well.
>
> Mark, ScottB, opinions?
What real benefit would CBOR bring over a raw 8 byte value other than saying it
was entered via X or X.X?
The CBOR encoding is going to be as long or longer in most cases on an internet
wide scale. It’s also going to require
more complicated validators other than the record length is 8.
0.0 -> 82 00 00
0 -> 00
3467.8979 -> 82 19 34 67 19 23 13
7.500 -> 82 1a 00 01 11 70 19 01 f4
I hope I’ve got the hand encoding right.
This is not to say that CBOR couldn’t be used. I’m just not seeing the benefit.
We already do stuff like this so CBOR complexity itself isn’t a issue.
static isc_result_t
check_private(isc_buffer_t *source, dns_secalg_t alg) {
isc_region_t sr;
if (alg == DNS_KEYALG_PRIVATEDNS) {
dns_fixedname_t fixed;
RETERR(dns_name_fromwire(dns_fixedname_initname(&fixed), source,
DNS_DECOMPRESS_DEFAULT, NULL));
/*
* There should be a public key or signature after the key name.
*/
isc_buffer_activeregion(source, &sr);
if (sr.length == 0) {
return (ISC_R_UNEXPECTEDEND);
}
} else if (alg == DNS_KEYALG_PRIVATEOID) {
/*
* Check that we can extract the OID from the start of the
* key data.
*/
const unsigned char *in = NULL;
ASN1_OBJECT *obj = NULL;
isc_buffer_activeregion(source, &sr);
in = sr.base;
obj = d2i_ASN1_OBJECT(NULL, &in, sr.length);
if (obj == NULL) {
ERR_clear_error();
RETERR(DNS_R_FORMERR);
}
ASN1_OBJECT_free(obj);
/* There should be a public key or signature after the OID. */
if (in >= sr.base + sr.length) {
return (ISC_R_UNEXPECTEDEND);
}
}
return (ISC_R_SUCCESS);
}
>> As an a side, could you describe the needs of your application, I didn't
>> quite understand your HTTP request
[DNSOP] Re: [v6ops] Re: [EXTERNAL] New Version Notification for draft-jens-7050-secure-channel-00.txt
You use getaddrinfo instead. That is the IPv6 way to handle address literals. That way you get the mappings done for you. -- Mark Andrews > On 27 Jun 2024, at 23:03, Philip Homburg wrote: > > >> >> If there is no IPv4 stack then a CLAT is not needed. Only address >> mapping is needed. socket(PF_INET,) should fail with EAFNOSUPPORT. > > How would that work with code that uses inet_pton? ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [v6ops] Re: [EXTERNAL] New Version Notification for draft-jens-7050-secure-channel-00.txt
It sounds like a unified approach to opening sockets as it does all the work of filling out the sockaddr structure required to make the application work with different kernel configurations. getaddrinfo uses inet_pton internally. You also don’t have to test command line inputs for address literals or have to worry about the different sockaddr elements on different OSs. Now if you are passing raw peer address over the wire you can not use them directly. You need to use inet_ntop then getaddrinfo on the result but the application should have been doing that in case the kernel wanted to use mapped addresses exclusively anyway. -- Mark Andrews > On 27 Jun 2024, at 23:50, Philip Homburg wrote: > > >> >> You use getaddrinfo >> instead. That is the IPv6 way to handle address literals. That way >> you get the mappings done for you. > > That sounds like a rather poor approach. You never know which applications > users want to run. And telling users that they have to replace inet_pton > with getaddrinfo usually doesn't have a lot of effect. > > RFC 3493 is also silent about a preference for using getaddrinfo over > inet_pton when it comes to parsing IP address literals. ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: draft-ietf-dnsop-zoneversion-09
What is the reasoning behind the following? Why not just FORMERR the request when the option length is not zero? How hard do we think writing a client is that they will get sending a zero length option wrong? What is wrong with sending back an immediate error signal? There is a thing of being too over permissive which is why we have so many issues with the DNS today. 3.2. Responders “A name server MUST ignore invalid ZONEVERSION options present in the query message.” -- 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 To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: New Version Notification for draft-yorgos-dnsop-dry-run-dnssec-02.txt
It is possible to have only burn a single DS Digest Type Algorithm and support multiple future algorithms by encoding the actual DS Digest Type Algorithm as the first byte of the current digest field. We actually need to do something like this for DNSSEC algorithms PRIVATEDNS and PRIVATEOID as DS is currently unusable with those DNSSEC algorithm types as there is no way to differentiate which private DNS or private OID is meant to be used. We under specified DS. Both OIDs and DNS names are self describing of their lengths. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Tag | Algorithm |DRY RUN|Sub Digest Type| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / /Digest / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PRIVATEOID and PRIVATEDNS 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Tag | PRIVATEOID | OID DIGEST |Sub Digest Type| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| / OID / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /Digest / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Tag | PRIVATEDNS | NAME DIGEST |Sub Digest Type| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| / NAME / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /Digest / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and combining the two methods 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Tag | PRIVATEOID |DRY RUN| OID DIGEST | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub Digest Type| / +-+-+-+-+-+-+-+-+ / /OID/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /Digest / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- 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 To unsubscribe send an email to dnsop-le...@ietf.org
