From paras at salesforce.com Wed Aug 3 15:50:14 2022 From: paras at salesforce.com (Pallavi Aras) Date: Wed, 3 Aug 2022 11:50:14 -0400 Subject: OARC 39 Call for Contributions Message-ID: OARC 39 will be a two-day hybrid meeting held on 22 & 23 October in Belgrade, Serbia at 10:00 AM (Local time - CEST (UTC+02:00)) The onsite part of the meeting will be co-located with RIPE 85. The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: - Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). - Deployment: DNS config management and release process. - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. - Scaling: DNS performance management and metrics. Increasing DNS Server Efficiency - Security/Privacy: DNSSEC signing and validation, key storage, rollovers, qname minimization, DoH/DoT As it is a *hybrid *workshop, we'd like to encourage brevity; presentations should not be longer than 20 minutes (with additional time for questions). **Workshop Milestones:** *2022-09-06 Deadline for submission (23:59 UTC)* 2022-09-08 Preliminary list of contributions published 2022-09-20 Full agenda published 2022-10-03 Deadline for slideset submission and Rehearsal 2022-10-22 OARC 39 Workshop - Day1 2022-10-23 OARC 39 Workshop - Day2 The Registration page and details for presentation submission are published at: To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. Additional information for speakers at OARC 39: * your talk will be broadcast live and recorded for future reference * your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting * *Remote speakers have mandatory rehearsal on 2022-10-04 at 14:00 UTC. *It would be very useful to have your slides (even if draft) ready for this. *Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens.* If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via *Pallavi Aras-Mathai, for the DNS-OARC Programme Committee* OARC depends on sponsorship to fund its workshops and associated social events. Please contact if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) -- Principal Software Engineer, Public DNS team | Salesforce DNS-OARC Programme Committee Chair | DNS conference -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Sun Aug 7 23:06:16 2022 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sun, 7 Aug 2022 19:06:16 -0400 Subject: [dns-operations] Systemic DoE failure at worldnic.com nameservers Message-ID: As seen at: https://dnssec-stats.ant.isi.edu/~viktor/dnsviz/worldnic.com.html over 400 "small" signed zones (zone apex only in the NSEC chain) return incorrect "NODATA" RCODEs for "_25._tcp.. TLSA ?". The provided NSEC records instead prove "NXDOMAIN". This breaks email to these domains from DANE-enabled MTAs. If I'm not mistaken, "worldnic.com" is a NetworkSolutions brand, don't know whether they have anyone on this list. WHOIS contact Cc'd. -- Viktor. P.S. Top 5 nameservers with DoE breakage: 609 registrar-servers.com 402 worldnic.com 248 mijndomein.nl 138 axc.nl 75 ebola.cz From chitianhao at google.com Thu Aug 11 20:35:16 2022 From: chitianhao at google.com (Tianhao Chi) Date: Thu, 11 Aug 2022 16:35:16 -0400 Subject: Google Public DNS plans to enable case randomization for cache poisoning protection Message-ID: Dear users and nameserver operators, As part of our efforts to increase DNS cache poisoning protection for UDP queries, we are planning to enable case randomization of DNS query names sent to most authoritative nameservers (see our *security page description* of the feature and https://datatracker.ietf.org/doc/html/draft-vixie-dnsext-dns0x20-00). We have been performing case randomization of query names since 2009 to a small set of chosen nameservers. This set of servers handled a minority of our query volume, so a year ago we started work on enabling case randomization by default. As part of this, we?ve identified a small set of nameservers (< 1000 distinct IPs) that do not handle case randomization correctly and have exempted these from case randomization. We are confident that case randomization will work without introducing significant increases in DNS query volume or resolution failures. The case-randomized query name in the request will be expected to exactly match the name in the question section of the DNS server?s reply, including the case of each ASCII letter (A?Z and a?z). For example, if ?ExaMplE.CoM? is the name sent in the request, the name in the question section of the response must also be ?ExaMplE.CoM? rather than, e.g., ?example.com.? Responses that fail to preserve the case of the query name may be dropped as potential cache poisoning attacks. Thus, nameservers that fail to preserve the query name in their response, or whose response to case-randomized requests is an unexpected error (SERVFAIL, NOTIMP, FORMERR, etc.) or a failure to respond, will negatively impact users' ability to resolve names in the domains they serve. Generally, when nameservers mishandle case-randomized queries, we recommend asking the nameserver operator to correct their behavior. While our exception list will work around the problem for now, it may not get immediate updates for newly broken name servers. We?ll have case randomization enabled in one or two regions starting on August 29th and enabled globally by the end of October. Meanwhile, we?ve already turned off case randomization to nameservers that we?ve identified as not handling it correctly. If you believe you have discovered name resolution failures with Google Public DNS due to case randomization, please file a bug in our *issue tracker* referencing this announcement. Let us know if there's any question via https://developers.google.com/speed/public-dns/groups. We've also posted this in our discussion group: https://groups.google.com/g/public-dns-discuss/c/aHSyiIlBfjo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondrej at sury.org Thu Aug 11 21:02:00 2022 From: ondrej at sury.org (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Fri, 12 Aug 2022 00:02:00 +0300 Subject: [dns-operations] Google Public DNS plans to enable case randomization for cache poisoning protection In-Reply-To: References: Message-ID: What would really help here is (continuous) sharing the list of problematic domains. That would really help the DNS community, we could talk to the people running these services, and prepare the configuration with exception for popular open-source implementations. Ond?ej -- Ond?ej Sur? (He/Him) > On 11. 8. 2022, at 23:35, Tianhao Chi wrote: > > As part of this, we?ve identified a small set of nameservers (< 1000 distinct IPs) that do not handle case randomization correctly and have exempted these from case randomization. From hallam at gmail.com Thu Aug 11 21:56:31 2022 From: hallam at gmail.com (Phillip Hallam-Baker) Date: Thu, 11 Aug 2022 21:56:31 +0000 Subject: [dns-operations] BlackHat Presentation on DNSSEC Downgrade attack Message-ID: Looks to me like there is a serious problem here. NSEC record specifies what is signed but not the algorithm used to sign. DNSSEC allows multiple signature and digest algorithms on the same zone. If a zone does this, validators are prohibited from rejecting records only signed using one of the algorithms rather than both. Won?t go into extreme detail here as researcher?s slides will be available tomorrow. This definitely needs fixing. One near term fix is to make SHA-1 a MUST NOT. It is long past its sell-by date now. Get Outlook for iOS -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at redbarn.org Thu Aug 11 22:58:46 2022 From: paul at redbarn.org (Paul) Date: Thu, 11 Aug 2022 16:58:46 -0600 Subject: [dns-operations] Google Public DNS plans to enable case randomization for cache poisoning protection In-Reply-To: Message-ID: Should we revive the 0x20 draft? > > On Aug 11, 2022 at 2:55 PM, wrote: > > > > _______________________________________________ dns-operations mailing list dns-operations at lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Thu Aug 11 23:11:37 2022 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 11 Aug 2022 19:11:37 -0400 Subject: [dns-operations] Google Public DNS plans to enable case randomization for cache poisoning protection In-Reply-To: References: Message-ID: On Thu, Aug 11, 2022 at 04:58:46PM -0600, Paul wrote: > Should we revive the 0x20 draft? Seems reasonable to me. -- Viktor. From d3e3e3 at gmail.com Thu Aug 11 22:41:23 2022 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Thu, 11 Aug 2022 18:41:23 -0400 Subject: [dns-operations] [dnsext] BlackHat Presentation on DNSSEC Downgrade attack In-Reply-To: References: Message-ID: Maybe I'm confused but I don't see that there is any problem with NSEC. If a resolver believes in a broken algorithm, of course you are screwed. Say BK is such a broken algorithm. Assume you go to the work of specifying an using NSECbis that specifies the signing algorithm(s). If BK is broken, the attacker can just forge new NSECbis RRs signed by BK that specify BK as the signing algorithm. It is the resolver's believe in BK that is the problem. So say a zone is signed by the zone owner with both BK and a strong algorithm denoted STRONG. As long as a resolver only trusts STRONG signatures I don't see how the status of what NSECs say is signed can cause forged data to be trusted. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3 at gmail.com On Thu, Aug 11, 2022 at 5:56 PM Phillip Hallam-Baker wrote: > Looks to me like there is a serious problem here. > > NSEC record specifies what is signed but not the algorithm used to sign. > DNSSEC allows multiple signature and digest algorithms on the same zone. If > a zone does this, validators are prohibited from rejecting records only > signed using one of the algorithms rather than both. > > Won?t go into extreme detail here as researcher?s slides will be available > tomorrow. > > This definitely needs fixing. > > One near term fix is to make SHA-1 a MUST NOT. It is long past its sell-by > date now. > > > > Get Outlook for iOS > _______________________________________________ > dnsext mailing list > dnsext at ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Fri Aug 12 02:11:16 2022 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 11 Aug 2022 22:11:16 -0400 Subject: [dns-operations] BlackHat Presentation on DNSSEC Downgrade attack In-Reply-To: References: Message-ID: On Thu, Aug 11, 2022 at 09:56:31PM +0000, Phillip Hallam-Baker wrote: > Looks to me like there is a serious problem here. There is not a problem with the specification. DNSSEC algorithm agility works when implemented correctly. Now that DNSSEC adoption is finally becoming noticeable (though at ~5% of global domains, still far from the norm), the DNS community is addressing operational issues and ferreting out the latent implementation bugs. > NSEC record specifies what is signed but not the algorithm used to > sign. DNSSEC allows multiple signature and digest algorithms on the > same zone. If a zone does this, validators are prohibited from > rejecting records only signed using one of the algorithms rather than > both. This is misleading. If any of the algorithms present in the zone's DS RRset published in the parent zone are supported by the validating resolver, then the zone is *signed*, and all authoritative response RRsets from the zone must be accompanied by a valid RRSIG that chains back to a valid SEP and is mutually supported by the resolver and zone signer. If only unsupported RRSIGs are returned, the response is BOGUS. Implementations that fail to make that conclusion are in error. Apparently, bugs in some implementations until recently tolerated responses that carried only unsupported RRSIGs, erroneously treating these as "insecure", by failing to require the presence of a shared supported ZSK algorithm chaining up to a valid SEP. This was an implementation bug, that can at most charitably be treated as missing explicit guidance in the specification to do the "obvious right thing(TM)". Such explicit guidance can be added in a new clarification RFC, if deemed appropriate, though my personal view is that it should not have been necessary. That said, on the evidence of the recent implementation bugs, perhaps being needlessly explicit is at times the prudent thing to do. > Won?t go into extreme detail here as researcher?s slides will be > available tomorrow. > > This definitely needs fixing. > > One near term fix is to make SHA-1 a MUST NOT. It is long past its > sell-by date now. SHA-1 is not the problem here. The downgrade issue is equally a problem with NSEC (which does not use SHA-1) and NSEC3 (where use of SHA-1 for light obfuscation to discourage zone-walking is just fine), and even for cases that are not denial of existence at all. And the problem exists also for zones signed with only SHA-256 (e.g. algorithms 8 and 13 if some now rare resolver supports only one and not the other). The abstract makes no mention of NSEC records or denial of existence: In this talk, we show that the cryptographic agility in DNSSEC, although critical for making DNS secure with strong cryptography, also introduces a severe vulnerability. We demonstrate that adversaries, by manipulating the cryptographic material in signed DNS responses, can reduce the security level provided by DNSSEC, or, even worse, prevent resolvers from validating DNSSEC at all. We experimentally and ethically evaluate our attacks against popular DNS resolver implementations, public DNS providers, and DNS services worldwide. We validate the success of DNSSEC-downgrade attacks by poisoning the resolvers: we inject fake records, from our own signed domains, into the caches of validating resolvers. Our findings show that major DNS providers, popular resolver implementations, and many other DNS services are vulnerable to our attacks. The abstract is IMNSHO misleading. Agility is not the problem, incorrect implementation is the problem, though perhaps the requirements for correctly handling multiple algorithms could have been more clearly spelled out in RFC 4035, which covers signer responsibility in full detail, but omits some of the (I claim obvious as a matter of logic, but it seems still perhaps worth stating explicitly) corresponding requirements on validators. -- Viktor. From ietf-dane at dukhovni.org Fri Aug 12 02:19:26 2022 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 11 Aug 2022 22:19:26 -0400 Subject: [dns-operations] [dnsext] BlackHat Presentation on DNSSEC Downgrade attack In-Reply-To: References: Message-ID: On Thu, Aug 11, 2022 at 06:41:23PM -0400, Donald Eastlake wrote: > So say a zone is signed by the zone owner with both BK and a strong > algorithm denoted STRONG. As long as a resolver only trusts STRONG > signatures I don't see how the status of what NSECs say is signed can cause > forged data to be trusted. The issue is arguable lack of clarity in the validator requirements of 4035 when the server returns only RRSIGs with algorithms none of which are supported by the validator. When only unsupported algorithms appear in DS, the zone is "insecure" and all's well. But otherwise, when only unsupported algorithms (or none at all) appear in an authoritative RRset's set of RRSIGs, the response is "bogus" not "insecure". The question of which algorithm is stronger or weaker does not arise here, MiTM can in fact "downgrade" a multi-signed zone to its weakest signing algorithm, by stripping the other RRSIGs. Don't use broken algorithms, by switching away from deprecated algorithms in a timely fashion. This has largely been accomplished for algorithms 5 and 7, which are down to ~7% of their peak deployment counts. DNSSEC algorithm agility is serving its intended purpose just fine. Resolver implementations had an apparently somewhat common bug, which most should have addressed by now (that the issue is public). -- Viktor. From phill at hallambaker.com Fri Aug 12 02:31:04 2022 From: phill at hallambaker.com (Phillip Hallam-Baker) Date: Thu, 11 Aug 2022 19:31:04 -0700 Subject: [dns-operations] [dnsext] BlackHat Presentation on DNSSEC Downgrade attack In-Reply-To: References: Message-ID: Looks like the 'downgrade attack' is actually a consequence of the fact that support for multiple algorithms means that you end up with the security of the weakest. So not really an 'attack' but a consequence of the design approach not considering the downgrade issue worth addressing because people should not be signing under multiple algorithms for very long. But given that, I think we are long past the time when anyone is doing anything of the slightest value signing with SHA-1. There is no reason to pick SHA-1 over SHA-2. You are not going to improve interop, you are much more likely to harm it. So moving SHA-1 to MUST NOT seems like the way to go. On Thu, Aug 11, 2022 at 7:23 PM Viktor Dukhovni wrote: > On Thu, Aug 11, 2022 at 06:41:23PM -0400, Donald Eastlake wrote: > > > So say a zone is signed by the zone owner with both BK and a strong > > algorithm denoted STRONG. As long as a resolver only trusts STRONG > > signatures I don't see how the status of what NSECs say is signed can > cause > > forged data to be trusted. > > The issue is arguable lack of clarity in the validator requirements of > 4035 when the server returns only RRSIGs with algorithms none of which > are supported by the validator. > > When only unsupported algorithms appear in DS, the zone is "insecure" > and all's well. But otherwise, when only unsupported algorithms (or > none at all) appear in an authoritative RRset's set of RRSIGs, the > response is "bogus" not "insecure". > > The question of which algorithm is stronger or weaker does not arise > here, MiTM can in fact "downgrade" a multi-signed zone to its weakest > signing algorithm, by stripping the other RRSIGs. Don't use broken > algorithms, by switching away from deprecated algorithms in a timely > fashion. This has largely been accomplished for algorithms 5 and 7, > which are down to ~7% of their peak deployment counts. > > DNSSEC algorithm agility is serving its intended purpose just fine. > Resolver implementations had an apparently somewhat common bug, which > most should have addressed by now (that the issue is public). > > -- > Viktor. > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Fri Aug 12 03:40:21 2022 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 11 Aug 2022 23:40:21 -0400 Subject: [dns-operations] [dnsext] BlackHat Presentation on DNSSEC Downgrade attack In-Reply-To: References: Message-ID: On Thu, Aug 11, 2022 at 07:31:04PM -0700, Phillip Hallam-Baker wrote: > Looks like the 'downgrade attack' is actually a consequence of the fact > that support for multiple algorithms means that you end up with the > security of the weakest. So not really an 'attack' but a consequence of the > design approach not considering the downgrade issue worth addressing > because people should not be signing under multiple algorithms for very > long. No, the downgrade in question is not from a stronger algoritm to a weaker (generally accepted, because multi-algorithm signed zones are a short-term affair), rather, it is a downgrade from "signed" to "unsigned", which is a serious implementation error. The paper's authors did not break any crypto, they just sent replies that some implementers failed to anticipate (for plausible lack of clear explicit, however obvious it should have been, advice in RFC 4035). > But given that, I think we are long past the time when anyone is doing > anything of the slightest value signing with SHA-1. There is no reason to > pick SHA-1 over SHA-2. You are not going to improve interop, you are much > more likely to harm it. So moving SHA-1 to MUST NOT seems like the way to > go. Again, SHA-1 has nothing to do with this. It is already NOT RECOMMENDED (i.e. SHOULD NOT) for signing: https://stats.dnssec-tools.org/explore/?ietf.org https://www.rfc-editor.org/rfc/rfc8624#section-3 but still a MUST for validation. The numbers have improved a lot since the RFC was published, see the algorithm counts under "DNSSEC parameter frequency analysis" at: https://stats.dnssec-tools.org/ but we're not quite there yet: https://stats.dnssec-tools.org/explore/?nsa.gov https://stats.dnssec-tools.org/explore/?icann.org ... -- Viktor. From abang at t-ipnet.net Fri Aug 12 04:51:30 2022 From: abang at t-ipnet.net (abang at t-ipnet.net) Date: Fri, 12 Aug 2022 06:51:30 +0200 Subject: [dns-operations] Google Public DNS plans to enable case randomization for cache poisoning protection In-Reply-To: References: Message-ID: Hi, > Responses that fail to preserve the case of > the query name may be dropped as >potential cache poisoning attacks Why not fallback to TCP in such cases? Winfried -------------- next part -------------- An HTML attachment was scrubbed... URL: From abang at t-ipnet.net Fri Aug 12 04:51:30 2022 From: abang at t-ipnet.net (abang at t-ipnet.net) Date: Fri, 12 Aug 2022 06:51:30 +0200 Subject: [dns-operations] Google Public DNS plans to enable case randomization for cache poisoning protection In-Reply-To: References: Message-ID: Hi, > Responses that fail to preserve the case of > the query name may be dropped as >potential cache poisoning attacks Why not fallback to TCP in such cases? Winfried -------------- next part -------------- An HTML attachment was scrubbed... URL: From chitianhao at google.com Fri Aug 12 18:02:25 2022 From: chitianhao at google.com (Tianhao Chi) Date: Fri, 12 Aug 2022 14:02:25 -0400 Subject: [dns-operations] Google Public DNS plans to enable case randomization for cache poisoning protection In-Reply-To: References: Message-ID: @Winfried, We do retry over TCP if there's a case mismatch. However, we've found out that many of the case-ignoring nameservers don't support TCP, resulting in resolution failures. On Fri, Aug 12, 2022 at 12:59 AM wrote: > Hi, > > > Responses that fail to preserve the case of > > the query name may be dropped as > >potential cache poisoning attacks > > Why not fallback to TCP in such cases? > > Winfried > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chitianhao at google.com Fri Aug 12 18:02:25 2022 From: chitianhao at google.com (Tianhao Chi) Date: Fri, 12 Aug 2022 14:02:25 -0400 Subject: [dns-operations] Google Public DNS plans to enable case randomization for cache poisoning protection In-Reply-To: References: Message-ID: @Winfried, We do retry over TCP if there's a case mismatch. However, we've found out that many of the case-ignoring nameservers don't support TCP, resulting in resolution failures. On Fri, Aug 12, 2022 at 12:59 AM wrote: > Hi, > > > Responses that fail to preserve the case of > > the query name may be dropped as > >potential cache poisoning attacks > > Why not fallback to TCP in such cases? > > Winfried > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at desec.io Sat Aug 13 19:07:22 2022 From: peter at desec.io (Peter Thomassen) Date: Sat, 13 Aug 2022 15:07:22 -0400 Subject: [dns-operations] BlackHat Presentation on DNSSEC Downgrade attack In-Reply-To: References: Message-ID: Hi, On 8/11/22 17:56, Phillip Hallam-Baker wrote: > Looks to me like there is a serious problem here. > ... > > Won?t go into extreme detail here as researcher?s slides will be available tomorrow. The slides are now available: http://i.blackhat.com/USA-22/Thursday/US-22-Heftrig-DNSSEC-Downgrade-Attacks.pdf For the benefit of all, in a nutshell: a) Slides 1-21 and 32-35: DNS/DNSSEC intro, refresher on IETF-recommended algorithms b) Slides 22-25: Attacker generates DNSKEY with colliding DS record, then takes over zone --> assumes very broken DS digest algorithm --> if multiple digest types present, this allows "downgrade" to "weakest" (whatever that means) c) Slides 26-31: Attacker generates RRSIG without knowing private key, then takes over zone --> assumes very broken signing algorithm --> if multiple algorithms present, this allows "downgrade" to "weakest" (whatever that means) d) Slides 36-43: Attacker strips RRSIG or rewrites algorithm, so validator receives only unsupported algorithm --> some resolvers pass this as "insecure" instead of "bogus" (even when DS indicates a supported algorithm) --> these are implementation bugs at some resolver operators (should be fixed) --> Google/Cloudflare bugs originally discovered by Nils Wisiol, sparking further analysis* e) Slides 44-47: Attacker strips all DNSKEY/RRSIG but one, so validator receives only unsupported DNSKEY/RRSIG --> some resolvers pass this as "insecure" instead of "bogus" (even when DS indicates a supported algorithm) --> these are implementation bugs at some resolver operators (not sure if fixed) f) Slides 48-51: --> Recommendation and wrap-up: RFCs need some clarification for d) and e) On 8/11/22 17:56, Phillip Hallam-Baker wrote: > NSEC record specifies what is signed but not the algorithm used to sign. DNSSEC allows multiple signature and digest algorithms on the same zone. If a zone does this, validators are prohibited from rejecting records only signed using one of the algorithms rather than both. > ... > > This definitely needs fixing. I agree that the specs should more clearly say that when a validating resolver sees a (supported?) algorithm in DS without seeing corresponding RRSIG authenticated via such DS record, the response MUST be bogus. Apart from that: What else needs fixing? (You mentioned something with NSEC.) Best. Peter * Further analysis occurred in collaboration with the Black Hat authors, but led to disagreement. The collaboration ended, and a flawed paper [1] was later uploaded on arXiv by the Black Hat authors. As it had Nils' and my name, but not our consent, we had the paper withdrawn. Besides the numerous technical and editorial errors in the paper, we in particular disagree with the conclusion that DNSSEC algorithm agility causes the problems. It's just bugs. [1]: https://arxiv.org/abs/2205.10608 Personally, I also don't believe that the claim of Section 5.2.1 has been experimentally demonstrated. It says: "[...] the adversary manipulates the algorithm number in an RRSIG RRset over DS RRset to some unsupported algorithm. This is required to disable DNSSEC validation of the DS RRset. The adversary manipulates the DS to correspond to its own key-pair. [...] Once this DNSKEY is stored in cache, the adversary can inject any record of its choice. [...] [...] it immediately affects all the subdomains of the poisoned domain. In particular, the adversary can further create secure delegations for the subdomains using its own malicious key. Launching this attack against Google public DNS would have severe consequences for all the domains under com.." [2] That would require that a resolver would regard a DNSKEY as trusted based on a DS record that it has not validated, and use that DNSKEY later to generate responses with AD bit for delegated names. While that is conceivable, it is conceptually different from finding d). At the time when Nils and I were part of the collaboration, the measurement tooling [3] was not capable of this measurement. There is no indication that it was later extended. I will therefore consider that finding a fabrication until the data is made available. [2]: Original revision of the paper (pre-withdrawal): https://arxiv.org/pdf/2205.10608v1.pdf [3]: https://github.com/nils-wisiol/dns-downgrade-attack (In the arXiv metadata, it is recorded that the paper was withdrawn upon request of one of the authors (me), and not because it was found to be inaccurate. Co-authors did not retract the claim from Section 5.2.1, and instead opposed withdrawal until a lawyer got involved. It is peculiar that the claim still was not made in the Black Hat talk, and I'm actually curious to see data that support it.) -- https://desec.io/ From ietf-dane at dukhovni.org Sat Aug 13 19:41:41 2022 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sat, 13 Aug 2022 15:41:41 -0400 Subject: [dns-operations] BlackHat Presentation on DNSSEC Downgrade attack In-Reply-To: References: Message-ID: On Sat, Aug 13, 2022 at 03:07:22PM -0400, Peter Thomassen wrote: > On 8/11/22 17:56, Phillip Hallam-Baker wrote: > > NSEC record specifies what is signed but not the algorithm used to > > sign. DNSSEC allows multiple signature and digest algorithms on the > > same zone. If a zone does this, validators are prohibited from > > rejecting records only signed using one of the algorithms rather > > than both. > > ... > > > > This definitely needs fixing. > > I agree that the specs should more clearly say that when a validating > resolver sees a (supported?) algorithm in DS without seeing > corresponding RRSIG authenticated via such DS record, the response > MUST be bogus. I am generally in favour of specifications being somewhat more explicit even on "obvious" details than is at times common in IETF RFCs. Implementors are sometimes busy, and the even the obvious may be overlooked. > Apart from that: What else needs fixing? (You mentioned something with NSEC.) The NSEC throw-away in the slides looks spurious to me. Sure NSEC records don't specify which RRSIG signature algorithms accompany the RRsets listed in the type bitmap, but this is not a compelling addition. NSEC records only accompany denial of existence, normal responses don't carry NSEC records. The DS and DNSKEY RRs provide all the needed information, the rest merely requires an implementation that avoids unnecessary downgrade issues. -- Viktor. From Jean-Pierre.Seifert at external.telekom.de Mon Aug 15 07:43:42 2022 From: Jean-Pierre.Seifert at external.telekom.de (Jean-Pierre.Seifert at external.telekom.de) Date: Mon, 15 Aug 2022 07:43:42 +0000 Subject: [dns-operations] BlackHat Presentation on DNSSEC Downgrade attack Message-ID: I would like to correct the claims of Peter Thomassen. I am the PhD advisor of Nils Wisiol and unfortunately allowed Peter to join the project at a very late stage as suggested to me by Nils. To clarify: the project started long ago before Peter joined and contrary to Peters claim's I don't remember any new contributions or discoveries since then. We have Emails and Overleaf logs that document everything. In fact, since the contributions were marginal a year ago, we offered Peter Thomassen to remove himself from the paper, which he refused, but insisted to stay as a coauthor, but without contributions. For good atmosphere we have not forced him unfortunately, ... . Due to my unlucky agreement to allow Peter to work with us, I decided to leave that project entirely and let the BH 2022 authors continue that work without any headaches caused by my person. So, please take what Peter writes with a grain of Salt. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Tue Aug 16 14:23:58 2022 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 16 Aug 2022 10:23:58 -0400 Subject: [dns-operations] BlackHat Presentation on DNSSEC Downgrade attack In-Reply-To: References: Message-ID: On Mon, Aug 15, 2022 at 07:43:42AM +0000, Jean-Pierre.Seifert at external.telekom.de wrote: > I would like to correct the claims of Peter Thomassen. [ No factual corrections followed, just ad-hominem. ] > So, please take what Peter writes with a grain of Salt. I don't believe such "corrections" (that look largely like mere attempts to discredit) are on-topic for this list. -- Viktor. From randy at psg.com Wed Aug 17 01:34:05 2022 From: randy at psg.com (Randy Bush) Date: Tue, 16 Aug 2022 18:34:05 -0700 Subject: [dns-operations] BlackHat Presentation on DNSSEC Downgrade attack In-Reply-To: References: Message-ID: have you folk sufficiently damaged your academic reputations and public images that we will not have to read more of this? randy From haya.shulman at gmail.com Mon Aug 22 14:18:36 2022 From: haya.shulman at gmail.com (Haya Shulman) Date: Mon, 22 Aug 2022 16:18:36 +0200 Subject: [dns-operations] BlackHat Presentation on DNSSEC Downgrade attack Message-ID: We allowed Peter Thomassen and Nils Wisiol to join our research. We are also not aware of any contributions they made. We removed both colleagues from our research. In fact, to Peter Thomassen we sent an email in November 2021 on behalf of all the senior researchers on this project, suggesting to him that since his contribution did not justify authorship it would be ethical to remove himself from the authors? list. He refused. If Mr Thomassen wanted to remove the arxiv paper version, it is surprising that he himself published the link of the arxiv paper to this list.... We wanted to remove the arxiv paper to replace it with a version without the two colleagues, however, we have not received their consent, which arxiv requires for removal of uploaded papers. Therefore, the current version is only "withdrawn", meaning, it is still available online. I also suspect Peter Thomassen might not have fully understood our research he wanted to join, esp. given his questions: "this allows "downgrade" to "weakest" (whatever that means)": in our project we evaluated two ways to downgrade DNSSEC, by disabling validation and by downgrading to a weaker cryptographic algorithm. On a different note, if DNSSEC used only one algorithm or a fixed set of algorithms, implementing this would have been simpler and our attacks would perhaps not apply. The different vulnerabilities are caused by an attempt to allow replacing and adding new algorithms. In some cases the recommendations are vague, while in other cases they lead to problems even if one avoids implementation bugs, e.g., during key rollover. Analysis of the different problems leads to one root cause: the current algorithm agility in DNSSEC is what allows our attacks. [RFC7696] says "Algorithm agility is achieved when a protocol can easily migrate from one algorithm suite to another more desirable one, over time." - The ability to migrate from one algorithm suite to another in the current implementations is what exposes DNSSEC to our attacks. In general, I recommend for questions about our work to follow the official announcements and tools of our group. Elias Heftrig, who leads this project as part of his PhD work, is setting up a website (like we typically do in our research projects) with explanations and a tool for checking vulnerabilities, which anyone can use. If there are questions or comments, please email them to us, since I am not following mailing lists. I will also use this opportunity to add pointers to other DNS related research projects of our group, which may be of interest to this audience: * In a recent USENIX Security 2022 research we showed that DNS forwarders in residential routers introduce a vulnerability and demonstrated attacks exploiting them. We did black box and white box analyses of popular routers, finding many to be vulnerable. Philipp Jeitner (just graduated PhD) set up a tool which you can use to check if your routers are vulnerable. More details here: https://www.usenix.org/conference/usenixsecurity22/presentation/jeitner * In a recent ACM CCS 2022 research we explored the dependency of RPKI deployments on DNS and the impact of DNS resolvers and nameservers on the resilience of RPKI deployments. We evaluated how attacks against DNS can subvert RPKI validation. This research will be presented in November 2022. Best, Haya Shulman -- Prof. Dr. Haya Shulman Goethe-Universit?t Frankfurt Fraunhofer SIT ATHENE -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Mon Aug 22 15:42:45 2022 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 22 Aug 2022 11:42:45 -0400 Subject: [dns-operations] BlackHat Presentation on DNSSEC Downgrade attack In-Reply-To: References: Message-ID: On Mon, Aug 22, 2022 at 04:18:36PM +0200, Haya Shulman wrote: > [ Further ad-hominem off-topic to this list removed ] Please refrain from further efforts in that direction. > in our project we evaluated two ways to downgrade DNSSEC, by disabling > validation and by downgrading to a weaker cryptographic algorithm. There is little evidence for, and much current practice to dispel, the idea that DNSSEC is intended to ensure that the "strongest" mutually supported algorithm will be used by validators of multi-algorithm signed zones. Failure to ensure that the strongest algorithm is used for validation is not a bug. Zone signers should not use weak algorithms (nor weak parameters, e.g. 512-bit RSA keys) for signing. If a zone is signed with weak crypto, it is potentially vulnerable to cryptographic attacks (more so in the case of DNSSEC from weak parameters than "weak" algorithms). > The different vulnerabilities are caused by an attempt to allow > replacing and adding new algorithms. No, the reported vulnerability is caused primarily by implementation bugs and only secondarily by insufficiently prescriptive language about the responsibilities of the validating resolver that left some of the requirements implicit. > Analysis of the different problems leads to one root cause: the > current algorithm agility in DNSSEC is what allows our attacks. DNSSEC algorithm agility is a success, and has supported multiple transitions: . RSA with MD5 originally -> RSA with SHA1 (5) -> RSA with SHA1 and NSEC3 (7) -> more recently, RSA with SHA256 (8) or ECDSA P256 (13) ... in a few years time ... -> EdDSA 25519 (15) DNSSEC allows the validator to employ a mutually supported algorithm to validate the signed zone, and, when implemented correctly, does so without downgrade opportunities to "Insecure". Bug reports on implementations that fail to avoid downgrade to "Insecure" are always appreciated (my thanks to Nils for one such report). > [RFC7696] says "Algorithm agility is achieved when a protocol > can easily migrate from one algorithm suite to another more desirable > one, over time." - The ability to migrate from one algorithm suite to > another in the current implementations is what exposes DNSSEC to our > attacks. This is not correct, as evidenced by implementations that are not vulnerable to the reported downgrades to "Insecure". "Downgrades" to the weaker of two signing algorithms are a "feature not a bug". -- Viktor. From keith at dns-oarc.net Mon Aug 22 16:02:14 2022 From: keith at dns-oarc.net (Keith Mitchell) Date: Mon, 22 Aug 2022 12:02:14 -0400 Subject: [dns-operations] BlackHat Presentation on DNSSEC Downgrade attack In-Reply-To: References: Message-ID: <80f684b3-c22c-257e-c413-efe66b9a18c2@dns-oarc.net> Now seems like a good time to remind everyone of the OARC Conduct Policy: https://www.dns-oarc.net/oarc/policies/conduct which applies to all interactions on OARC fora, online and in-person, and including this mailing list. By all means respectfully debate the subject matter, please avoid making it personal. Keith From simamura at iij.ad.jp Thu Aug 25 15:26:59 2022 From: simamura at iij.ad.jp (Mitsuru SHIMAMURA) Date: Fri, 26 Aug 2022 00:26:59 +0900 Subject: APNIC's in-addr.arpa zones were bogus Message-ID: <7f2d34f4-4e64-7fa4-ecb2-51e99b346e41@iij.ad.jp> Hi, I found our DNSSEC validating full service resolver(unbound) prints bellow validation failer logs. 2022-08-25T12:37:04.808871+09:00 resolver unbound - - - [27541:3] info: validation failure <136.197.63.119.in-addr.arpa. PTR IN>: no keys have a DS with algorithm ECDSAP256SHA256 from 2001:13c7:7002:3000::14 for key 119.in-addr.arpa. while building chain of trust 2022-08-25T13:50:39.964228+09:00 resolver unbound - - - [27541:5] info: validation failure <148.99.253.202.in-addr.arpa. PTR IN>: no keys have a DS with algorithm ECDSAP256SHA256 from 2001:67c:e0::9 for key 202.in-addr.arpa. while building chain of trust Not only 119 and 202.in-addr.arpa zones were bogus, below is list. 1.in-addr.arpa. 14.in-addr.arpa. 27.in-addr.arpa. 36.in-addr.arpa. 39.in-addr.arpa. 42.in-addr.arpa. 43.in-addr.arpa. 49.in-addr.arpa. 58.in-addr.arpa. 59.in-addr.arpa. 60.in-addr.arpa. 61.in-addr.arpa. 101.in-addr.arpa. 103.in-addr.arpa. 106.in-addr.arpa. 110.in-addr.arpa. 111.in-addr.arpa. 112.in-addr.arpa. 113.in-addr.arpa. 114.in-addr.arpa. 115.in-addr.arpa. 116.in-addr.arpa. 117.in-addr.arpa. 118.in-addr.arpa. 119.in-addr.arpa. 120.in-addr.arpa. 121.in-addr.arpa. 122.in-addr.arpa. 123.in-addr.arpa. 124.in-addr.arpa. 125.in-addr.arpa. 126.in-addr.arpa. 150.in-addr.arpa. 153.in-addr.arpa. 163.in-addr.arpa. 171.in-addr.arpa. 175.in-addr.arpa. 180.in-addr.arpa. 182.in-addr.arpa. 183.in-addr.arpa. 202.in-addr.arpa. 210.in-addr.arpa. 211.in-addr.arpa. 218.in-addr.arpa. 219.in-addr.arpa. 220.in-addr.arpa. 221.in-addr.arpa. 222.in-addr.arpa. 223.in-addr.arpa. The last bogus log is logged at 18:45(UTC+9). So, we were affected over 6 hours. I found the problem after fix. And I cannot found dnsviz's analyze at the time. Does this outage only affect our network? -- Mitsuru SHIMAMURA Internet Initiative Japan, Inc. From jdamick at amazon.com Thu Aug 25 18:42:40 2022 From: jdamick at amazon.com (Damick, Jeffrey) Date: Thu, 25 Aug 2022 18:42:40 +0000 Subject: APNIC's in-addr.arpa zones were bogus In-Reply-To: <7f2d34f4-4e64-7fa4-ecb2-51e99b346e41@iij.ad.jp> References: <7f2d34f4-4e64-7fa4-ecb2-51e99b346e41@iij.ad.jp> Message-ID: <94F7AB11-E2F2-4EEF-ADC8-332C3A8C2CDD@amazon.com> We also noticed this change, was this a rollover mistake? It looks like RRSIG on the SOA expired at around 2022-08-25 03:12 (UTC) which correlates to approximately when we saw the event begin. ?On 8/25/22, 11:26 AM, "Mitsuru SHIMAMURA" wrote: Hi, I found our DNSSEC validating full service resolver(unbound) prints bellow validation failer logs. 2022-08-25T12:37:04.808871+09:00 resolver unbound - - - [27541:3] info: validation failure <136.197.63.119.in-addr.arpa. PTR IN>: no keys have a DS with algorithm ECDSAP256SHA256 from 2001:13c7:7002:3000::14 for key 119.in-addr.arpa. while building chain of trust 2022-08-25T13:50:39.964228+09:00 resolver unbound - - - [27541:5] info: validation failure <148.99.253.202.in-addr.arpa. PTR IN>: no keys have a DS with algorithm ECDSAP256SHA256 from 2001:67c:e0::9 for key 202.in-addr.arpa. while building chain of trust Not only 119 and 202.in-addr.arpa zones were bogus, below is list. 1.in-addr.arpa. 14.in-addr.arpa. 27.in-addr.arpa. 36.in-addr.arpa. 39.in-addr.arpa. 42.in-addr.arpa. 43.in-addr.arpa. 49.in-addr.arpa. 58.in-addr.arpa. 59.in-addr.arpa. 60.in-addr.arpa. 61.in-addr.arpa. 101.in-addr.arpa. 103.in-addr.arpa. 106.in-addr.arpa. 110.in-addr.arpa. 111.in-addr.arpa. 112.in-addr.arpa. 113.in-addr.arpa. 114.in-addr.arpa. 115.in-addr.arpa. 116.in-addr.arpa. 117.in-addr.arpa. 118.in-addr.arpa. 119.in-addr.arpa. 120.in-addr.arpa. 121.in-addr.arpa. 122.in-addr.arpa. 123.in-addr.arpa. 124.in-addr.arpa. 125.in-addr.arpa. 126.in-addr.arpa. 150.in-addr.arpa. 153.in-addr.arpa. 163.in-addr.arpa. 171.in-addr.arpa. 175.in-addr.arpa. 180.in-addr.arpa. 182.in-addr.arpa. 183.in-addr.arpa. 202.in-addr.arpa. 210.in-addr.arpa. 211.in-addr.arpa. 218.in-addr.arpa. 219.in-addr.arpa. 220.in-addr.arpa. 221.in-addr.arpa. 222.in-addr.arpa. 223.in-addr.arpa. The last bogus log is logged at 18:45(UTC+9). So, we were affected over 6 hours. I found the problem after fix. And I cannot found dnsviz's analyze at the time. Does this outage only affect our network? -- Mitsuru SHIMAMURA Internet Initiative Japan, Inc. From simamura at iij.ad.jp Fri Aug 26 05:20:18 2022 From: simamura at iij.ad.jp (Mitsuru SHIMAMURA) Date: Fri, 26 Aug 2022 14:20:18 +0900 Subject: APNIC's in-addr.arpa zones were bogus In-Reply-To: <94F7AB11-E2F2-4EEF-ADC8-332C3A8C2CDD@amazon.com> References: <7f2d34f4-4e64-7fa4-ecb2-51e99b346e41@iij.ad.jp> <94F7AB11-E2F2-4EEF-ADC8-332C3A8C2CDD@amazon.com> Message-ID: <4325f9c2-67d5-3da7-1e32-98b7ec40a846@iij.ad.jp> Thank you for your infomation. So, I have certainty that this is not our own problem. I'll ask this to APNIC. On 2022/08/26 3:42, Damick, Jeffrey wrote: > We also noticed this change, was this a rollover mistake? It looks like RRSIG on the SOA expired at around 2022-08-25 03:12 (UTC) which correlates to approximately when we saw the event begin. > > -- Mitsuru SHIMAMURA Internet Initiative Japan, Inc. From arth at apnic.net Fri Aug 26 10:17:35 2022 From: arth at apnic.net (Arth Paulite) Date: Fri, 26 Aug 2022 10:17:35 +0000 Subject: [dns-operations] APNIC's in-addr.arpa zones were bogus Message-ID: Hi all, Thank you for reporting this issue. We had a DNSSEC KSK rollover event yesterday for all APNIC IPv4 and IPv6 blocks. It's part of our annual DNSSEC rollover where we change DS record of IPv4 and IPv6 blocks in the parent zone to a pre-published DNSKEY. We apologise if this caused an outage for some of you. We will perform another KSK rollover on a test zone to see if we can reproduce this issue and prevent this from happening in the future. We will also announce our rollover event here in the future. Below are some historical analysis result from dnsviz.net within that period but didn?t show DNSSEC failures. 2022-08-25 01:38:31 UTC https://dnsviz.net/d/1.in-addr.arpa/YwbSlw/dnssec/ 2022-08-25 07:54:06 UTC https://dnsviz.net/d/153.in-addr.arpa/Ywcqng/dnssec/ Regards, Arth Paulite APNIC ? Infrastructure Services Manager -----Original Message----- From: Damick, Jeffrey Date: Friday, 26 August 2022 at 4:42 am To: Mitsuru SHIMAMURA , dns-operations at lists.dns-oarc.net Subject: Re: APNIC's in-addr.arpa zones were bogus We also noticed this change, was this a rollover mistake? It looks like RRSIG on the SOA expired at around 2022-08-25 03:12 (UTC) which correlates to approximately when we saw the event begin. ?On 8/25/22, 11:26 AM, "Mitsuru SHIMAMURA" > wrote: Hi, I found our DNSSEC validating full service resolver(unbound) prints bellow validation failer logs. 2022-08-25T12:37:04.808871+09:00 resolver unbound - - - [27541:3] info: validation failure <136.197.63.119.in-addr.arpa. PTR IN>: no keys have a DS with algorithm ECDSAP256SHA256 from 2001:13c7:7002:3000::14 for key 119.in-addr.arpa. while building chain of trust 2022-08-25T13:50:39.964228+09:00 resolver unbound - - - [27541:5] info: validation failure <148.99.253.202.in-addr.arpa. PTR IN>: no keys have a DS with algorithm ECDSAP256SHA256 from 2001:67c:e0::9 for key 202.in-addr.arpa. while building chain of trust Not only 119 and 202.in-addr.arpa zones were bogus, below is list. 1.in-addr.arpa. 14.in-addr.arpa. 27.in-addr.arpa. 36.in-addr.arpa. 39.in-addr.arpa. 42.in-addr.arpa. 43.in-addr.arpa. 49.in-addr.arpa. 58.in-addr.arpa. 59.in-addr.arpa. 60.in-addr.arpa. 61.in-addr.arpa. 101.in-addr.arpa. 103.in-addr.arpa. 106.in-addr.arpa. 110.in-addr.arpa. 111.in-addr.arpa. 112.in-addr.arpa. 113.in-addr.arpa. 114.in-addr.arpa. 115.in-addr.arpa. 116.in-addr.arpa. 117.in-addr.arpa. 118.in-addr.arpa. 119.in-addr.arpa. 120.in-addr.arpa. 121.in-addr.arpa. 122.in-addr.arpa. 123.in-addr.arpa. 124.in-addr.arpa. 125.in-addr.arpa. 126.in-addr.arpa. 150.in-addr.arpa. 153.in-addr.arpa. 163.in-addr.arpa. 171.in-addr.arpa. 175.in-addr.arpa. 180.in-addr.arpa. 182.in-addr.arpa. 183.in-addr.arpa. 202.in-addr.arpa. 210.in-addr.arpa. 211.in-addr.arpa. 218.in-addr.arpa. 219.in-addr.arpa. 220.in-addr.arpa. 221.in-addr.arpa. 222.in-addr.arpa. 223.in-addr.arpa. The last bogus log is logged at 18:45(UTC+9). So, we were affected over 6 hours. I found the problem after fix. And I cannot found dnsviz's analyze at the time. Does this outage only affect our network? -- Mitsuru SHIMAMURA > Internet Initiative Japan, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From meir at isoc.org.il Fri Aug 26 10:38:21 2022 From: meir at isoc.org.il (Meir Kraushar) Date: Fri, 26 Aug 2022 13:38:21 +0300 Subject: Browser Public suffixes list Message-ID: Hi My name is Meir, from ISOC-IL, the .il registry. We are about to go public with a new IDN ccTLD in Hebrew, being xn--4dbrk0ce. We have done the procedure of updating Mozilla PSL, also merged the list into chromium. But as far as how Safari browser behaves, we are totally in the dark. How to to reach out to any Apple staff, or crate an update request? Any help will be much appreciated. Also, out of curiosity.. if anyone knows why the mess? Why evey browser needs attention, rather than relaying on the IANA tld list? Thank you very much in advance Meir Kraushar -------------- next part -------------- An HTML attachment was scrubbed... URL: From dns at fl1ger.de Fri Aug 26 11:35:38 2022 From: dns at fl1ger.de (Ralf Weber) Date: Fri, 26 Aug 2022 13:35:38 +0200 Subject: [dns-operations] APNIC's in-addr.arpa zones were bogus In-Reply-To: References: Message-ID: <1869CF0D-CADC-4EFF-8128-921582668146@fl1ger.de> Moin! On 25 Aug 2022, at 17:26, Mitsuru SHIMAMURA via dns-operations wrote: > I found our DNSSEC validating full service resolver(unbound) prints bellow validation failer logs. > > 2022-08-25T12:37:04.808871+09:00 resolver unbound - - - [27541:3] info: validation failure <136.197.63.119.in-addr.arpa. PTR IN>: no keys have a DS with algorithm ECDSAP256SHA256 from 2001:13c7:7002:3000::14 for key 119.in-addr.arpa. while building chain of trust > > 2022-08-25T13:50:39.964228+09:00 resolver unbound - - - [27541:5] info: validation failure <148.99.253.202.in-addr.arpa. PTR IN>: no keys have a DS with algorithm ECDSAP256SHA256 from 2001:67c:e0::9 for key 202.in-addr.arpa. while building chain of trust > > Not only 119 and 202.in-addr.arpa zones were bogus, below is list. I can confirm that I saw similar errors on my resolver (Akamai Cacheserve) between August 25 03:00 UTC and 23:00 UTC > The last bogus log is logged at 18:45(UTC+9). > > So, we were affected over 6 hours. As said mine lasted longer, but it is doing lots of PTR request as it runs a mail server. It was different networks that were affected over that time frame. > I found the problem after fix. Out of curiosity what was the problem? > And I cannot found dnsviz's analyze at the time. DNSViz no longer automatically does checking, as the storage and processing requirements were too much for DNS OARC who runs it now. It only does and stores when you ask it on the website. > Does this outage only affect our network? No, my guess is that others will also see it when they dig in their logs. So long -Ralf --- Ralf Weber From peter at desec.io Fri Aug 26 14:51:03 2022 From: peter at desec.io (Peter Thomassen) Date: Fri, 26 Aug 2022 10:51:03 -0400 Subject: [dns-operations] Browser Public suffixes list In-Reply-To: References: Message-ID: Hi Meir, On 8/26/22 06:38, Meir Kraushar via dns-operations wrote: > We are about to go public with a new IDN ccTLD in Hebrew, being xn--4dbrk0ce. > We have done the procedure of updating Mozilla PSL, also merged the list into chromium. But as far as how Safari browser behaves, we are totally in the dark. > How to to reach out to any Apple staff, or crate an update request? > Any help will be much appreciated. As per the PSL algorithm [1], there is a rule "*" that matches the top level, so that all TLDs automatically qualify as Public Suffixes. You can verify this by entering "example.xn--4dbrk0ce" into the form at [2]. Given that, it does not seem necessary to make sure that browsers include new TLDs explicitly. Are you encountering a problem due to the lack of inclusion in the PSL, or are you merely trying to get it included for completeness? [1]: https://github.com/publicsuffix/list/wiki/Format#algorithm [2]: https://publicsuffix.zone/ > Also, out of curiosity.. if anyone knows why the mess? Why evey browser needs attention, rather than relaying on the IANA tld list? That's because there are public suffixes that are operated by other entities [3]. For example, s3.amazonaws.com is a public suffix. There is a significant number of them (just take a look at the raw PSL file on GitHub). [3]: https://github.com/publicsuffix/list/wiki/Format#divisions HTH, Peter -- https://desec.io/ From meir at isoc.org.il Fri Aug 26 18:20:00 2022 From: meir at isoc.org.il (Meir Kraushar) Date: Fri, 26 Aug 2022 21:20:00 +0300 Subject: [dns-operations] Browser Public suffixes list In-Reply-To: References: Message-ID: Hi peter Yes the problem is that browsers not aware of a TLD, in this case SAFARI unaware of xn--4dbrk0ce, do not treat it as a domain. It won't resolve the given name and go to the address. Instead, it will pass the value to the search engine. This is bad. Most certainly not the desired behavior when launching a new domain. On Fri, Aug 26, 2022, 17:58 Peter Thomassen wrote: > Hi Meir, > > On 8/26/22 06:38, Meir Kraushar via dns-operations wrote: > > We are about to go public with a new IDN ccTLD in Hebrew, being > xn--4dbrk0ce. > > We have done the procedure of updating Mozilla PSL, also merged the list > into chromium. But as far as how Safari browser behaves, we are totally in > the dark. > > How to to reach out to any Apple staff, or crate an update request? > > Any help will be much appreciated. > > As per the PSL algorithm [1], there is a rule "*" that matches the top > level, so that all TLDs automatically qualify as Public Suffixes. > > You can verify this by entering "example.xn--4dbrk0ce" into the form at > [2]. > > Given that, it does not seem necessary to make sure that browsers include > new TLDs explicitly. Are you encountering a problem due to the lack of > inclusion in the PSL, or are you merely trying to get it included for > completeness? > > [1]: https://github.com/publicsuffix/list/wiki/Format#algorithm > [2]: https://publicsuffix.zone/ > > > Also, out of curiosity.. if anyone knows why the mess? Why evey browser > needs attention, rather than relaying on the IANA tld list? > > That's because there are public suffixes that are operated by other > entities [3]. For example, s3.amazonaws.com is a public suffix. There is > a significant number of them (just take a look at the raw PSL file on > GitHub). > > [3]: https://github.com/publicsuffix/list/wiki/Format#divisions > > HTH, > Peter > > -- > https://desec.io/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Fri Aug 26 19:16:42 2022 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 26 Aug 2022 15:16:42 -0400 Subject: [dns-operations] Browser Public suffixes list In-Reply-To: References: Message-ID: On Fri, Aug 26, 2022 at 09:20:00PM +0300, Meir Kraushar wrote: > Yes the problem is that browsers not aware of a TLD, in this case SAFARI > unaware of xn--4dbrk0ce, do not treat it as a domain. It won't resolve > the given name and go to the address. Instead, it will pass the value to > the search engine. This is bad. Most certainly not the desired behavior > when launching a new domain. That's rather odd. How old is the Safari release you're testing? The TLD is no longer "brand new": DNSSEC/DANE survey data for the TLD shows a go-live date in Mar 2021, with DNSSEC signing in May of this year. qname | dnssec | date --------------+--------+------------ xn--4dbrk0ce | f | 2021-03-18 xn--4dbrk0ce | t | 2022-05-13 If Safari has a built-in list of TLDs, it'd have to have been "baked in" at least ~1.5 years ago. Speaking of DNSSEC, I see you're using NSEC3 with opt-out and 5 iterations. Please consider 0 iterations, *no* opt-out and possibly empty salt. See: https://www.rfc-editor.org/rfc/rfc9276.html Indeed when trying: xn--5dbedt4e.xn--4dbrk0ce, also recent Firefox and Chrome suggest a search rather than treating it (?????.?????) as a domain first. It seems that PSL aside (cookie scope management), the browsers have additional rules about which punycode strings they accept as domain names. -- Viktor. From paul.hoffman at icann.org Fri Aug 26 19:24:57 2022 From: paul.hoffman at icann.org (Paul Hoffman) Date: Fri, 26 Aug 2022 19:24:57 +0000 Subject: [dns-operations] [Ext] Browser Public suffixes list In-Reply-To: References: Message-ID: On Aug 26, 2022, at 11:20 AM, Meir Kraushar via dns-operations wrote: > Yes the problem is that browsers not aware of a TLD, in this case SAFARI unaware of xn--4dbrk0ce, do not treat it as a domain. It won't resolve the given name and go to the address. Instead, it will pass the value to the search engine. This is bad. Most certainly not the desired behavior when launching a new domain. The problem is not that "browsers not aware of a TLD", it is that they are having a problem with the right-to-left conversion in that name. For example, using another ccTLD IDN such as xn--4gbrim works fine. Firefox works correctly when you enter the non-existent "nic.xn--4dbrk0ce", but Safari and Chrome fall back to search. All three work fine when entering the non-existent "nic.xn--4gbrim". --Paul Hoffman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2584 bytes Desc: not available URL: From meir at isoc.org.il Fri Aug 26 21:43:51 2022 From: meir at isoc.org.il (Meir Kraushar) Date: Sat, 27 Aug 2022 00:43:51 +0300 Subject: [dns-operations] Browser Public suffixes list In-Reply-To: References: Message-ID: Indeed, TLD xn--4dbrk0ce was signed and published earlier this year. As the DNS guy I was sure this is it. Later on we discovered that browsers have their own lives. It appears as if firefox and chromium browsers determine if an entered value is a domain name or a search value, based on a list called "PSL", which is maintained by Mozilla volunteers: https://publicsuffix.org/ Like I said, this was new to us and frankly very surprising. I think this xkcd describes this situation best: https://xkcd.com/2347 So bottom line, browser behavior is not based on DNS resolving, nor by any IANA list, but rather on the PSL. As I wrote earlier we have already merged the diff into the list. The next update of firefox and hopefully chromium based browsers (sept 26), should contain the updated list. The only browser we could not find any documentation on this matter is Apple's safari. p.s It has nothing to do with right to left scripts. On Fri, Aug 26, 2022, 22:31 Viktor Dukhovni wrote: > On Fri, Aug 26, 2022 at 09:20:00PM +0300, Meir Kraushar wrote: > > > Yes the problem is that browsers not aware of a TLD, in this case SAFARI > > unaware of xn--4dbrk0ce, do not treat it as a domain. It won't resolve > > the given name and go to the address. Instead, it will pass the value to > > the search engine. This is bad. Most certainly not the desired behavior > > when launching a new domain. > > That's rather odd. How old is the Safari release you're testing? The > TLD is no longer "brand new": DNSSEC/DANE survey data for the TLD shows > a go-live date in Mar 2021, with DNSSEC signing in May of this year. > > qname | dnssec | date > --------------+--------+------------ > xn--4dbrk0ce | f | 2021-03-18 > xn--4dbrk0ce | t | 2022-05-13 > > If Safari has a built-in list of TLDs, it'd have to have been "baked in" > at least ~1.5 years ago. > > Speaking of DNSSEC, I see you're using NSEC3 with opt-out and 5 > iterations. Please consider 0 iterations, *no* opt-out and possibly > empty salt. See: > > https://www.rfc-editor.org/rfc/rfc9276.html > > Indeed when trying: xn--5dbedt4e.xn--4dbrk0ce, also recent Firefox and > Chrome suggest a search rather than treating it (?????.?????) as a > domain first. > > It seems that PSL aside (cookie scope management), the browsers have > additional rules about which punycode strings they accept as domain > names. > > -- > Viktor. > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.hoffman at icann.org Fri Aug 26 22:25:49 2022 From: paul.hoffman at icann.org (Paul Hoffman) Date: Fri, 26 Aug 2022 22:25:49 +0000 Subject: [dns-operations] [Ext] Browser Public suffixes list In-Reply-To: References: Message-ID: <7A7A5799-548C-4D16-AA50-1C5D573CE7B0@icann.org> On Aug 26, 2022, at 2:43 PM, Meir Kraushar via dns-operations wrote: > So bottom line, browser behavior is not based on DNS resolving, nor by any IANA list, but rather on the PSL. This is interesting info, thanks! The PSL is used by browsers for things like preventing cross-site scripting, but should not be relied on for "is it really a TLD". For that, IANA has many tools, including . There's also, you know, the DNS itself.... > As I wrote earlier we have already merged the diff into the list. > The next update of firefox and hopefully chromium based browsers (sept 26), should contain the updated list. > The only browser we could not find any documentation on this matter is Apple's safari. > p.s It has nothing to do with right to left scripts. Whew! That's very good news. --Paul Hoffman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2584 bytes Desc: not available URL: From rubensk at nic.br Fri Aug 26 22:57:57 2022 From: rubensk at nic.br (rubensk at nic.br) Date: Fri, 26 Aug 2022 19:57:57 -0300 Subject: [dns-operations] Browser Public suffixes list In-Reply-To: References: Message-ID: <14BC69BE-A356-4B44-B1B1-8D972DCC8057@nic.br> > > So bottom line, browser behavior is not based on DNS resolving, nor by any IANA list, but rather on the PSL. > As I wrote earlier we have already merged the diff into the list. > The next update of firefox and hopefully chromium based browsers (sept 26), should contain the updated list. > The only browser we could not find any documentation on this matter is Apple's safari. > p.s It has nothing to do with right to left scripts. In my experience launching gTLDs, it takes a few months for Safari to reflect published PSL. It seems they add that at the beginning of a release cycle, instead of the tail-end like Firefox and Chrome. If you have any Apple device with AppleCare contract, you can use that to open a support case for that platform (Mobile Safari and Desktop Safari have different release cycles). That won't speed things up, but can provide you emotional comfort. Rubens -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 529 bytes Desc: Message signed with OpenPGP URL: From johnl at taugh.com Fri Aug 26 22:59:56 2022 From: johnl at taugh.com (John Levine) Date: 26 Aug 2022 18:59:56 -0400 Subject: [dns-operations] [Ext] Browser Public suffixes list In-Reply-To: <7A7A5799-548C-4D16-AA50-1C5D573CE7B0@icann.org> Message-ID: <20220826225956.F2F31487D199@ary.qy> It appears that Paul Hoffman said: >-=-=-=-=-=- >-=-=-=-=-=- > >On Aug 26, 2022, at 2:43 PM, Meir Kraushar via dns-operations wrote: >> So bottom line, browser behavior is not based on DNS resolving, nor by any IANA list, but rather on the PSL. > >This is interesting info, thanks! The PSL is used by browsers for things like preventing cross-site scripting, but should not be >relied on for "is it really a TLD". The browser makeers would disagree with you: https://publicsuffix.org/learn/ These are some of the uses of the list we know about. ,,, Firefox Restricting cookie setting Restricting the setting of the document.domain property Sorting in the download manager Sorting in the cookie manager Searching in history --> Domain highlighting in the URL bar Chromium/Google Chrome (pre-processing, DAFSA builder, parser) Restricting cookie setting --> Determining whether entered text is a search or a website URL Determining whether wildcard subdomains are allowed in Origin Trial tokens Internet Explorer Restricting cookie setting --> Domain highlighting in the URL bar --> Zone determination ActiveX opt-in list security restriction I'm not saying they're right, but it's been like this for a long time. R's, John From paul.hoffman at icann.org Fri Aug 26 23:05:23 2022 From: paul.hoffman at icann.org (Paul Hoffman) Date: Fri, 26 Aug 2022 23:05:23 +0000 Subject: [dns-operations] [Ext] Browser Public suffixes list In-Reply-To: <20220826225956.F2F31487D199@ary.qy> References: <20220826225956.F2F31487D199@ary.qy> Message-ID: <3B8E8A0B-D0FC-40B1-B196-CFD630FF3D64@icann.org> Even worse! Thanks. --Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2584 bytes Desc: not available URL: From meir at isoc.org.il Sat Aug 27 00:11:50 2022 From: meir at isoc.org.il (Meir Kraushar) Date: Sat, 27 Aug 2022 03:11:50 +0300 Subject: [dns-operations] Browser Public suffixes list In-Reply-To: References: Message-ID: Rubens thank you for the tip, I will most certainly look at it. On Sat, Aug 27, 2022, 02:32 Rubens Kuhl via dns-operations < dns-operations at dns-oarc.net> wrote: > > > > ---------- Forwarded message ---------- > From: rubensk at nic.br > To: dns-operations at dns-oarc.net > Cc: > Bcc: > Date: Fri, 26 Aug 2022 19:57:57 -0300 > Subject: Re: [dns-operations] Browser Public suffixes list > > > > So bottom line, browser behavior is not based on DNS resolving, nor by > any IANA list, but rather on the PSL. > > As I wrote earlier we have already merged the diff into the list. > > The next update of firefox and hopefully chromium based browsers (sept > 26), should contain the updated list. > > The only browser we could not find any documentation on this matter is > Apple's safari. > > p.s It has nothing to do with right to left scripts. > > In my experience launching gTLDs, it takes a few months for Safari to > reflect published PSL. It seems they add that at the beginning of a release > cycle, instead of the tail-end like Firefox and Chrome. > If you have any Apple device with AppleCare contract, you can use that to > open a support case for that platform (Mobile Safari and Desktop Safari > have different release cycles). That won't speed things up, but can provide > you emotional comfort. > > > > Rubens > > > > > ---------- Forwarded message ---------- > From: Rubens Kuhl via dns-operations > To: dns-operations at dns-oarc.net > Cc: > Bcc: > Date: Fri, 26 Aug 2022 19:57:57 -0300 > Subject: Re: [dns-operations] Browser Public suffixes list > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > -------------- next part -------------- An HTML attachment was scrubbed... URL: From meir at isoc.org.il Sat Aug 27 00:17:18 2022 From: meir at isoc.org.il (Meir Kraushar) Date: Sat, 27 Aug 2022 03:17:18 +0300 Subject: [dns-operations] Browser Public suffixes list In-Reply-To: References: Message-ID: Hi Viktor You are right, I'll change the nsec3 iterations on xn--4dbrk0ce to 0, no salt. You also suggested to not opt-out? What would be the reason for that? Thank you for the clarification Meir On Fri, Aug 26, 2022, 22:31 Viktor Dukhovni wrote: > On Fri, Aug 26, 2022 at 09:20:00PM +0300, Meir Kraushar wrote: > > > Yes the problem is that browsers not aware of a TLD, in this case SAFARI > > unaware of xn--4dbrk0ce, do not treat it as a domain. It won't resolve > > the given name and go to the address. Instead, it will pass the value to > > the search engine. This is bad. Most certainly not the desired behavior > > when launching a new domain. > > That's rather odd. How old is the Safari release you're testing? The > TLD is no longer "brand new": DNSSEC/DANE survey data for the TLD shows > a go-live date in Mar 2021, with DNSSEC signing in May of this year. > > qname | dnssec | date > --------------+--------+------------ > xn--4dbrk0ce | f | 2021-03-18 > xn--4dbrk0ce | t | 2022-05-13 > > If Safari has a built-in list of TLDs, it'd have to have been "baked in" > at least ~1.5 years ago. > > Speaking of DNSSEC, I see you're using NSEC3 with opt-out and 5 > iterations. Please consider 0 iterations, *no* opt-out and possibly > empty salt. See: > > https://www.rfc-editor.org/rfc/rfc9276.html > > Indeed when trying: xn--5dbedt4e.xn--4dbrk0ce, also recent Firefox and > Chrome suggest a search rather than treating it (?????.?????) as a > domain first. > > It seems that PSL aside (cookie scope management), the browsers have > additional rules about which punycode strings they accept as domain > names. > > -- > Viktor. > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hsalgado at nic.cl Sat Aug 27 01:32:43 2022 From: hsalgado at nic.cl (Hugo Salgado) Date: Fri, 26 Aug 2022 21:32:43 -0400 Subject: [dns-operations] Browser Public suffixes list In-Reply-To: References: Message-ID: Hi Meir. It might also be good to write to the uasg discussion list (https://uasg.tech/). I don't know if they'll have contacts with apple, but this topic fits right in with their "universal acceptance" goal. I remember a similar case a few years ago, and I'm sure they'll be interested in hearing about your case and pushing for a coordinated solution in the future, within icann. Regards, Hugo On August 26, 2022 8:11:50 PM GMT-04:00, Meir Kraushar via dns-operations wrote: >_______________________________________________ >dns-operations mailing list >dns-operations at lists.dns-oarc.net >https://lists.dns-oarc.net/mailman/listinfo/dns-operations -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Sat Aug 27 01:55:13 2022 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 26 Aug 2022 21:55:13 -0400 Subject: [dns-operations] Browser Public suffixes list In-Reply-To: References: Message-ID: On Sat, Aug 27, 2022 at 03:17:18AM +0300, Meir Kraushar wrote: > You also suggested to not opt-out? What would be the reason for that? Attackers can no longer fabricate the existence or non-existence of unsigned delegations whose hashes fall between those of the signed ones. Of course all answers under an unsigned delegation are still subject to some tampering. Most of the value of avoiding opt-out is obtained in "leaf" zones with no delegations. A delegation-mostly zone (such as a TLD) benefits less, but unless you're operating something as large as .COM, there's little reason to bother with opt-out. -- Viktor. From jothan at gmail.com Sat Aug 27 03:07:20 2022 From: jothan at gmail.com (Jothan Frakes) Date: Fri, 26 Aug 2022 20:07:20 -0700 Subject: [dns-operations] Browser Public suffixes list In-Reply-To: References: Message-ID: Hi Meir- I have had some dialog with your CEO on this related to the introduction of this TLD and its subdomains and the PSL PR expediting for https://github.com/publicsuffix/list/pull/1595. I volunteer time to maintain the PSL and I did bump the ?????, ??????.?????, ????.????? , ???.????? , ????.????? namespaces to the front of the queue and invested time to get that pushed and merged. He explained the delay in launch that the ISOC had to do related to this, which is really regrettable. I spend a tremendous amount of time attempting to spread the word about the PSL to ccTLDs and gTLDs to help with awareness, at TechDay during ICANN meetings, the Registry Operators Workshop (ROW), regional ccTLD associations and a variety of conferences so that ccTLD administrators are aware of it. Crucially, around 2019 I spent a good amount of time with Paul Hoffman (who you see here in thread) from the ICANN Office of the CTO (OCTO) in authoring a document that the IANA would furnish to ccTLDs/gTLDs upon their delegation to the root. This was another proactive effort to spread information about the PSL and the reach it has in bridging the divide, and ccTLDs were to receive this so that they were informed proactively about the Public Suffix List. Quick question for you. *Was the PSL information provided to you by the IANA at delegation last year*? It was a lot of proactive effort and time investment on our parts and it could have prevented the current timing matter being faced. The PSL is a catalog. Full stop. We have zero ability to direct how it is used, what changes someone may make (add/remove entries), frequency of updates or product roadmaps. In the case of IOS/MACOS, Safari updates are typically included with general OS updates so they are less frequent. The Universal Acceptance direction that you're being steered to is something that really does not like to give any attention or credence to the reach of the PSL and what it does to reduce the aggravation you are experiencing, but there might be some connections to browser contacts that could be helpful. And you're likely to meet others that experience some of the challenges that are unknown unknowns in navigating IDN interoperability. Candidly, there is a massive chasm between the world of software and solution developers and the world of ICANN, and the PSL is a rope bridge between them that has been in place. Devs have zero tolerance for bureaucracy and candidly there is not a place that exists within the ICANN multistakeholder model that has any amount of benefits to offset the friction that participation would represent (costs, time, obligations, etc). Browsers (etc users of PSL) voluntarily include it, give or take, at their pace. Can't force anything on them, and straying from our status quo has some of them talking about splintering off their own. So imagine having to hunt the resource down being multiplied by the number of browsers, each with their own process, and you might see how this has been left in its current state. -Jothan On Fri, Aug 26, 2022 at 6:44 PM Hugo Salgado wrote: > Hi Meir. It might also be good to write to the uasg discussion list ( > https://uasg.tech/). I don't know if they'll have contacts with apple, > but this topic fits right in with their "universal acceptance" goal. I > remember a similar case a few years ago, and I'm sure they'll be interested > in hearing about your case and pushing for a coordinated solution in the > future, within icann. > > Regards, > > Hugo > > > On August 26, 2022 8:11:50 PM GMT-04:00, Meir Kraushar via dns-operations < > dns-operations at dns-oarc.net> wrote: >> >> ------------------------------ >> dns-operations mailing list >> dns-operations at lists.dns-oarc.net >> https://lists.dns-oarc.net/mailman/listinfo/dns-operations >> >> _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > -------------- next part -------------- An HTML attachment was scrubbed... URL: From meir at isoc.org.il Sat Aug 27 09:56:30 2022 From: meir at isoc.org.il (Meir Kraushar) Date: Sat, 27 Aug 2022 12:56:30 +0300 Subject: [dns-operations] Browser Public suffixes list In-Reply-To: References: Message-ID: Hi Jothan Thank you for the detailed response. 1) After approval and implementation of delegation from the root , I did not notice any information sent from IANA about PSL. We were referred to it only much later. 2) The need to maintain a list dedicated to browser issues is out of our scope. I'm sure there are good reasons to have it, like you said, there is gap between the worlds. The problems in this gap are these: - Even after you find your way and manage to update the list, it takes VERY long time before browsers will actually adopt it. 6 months is the default with chromium (unless you want to expedite the process which requires downloading the source and re compile it with the changes). So this has to be very clear from the beginning. Even after all procedures with ICANN & IANA are done there is a second stage, that can take just as long. - Having said that, we did mange to expedite the process, with the help of good people in both Mozilla and chromium projects. But the biggest enigma , something we still haven't sorted out, is how to reach Apple Safari. Zero, none information . Just a big enigma which is very frustrating. 3)Thanks for the info about UASG I will certainly check it out On Sat, Aug 27, 2022, 06:28 Jothan Frakes wrote: > Hi Meir- > > I have had some dialog with your CEO on this related to the introduction > of this TLD and its subdomains and the PSL PR expediting for > https://github.com/publicsuffix/list/pull/1595. I volunteer time to > maintain the PSL and I did bump the ?????, ??????.?????, ????.????? , > ???.????? , ????.????? namespaces to the front of the queue and invested > time to get that pushed and merged. > > He explained the delay in launch that the ISOC had to do related to this, > which is really regrettable. > > I spend a tremendous amount of time attempting to spread the word about > the PSL to ccTLDs and gTLDs to help with awareness, at TechDay during ICANN > meetings, the Registry Operators Workshop (ROW), regional ccTLD > associations and a variety of conferences so that ccTLD administrators are > aware of it. > > Crucially, around 2019 I spent a good amount of time with Paul Hoffman > (who you see here in thread) from the ICANN Office of the CTO (OCTO) in > authoring a document that the IANA would furnish to ccTLDs/gTLDs upon their > delegation to the root. > > This was another proactive effort to spread information about the PSL and > the reach it has in bridging the divide, and ccTLDs were to receive this so > that they were informed proactively about the Public Suffix List. > > Quick question for you. *Was the PSL information provided to you by the > IANA at delegation last year*? It was a lot of proactive effort and time > investment on our parts and it could have prevented the current timing > matter being faced. > > The PSL is a catalog. Full stop. We have zero ability to direct how it > is used, what changes someone may make (add/remove entries), frequency of > updates or product roadmaps. In the case of IOS/MACOS, Safari updates are > typically included with general OS updates so they are less frequent. > > The Universal Acceptance direction that you're being steered to is > something that really does not like to give any attention or credence to > the reach of the PSL and what it does to reduce the aggravation you are > experiencing, but there might be some connections to browser contacts that > could be helpful. And you're likely to meet others that experience some of > the challenges that are unknown unknowns in navigating IDN interoperability. > > Candidly, there is a massive chasm between the world of software and > solution developers and the world of ICANN, and the PSL is a rope bridge > between them that has been in place. Devs have zero tolerance for > bureaucracy and candidly there is not a place that exists within the ICANN > multistakeholder model that has any amount of benefits to offset the > friction that participation would represent (costs, time, obligations, etc). > > Browsers (etc users of PSL) voluntarily include it, give or take, at their > pace. Can't force anything on them, and straying from our status quo has > some of them talking about splintering off their own. So imagine having to > hunt the resource down being multiplied by the number of browsers, each > with their own process, and you might see how this has been left in its > current state. > > -Jothan > > On Fri, Aug 26, 2022 at 6:44 PM Hugo Salgado wrote: > >> Hi Meir. It might also be good to write to the uasg discussion list ( >> https://uasg.tech/). I don't know if they'll have contacts with apple, >> but this topic fits right in with their "universal acceptance" goal. I >> remember a similar case a few years ago, and I'm sure they'll be interested >> in hearing about your case and pushing for a coordinated solution in the >> future, within icann. >> >> Regards, >> >> Hugo >> >> >> On August 26, 2022 8:11:50 PM GMT-04:00, Meir Kraushar via dns-operations >> wrote: >>> >>> ------------------------------ >>> dns-operations mailing list >>> dns-operations at lists.dns-oarc.net >>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations >>> >>> _______________________________________________ >> dns-operations mailing list >> dns-operations at lists.dns-oarc.net >> https://lists.dns-oarc.net/mailman/listinfo/dns-operations >> > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gaurav.kansal at nic.in Sat Aug 27 04:03:32 2022 From: gaurav.kansal at nic.in (Gaurav Kansal) Date: Sat, 27 Aug 2022 09:33:32 +0530 Subject: [dns-operations] [Ext] Browser Public suffixes list In-Reply-To: <7A7A5799-548C-4D16-AA50-1C5D573CE7B0@icann.org> References: <7A7A5799-548C-4D16-AA50-1C5D573CE7B0@icann.org> Message-ID: <183ACB3A-91B1-49F3-B774-2477AFB09F5F@nic.in> > On 27-Aug-2022, at 04:18, paul.hoffman at icann.org wrote: > ?On Aug 26, 2022, at 2:43 PM, Meir Kraushar via dns-operations wrote: >> So bottom line, browser behavior is not based on DNS resolving, nor by any IANA list, but rather on the PSL. > > This is interesting info, thanks! The PSL is used by browsers for things like preventing cross-site scripting, but should not be relied on for "is it really a TLD". For that, IANA has many tools, including . There's also, you know, the DNS itself.... Nearly all of the TLDs have second level suffixes (like gov.in, co.in and various others) which are used as special names, and zones are further delegated from these suffixes. Merely depending on IANA?s TLDs list will not be enough for Browsers or for anyone who want info about this (like Registrars, CAs etc..).. so PSL is must at least for browsers and CAs. Recently, Jothan, who is maintaining PSL list, has helped me in updating our records in PSL. Regards Gaurav Kansal > >> As I wrote earlier we have already merged the diff into the list. >> The next update of firefox and hopefully chromium based browsers (sept 26), should contain the updated list. >> The only browser we could not find any documentation on this matter is Apple's safari. >> p.s It has nothing to do with right to left scripts. > > Whew! That's very good news. > > --Paul Hoffman > > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations From paul at redbarn.org Sat Aug 27 17:48:46 2022 From: paul at redbarn.org (Paul Vixie) Date: Sat, 27 Aug 2022 10:48:46 -0700 Subject: [dns-operations] Browser Public suffixes list In-Reply-To: References: Message-ID: this... Meir Kraushar via dns-operations wrote on 2022-08-27 02:56: > 2) The need to maintain a list dedicated to browser issues is out of our > scope. I'm sure there are good reasons to have it, like you said, there > is gap between the worlds. ...is why the IETF DBOUND (domain boundaries) working group was originally formed, and why efforts are underway to resuscitate it. see: https://www.ietf.org/mailman/listinfo/dbound -- P Vixie From ietf-dane at dukhovni.org Sat Aug 27 18:06:04 2022 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sat, 27 Aug 2022 14:06:04 -0400 Subject: [dns-operations] Browser Public suffixes list In-Reply-To: References: Message-ID: On Sat, Aug 27, 2022 at 10:48:46AM -0700, Paul Vixie wrote: > this... > > Meir Kraushar via dns-operations wrote on 2022-08-27 02:56: > > 2) The need to maintain a list dedicated to browser issues is out of our > > scope. I'm sure there are good reasons to have it, like you said, there > > is gap between the worlds. > > ...is why the IETF DBOUND (domain boundaries) working group was > originally formed, and why efforts are underway to resuscitate it. > > see: https://www.ietf.org/mailman/listinfo/dbound Another aspect of the problem, is that the browsers unified the address bar and the search bar in order to "improve" (make simpler than possible) the browser user interface. This creates a fundamental ambiguity about user intent. Did the user type a URL sans scheme prefix or a search term? Using the PSL to "disambiguate" is a hack. -- Viktor. From paul at redbarn.org Sat Aug 27 18:20:53 2022 From: paul at redbarn.org (Paul Vixie) Date: Sat, 27 Aug 2022 11:20:53 -0700 Subject: [dns-operations] Browser Public suffixes list In-Reply-To: References: Message-ID: Viktor Dukhovni wrote on 2022-08-27 11:06: > On Sat, Aug 27, 2022 at 10:48:46AM -0700, Paul Vixie wrote: >> ... >> see: https://www.ietf.org/mailman/listinfo/dbound > > Another aspect of the problem, is that the browsers unified the address > bar and the search bar in order to "improve" (make simpler than > possible) the browser user interface. This creates a fundamental > ambiguity about user intent. Did the user type a URL sans scheme prefix > or a search term? Using the PSL to "disambiguate" is a hack. browsers gonna browse. there's nothing we can do about that in the protocols. time was, any character-by-character current value in the browser bar which was syntactically valid as a domain name (by regex without reference to a PSL or any other dictionary) would be sent to the DNS resolver. apparently this wasn't monetizing enough. we march on. -- P Vixie From ietf-dane at dukhovni.org Sat Aug 27 18:25:56 2022 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sat, 27 Aug 2022 14:25:56 -0400 Subject: [dns-operations] .in ccTLD 2-level public suffixes In-Reply-To: <183ACB3A-91B1-49F3-B774-2477AFB09F5F@nic.in> References: <7A7A5799-548C-4D16-AA50-1C5D573CE7B0@icann.org> <183ACB3A-91B1-49F3-B774-2477AFB09F5F@nic.in> Message-ID: > Nearly all of the TLDs have second level suffixes (like gov.in, co.in > and various others) which are used as special names, and zones are > further delegated from these suffixes. Speaking of ccTLD second level public suffixes, for .in I've just noticed not only some "expected" suffixes like: ac.in biz.in co.in com.in edu.in firm.in gen.in gov.in ind.in info.in net.in nic.in org.in res.in web.in But also some that appear to just mirror other ccTLDs without an obvious connection to a category of child domains (com, edu, gov, net, org, ...): ai.in am.in ca.in cn.in er.in io.in me.in pg.in tv.in uk.in us.in What are these for? I'm afraid these may create or add to user confusion. -- Viktor. From johnl at taugh.com Sat Aug 27 20:00:01 2022 From: johnl at taugh.com (John Levine) Date: 27 Aug 2022 16:00:01 -0400 Subject: [dns-operations] .in ccTLD 2-level public suffixes In-Reply-To: Message-ID: <20220827200001.5CCDA4887452@ary.qy> It appears that Viktor Dukhovni said: >But also some that appear to just mirror other ccTLDs without an obvious >connection to a category of child domains (com, edu, gov, net, org, ...): > > ai.in am.in ca.in cn.in er.in io.in me.in pg.in tv.in uk.in us.in > >What are these for? I'm afraid these may create or add to user confusion. The registry web site says since 2005 they've been available for anyone to register anything. The 2LDs that limit who can register are ac.in res.in edu.in gov.in mil.in. https://registry.in/policies R's, John From ietf-dane at dukhovni.org Sat Aug 27 20:21:37 2022 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sat, 27 Aug 2022 16:21:37 -0400 Subject: [dns-operations] .in ccTLD 2-level public suffixes In-Reply-To: <20220827200001.5CCDA4887452@ary.qy> References: <20220827200001.5CCDA4887452@ary.qy> Message-ID: On Sat, Aug 27, 2022 at 04:00:01PM -0400, John Levine wrote: > It appears that Viktor Dukhovni said: > >But also some that appear to just mirror other ccTLDs without an obvious > >connection to a category of child domains (com, edu, gov, net, org, ...): > > > > ai.in am.in ca.in cn.in er.in io.in me.in pg.in tv.in uk.in us.in > > > >What are these for? I'm afraid these may create or add to user confusion. > > The registry web site says since 2005 they've been available for > anyone to register anything. The 2LDs that limit who can register are > ac.in res.in edu.in gov.in mil.in. > > https://registry.in/policies Thanks, that confirms and details their availability as public suffixes. These suffixes were specifically provisioned (and are not themselves delegated, they are included directly in the .in zone) by the .IN ccTLD, and I am curious whether the intent was specifically to "mirror" similarly named ccTLDs (and if so, why), or whether perhaps these 2-letter abbreviations have some other significance in India... -- Viktor. From ietf-dane at dukhovni.org Sat Aug 27 20:21:37 2022 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sat, 27 Aug 2022 16:21:37 -0400 Subject: [dns-operations] .in ccTLD 2-level public suffixes In-Reply-To: <20220827200001.5CCDA4887452@ary.qy> References: <20220827200001.5CCDA4887452@ary.qy> Message-ID: On Sat, Aug 27, 2022 at 04:00:01PM -0400, John Levine wrote: > It appears that Viktor Dukhovni said: > >But also some that appear to just mirror other ccTLDs without an obvious > >connection to a category of child domains (com, edu, gov, net, org, ...): > > > > ai.in am.in ca.in cn.in er.in io.in me.in pg.in tv.in uk.in us.in > > > >What are these for? I'm afraid these may create or add to user confusion. > > The registry web site says since 2005 they've been available for > anyone to register anything. The 2LDs that limit who can register are > ac.in res.in edu.in gov.in mil.in. > > https://registry.in/policies Thanks, that confirms and details their availability as public suffixes. These suffixes were specifically provisioned (and are not themselves delegated, they are included directly in the .in zone) by the .IN ccTLD, and I am curious whether the intent was specifically to "mirror" similarly named ccTLDs (and if so, why), or whether perhaps these 2-letter abbreviations have some other significance in India... -- Viktor. From johnl at taugh.com Sat Aug 27 20:46:19 2022 From: johnl at taugh.com (John Levine) Date: 27 Aug 2022 16:46:19 -0400 Subject: [dns-operations] .in ccTLD 2-level public suffixes In-Reply-To: Message-ID: <20220827204619.C93F84888250@ary.qy> It appears that Viktor Dukhovni said: >> > >> > ai.in am.in ca.in cn.in er.in io.in me.in pg.in tv.in uk.in us.in >Thanks, that confirms and details their availability as public suffixes. > >These suffixes were specifically provisioned (and are not themselves >delegated, they are included directly in the .in zone) by the .IN ccTLD, >and I am curious whether the intent was specifically to "mirror" >similarly named ccTLDs (and if so, why), or whether perhaps these >2-letter abbreviations have some other significance in India... I'm pretty sure they were opportunistic. They don't appear to match up with Indian states or anything else I can recognize. R's, John From jothan at gmail.com Sun Aug 28 01:43:45 2022 From: jothan at gmail.com (Jothan Frakes) Date: Sat, 27 Aug 2022 18:43:45 -0700 Subject: [dns-operations] Browser Public suffixes list In-Reply-To: References: Message-ID: I am really frustrated that the materials developed for IANA to share to avoid things like this were not distributed, as awareness would have led to earlier request, which in turn would have diminished the propagation timing gap with the browser side. Not saying all the planets would have lined up, but the odds would have improved. "Browsers gonna browse" - love that Vixie quote. The performance of the combined 'omnibox' that mashed up search and location was also a driver, although screen real estate on mobile/tablet certainly made this a practical argument for omnibox vs them sweet, sweet search dollas Anyways, as far as the propagation timing goes, PSL is just a drop in component that is *relatively* static, and we're quite mindful of keeping the file size modest for a number of reasons. I am glad that the team at ISOC.IL were able to find waldo within Mozilla and Google. I think with Safari it is important to note that updates to it are typically done at the time of their OS upgrades as a 'whole cloth' update, and it seems Apple likes to make modest update frequency, so Safari internals are one of the train cars attached to the OS Train but not the train itself, and this is just an efficiency thing. The performance benefit is the best argument I have been presented as to why there is a static list baked in on the browser. Generally speaking, the PSL being used as a static list incorporated into software kind of perpetuates the hosts.txt dilemma that DNS started to distribute better, and the DBOUND began a good direction but we ended up with a low 'juice to squeeze' ratio and could not quite work out what flavor either. There is some activity inside of the W3C WhatWG kind of as a parallel evolution to DBOUND (bridge being built from other side of canyon). Crucially, there are a number of ways in addition to administrative boundaries that overlap, and there are other projects like DKIM DMARC HSTS etc that have a lot of overlap in ways a common project might be helpful in allowing an administrator of a namespace for a domain name in having some means to express to the internet how they would prefer their domain name be interacted with. -Jothan On Sat, Aug 27, 2022 at 11:26 AM Paul Vixie via dns-operations < dns-operations at dns-oarc.net> wrote: > > > > ---------- Forwarded message ---------- > From: Paul Vixie > To: DNS Operations List > Cc: > Bcc: > Date: Sat, 27 Aug 2022 11:20:53 -0700 > Subject: Re: [dns-operations] Browser Public suffixes list > > > Viktor Dukhovni wrote on 2022-08-27 11:06: > > On Sat, Aug 27, 2022 at 10:48:46AM -0700, Paul Vixie wrote: > >> ... > >> see: https://www.ietf.org/mailman/listinfo/dbound > > > > Another aspect of the problem, is that the browsers unified the address > > bar and the search bar in order to "improve" (make simpler than > > possible) the browser user interface. This creates a fundamental > > ambiguity about user intent. Did the user type a URL sans scheme prefix > > or a search term? Using the PSL to "disambiguate" is a hack. > > browsers gonna browse. there's nothing we can do about that in the > protocols. time was, any character-by-character current value in the > browser bar which was syntactically valid as a domain name (by regex > without reference to a PSL or any other dictionary) would be sent to the > DNS resolver. apparently this wasn't monetizing enough. we march on. > > -- > P Vixie > > > > > ---------- Forwarded message ---------- > From: Paul Vixie via dns-operations > To: DNS Operations List > Cc: > Bcc: > Date: Sat, 27 Aug 2022 11:20:53 -0700 > Subject: Re: [dns-operations] Browser Public suffixes list > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rubensk at nic.br Sun Aug 28 11:04:50 2022 From: rubensk at nic.br (rubensk at nic.br) Date: Sun, 28 Aug 2022 08:04:50 -0300 Subject: [dns-operations] Browser Public suffixes list In-Reply-To: References: Message-ID: <7785CE22-0D59-48C6-B82C-B6EBD59BC698@nic.br> The list of malicious websites in browsers is constantly updated without having to follow the release cycle... where there's a will, there's a way. Rubens > On 27 Aug 2022, at 22:43, Jothan Frakes wrote: > > I am really frustrated that the materials developed for IANA to share to avoid things like this were not distributed, as awareness would have led to earlier request, which in turn would have diminished the propagation timing gap with the browser side. > > Not saying all the planets would have lined up, but the odds would have improved. > > "Browsers gonna browse" - love that Vixie quote. > > The performance of the combined 'omnibox' that mashed up search and location was also a driver, although screen real estate on mobile/tablet certainly made this a practical argument for omnibox vs them sweet, sweet search dollas > > Anyways, as far as the propagation timing goes, PSL is just a drop in component that is *relatively* static, and we're quite mindful of keeping the file size modest for a number of reasons. I am glad that the team at ISOC.IL were able to find waldo within Mozilla and Google. I think with Safari it is important to note that updates to it are typically done at the time of their OS upgrades as a 'whole cloth' update, and it seems Apple likes to make modest update frequency, so Safari internals are one of the train cars attached to the OS Train but not the train itself, and this is just an efficiency thing. > > The performance benefit is the best argument I have been presented as to why there is a static list baked in on the browser. > > Generally speaking, the PSL being used as a static list incorporated into software kind of perpetuates the hosts.txt dilemma that DNS started to distribute better, and the DBOUND began a good direction but we ended up with a low 'juice to squeeze' ratio and could not quite work out what flavor either. > > There is some activity inside of the W3C WhatWG kind of as a parallel evolution to DBOUND (bridge being built from other side of canyon). > > Crucially, there are a number of ways in addition to administrative boundaries that overlap, and there are other projects like DKIM DMARC HSTS etc that have a lot of overlap in ways a common project might be helpful in allowing an administrator of a namespace for a domain name in having some means to express to the internet how they would prefer their domain name be interacted with. > > -Jothan > > > On Sat, Aug 27, 2022 at 11:26 AM Paul Vixie via dns-operations > wrote: > > > > ---------- Forwarded message ---------- > From: Paul Vixie > > To: DNS Operations List > > Cc: > Bcc: > Date: Sat, 27 Aug 2022 11:20:53 -0700 > Subject: Re: [dns-operations] Browser Public suffixes list > > > Viktor Dukhovni wrote on 2022-08-27 11:06: > > On Sat, Aug 27, 2022 at 10:48:46AM -0700, Paul Vixie wrote: > >> ... > >> see: https://www.ietf.org/mailman/listinfo/dbound > > > > Another aspect of the problem, is that the browsers unified the address > > bar and the search bar in order to "improve" (make simpler than > > possible) the browser user interface. This creates a fundamental > > ambiguity about user intent. Did the user type a URL sans scheme prefix > > or a search term? Using the PSL to "disambiguate" is a hack. > > browsers gonna browse. there's nothing we can do about that in the > protocols. time was, any character-by-character current value in the > browser bar which was syntactically valid as a domain name (by regex > without reference to a PSL or any other dictionary) would be sent to the > DNS resolver. apparently this wasn't monetizing enough. we march on. > > -- > P Vixie > > > > > ---------- Forwarded message ---------- > From: Paul Vixie via dns-operations > > To: DNS Operations List > > Cc: > Bcc: > Date: Sat, 27 Aug 2022 11:20:53 -0700 > Subject: Re: [dns-operations] Browser Public suffixes list > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 529 bytes Desc: Message signed with OpenPGP URL: From kim.davies at iana.org Sun Aug 28 23:40:32 2022 From: kim.davies at iana.org (Kim Davies) Date: Sun, 28 Aug 2022 16:40:32 -0700 Subject: [dns-operations] [Ext] Re: Browser Public suffixes list In-Reply-To: References: Message-ID: Hi Jothan, Quoting Jothan Frakes on Saturday August 27, 2022: > I am really frustrated that the materials developed for IANA to share to > avoid things like this were not distributed, as awareness would have led to > earlier request, which in turn would have diminished the propagation timing > gap with the browser side. I'll confess to being quite perplexed because it sounds like IANA has dropped the ball, but I am at a loss as to what IANA materials you are referring to. I am not aware of any materials developed for IANA to distribute, and we don't have an existing practice of relaying information about third party projects to TLD managers. Apologies if I've completely overlooked something. I know you and I have had discussions in years past about other TLDs that were missing from the PSL, and I've asked if there were ways IANA could contribute. The impression I came away with was the PSL guarded its independence and therefore there wasn't a role for IANA. In light of that I'd shared with you some sample code that I felt could immediately be used by the PSL maintainers to identify gaps, or built upon to trigger additions in your workflow: https://gist.github.com/kjd/3b1141451c77e50e0ab1120caac40072 If PSL is still not automatically recognizing new TLDs, I would suggest it would still be a better approach to automate rather than putting the burden on each and every TLD manager to manually request to be added. After all, the underlying truth of a TLD's existence is easily ascertainable with existing tools without adding extraneous workflow steps. kim From jothan at gmail.com Mon Aug 29 08:44:28 2022 From: jothan at gmail.com (Jothan Frakes) Date: Mon, 29 Aug 2022 01:44:28 -0700 Subject: [dns-operations] [Ext] Re: Browser Public suffixes list In-Reply-To: References: Message-ID: > > I am really frustrated that the materials developed for IANA to share to > > avoid things like this were not distributed, as awareness would have led > to > > earlier request, which in turn would have diminished the propagation > timing > > gap with the browser side. > > I'll confess to being quite perplexed because it sounds like IANA has > dropped the ball, but I am at a loss as to what IANA materials you > are referring to. I am not aware of any materials developed for IANA > to distribute, and we don't have an existing practice of relaying > information about third party projects to TLD managers. Apologies if > I've completely overlooked something. > Apologies, Kim, you didn't overlook something. I didn't mean to infer that IANA didn't do something they should have done here, but rather the document that was developed would have proactively helped the situation. It resulted in OCTO-11 "The Public Suffix List: A Guide for TLD Administrators" https://www.icann.org/en/system/files/files/octo-011-18may20-en.pdf I scrolled back through my email to May of 2020 when I was collaborating with OCTO and completed the materials with them. Although I was pushing a bit for these to be distributed by the IANA to ccTLDs to meet the requirements of Recommendation 3 of SAC-070 on ICANN's side, now that I scroll through it, I notice I was informed by them at the time that the IANA would not be distributing anything as a result of that work. The exact phrasing from SAC-070, Rec 3 was, "Recommendation 3: To close the knowledge gap between registries and popular PSL maintainers, ICANN and the Mozilla Foundation should collaboratively create informational material that can be given to TLD registry operators about the Mozilla PSL." I've often seen where advisory committees produce recommendations or advice that have to become workstream or other activities, and I get that ICANN != IANA or ccTLD obligations necessarily, but it made sense to have ccTLDs that light up into the root getting some information to help understand some of the unknown unknowns. > I know you and I have had discussions in years past about other TLDs > that were missing from the PSL, and I've asked if there were ways IANA > could contribute. Yes, I completely appreciate that. As you know, the PSL has no budget or funding and is entirely volunteer maintained, so these conversations are typically hallway flyby > The impression I came away with was the PSL guarded > its independence and therefore there wasn't a role for IANA. The development community have demonstrated their wants as light-touch, sans bureaucratic things, and free-license with no obligations The requested role for IANA would be to manage and collect subspaces directly for ccTLDs in the interactions with ccTLD administrators and then publish something that could override those that the PSL was created initially to address. There is no other org with those direct relationships that would be more trusted, and the PSL being relied upon in performing that role could be sunsetted with something better and more appropriate and trusted. > In light of > that I'd shared with you some sample code that I felt could immediately > be used by the PSL maintainers to identify gaps, or built upon to > trigger additions in your workflow: > > https://gist.github.com/kjd/3b1141451c77e50e0ab1120caac40072 Thanks for that - it was appreciated, and running it happens when cycles available, manually. > If PSL is still not automatically recognizing new TLDs, We have automation tied to the json file that ICANN publishes when nTLD contracting occurs, but that json does not include ccTLDs, and the automation does not currently parse the tlds.txt from IANA, although there is a request from our community of volunteers to update the automation in https://github.com/publicsuffix/list/issues/1325 You'll note that I said nTLD contracting entries rather than delegated strings in describing the json. Contracting time on gTLDs was a better trigger time for a PSL entry to be added, as it would be in advance of the TLD being included in the root. This helped to bridge the browser propagation delays a bit, as a PSL entry would have baked into the downstream by the time it lit up. Problems experienced by the ISOC on this one typically are result from the lack of the advance notice for proactive addition on the PSL side, and due to the infrequency of new introductions, the rate of occurrence is low - and only a problem when a new ccTLD or IDN ccTLD gets added to the root. I would suggest > it would still be a better approach to automate rather than putting > the burden on each and every TLD manager to manually request to be > added. After all, the underlying truth of a TLD's existence is easily > ascertainable with existing tools without adding extraneous workflow > steps. > Not disagreeing at all on the automation perhaps being beneficial, as we're running long on requests because the volunteer cycles are our only fuel so it lets us do more, faster and accurately. Utopia would be that entries are always being directed by the ccTLD administrator, so that it is representative of their intentional behaviour for their TLD being expressed. I'll also note that automation would have not been a solution for ISOC's issue due to the presence of the stub zones, despite any of the existing tools, no automation nor existing tools could have divined the four stub zones from the minds of the administrators. I still think that sharing a link to OCTO-11 "The Public Suffix List: A Guide for TLD Administrators" or at least a mention of the PSL would be beneficial to consider distributing to whatever new ccTLDs or IDN ccTLDs get added to the root. -Jothan -------------- next part -------------- An HTML attachment was scrubbed... URL: From bortzmeyer at nic.fr Mon Aug 29 09:56:34 2022 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 29 Aug 2022 11:56:34 +0200 Subject: [dns-operations] Browser Public suffixes list In-Reply-To: <7A7A5799-548C-4D16-AA50-1C5D573CE7B0@icann.org> References: <7A7A5799-548C-4D16-AA50-1C5D573CE7B0@icann.org> Message-ID: On Fri, Aug 26, 2022 at 10:25:49PM +0000, Paul Hoffman wrote a message of 100 lines which said: > There's also, you know, the DNS itself.... Speaking of DNS, it is time to remind readers that there was a project to express information such as "is it a public suffix?" in the DNS and it failed: https://mailarchive.ietf.org/arch/msg/dbound/F9SkNAZmYHGKlRwbn5Il78pOkFs/ https://datatracker.ietf.org/wg/dbound/about From laviebb at isoc.org.il Mon Aug 29 10:55:10 2022 From: laviebb at isoc.org.il (Lavie B.B.) Date: Mon, 29 Aug 2022 13:55:10 +0300 Subject: [dns-operations] [Ext] Re: Browser Public suffixes list In-Reply-To: References: Message-ID: Hey Jothan, The OCTO-11 Document is good and important, but is lacking some impotent items such as Browsers and dependent parties. * Browsers - E.G. (Chromium, Firefox) whoch have a good process, Safari / Edge / Samsung which is a patial Enigma or bug reporting process * Dependent parties - PublicSuffixList, publicsuffix-go, LetsEncrypt I would say that a lot of good people are trying to help but some of it have overlapping dependencies and other considerations. I'm still taking notes and will publish a post when i have all the data (contact channels, release time frames, addition important relaying parties, etc...) * Thanks,* *Lavie Ben-Baruch* | *???? ??-????* laviebb at isoc.org.il | +972-54-595-7071 Office | +972-3-970-0919 ????? ???????? ??????? | Israel Internet Association ISOC-IL www.isoc.org.il [image: ????? ???????? ??????? - ISOC-IL] On Mon, 29 Aug 2022 at 12:08, Jothan Frakes wrote: > > I am really frustrated that the materials developed for IANA to share to >> > avoid things like this were not distributed, as awareness would have >> led to >> > earlier request, which in turn would have diminished the propagation >> timing >> > gap with the browser side. >> >> I'll confess to being quite perplexed because it sounds like IANA has >> dropped the ball, but I am at a loss as to what IANA materials you >> are referring to. I am not aware of any materials developed for IANA >> to distribute, and we don't have an existing practice of relaying >> information about third party projects to TLD managers. Apologies if >> I've completely overlooked something. >> > > Apologies, Kim, you didn't overlook something. I didn't mean to infer > that IANA didn't do something they should have done here, but rather the > document that was developed would have proactively helped the situation. > It resulted in OCTO-11 "The Public Suffix List: A Guide for TLD > Administrators" > https://www.icann.org/en/system/files/files/octo-011-18may20-en.pdf > > I scrolled back through my email to May of 2020 when I was collaborating > with OCTO and completed the materials with them. Although I was pushing a > bit for these to be distributed by the IANA to ccTLDs to meet the > requirements of Recommendation 3 of SAC-070 on ICANN's side, now that I > scroll through it, I notice I was informed by them at the time that the > IANA would not be distributing anything as a result of that work. > > The exact phrasing from SAC-070, Rec 3 was, "Recommendation 3: To close > the knowledge gap between registries and popular PSL maintainers, ICANN and > the Mozilla Foundation should collaboratively create informational material > that can be given to TLD registry operators about the Mozilla PSL." > > I've often seen where advisory committees produce recommendations or > advice that have to become workstream or other activities, and I get that > ICANN != IANA or ccTLD obligations necessarily, but it made sense to have > ccTLDs that light up into the root getting some information to help > understand some of the unknown unknowns. > > >> I know you and I have had discussions in years past about other TLDs >> that were missing from the PSL, and I've asked if there were ways IANA >> could contribute. > > > Yes, I completely appreciate that. As you know, the PSL has no budget or > funding and is entirely volunteer maintained, so these conversations are > typically hallway flyby > > >> The impression I came away with was the PSL guarded >> its independence and therefore there wasn't a role for IANA. > > > The development community have demonstrated their wants as light-touch, > sans bureaucratic things, and free-license with no obligations > > The requested role for IANA would be to manage and collect subspaces > directly for ccTLDs in the interactions with ccTLD administrators and then > publish something that could override those that the PSL was created > initially to address. There is no other org with those direct > relationships that would be more trusted, and the PSL being relied upon in > performing that role could be sunsetted with something better and more > appropriate and trusted. > > >> In light of >> that I'd shared with you some sample code that I felt could immediately >> be used by the PSL maintainers to identify gaps, or built upon to >> trigger additions in your workflow: >> >> https://gist.github.com/kjd/3b1141451c77e50e0ab1120caac40072 > > > Thanks for that - it was appreciated, and running it happens when cycles > available, manually. > > >> If PSL is still not automatically recognizing new TLDs, > > > We have automation tied to the json file that ICANN publishes when nTLD > contracting occurs, but that json does not include ccTLDs, and the > automation does not currently parse the tlds.txt from IANA, although there > is a request from our community of volunteers to update the automation in > https://github.com/publicsuffix/list/issues/1325 > > > You'll note that I said nTLD contracting entries rather than delegated > strings in describing the json. Contracting time on gTLDs was a better > trigger time for a PSL entry to be added, as it would be in advance of the > TLD being included in the root. This helped to bridge the browser > propagation delays a bit, as a PSL entry would have baked into the > downstream by the time it lit up. > > Problems experienced by the ISOC on this one typically are result from the > lack of the advance notice for proactive addition on the PSL side, and due > to the infrequency of new introductions, the rate of occurrence is low - > and only a problem when a new ccTLD or IDN ccTLD gets added to the root. > > > I would suggest >> it would still be a better approach to automate rather than putting >> the burden on each and every TLD manager to manually request to be >> added. After all, the underlying truth of a TLD's existence is easily >> ascertainable with existing tools without adding extraneous workflow >> steps. >> > > Not disagreeing at all on the automation perhaps being beneficial, as > we're running long on requests because the volunteer cycles are our only > fuel so it lets us do more, faster and accurately. Utopia would be that > entries are always being directed by the ccTLD administrator, so that it is > representative of their intentional behaviour for their TLD being expressed. > > I'll also note that automation would have not been a solution for ISOC's > issue due to the presence of the stub zones, despite any of the existing > tools, no automation nor existing tools could have divined the four stub > zones from the minds of the administrators. > > I still think that sharing a link to OCTO-11 "The Public Suffix List: A > Guide for TLD Administrators" or at least a mention of the PSL would be > beneficial to consider distributing to whatever new ccTLDs or IDN ccTLDs > get added to the root. > > -Jothan > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > -------------- next part -------------- An HTML attachment was scrubbed... URL: From meir at isoc.org.il Mon Aug 29 20:31:27 2022 From: meir at isoc.org.il (Meir Kraushar) Date: Mon, 29 Aug 2022 23:31:27 +0300 Subject: [dns-operations] [Ext] Re: Browser Public suffixes list In-Reply-To: References: Message-ID: Hi kim Launching this IDN TLD was actually the first time we created a new TLD (well, besides the cctld we already maintain from long ago). For a small registry like ours, it is something you will probably never practice. So frankly, no one here knew that the PSL ever existed, until we were cought in a bind. Even then, it took us a lot of googling and time to come across some relevant information, and finally to realize the existance of PSL, to our embarrassment. When that happened it was already too late, we had to postpone the new TLD launch. As the DNS guy we did everything. All required procedures with ICANN and IANA. But then we found out that there is this "little thing" with browsers. I think it's important to prevent such a mishap from happening again. My experience with IANA is such that when something matters and is important, you know how to make it very clear to us registries. I was not suggesting automation or synchronization with Mozilla, that of course is complicated. But for example a remark in the rzm site, a reference to the documentation would have emphasized the PSL stage, would have put that info in front of us. Meir On Mon, Aug 29, 2022, 03:05 Kim Davies wrote: > Hi Jothan, > > Quoting Jothan Frakes on Saturday August 27, 2022: > > I am really frustrated that the materials developed for IANA to share to > > avoid things like this were not distributed, as awareness would have led > to > > earlier request, which in turn would have diminished the propagation > timing > > gap with the browser side. > > I'll confess to being quite perplexed because it sounds like IANA has > dropped the ball, but I am at a loss as to what IANA materials you > are referring to. I am not aware of any materials developed for IANA > to distribute, and we don't have an existing practice of relaying > information about third party projects to TLD managers. Apologies if > I've completely overlooked something. > > I know you and I have had discussions in years past about other TLDs > that were missing from the PSL, and I've asked if there were ways IANA > could contribute. The impression I came away with was the PSL guarded > its independence and therefore there wasn't a role for IANA. In light of > that I'd shared with you some sample code that I felt could immediately > be used by the PSL maintainers to identify gaps, or built upon to > trigger additions in your workflow: > > https://gist.github.com/kjd/3b1141451c77e50e0ab1120caac40072 > > If PSL is still not automatically recognizing new TLDs, I would suggest > it would still be a better approach to automate rather than putting > the burden on each and every TLD manager to manually request to be > added. After all, the underlying truth of a TLD's existence is easily > ascertainable with existing tools without adding extraneous workflow > steps. > > kim > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Tue Aug 30 16:42:06 2022 From: randy at psg.com (Randy Bush) Date: Tue, 30 Aug 2022 09:42:06 -0700 Subject: [dns-operations] Stale .GN and .LR zone data in some instances of "ns-{gn, lr}.afrinic.net" In-Reply-To: References: Message-ID: cc:s changed and a couple of bcc:s added > Sadly, not yet, even yesterday the SOA serial on the problem instances was > behind, and the RRSIGs are still 2-weeks expired. It is beginning to look > like Afrinic are diverting all queries from Google to a separate server > pool, and it is *that* server pool that has stale data... > > ; <<>> DiG 9.11.10 <<>> @196.216.168.49 soa gn. +nosplit +dnssec +cd +nsid > +norecur +nocrypt > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25967 > ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 1232 > ; NSID: 73 30 31 2d 6e 73 32 2e 6a 69 6e 78 ("s01-ns2.jinx") > ;; QUESTION SECTION: > ;gn. IN SOA > > ;; ANSWER SECTION: > gn. 3600 IN SOA rip.psg.com. > hostmaster.psg.com. 2202015289 86400 3600 2592000 3600 > gn. 3600 IN RRSIG SOA 8 1 3600 20220818095230 > 20220803224100 53103 gn. [omitted] > > ;; AUTHORITY SECTION: > gn. 14400 IN NS rip.psg.com. > gn. 14400 IN NS fork.sth.dnsnode.net. > gn. 14400 IN NS ns-gn.afrinic.net. > gn. 14400 IN RRSIG NS 8 1 14400 20220816200031 > 20220803023758 53103 gn. [omitted] > > On Mon, 29 Aug 2022 at 23:22, Randy Bush wrote: > >>> The zone data for .GN and .LR has older SOA serial numbers and expired >>> signatures on some of the anycast instances of ns-gn.afrinic.net and >>> ns-lr.afrinic.net. Specifically, at least the ones with NSID >>> "s01-ns2.jinx". This breaks resolution of .GN and .LR names via >>> Google DNS from some locations. Please ensure that the zones are >>> updated at all anycast locations. >> >> thanks viktor, >> >> i have bumped the zones at the primary. let's see if afrinic servers >> get the message. thanks viktor another day of no response from afrinic, and i guess i should ask the iana to remove them from the NS RRset for GN and LR. anyone have a way to get afrinic dns folk's attention? randy From anandb at ripe.net Tue Aug 30 17:42:30 2022 From: anandb at ripe.net (Anand Buddhdev) Date: Tue, 30 Aug 2022 19:42:30 +0200 Subject: [dns-operations] Stale .GN and .LR zone data in some instances of "ns-{gn, lr}.afrinic.net" In-Reply-To: References: Message-ID: On 30/08/2022 18:42, Randy Bush wrote: Hi Randy, Viktor, > another day of no response from afrinic, and i guess i should ask the > iana to remove them from the NS RRset for GN and LR. > > anyone have a way to get afrinic dns folk's attention? Try the address dns-masters at afrinic.net. This is the address I use when I need to ask for configuration changes or alert them about problems. Regards, Anand From ietf-dane at dukhovni.org Tue Aug 30 17:54:59 2022 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 30 Aug 2022 13:54:59 -0400 Subject: [dns-operations] Stale .GN and .LR zone data in some instances of "ns-{gn, lr}.afrinic.net" In-Reply-To: References: Message-ID: On Tue, Aug 30, 2022 at 07:42:30PM +0200, Anand Buddhdev wrote: > On 30/08/2022 18:42, Randy Bush wrote: > > Hi Randy, Viktor, > > > another day of no response from afrinic, and i guess i should ask the > > iana to remove them from the NS RRset for GN and LR. > > > > anyone have a way to get afrinic dns folk's attention? > > Try the address dns-masters at afrinic.net. This is the address I use when > I need to ask for configuration changes or alert them about problems. I forwarded Randy's message to dns at anfrinic.net and got an auto-reply with the subject tagged with "[DNS #825742]" as the ticket number, and a "Reply-To" dns-master. So with a bit of luck that'll match your suggestion. -- Viktor. From nishal at controlfreak.co.za Tue Aug 30 19:42:14 2022 From: nishal at controlfreak.co.za (Nishal Goburdhan) Date: Tue, 30 Aug 2022 21:42:14 +0200 Subject: [dns-operations] Stale .GN and .LR zone data in some instances of "ns-{gn, lr}.afrinic.net" In-Reply-To: References: Message-ID: <787C6FC1-FF9B-40F6-AEF3-4DB798BB222F@controlfreak.co.za> On 30 Aug 2022, at 18:42, Randy Bush wrote: > cc:s changed and a couple of bcc:s added hi randy, > anyone have a way to get afrinic dns folk's attention? they?re on it now; i can see that they?re serving the correct serial for .LR already. nishal at jnb:~$ dig +nsid +norec soa @ns-lr.afrinic.net lr. [snip] ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; NSID: 73 30 31 2d 6e 73 32 2e 6a 69 6e 78 ("s01-ns2.jinx") ;; QUESTION SECTION: ;lr. IN SOA ;; ANSWER SECTION: lr. 3600 IN SOA rip.psg.com. hostmaster.psg.com. 1661887443 86400 3600 2592000 3600 [snip] -n. From cedrick.mbeyet at afrinic.net Tue Aug 30 19:37:00 2022 From: cedrick.mbeyet at afrinic.net (Cedrick Adrien Mbeyet) Date: Tue, 30 Aug 2022 23:37:00 +0400 Subject: [dns-operations] Stale .GN and .LR zone data in some instances of "ns-{gn, lr}.afrinic.net" In-Reply-To: References: Message-ID: Dear Viktor, Thanks for reaching out and sorry for the inconvenience. Our team is working on the maters and it is currently recovering. In the meantime I confirm that the best way to reach out to AFRINIC DNS team is through dns-masters at afrinic.net. Then you will for sure get at least one person to respond to you ASAP. Best regards, -- _______________________________________________________________ Cedrick Adrien Mbeyet AFRINIC t: +230 403 5100 / 403 5115 | f: +230 466 6758 | tt: @afrinic | w: www.afrinic.net facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia ______________________________________________________ V: ?A secure and accessible Internet for sustainable digital growth in Africa? M: ?To serve the African Internet community by delivering efficient services in a global multi-stakeholder environment? EPIC (? Excellence ? Passion ? Integrity ? Community Driven) **************************************************************************************** This email and any attachment (s) transmitted with it are confidential. They may also be privileged or otherwise protected by law. They are intended solely for the use of the individual or entity to whom they are addressed. If you have received this email by error, please notify the sender immediately by e-mail and delete this e-mail from your system. You are also notified that disclosing, copying, distributing, or taking any action in relation to its contents is strictly prohibited and unlawful. By reading the message and opening any attachment, the recipient accepts full responsibility for taking protective and remedial action about viruses and other defects. **************************************************************************************** On 30/08/2022 21:54, Viktor Dukhovni wrote: > On Tue, Aug 30, 2022 at 07:42:30PM +0200, Anand Buddhdev wrote: >> On 30/08/2022 18:42, Randy Bush wrote: >> >> Hi Randy, Viktor, >> >>> another day of no response from afrinic, and i guess i should ask the >>> iana to remove them from the NS RRset for GN and LR. >>> >>> anyone have a way to get afrinic dns folk's attention? >> Try the address dns-masters at afrinic.net. This is the address I use when >> I need to ask for configuration changes or alert them about problems. > I forwarded Randy's message to dns at anfrinic.net and got an auto-reply > with the subject tagged with "[DNS #825742]" as the ticket number, and a > "Reply-To" dns-master. So with a bit of luck that'll match your > suggestion. > From paras at salesforce.com Wed Aug 31 14:21:09 2022 From: paras at salesforce.com (Pallavi Aras) Date: Wed, 31 Aug 2022 10:21:09 -0400 Subject: Reminder OARC 39 - Call for Contribution Message-ID: *Reminder: Deadline for OARC 39 abstract submission - September 06, 23:59 UTC * Please note that, we are looking for contributions and remote participation is actively supported ------- OARC 39 will be a two-day hybrid meeting held on* 22 & 23 October in Belgrade, Serbia *at 10:00 AM (Local time - CEST (UTC+02:00)) The onsite part of the meeting will be *co-located with RIPE** 85.* The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: - Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). - Deployment: DNS config management and release process. - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. - Scaling: DNS performance management and metrics. Increasing DNS Server Efficiency - Security/Privacy: DNSSEC signing and validation, key storage, rollovers, qname minimization, DoH/DoT As it is a *hybrid *workshop, we'd like to encourage brevity; presentations should not be longer than 20 minutes (with additional time for questions). **Workshop Milestones:** *2022-09-06 Deadline for submission (23:59 UTC)* 2022-09-08 Preliminary list of contributions published 2022-09-20 Full agenda published 2022-10-03 Deadline for slideset submission and Rehearsal 2022-10-22 OARC 39 Workshop - Day1 2022-10-23 OARC 39 Workshop - Day2 The Registration page and details for presentation submission are published at: To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. Additional information for speakers at OARC 39: * your talk will be broadcast live and recorded for future reference * your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting * *Remote speakers have mandatory rehearsal on 2022-10-04 at 14:00 UTC. *It would be very useful to have your slides (even if draft) ready for this. *Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens.* If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via *Pallavi Aras-Mathai, for the DNS-OARC Programme Committee* OARC depends on sponsorship to fund its workshops and associated social events. Please contact if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) -- Principal Software Engineer, Public DNS team | Salesforce DNS-OARC Programme Committee Chair | DNS conference -------------- next part -------------- An HTML attachment was scrubbed... URL: