[dns-operations] NEW SLOT for PQ DNSSEC Side Meeting at IETF 123

--- Begin Message --- Hi, To minimize collision with SAAG, we intended to start the PQ DNSSEC side meeting later, still finishing in time. Due to a short-notice agenda addition, that's no longer viable. After consulting with presenters, we have thus rescheduled the meeting to Thursday, J

[dns-operations] Fwd: [Pq-dnssec] Re: Agenda for IETF 122 side meeting

+0100 From: Peter Thomassen To: pq-dns...@ietf.org CC: Caspar Schutijser Hi all, We've received one late submission, so here is the updated agenda. The IETF 112 PQ DNSSEC side meeting is scheduled on Tuesday, March 18, 2025 at 09:30-10:30 (local Bangkok time) in Meeting

Re: [dns-operations] Registrars with a "registry lock" service

--- Begin Message --- Hi Anand, Hexonet supports it for .com, .net, and some other TLDs, but unfortunately not for .org (where we need it) and .community: https://wiki.hexonet.net/wiki/Registry_Lock#Supported_TLDs We got an account there; feel free to message me privately if you need more inf

Re: [dns-operations] .FI going insecure for two weeks (!)

--- Begin Message --- Hi Shumon, On 12/17/24 22:13, Shumon Huque wrote: Yup, but moving to the new platform using the same algorithm non-disruptively still requires some specific features to be supported (multi-signer ZSK import Only by the new system; you do not need to touch the old system

Re: [dns-operations] .FI going insecure for two weeks (!)

--- Begin Message --- Hi Shumon, On 12/17/24 21:51, Shumon Huque wrote: We probably need to know some more details about what exactly is changing. Do we have any contacts at .FI that can provide them? According to a statement sent to their registrars, they are moving from algorithm 8 to 13.

[dns-operations] Fwd: [Pq-dnssec] Agenda for IETF 121 side meeting

121 side meeting Date: Wed, 16 Oct 2024 00:52:34 +0200 From: Peter Thomassen To: pq-dns...@ietf.org CC: caspar.schutij...@sidn.nl Hi all, We have scheduled the PQ DNSSEC side meeting on Thursday, November 7, 2024 at 10:00-11:30 (local Dublin time) in Wicklow Hall 2A Remote

Re: [dns-operations] Apex ALIASES that re NOT flattened CNAMEs

--- Begin Message --- Hi Mark, On 10/23/24 01:16, Mark E. Jeftovic wrote: But most providers do it via CNAME flattening, so at the end of the process, they aren't really CNAMEs, they're A recs. But this will not work for Substack custom domains - and after going back and forth with their supp

Re: [dns-operations] Survey of How to Solving DNS Errors

the study remains as is, my expectation is that insights will be biased and/or limited, and you should expect them to be strongly criticized. Thanks for inviting again to participate, but I don't feel comfortable with it at this point. Best, Peter On 8/16/24 15:54, 苗发生 wrote: -

Re: [dns-operations] Survey of How to Solving DNS Errors

Hi. On 8/15/24 11:25, Ralf Weber wrote: I’m not sure what data you want to get out of that research, but IMHO it is upfront missing a definition of what a resolution error is. Question 4 ("What types of DNS resolution errors have you encountered most frequently?") has NXDOMAIN as one option,

[dns-operations] New tool for Authenticated DNSSEC Bootstrapping (RFC 9615)

(bcc: dn...@ietf.org) Hi, We've just published a new tool that automates generation of RFC 9615 signaling zones (when synthesis is not available). --> https://pypi.org/project/dsboot/ Usage: In its simplest form, feed in zones via stdin (at least their CDS/CDNSKEY/NS records), and signaling

Re: [dns-operations] nz DNSSEC KSK rollover - Standby Chain

Hi Felipe, Thank you for sharing your plans. On 7/9/24 00:34, Felipe Barbosa via dns-operations wrote: The current standby chain key tags for each zone are as follows: nz: 49157, ac.nz : 5938, co.nz : 59176, cri.nz : 19190, geek.nz

[dns-operations] Filtering policy: false positive rate

Hi, Resolver policies typically describe operational rules, such as which data is collected and retained for how long etc. When a resolver offers filtering for ads, abuse, ... their policy ought to say something about this, such as how to unblock a benign domain that was flagged in error. Now

Re: [dns-operations] Percentage of DoT/DoH requests for public resolvers?

Hi Stephane, On 6/12/23 08:49, Stephane Bortzmeyer wrote: I'm looking for the current percentage of encrypted DNS requests vs. in-the-clear ones on public resolvers having DoT/DoH/DoQ. I do not find public information about it. May be I searched too fast? Geoff gave an IEPG presentation in Nov

Re: [dns-operations] List of registries that support CDS/CDNSKEY ?

Hi, On 11/20/22 16:50, vom513 wrote: My understanding is that unfortunately this list is currently pretty small. But is this being tracked anywhere ? Would be nice to have a wiki or something with a table and status, notes etc. Some information on the CDS/CDNSKEY prevalence is kept here: h

Re: [dns-operations] Browser Public suffixes list

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 th

Re: [dns-operations] BlackHat Presentation on DNSSEC Downgrade attack

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-

Re: [dns-operations] How should work name resolution on a modern system?

Hi Dave, On 6/15/22 19:33, Dave Lawrence wrote: Kind of surprising to me the number of TLDs who report their address as 127.0.53.53: .arab .cpa .kids .music .xn--mxtq1m (Chinese: "government") .xn--ngbrx (Urdu: "Arab") This looks reminiscent of the 2014 NCAP approach for new gTLDs: https://w

Re: [dns-operations] Input from dns-operations on NCAP proposal

Hi Thomas, On 5/23/22 15:48, Thomas, Matthew wrote: In the 2012 round of new gTLDs, DNS data collected at the root server system via DNS-OARC’s DITL collection was used to assess name collision visibility. The use of DITL data for name collision assessment purposes has growing limitations in

Re: [dns-operations] Survey on DNS resolver operations and DNSSEC

On 3/21/22 13:19, Bill Woodcock wrote: The alternative to DNSSEC validation is man-in-the-middle compromises.  We wouldn’t be doing DNSSEC validation if it caused more workload than man-in-the-middle compromises.  Therefore the increased workload is negative, not positive. Is that (economic)