From felipe at internetnz.net.nz Wed Oct 2 01:38:32 2024 From: felipe at internetnz.net.nz (Felipe Barbosa) Date: Tue, 1 Oct 2024 22:38:32 -0300 Subject: InternetNZ .nz DNSSEC ZSK Standby Chain Rollover Message-ID: InternetNZ will begin a DNSSEC Zone Signing Key rollover in our standby chain, this should not affect the active chain used in DNS resolution for .nz, the status and scheduling will be posted to status.internetnz.nz. This will consist of two maintenance windows, in each window we will pause zone distribution to make changes, perform validation, and resume zone distribution for the following zones nz, ac.nz, co.nz, cri.nz, geek.nz, gen.nz, govt.nz, health.nz, iwi.nz, kiwi.nz, maori.nz, mil.nz, net.nz, org.nz, parliament.nz, and school.nz The first change window will be used to add new Zone Signing Keys. https://status.internetnz.nz/incidents/xlygrzg6d3tg The second change window will be used to remove inactive Zone Signing Keys. https://status.internetnz.nz/incidents/tftwdv101sz0 For questions or issues please contact registry at internetnz.net.nz, for updates please subscribe to the IRS Production > Zone Publish component of status.internetnz.nz Cheers, -- Ng? mihi Felipe Agnelli Barbosa DNS Specialist InternetNZ | Ipurangi Aotearoa We are the home of .nz and we work for an Internet that benefits all of Aotearoa. www.internetnz.nz GPG: 95C1 8BDC EFA7 9CAC 303D 003E A058 2449 D152 8580 From fw at deneb.enyo.de Sat Oct 5 17:50:26 2024 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 05 Oct 2024 19:50:26 +0200 Subject: [dns-operations] __p_rcode() deprecated? (glibc/Suse) In-Reply-To: (Paul Vixie via dns-operations's message of "Mon, 30 Sep 2024 10:29:42 -0700") References: Message-ID: <87jzemzbfh.fsf@mid.deneb.enyo.de> * Paul Vixie via dns-operations: > Can someone from glibc (as experienced via Suse Leap 15.6) self-identify so > that we can discuss some changes to /usr/include/resolv.h ? > >> const char * p_class (int) __THROW __RESOLV_DEPRECATED; >> const char * p_time (uint32_t) __THROW __RESOLV_DEPRECATED; >> const char * p_type (int) __THROW __RESOLV_DEPRECATED; >> const char * p_rcode (int) __THROW __RESOLV_DEPRECATED; > > These and some other now-deprecated symbols are in fairly wide use. These aren't thread-safe and have not been updated since circa 2000. Widely-used seems a bit of an exaggeration. The names are somewhat common, so Debian Code Search is not directly useful: Apparently, there is a use of p_rcode in a piece of software called prads. But beyond that, I couldn't spot any actual uses. I don't see anything in the Fedora ELF symbols, either. You didn't mention res_opcodes for some reason ? From paul at redbarn.org Sun Oct 6 05:12:21 2024 From: paul at redbarn.org (Paul Vixie) Date: Sat, 05 Oct 2024 22:12:21 -0700 Subject: [dns-operations] __p_rcode() deprecated? (glibc/Suse) In-Reply-To: <87jzemzbfh.fsf@mid.deneb.enyo.de> References: <87jzemzbfh.fsf@mid.deneb.enyo.de> Message-ID: <2358320.ElGaqSPkdT@heater.srcl.tisf.net> if i contribute thread-safe versions of these functions, would they be uptaken? -- P Vixie On Saturday, October 5, 2024 10:50:26 AM PDT Florian Weimer wrote: > * Paul Vixie via dns-operations: > > Can someone from glibc (as experienced via Suse Leap 15.6) self-identify > > so > > that we can discuss some changes to /usr/include/resolv.h ? > > > >> const char * p_class (int) __THROW __RESOLV_DEPRECATED; > >> const char * p_time (uint32_t) __THROW __RESOLV_DEPRECATED; > >> const char * p_type (int) __THROW __RESOLV_DEPRECATED; > >> const char * p_rcode (int) __THROW __RESOLV_DEPRECATED; > > > > These and some other now-deprecated symbols are in fairly wide use. > > These aren't thread-safe and have not been updated since circa 2000. > > Widely-used seems a bit of an exaggeration. The names are somewhat > common, so Debian Code Search is not directly useful: > > > e%7Ctype%7Crcode%29%5Cs*%5C%28&literal=0&perpkg=1&page=8> > > Apparently, there is a use of p_rcode in a piece of software called > prads. But beyond that, I couldn't spot any actual uses. > > I don't see anything in the Fedora ELF symbols, either. > > You didn't mention res_opcodes for some reason ? From markjr at easydns.com Tue Oct 22 23:16:48 2024 From: markjr at easydns.com (Mark E. Jeftovic) Date: Tue, 22 Oct 2024 19:16:48 -0400 Subject: [dns-operations] Apex ALIASES that re NOT flattened CNAMEs Message-ID: <244bf871-c6a5-4625-a807-9550084356eb@easydns.com> For a few weeks I was trying to get a custom domain working with Substack, which does allow it, usually they specify to use the "www." domain level for the CNAME to point at *target.substack-custom-domains.com* But some people want to to this at the domain apex, and the Substack docs state that /some /providers support zone apex aliasing. Which is true. 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 support, who took it up with some ops, it turns out that custom domains /at the apex/ on Substack will /only work/ when the query returns, literally, a CNAME when queried. The example they gave me to replicate was: *theamazingnewsletterofjosh.com* which if you do $ dig theamazingnewsletterofjosh.com @dns1.registrar-servers.com gives you ;; ANSWER SECTION: theamazingnewsletterofjosh.com. 60 IN?? CNAME target.substack-custom-domains.com. Even though if you also do this: $ dig -t ns theamazingnewsletterofjosh.com @dns1.registrar-servers.com you'll get ;; ANSWER SECTION: theamazingnewsletterofjosh.com. 1800 IN NS dns1.registrar-servers.com. theamazingnewsletterofjosh.com. 1800 IN NS dns2.registrar-servers.com. Which would seem to be non-compliant (CNAME and other data) but if you do this $ dig -t soa theamazingnewsletterofjosh.com @dns1.registrar-servers.com you get ;; ANSWER SECTION: theamazingnewsletterofjosh.com. 60 IN?? CNAME target.substack-custom-domains.com. Which is also weird So apparently, Namecheap (which I believe uses UltraDNS on the backend) and apparently Cloudflare handle this apex aliasing, with a literal alias, but if you simply flatten the apex alias, for some reason, it will not work as a Substack custom domain. I thought maybe the powerdns ALIAS pseudo type might facilitate this, https://doc.powerdns.com/authoritative/guides/alias.html but after setting up a test case, it looks like it too, implements this by flattening it out to A records. Am I to assume this is some customized DNS response then? Is it even standards compliant to be handing out a CNAME response for the same zone that has NS records? (I would say no, but it seems to be a thing?) - mark -- Mark E. Jeftovic Co-founder & CEO easyDNS Technologies Inc. +1-(416)-535-8672 ext 225 /"Never expect a thing you do not want, and never desire a thing you do not expect." -- Bob Proctor / -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at redbarn.org Tue Oct 22 23:43:20 2024 From: paul at redbarn.org (Paul Vixie) Date: Tue, 22 Oct 2024 23:43:20 +0000 Subject: [dns-operations] Apex ALIASES that re NOT flattened CNAMEs In-Reply-To: <244bf871-c6a5-4625-a807-9550084356eb@easydns.com> References: <244bf871-c6a5-4625-a807-9550084356eb@easydns.com> Message-ID: <10549477.nUPlyArG6x@dhcp-155.access.rits.tisf.net> every few years the cdn world proposes something like an ALIAS RR. usually it fails at the problem-statement stage. afterward a few more innovators hack their own name servers to do what they need -- usually in a unique way and often in a way that blows chunks when other differently-hacked name servers get a look at the on-the-wire signaling. mark andrews sometimes reminds us that SRV is /n/ decades old and had the web adopted it even /n-1/ decades ago these problems would no longer be with us. now we're getting SVCB and HTTPS records. that'll take a while to push CNAME aside but it's the right horse to bet on, vs. getting innovators to stop inventing new ways to avoid change CNAME for their own use cases. From markjr at easydns.com Tue Oct 22 23:52:03 2024 From: markjr at easydns.com (Mark E. Jeftovic) Date: Tue, 22 Oct 2024 19:52:03 -0400 Subject: [dns-operations] Apex ALIASES that re NOT flattened CNAMEs In-Reply-To: <10549477.nUPlyArG6x@dhcp-155.access.rits.tisf.net> References: <244bf871-c6a5-4625-a807-9550084356eb@easydns.com> <10549477.nUPlyArG6x@dhcp-155.access.rits.tisf.net> Message-ID: <5caa41b7-360f-46b1-b266-220b0cccee26@easydns.com> I hadn't even heard of SCVB until now. Thx. On 2024-10-22 7:43 PM, Paul Vixie wrote: > CAUTION: This email is from an external source. Be careful when clicking links or opening attachments. > > every few years the cdn world proposes something like an ALIAS RR. usually it > fails at the problem-statement stage. afterward a few more innovators hack > their own name servers to do what they need -- usually in a unique way and > often in a way that blows chunks when other differently-hacked name servers get > a look at the on-the-wire signaling. > > mark andrews sometimes reminds us that SRV is /n/ decades old and had the web > adopted it even /n-1/ decades ago these problems would no longer be with us. > > now we're getting SVCB and HTTPS records. that'll take a while to push CNAME > aside but it's the right horse to bet on, vs. getting innovators to stop > inventing new ways to avoid change CNAME for their own use cases. > > -- Mark E. Jeftovic Co-founder & CEO easyDNS Technologies Inc. +1-(416)-535-8672 ext 225 /"Never expect a thing you do not want, and never desire a thing you do not expect." -- Bob Proctor / -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at desec.io Wed Oct 23 05:38:40 2024 From: peter at desec.io (Peter Thomassen) Date: Wed, 23 Oct 2024 07:38:40 +0200 Subject: [dns-operations] Apex ALIASES that re NOT flattened CNAMEs In-Reply-To: <244bf871-c6a5-4625-a807-9550084356eb@easydns.com> References: <244bf871-c6a5-4625-a807-9550084356eb@easydns.com> Message-ID: <26d4bb35-9161-4be2-b4a0-0afa87da22ee@desec.io> 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 support, who took it up with some ops, it turns out that custom domains /at the apex/ on Substack will /only work/ when the query returns, literally, a CNAME when queried. Hm, so why is that? From Substack's web server perspective, the client is making an HTTP request to their IP address, and it does not matter (in fact, the web server does not know) whether that IP address is looked up from a CNAME or via an A record directly. In the latter case, it also does not matter whether that A record is maintained manually or automatically (via CNAME flattening). Of course, the flattened CNAME (A target) could be out of date, but I imagine that an auth synthesizing such flattening would update the synthesized address record(s) after the TTL expires, so the effects are supposed to be the same as those of a cached CNAME target (and associated target address) in a resolver. So it seems to me that if done "correctly" (with refreshing), there's no reason why flattening shouldn't work. Can you provide some detail why that should be different? (Note that their support might have said "you must do apex CNAME" so they don't have to address out-of-date flattened addresses; I don't think that their statement actually is accurate.) Apart from wanting to understand this better, Paul is of course right that SVCB/HTTPS records are the way to go, and in fact surprisingly widely supported already (https://www.netmeister.org/blog/https-rrs.html). Cheers, Peter -- https://desec.io/ From ask at develooper.com Wed Oct 23 05:44:49 2024 From: ask at develooper.com (=?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?=) Date: Tue, 22 Oct 2024 22:44:49 -0700 Subject: [dns-operations] Apex ALIASES that re NOT flattened CNAMEs In-Reply-To: References: <244bf871-c6a5-4625-a807-9550084356eb@easydns.com> Message-ID: <53745A5B-C055-495A-8781-F7D77F5D3711@develooper.com> > On Oct 22, 2024, at 22:38, Peter Thomassen via dns-operations wrote: > > (Note that their support might have said "you must do apex CNAME" so they don't have to address out-of-date flattened addresses; I don't think that their statement actually is accurate.) It sounds like they?re doing the equivalent of `dig -t soa [domain]` rather than checking that DNS eventually points to the right place. Ask -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank at louwers.be Wed Oct 23 07:02:13 2024 From: frank at louwers.be (Frank Louwers) Date: Wed, 23 Oct 2024 09:02:13 +0200 Subject: [dns-operations] Apex ALIASES that re NOT flattened CNAMEs In-Reply-To: <5caa41b7-360f-46b1-b266-220b0cccee26@easydns.com> References: <244bf871-c6a5-4625-a807-9550084356eb@easydns.com> <10549477.nUPlyArG6x@dhcp-155.access.rits.tisf.net> <5caa41b7-360f-46b1-b266-220b0cccee26@easydns.com> Message-ID: <665AAA05-1F66-4027-AEF4-E738AEFD4D4B@louwers.be> Just for lols: ask any operator what the top 3 types these days are. And be surprised to find HTTPS (which is a form of SCVB and only became an RFC less than a year ago) firmly in the top 3 :) Frank > On 23 Oct 2024, at 01:52, Mark E. Jeftovic wrote: > > I hadn't even heard of SCVB until now. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregchoules+dnsops at googlemail.com Wed Oct 23 08:03:28 2024 From: gregchoules+dnsops at googlemail.com (Greg Choules) Date: Wed, 23 Oct 2024 09:03:28 +0100 Subject: [dns-operations] Apex ALIASES that re NOT flattened CNAMEs In-Reply-To: References: <244bf871-c6a5-4625-a807-9550084356eb@easydns.com> <10549477.nUPlyArG6x@dhcp-155.access.rits.tisf.net> <5caa41b7-360f-46b1-b266-220b0cccee26@easydns.com> Message-ID: > ...be surprised to find HTTPS ... firmly in the top 3 That's because (I would say) two companies have a virtual duopoly on the mobile phone OS market, both have had support for the HTTPS record for several years (AFAIK) and so the number of devices making queries for them comfortably exceeds the population of the planet. Greg On Wed, 23 Oct 2024 at 08:04, Frank Louwers via dns-operations < dns-operations at dns-oarc.net> wrote: > > > > ---------- Forwarded message ---------- > From: Frank Louwers > To: "Mark E. Jeftovic" > Cc: Paul Vixie , dns-operations at lists.dns-oarc.net > Bcc: > Date: Wed, 23 Oct 2024 09:02:13 +0200 > Subject: Re: [dns-operations] Apex ALIASES that re NOT flattened CNAMEs > Just for lols: ask any operator what the top 3 types these days are. And > be surprised to find HTTPS (which is a form of SCVB and only became an RFC > less than a year ago) firmly in the top 3 :) > > Frank > > On 23 Oct 2024, at 01:52, Mark E. Jeftovic wrote: > > I hadn't even heard of SCVB until now. > > > > > > ---------- Forwarded message ---------- > From: Frank Louwers via dns-operations > To: "Mark E. Jeftovic" > Cc: dns-operations at lists.dns-oarc.net > Bcc: > Date: Wed, 23 Oct 2024 09:02:13 +0200 > Subject: Re: [dns-operations] Apex ALIASES that re NOT flattened CNAMEs > _______________________________________________ > 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 frank at louwers.be Wed Oct 23 08:07:29 2024 From: frank at louwers.be (Frank Louwers) Date: Wed, 23 Oct 2024 10:07:29 +0200 Subject: [dns-operations] Apex ALIASES that re NOT flattened CNAMEs In-Reply-To: References: <244bf871-c6a5-4625-a807-9550084356eb@easydns.com> <10549477.nUPlyArG6x@dhcp-155.access.rits.tisf.net> <5caa41b7-360f-46b1-b266-220b0cccee26@easydns.com> Message-ID: <40DDF0E3-41BF-4290-A518-E0B95FEE6A21@louwers.be> Sure. But it's a really these days that a huge amount of dns these days are HTTPS queries. And duopoly remarks aside, we as the dns operators community should learn about them and be aware of them. Frank > On 23 Oct 2024, at 10:03, Greg Choules wrote: > > > ...be surprised to find HTTPS ... firmly in the top 3 > That's because (I would say) two companies have a virtual duopoly on the mobile phone OS market, both have had support for the HTTPS record for several years (AFAIK) and so the number of devices making queries for them comfortably exceeds the population of the planet. > > Greg > > On Wed, 23 Oct 2024 at 08:04, Frank Louwers via dns-operations > wrote: >> >> >> >> ---------- Forwarded message ---------- >> From: Frank Louwers > >> To: "Mark E. Jeftovic" > >> Cc: Paul Vixie >, dns-operations at lists.dns-oarc.net >> Bcc: >> Date: Wed, 23 Oct 2024 09:02:13 +0200 >> Subject: Re: [dns-operations] Apex ALIASES that re NOT flattened CNAMEs >> Just for lols: ask any operator what the top 3 types these days are. And be surprised to find HTTPS (which is a form of SCVB and only became an RFC less than a year ago) firmly in the top 3 :) >> >> Frank >> >>> On 23 Oct 2024, at 01:52, Mark E. Jeftovic > wrote: >>> >>> I hadn't even heard of SCVB until now. >>> >>> >> >> >> >> >> ---------- Forwarded message ---------- >> From: Frank Louwers via dns-operations > >> To: "Mark E. Jeftovic" > >> Cc: dns-operations at lists.dns-oarc.net >> Bcc: >> Date: Wed, 23 Oct 2024 09:02:13 +0200 >> Subject: Re: [dns-operations] Apex ALIASES that re NOT flattened CNAMEs >> _______________________________________________ >> 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 vulcano.cl Wed Oct 23 11:48:18 2024 From: hsalgado at vulcano.cl (Hugo Salgado) Date: Wed, 23 Oct 2024 08:48:18 -0300 Subject: [dns-operations] Apex ALIASES that re NOT flattened CNAMEs In-Reply-To: References: <244bf871-c6a5-4625-a807-9550084356eb@easydns.com> Message-ID: Geolocalization dies with CNAME flattening. Several CDNs answer different sets of As depending on client (or resolver's client) location. That is not possible if you flatten in the CNAME at the origin. You have to choose one point of view, or use several and send a union of all As, and let the browser sort it out. Which I think they can't. Hugo On October 23, 2024 2:38:40 AM GMT-03:00, Peter Thomassen via dns-operations wrote: >_______________________________________________ >dns-operations mailing list >dns-operations at lists.dns-oarc.net >https://lists.dns-oarc.net/mailman/listinfo/dns-operations From markjr at easydns.com Wed Oct 23 13:12:39 2024 From: markjr at easydns.com (Mark E. Jeftovic) Date: Wed, 23 Oct 2024 09:12:39 -0400 Subject: [dns-operations] Apex ALIASES that re NOT flattened CNAMEs In-Reply-To: <26d4bb35-9161-4be2-b4a0-0afa87da22ee@desec.io> References: <244bf871-c6a5-4625-a807-9550084356eb@easydns.com> <26d4bb35-9161-4be2-b4a0-0afa87da22ee@desec.io> Message-ID: On 2024-10-23 1:38 AM, Peter Thomassen wrote: > CAUTION: This email is from an external source. Be careful when > clicking links or opening attachments. > > 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 support, who took it up with some ops, it >> turns out that custom domains /at the apex/ on Substack will /only >> work/ when the query returns, literally, a CNAME when queried. > > Hm, so why is that? > > From Substack's web server perspective, the client is making an HTTP > request to their IP address, and it does not matter (in fact, the web > server does not know) whether that IP address is looked up from a > CNAME or via an A record directly. In the latter case, it also does > not matter whether that A record is maintained manually or > automatically (via CNAME flattening). > I believe it's because *target.substack-custom-domains.com* runs on Cloudflare CDN and they either need the custom domain to be /on Cloudflare/ nameservers or implemented the same way as Namecheap (which the original email email outlined). Presumably if its the former, it's because CF can then use some internal mapping to know which custom domains are in use, for the latter, well, that's why I asked. It shouldn't make a difference, because the resolver should just re-query the CNAME target and wind up with A/AAAA recs anyway (right?) After I sent the original message I realized that the example domain name Substack support gave me, doesn't even map to a custom domain there, it just redirects to main substack page, so now I'm wondering if perhaps I'm still not getting a totally accurate explanation from Substack. - mark -- Mark E. Jeftovic Co-founder & CEO easyDNS Technologies Inc. +1-(416)-535-8672 ext 225 /"Never expect a thing you do not want, and never desire a thing you do not expect." -- Bob Proctor / -------------- next part -------------- An HTML attachment was scrubbed... URL: From markjr at easydns.com Wed Oct 23 14:33:49 2024 From: markjr at easydns.com (Mark E. Jeftovic) Date: Wed, 23 Oct 2024 10:33:49 -0400 Subject: [dns-operations] Apex ALIASES that re NOT flattened CNAMEs In-Reply-To: <5caa41b7-360f-46b1-b266-220b0cccee26@easydns.com> References: <244bf871-c6a5-4625-a807-9550084356eb@easydns.com> <10549477.nUPlyArG6x@dhcp-155.access.rits.tisf.net> <5caa41b7-360f-46b1-b266-220b0cccee26@easydns.com> Message-ID: <92cdf6b2-5fc4-4b2b-8baf-251832df0d6f@easydns.com> Now I really feel like the PHB from Dilbert. Brought this up on dev scrum this morning and apparently SVCB and HTTPS has been supported here since last year. No mention of it on our website though :( - mark On 2024-10-22 7:52 PM, Mark E. Jeftovic wrote: > > I hadn't even heard of SCVB until now. > > Thx. > > > On 2024-10-22 7:43 PM, Paul Vixie wrote: >> CAUTION: This email is from an external source. Be careful when clicking links or opening attachments. >> >> every few years the cdn world proposes something like an ALIAS RR. usually it >> fails at the problem-statement stage. afterward a few more innovators hack >> their own name servers to do what they need -- usually in a unique way and >> often in a way that blows chunks when other differently-hacked name servers get >> a look at the on-the-wire signaling. >> >> mark andrews sometimes reminds us that SRV is /n/ decades old and had the web >> adopted it even /n-1/ decades ago these problems would no longer be with us. >> >> now we're getting SVCB and HTTPS records. that'll take a while to push CNAME >> aside but it's the right horse to bet on, vs. getting innovators to stop >> inventing new ways to avoid change CNAME for their own use cases. >> >> > -- > Mark E. Jeftovic > Co-founder & CEO easyDNS Technologies Inc. > +1-(416)-535-8672 ext 225 > > /"Never expect a thing you do not want, > and never desire a thing you do not expect." > -- Bob Proctor / -- Mark E. Jeftovic Co-founder & CEO easyDNS Technologies Inc. +1-(416)-535-8672 ext 225 /"Never expect a thing you do not want, and never desire a thing you do not expect." -- Bob Proctor / -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at desec.io Tue Oct 29 16:05:59 2024 From: peter at desec.io (Peter Thomassen) Date: Tue, 29 Oct 2024 17:05:59 +0100 Subject: Fwd: [Pq-dnssec] Agenda for IETF 121 side meeting In-Reply-To: <17d2e971-2fa4-48f0-b207-09be0c21d1f2@desec.io> References: <17d2e971-2fa4-48f0-b207-09be0c21d1f2@desec.io> Message-ID: Hi all, In case you are interested, please note the below side meeting at the IETF next week, on PQ DNSSEC research. Best, Peter + Caspar PS: If you want to respond, pls use pq-dnssec at ietf.org. -------- Forwarded Message -------- Subject: [Pq-dnssec] Agenda for IETF 121 side meeting Date: Wed, 16 Oct 2024 00:52:34 +0200 From: Peter Thomassen To: pq-dnssec at ietf.org CC: caspar.schutijser at 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 participation: https://ietf.webex.com/meet/ietfsidemeeting2 For more information, see: https://wiki.ietf.org/meeting/121/sidemeetings#meeting-thursday We'll have three presentations. The agenda looks as follows: 5' Note Well / Agenda Bashing 15'+q Swapneel Sheth and Joe Harvey (Verisign): PQ DNSSEC with MTL Mode 20'+q Jason Goertzen (SandboxAQ): Field study on mitigating the costs of Post-Quantum DNSSEC with Merkle Trees 20'+q Ralph Koning (SIDN): A testbed to evaluate post-quantum cryptography in DNSSEC ... Open Discussion / AOB Abstracts are found here: https://wiki.ietf.org/en/group/pq-dnssec Going forward, we'll add slides to this wiki, and use it for documenting progress. See you all on November 7! Best regards, Caspar and Peter _______________________________________________ Pq-dnssec mailing list -- pq-dnssec at ietf.org To unsubscribe send an email to pq-dnssec-leave at ietf.org From tony.mccrory at gmail.com Tue Oct 29 19:54:40 2024 From: tony.mccrory at gmail.com (Tony McCrory) Date: Tue, 29 Oct 2024 19:54:40 +0000 Subject: [dns-operations] incometax.gov.in nameservers intermittent outages Message-ID: Is anyone from or connected with incometax.gov.in here? Both authoritative nameservers ns01.incometax.gov.in and ns02.incometax.gov.in have frequent connectivity failures (timeouts) Inevitable chaos ensues including inability to verify SPF. Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmaestas95 at gmail.com Tue Oct 29 20:44:50 2024 From: tmaestas95 at gmail.com (Tim Maestas) Date: Tue, 29 Oct 2024 13:44:50 -0700 Subject: [dns-operations] incometax.gov.in nameservers intermittent outages In-Reply-To: References: Message-ID: Their nameservers also don't (or didn't) accept TCP yet set +tc on responses - we had to put in a validate-except for them. -Tim On Tue, Oct 29, 2024 at 1:00?PM Tony McCrory wrote: > Is anyone from or connected with incometax.gov.in here? > > Both authoritative nameservers ns01.incometax.gov.in and > ns02.incometax.gov.in have frequent connectivity failures (timeouts) > > Inevitable chaos ensues including inability to verify SPF. > > Tony > _______________________________________________ > 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 dougb at dougbarton.email Wed Oct 30 22:49:42 2024 From: dougb at dougbarton.email (Doug Barton) Date: Wed, 30 Oct 2024 15:49:42 -0700 Subject: R53 Introduces service Binding (SVCB), HTTPS, TLSA, and Secure Shell fingerprint (SSHFP) records Message-ID: <7789b4e3-7338-4ac5-bd7f-36a84065b686@dougbarton.email> Seems like an interesting development. Thoughts? https://aws.amazon.com/blogs/networking-and-content-delivery/improving-security-and-performance-with-additional-dns-resource-record-types-in-amazon-route-53/ From manu.fuste at gmail.com Wed Oct 30 23:08:51 2024 From: manu.fuste at gmail.com (=?UTF-8?Q?Emmanuel_Fust=C3=A9?=) Date: Thu, 31 Oct 2024 00:08:51 +0100 Subject: [dns-operations] R53 Introduces service Binding (SVCB), HTTPS, TLSA, and Secure Shell fingerprint (SSHFP) records In-Reply-To: References: Message-ID: > Seems like an interesting development. > > Thoughts? > > https://aws.amazon.com/blogs/networking-and-content-delivery/improving-security-and-performance-with-additional-dns-resource-record-types-in-amazon-route-53/ They are just catching up. For TLSA, it was about time. Emmanuel. From dougb at dougbarton.us Thu Oct 31 01:27:25 2024 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 30 Oct 2024 18:27:25 -0700 Subject: [dns-operations] R53 Introduces service Binding (SVCB), HTTPS, TLSA, and Secure Shell fingerprint (SSHFP) records In-Reply-To: References: Message-ID: <941f206f-ff1f-4941-9bd4-adae389b2291@dougbarton.us> On 2024-10-30 4:08 PM, Emmanuel Fust? wrote: >> Seems like an interesting development. >> >> Thoughts? >> >> https://aws.amazon.com/blogs/networking-and-content-delivery/improving-security-and-performance-with-additional-dns-resource-record-types-in-amazon-route-53/ > > They are just catching up. > For TLSA, it was about time. > > Emmanuel. Yeah, I had to restrain a snarky response on our internal AWS help channel about DANE support, finally. :) What I'm most curious about is whether HTTPS is going to get broader support from the browsers now that AWS is on board? I lived through several rounds of the ALIAS vs. SRV wars, and remain disappointed in all sides of that argument. The need is obviously there, and the AliasMode for HTTPS seems like it will meet that need, if it's universally supported. It's still not enabled by default in the latest Firefox without DOH, for example. It seems that Chrome and Safari support it on desktop, and that mobile support is also strong. Am I missing anything? My issue is that I can't "sell" this to my organization as an 80% solution. The response I'm likely to get is, "If we need to provision an alternate solution anyway, why bother with the HTTPS records in the first place?" Doug From ietf-dane at dukhovni.org Thu Oct 31 01:31:48 2024 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 31 Oct 2024 12:31:48 +1100 Subject: [dns-operations] R53 Introduces service Binding (SVCB), HTTPS, TLSA, and Secure Shell fingerprint (SSHFP) records In-Reply-To: References: Message-ID: On Wed, Oct 30, 2024 at 03:49:42PM -0700, Doug Barton via dns-operations wrote: > From: Doug Barton > Date: Wed, 30 Oct 2024 15:49:42 -0700 > Subject: R53 Introduces service Binding (SVCB), HTTPS, TLSA, and Secure > Shell fingerprint (SSHFP) records > To: dns-operations at dns-oarc.net > > Seems like an interesting development. > > Thoughts? > > https://aws.amazon.com/blogs/networking-and-content-delivery/improving-security-and-performance-with-additional-dns-resource-record-types-in-amazon-route-53/ Good to see it happen, better late than never. The high level overview is roughly right, be it that some of the technical details are a bit off: - The example TLSA record associated data is not valid hexadecimal. - DANE-enabled SMTP clients don't launch right into a TLS client Hello, after reading the server 220 banner. EHLO and STARTTLS are still required first. If this were a tutorial on deploying server-side DANE TLSA records, I'd have asked for more coverage of the operational requirements of keeping it working (not just fire and forget initial configuration), but this is a service rollout announcement, not a user guide, so the scope is about right... -- Viktor. From ask at develooper.com Thu Oct 31 04:10:45 2024 From: ask at develooper.com (=?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?=) Date: Wed, 30 Oct 2024 21:10:45 -0700 Subject: [dns-operations] R53 Introduces service Binding (SVCB), HTTPS, TLSA, and Secure Shell fingerprint (SSHFP) records In-Reply-To: References: Message-ID: <9E0AB758-796C-4264-B453-518BE8317668@develooper.com> > On Oct 30, 2024, at 18:27, Doug Barton via dns-operations wrote: > > What I'm most curious about is whether HTTPS is going to get broader support from the browsers now that AWS is on board? > > I lived through several rounds of the ALIAS vs. SRV wars, and remain disappointed in all sides of that argument. The need is obviously there, and the AliasMode for HTTPS seems like it will meet that need, if it's universally supported. > > It's still not enabled by default in the latest Firefox without DOH, for example. It seems that Chrome and Safari support it on desktop, and that mobile support is also strong. Am I missing anything? My understanding is that Chrome only supports the flags to use TLS, HTTP/2 and HTTP/3; not the ?use this target? data; but it?s been a while since I checked. In particular if your domain isn?t in the HSTS preload lists then using this as a signal to the clients to connect securely can be very helpful. On macOS/iOS/etc you get the ?full functionality?; depending on your client base it can be a meaningful improvement over anycast IPs (or the proprietary ?alias? type features). Ask -------------- next part -------------- An HTML attachment was scrubbed... URL: