**Session Date/Time:** 20 Jul 2026 14:30

[00:00:14] **Johan Stenstam**: Yeah.

[00:00:19] **Ben Schwartz**: Yeah. It is.

[00:00:20] **John Levine**: You sure?

[00:00:21] **Benno Overeinder**: Yeah. So the time meeting was

[00:00:24] **Andreii Robachevsky**: I think Maybe. I don't know. Okay.

[00:00:28] **Ralf Weber**: It's good to know.

[00:00:31] **Benno Overeinder**: It was you know, maybe.

[00:00:34] **Andreii Robachevsky**: I don't I don't really know. I think it was dispatch. Also, you can I think

[00:00:38] **Jim Reid**: it was dispatch?

[00:00:39] **Benno Overeinder**: Correct that. But it I think given time yeah. So

[00:00:44] **Andreii Robachevsky**: Hello. Hello. It's time to start. Can someone close the door, please? So this is the first session of the week for the NS Operations Working Group. This is Benno. I'm Andrei. We also have our secretaries here, Shumon Huque here in the first row, and Peter there. There should be Jim Reid somewhere, our technical advisor, and Warren is our AD. There are links for your convenience, but I'm thinking that the links might be outdated now. So Use the fresh ones. This is the IETF Note Well. It is a reminder about our processes and policies, including about conduct, privacy, and intellectual property rights. You agree to follow when you participate in the IETF. Please read it carefully. Behave respectfully. We take this very seriously. You are encouraged to read the source documents to which the note well refers. If you have questions, please talk to the working group chairs, us, or the area directors. So, meeting tips. Make sure you sign into the data tracker. So for or using the data tracker or QR code for the session, use the Meet Echo client to join the queue, show events and stuff like this. Keep audio and video off if not using the on-site version. For remote participants, we have some presenting. Make sure your audio and video is off unless you are presenting and use of the headset is strongly recommended. State your name each time you begin speaking in the queue. There might be new people who don't know you. And the time includes the time for the questions. So, without further ado, this is our agenda for today. We have a couple of working group updates, the clarification of the CDS, CDNSKEY and the consistency. Sorry, that was I skipped ahead. This is the updates since the last meeting. The RFC 9595 was published and we have two RFCs to be in the edit review or the assigned number. There are two documents with ISG, the structured error data for filter DNS and the like extensions, the code allocations. So this is just a short reminder. We are still in the process for splitting this working group into two. Dnscommentary consultation is now over. The ADs for DNSOP and the Area Directors, I will discuss this. And they will likely start implementing those changes before the next ITF. So current working group business and agenda for today. First, we have Andreiw speaking about integration of DNS domain names in application environments, then our DNSSEC Key Restore and automating DNS delegations. This is all current working group business. We have a couple of drafts for consideration. The NTAs, the EDE for NTAs, Zone Cut to Nowhere and Add TTLs to DNS errors. And we have a couple of speakers for the DNS dispatch function. Reminder, this is not the discussion about the contents of the drafts. This is just about giving guidance to the draft authors where this needs to land. So we are dispatching the staff somewhere. So if you start discussing the contents of the drafts, I will cut you short. I will be the bad cop here. We have two drafts from the same author. We have two more drafts for consideration for the DNS dispatch and one more if time permits. But I kindly doubt that it will happen, but miracles happen. So, of interest, there's a post quantum DNS-site meeting on Thursday. And Karl has asked us if she can say something. She's here. Is she here? So or Karl.

[00:05:54] **Karl**: Or Karl? So so that's that's me, not Karl. Thank you. So just a real quick thirty seconds. You folks, I'm sure, are aware that last year we funded a whole bunch of maintenance of open source DNS related stuff. Some of the successful applicants from last year are in the room. We're doing the same thing again this year. This year we have a larger budget, so this year we're looking to give away in the order of £650,000, so about a million dollars. We the notable changes this year are that you can can apply if you're an individual up to £15,000 a year, up to three years, and institutions can apply for up to a £100,000. And, again, that's per year for up to three years. So if if you think you've got something that you wanna have a chat, please come and say hello. Thank you.

[00:06:49] **Andreii Robachevsky**: And that's it. Andreiw?

[00:07:04] **Benno Overeinder**: Now Timer.

[00:07:23] **Andreiw Fregly**: Alright. Hello. Everyone. I'm Andreiw Kayser here to present an update to our draft integration of DNS domain names in application environments in the application environments. So a quick update about the draft's focus. There's three goals for the draft. One is to minimize conflicts between the global DNS and applications that integrate with the global DNS. This has come about recently because of many new use cases. For example, Bluesky, the social media platform, one of our coauthors uses domain names as a social media handle, and ENS uses a domain name as a way to identify a blockchain wallet. And there are many other new use cases coming about. So we wanna ensure that we can also provide a consistent user experience so that when you use a domain name for a website and email and social media and blockchain address that we're gonna avoid impacts to SSR of the global DNS. So the draft works towards this by providing informational statements on both considerations that applications should account for to minimize such conflicts and also some motivations about why applications are looking at DNS domain names for some of these use cases. And our latest latest update addresses DNS directorate and other mailing list feedback. So what are the updates since we last presented at IETF 119? We've updated the text in the abstract in the introduction to emphasize that the considerations can help avoid potential impacts to SSR. Previous language was a little stronger. We agree that avoid is a better word to use there. We've also updated the completeness consideration text to account for the evolution of namespaces. This is for two reasons. One, of course, is the new gTLD round that is in progress, but also the research around universal acceptance and examples where well known applications were hard coding list of TLDs or domain names they would accept, not accounted for the fact that these can change over time. We've also streamlined several considerations to focus on the key salient points. This is mostly cutting text and trying to distill it down to something that is easier for DNS integrations to consume as they read the document. And we've added text to tell readers that there is an appendix, and it describes how our coauthors from ENS and Bluesky are accounted for these considerations with link backs into the document as well as updates to those appendix sections to ensure that they align with the revised considerations and motivations. So where does that leave our current list of considerations? This list is not meant to be exhaustive. It is high level guidance, but we've now trimmed it down from about 10 to seven considerations. And then the idea here is that an integration can look through this as a checklist of sorts and say, oh, yes. I'm aware that I should account for the domain name life cycle when I integrate with the domain name system to ensure that I can try and stay aligned. Each of these is just a couple paragraphs in the document, and I encourage you to spend some time reading this to provide any feedback. So where does that leave us now? Well, we think the document is in a good shape for the last call. We've incorporated all the feedback that we've heard both on and off the list, and we have not heard anything more since the latest round of updates. So we are, of course, happy to make additional updates if we hear them, but we believe we are ready to move towards last call. Thank you.

[00:10:35] **Benno Overeinder**: It was fast. Thank you. Any questions, remarks? No? So yes, the working group chairs are planning to issue start a working group last call for the drafts, and then we will follow-up on that. Thanks. Thank you. Someone in the queue. Alright. Ben. Ben. Okay. Please go ahead.

[00:11:00] **Ben Schwartz**: Thanks. Hi. Ben Schwartz. So the I'm just taking a look at the the updates. There's section 3.3 talks about domain name not being limited to ASCII characters and talks about internationalized domain names. But the those internationalized domain names do are composed of ASCII characters when they're actually in in the DNS. But DNS also supports domain names if that are not composed of ASCII characters when they are actually in the DNS. I I don't know. I feel like this topic needs a little bit more guidance. In particular, as a practical matter, applications routinely limit themselves to domain names that are in what is called the preferred form, which is limited to ASCII characters. That that is actually kind of a best practice even for IDN, even for internationalized domain names where they're, like, accepted and supported, but, but required to be able to be puny coded into ASCII.

[00:12:22] **Andreiw Fregly**: Alright. Thanks, Ben. We'll take a look at that and see if if if you have a particular BCP or RFC we can reference for the best practice that we can put in there. That'd great. Or or I we'll we'll try and find it. But

[00:12:34] **Ben Schwartz**: There is a an official def there's an official RFC definition of the preferred name syntax.

[00:12:39] **Andreiw Fregly**: Alright. Thanks, Ben.

[00:12:45] **Benno Overeinder**: Good. Thank you. Oh, you're already in. Yeah.

[00:13:02] **Andreii Robachevsky**: Okay. Yeah.

[00:13:04] **Benno Overeinder**: I you're now Oh. I I don't have to.

[00:13:07] **Andreii Robachevsky**: You don't have to. Yes.

[00:13:10] **Benno Overeinder**: Oh,

[00:13:13] **Peter Thomassen**: I know this.

[00:13:16] **Ulrich Wisser**: So hi. I'm I'm I'm about our DNSSEC, key restore draft. Presented this last in, Montreal. So quick recap on the on the problem statement. So you have your DNS zone. You sign it with DNSSEC as you should, and then you, for some reason, lose your private key. There are multiple reasons why this could happen. Now a lofty goal would be to say, I'm operating this perfectly, and it will never happen to me. This is probably difficult to get past your risk and compliance department or any auditor. So the question is, what are you doing next if this boo boo happens? And your current options are you you just introduce a new key, and it's almost going to be bogus for probably around a day, and you write it out. Maybe this is okay for you. Maybe your resolvers do not validate. Maybe you can put in a NTA, that kind of thing. Or you decide to go intentionally insecure. Someone should totally write a draft on how to do that properly. Hi, Wes. Or maybe early retirement or this draft. And the idea behind this draft is if you squint just right, you can use the timing considerations for the key rollover to actually get your private key back. Or while you don't get your private key back, you can introduce a new key without, you know, going bogus or insecure. You have some prerequisites for this. Your zone needs to be offline signed. So if you're if you're going online signing, this this does not apply to you, you have different problems. And you have your assigned zone still available somewhere. Maybe you can talk to your secondaries who have it somewhere on disk. Also note that a assigned zone is integrity protected, and you can also maybe consider it public data. So just put it onto GitHub or store it somewhere. This is much easier than to back up than a private key that you, you know, need to keep private. Now with that, you need to pick the right method from 7503 because you cannot resign everything. So if you lose your KSK, you use the you use the double d s method, which is usually not the preferred method to do a KSK rule because you need to talk to your parents more often. But this is the one that's available here for you. So you introduce so you create a new private key. You keep it to yourself and introduce a DS record into the parents. So you have two DS records now. You wait until this propagates, and then you can swap your DNS key or set. Special considerations apply if you're if you also lost your ZSK at the same time. So and if you lose your ZSK, you need to use the double signature procedure, and your zone is immutable. And this one talks about what that means. So you can change your DNS key RSAT because the the signatures, the over the DNS key RSAT and the DNS key RSAT have the same TTL, which means that your resolver or that the resolvers will have either the old set cached with the signatures over it or the new set. So this is basically the core idea why this works. But you need to keep all the other RSNs immutable, and you need to ensure that you have the old r six still around. So you you create a new key. You you you prefer you perform the ZSK role. You create a new key, and your signer will probably remove the old r six because that's I don't have a private key for this. So you need to make sure that they're in there. Maybe just copy them in. And you need to keep the actual r sets as they are because the resolvers in the cache either have the old DNS key set or the the new one. So you need to ensure that both cards can validate this. Now this has consequences because you cannot if you use a CDS and CDNS key, you you you need to disable this, so especially if you introduce a KSK because this will break or change the NSEC type map. So you actually would need to resign that, which you can't. And you also cannot change the SOA record because this will break MX domain proofs. Because, basically, the the NSEC will use the old r six, and your SOO will use the new DNS key set, which means that you cannot change the the serial, which is slightly annoying if you're using AXFR because your secondaries will not pick up the new zone because, as well, the the the serial has not changed. Could someone please close the door? Thanks. So we've so you you need to actively poke your secondaries to please bring in the zone. And my co author, Markus, on this draft wrote another draft where you can signal to your secondaries, could you pretty please pick up the zone now? I know this hero did not change, but I promise you the zone changed. Please get it in. So the yeah. Since I last presented this, this was adopted, and, we incorporated all the feedback that, we got, during the adoption call. Mainly, I want to point out that we removed the lengthy discussion about HSMs. People pointed out, quite rightly so that, no. HSMs is not the normal way to do DNSSEC, And I fully agree, and the text was not supposed to say that. And I messed that up, so it's all gone. We also tried it out multiple times. It's a part of our disaster recovery tests, and it works. And we found a few bugs, mainly the CDS, CDNS key thing that bid us. So we introduced that. And, well, next steps, they also think this document is ready, and we would like to ask the chairs to consider working group last call. And while you're then very excited to review this, maybe you can also try this out. That's it. Thanks.

[00:19:53] **Benno Overeinder**: You.

[00:19:54] **Wes Hardiker**: Wes Hardiker. Nice hack. Can can you speak to the timing between the two different TTLs? So you have essentially an old zone and a new zone role, old ORCET and a new ORCET under the same SOA. Isn't there a timing consideration where the the signature life in the TTLs, they're, like, really closely published or you're publishing the new one really close to the end of the old one, don't you run into a tight situation? I'm envisioning this in my head, so I may be wrong.

[00:20:26] **Ulrich Wisser**: I'm not quite following. So the, the time considerations are basically the the old ones from, how you do a key rollover. That did not change. But maybe I misunderstand your question.

[00:20:39] **Wes Hardiker**: So I guess in the end, win so you also so in the document, you talk about publishing both DSs too at some point. Right? So you you have to leave the old DS in the parent and publish a new DS?

[00:20:51] **Ulrich Wisser**: Yes. Correct. Yes. Yeah. It's the double DS rollover. That that actually does not change at all. So if you only lose your KSK, it's brilliant. You you just use that other that other RFC that's already published. Not nothing changes there.

[00:21:04] **Wes Hardiker**: Right. Alright. Well, thank you, and thank you for the reference. I need to go add into my nonexistent draft that this also works in an emergency situation to go insecure. Thanks.

[00:21:17] **Philip Homburg**: Philip Humberg and LNetlabs. I meant to try this out on our new upcoming signer, and I'm pretty sure that it's not going to work on our upcoming signer. But then work gets in the way, so I never got to do that. So so my question for you is is on what signers does this work, and do you think that it, in general, works on signers, or how much modifications do you expect there need to be to make this work? Because the thing is if if we only look at this when you need it, then it's probably too late. So we we probably have to test every possible signer whether it can implement this this this drafts Yeah. As as operational community, not so much as a as a standard.

[00:22:02] **Ulrich Wisser**: So we used the the Knot DNS signer for this, but we did not think that you would need to actually change a signer. Like, we we because it's we basically explain how to creatively use the existing rollover draw the rollover RFC. So if that works with your signer, this should also work. So that's the that's the thought behind this. You you will run into a few issues where one thing I pointed out is your signer will be adamant to remove the old r r six because it says, I don't have that key. I'll remove the r r six. So what we actually do is we use that to get them back in into the into the actual text zone file. That that's a hack, and you probably can add some code to the signer that it does not do that, but you don't need to do that. But I would be very interested if you find a signer where this does not work, and I want to know why.

[00:22:55] **Philip Homburg**: Well, so my guess is that with cascade, if you do try to do any kind of k s k role, then it will include a CDS and CDNSKEY.

[00:23:04] **Ulrich Wisser**: Well, don't do that then. So for for not, you can turn it off.

[00:23:07] **Philip Homburg**: Yeah. Exactly. But there's nothing for that. That that's why I know it needs changes. So I was wondering when

[00:23:12] **Ulrich Wisser**: I see. I see.

[00:23:13] **Philip Homburg**: Things that also need changes to to have more knobs to to make sure that it doesn't do the things that it shouldn't be doing.

[00:23:19] **Ulrich Wisser**: So you you can turn this around. So the the another way you can read this draft is only ever change the DNS key set. So have you you have to fully sign zone on the site, and then you tell your signer, please resign the thing. And then you just take the DNS key r set and the r sig, and you transplant it into your old backup zone. That will also work. It's it's more manual steps That ensures that your signer does not mess around with the whole zone.

[00:23:50] **Andreii Robachevsky**: So the time is over, but it feels like that draft should have an implementation section.

[00:24:00] **Ulrich Wisser**: Okay.

[00:24:04] **Benno Overeinder**: Thank you.

[00:24:05] **Andreii Robachevsky**: Thank you. No. Johan was

[00:24:16] **Benno Overeinder**: Okay. I just I I follow the the order of.

[00:24:22] **Andreii Robachevsky**: Johan is Johan is next. When you send your slides on the last possible moment. Now

[00:24:36] **Benno Overeinder**: we are bitten by yeah. It's indeed yeah. There we are. You break the flow of meter ago.

[00:24:45] **Johan Stenstam**: So I will I had a senior moment and was asleep.

[00:24:56] **Andreii Robachevsky**: I think you need to speak really close to the mic.

[00:24:58] **Johan Stenstam**: Yeah. I know. So I'm trying to bring the mic closer to me. So this is a draft that has been kicking around for several years and it was adopted, I think, one years point ago. And this is what has happened since last time. I presented this at the last IETf and after that IETf, we have made, well, substantial changes to the draft text, but not really to the protocol described or the process described. It's more a question of clarifying how it was always intended to work so it's slightly easier to read and also adding a couple of tweaks, if I put it that way. So that it doesn't change anything materially, but they show a wider set of use cases and it's slightly clearer to use. As, of course, everyone is well aware, we do have DNS updates since more than twenty five years back. This draft doesn't change anything about how dynamic update works. We've been able to, for more than twenty five years, to update the delegation information in the parent by assigned dynamic update message from, well, let's call it a child representative. This has never been very popular and not very useful. And that is because of two reasons. The first reason being, how should the child know where to send the update? Well, we solved that problem with DELEG. So this is more or less a bootstrap on top of the DELEG RFC where we generalize DELEG from only speaking about generalized notifications, where should you send those, to also talk about dynamic updates, where should you send those. So from that point of view, the only thing that this draft introduces is a new code point in the DELEG registry for a new kind of notification or new kind of receiver. So once the child knows where to send this, it just sends a standard dynamic update. No change. And here comes the second week. How should the parent know where to find and validate and trust the key that signs the message? And that is sort of the larger part of this draft, methods and mechanisms for the parents to discover and validate the child SIG(0) key. Again, this is not a change to the dns wire protocol or it doesn't essentially nothing to do with dynamic update, but it's obviously an important part of making this useful. The child discovery process of of using the decent RR set in the parent is trivial today, standardized, done. The update itself is trivial today, worked since many, many years back. And the parent discovery of the child key is sort of where most of the work has been over the last few years. Once we have it working, well, it does have a very, very interesting property compared to, let's call it the alternative of using CDS scanners or c sync scanners. And that is that CDS and c sync scanners, they do only work with signed zones. It only works if the child is signed so that you can look up the CDS or c sync record and verify it. This works also for unsigned zones. And as all of us are aware, in spite of all of us sort of liking the dnssec thing, we also know that most of the zones are not signed. So the use case here is much, much, much wider than for CDS and c sync as a mechanism for automatic delegation synchronization. Another interesting thing these days when when post quantum is becoming more of a thing is that because we send a dynamic update signed by a SIG(0) key at a much lower frequency than you do, well, normal DNS queries and things, We really don't have a size constraint here. We signed this send the SIG(0) signed dynamic update over TCP to the parent receiver. And if that has a large signature by a post quantum safe algorithm, it really is a non issue. And that works today. And we we use this today. And it's it's sort of cool that we we actually have a test bed that has been running for, well, four or five months now. It's it's done more than 10,000 key signing key rollovers, each rollover signed by ML-DSA-44. So so for this particular use case, you're sort of already post quantum ready. Well, almost. There is one tiny bit that we need and that is of course allocation of a code point. But that's a sort of separate discussion. Another thing, going back to what was sort of the major discovery process here during the draft development. How should the parent find and validate the child key? And we support a number of different mechanisms for this. You could look it up in the child's own and if the child's own is signed, everything is good. You can look it up through various other mechanisms like RFC eighty seventy eight and and do some sort of stochastic thing where you try a number of times. And if it's the same key every time, eventually you trust it. But there is also another method which is the CDS bootstrap draft or RFC 65 oh, what number is it? Ninety six fifteen, is it? Where you publish the child CDS record under a magic name below the name server name. And the assumption is that the name server name is in a signed zone while the child is in an unsigned zone. Then you can, as a parent, look up the child, the CDS record over here at provider.com and do the DNS validation, and then you can trust the CDS. So we do exactly the same thing here, but for the SIG(0) key. So so this magic name here with the underscore signal thing, etcetera, is just us replicating the exact same mechanism as is already being used in RFC 9,615. But that, of course, prompts another question. What if providers need to go look for more and more strange things in the customer zones? Oh, here's a CDS, perhaps I should publish that over here. Or here is a SIG(0) key, perhaps I or perhaps not. Should I publish that somewhere? And and I think we can all agree that some strange person from Sweden will probably come up with a new idea. And a third thing needs to be published somewhere. So we we we really sort of orthogonal to this draft. We really would like some sort of standardized mechanism for instructions from the zone owner to the provider, what the zone owner wants the provider to do. And guess what? There's a draft for that. It's a it's an individual draft. It's not a working group document yet, but there is a draft for this. And there is a record called delegation-mgmt-via-ddns that is exactly for this use. So it's possible to publish from me being the zone owner to the provider, whoever that is, that I would very much like you to pick up the SIG(0) key that is published in my zone and publish this under this magic name. And then we close the loop on on how to validate the SIG(0) key from the point of view of the parent. So that brings me to the close, which is there is a companion document to this. And the companion document is about how to avoid having the failure of some something got out of sync. How to avoid having the failure just when you need to do a change. As in when you send the dynamic update, I have changed my name servers. That's typically not the time you want to get a response back which says bad key. And then you need to redo all your bootstrapping and etcetera, that will take time and things will be out of whack for a while. It would be much better if you could verify that everything is in sync and if I have a need to make a change, the key is already trusted by the parent and everything is just fine. And that's what key state is about. It's a mechanism for the child to inquire with the parent what is the state of this key and get a detailed response whether it's known, whether it's validated, whether it's trusted or if it's not, why and all that. So it's a small draft for a very specific purpose, but it's very, very important. And that's more or less where we are. We've with all issues we are aware of. We have an implementation that does all of this. And we are, from our point of view, unless there is more feedback, to my mind, ready for some sort of last call decision by the shares in the group.

[00:35:15] **Andreii Robachevsky**: I'm sorry, but the time is over and there's no time for the questions.

[00:35:22] **Johan Stenstam**: Okay. Thank you.

[00:35:28] **Andreii Robachevsky**: So next one is.

[00:35:45] **Ahmad Al-Alfi**: Well, this is a simple proposal, so I'm going to keep it very short and to the point. This idea started as a conversation we had with folks at Cloudflare about how we deal with end well, DNSSEC incidents where we need to implement NTAs. And unfortunately, well, bad things happen to the best of us, especially if best of us run DNSsec. So we had the incident a few months ago. We had dot AL a few weeks ago. We had dot BD a year and a half ago. And unfortunately, we have to make the difficult call to deploy an NTA. Sorry. But when this happens, we usually publish a blog post in a few days. And we thought, well, this is good, but maybe it's not good enough. So there is no inbound mechanism to inform users that an NTA is in effect. So we looked into the RFC 7,646. Authors recommended that reading from the RFC. Implementers should consider transparently disclosing NTAs that are currently in place. And this was written a few years before EDEs existed. I think this is 2015. EDEs are 2020 and we thought maybe we should put EDEs to some good use. So we registered EDE 33 and put together a draft and Cloudflare like immediately implemented it in their resolver. Well, this is a canary domain that we registered for this purpose. And as you can see, like this is intentionally broken. If you run a query against a validating resolver, well, it shows it as as broken obviously. And this is a case where EDE33 is not implemented. With Cloudflare, you can see as because this is already in production, you will get an EE33 as indicating that an an NTA is implemented. So together with the coauthors, we spent a few days to sort of poked around with the code and try to implement it in different resolvers and different open source software out there and open the pull requests. This is a current stat and we already have this partially in not resolver. Knot DNS currently supports it. We have pull requests in unbound and power dense recursor currently being reviewed. And somebody advised me maybe you should not touch the code and ask smarter people to do it. So I opened the feature request for ISC and it's already implemented I think within sixteen minutes after the initial request. So thanks for the work.

[00:39:07] **Andreii Robachevsky**: I felt left out.

[00:39:14] **Ahmad Al-Alfi**: So when we shared this draft initially on the mailing list, we received a lot of positive feedback, lot of good feedback that we integrated into the recent updates. So we submitted revision one yesterday morning. Currently, the revision o one has some additions to the original text which supports structured data in the EDE text because everyone likes JSON DNS. And this JSON is optional. Well, this EDE text is optional. So if you want to go to the the structured data path, you might want to add a date that is like a indication of when your EDE will be removed. We know when EDE is implemented, it's usually in response to an unplanned event. So there is normally no way to know when you're going to remove the NTA, but this is like an indication. Maybe you're you're going to revisit your decision within the next six hours, and then you renew the timer. And, also, we added support for sig for SIG(0) and T SIG in case clients want to basically ensure that this is an authentic answer. This is in addition to DNS over TLS and DNS over HTTPS. And, yeah, some some basic, well, clean up to the original text if you have seen the original one. And what are the next steps? We would like to encourage the working group to adopt this document. We've already received a lot of like, good feedback which helped us to improve the current draft. And we think that adopting this in the working group would be super helpful, especially because this sort of updates RFC seventy six forty six. That was also a workgroup document and adopting this document would also help to basically prep the adoption of this as a standard. Yeah. Well, I guess that's it. And with that, I return a few minutes to the working group.

[00:41:36] **Benno Overeinder**: Yeah. Well, there are people in the queue. Okay. Peter.

[00:41:43] **Peter van Dijk**: Hi. Peter van Dijk, Powerdns. Thanks for the PR. We are very much intending to merge it. We support the adoption of the document.

[00:41:50] **Ahmad Al-Alfi**: Yeah. Thank you very much.

[00:41:53] **Ralf Weber**: Ralf Weber, one of the authors of seven six four six. Really like that good work. I mean, we didn't have that when we wrote the RFC. And one of the things, I mean, having an NTA or having a signal when that there is an NTA deployed in general isn't a, how to say, signal that people don't like DNSSEC, which I think was brought up in the mailing list. So this is work to actually make it more operational, and I really like it. Thanks. Thank you.

[00:42:20] **Jim Reid**: Jim Reed. I'm speaking for myself as always. I just wonder, is there really a point to this? Does the average DNS user know or care about negative trust anchors would even notice if they got one? So whether it's useful to put this thing in the code, I'm not sure this has much value. And I'm always reminded about the discussion we used to have years ago about the DNS camel. Is this yet another straw on the DNS camel's back?

[00:42:53] **Ahmad Al-Alfi**: Yep. Thank you very much for the feedback. This is something that we are aware of and we know pretty much all the people that, like, look at EDEs, look at the responses are in this room now and there is no like, users do not care, but we are also working with Resolver with with with with browser vendors, and they're working on, like, different ways of of displaying to the users.

[00:43:16] **Jim Reid**: Okay. Thanks. And having said that, it's the whole bunch of the providers running up to the mic, so clearly I have upset them.

[00:43:24] **Warren Kumari**: So Warren Kumar, Google. Yeah. I mean, I agree users aren't gonna care at all, but users are never gonna see this. The people are gonna see this as people go like, wow, that's really weird that Cloudflare is still resolving .de. How the hell did negative trust anchor. Yeah,

[00:43:42] **Ralf Weber**: to repeat what Warren said, mean, is for operators or people that kind of, like, care about DNS that that operate resolvers or whatever. I mean, these people need some debugging tools, and EDE really was good. And I think continue on extending EDE to kind of cover more use cases to give more information to actually if people have the information, what's wrong? They have the ability to fix it. If the information is not there, you're in the dark.

[00:44:07] **Johan Stenstam**: Thank you. Other questions? Victor?

[00:44:13] **Victor Dukhovni**: Yeah. Same as Warren, and I just implemented it in my stub resolver.

[00:44:21] **Benno Overeinder**: Joe. Joe, you're you have a request? No? Okay.

[00:44:28] **Johan Stenstam**: That's it. Thank you. Thank you. Thank you.

[00:44:38] **Andreii Robachevsky**: Next up is Joe.

[00:44:55] **Joe Abley**: Okay. I'll speak slowly so that when the door opens every ten seconds, you can still hear me. Alright. So this is familiar, I think. I won't I won't bore you with the details. In summary, we had this idea that maybe sometimes it's useful to signal that a zone cut exists, but for various reasons you can't follow it. And the reason this is important is because it allows a system not to break the namespace, whilst at the same time not allowing a client to be able to access part of it. So, easy examples are internal namespaces, which are not part of a global namespace. Maybe it's a corporate namespace. And we found this mechanism is a kind of elegant looking way of doing it. And it also has some benefits, which is, for example, you could put DS records next to it and say that if you are able to follow the delegation, here is, it's a secure delegation. So when you move between namespaces, perhaps DNSSEC is not confused and you need fewer hacks on your resolver. So it seems in general, in summary, there are some good reasons to have this. But then, perhaps, oh no, perhaps it's frightening. Perhaps it's frightening because the root servers because it's got a dot. Perhaps the root servers will get a lot of extra traffic, and this will break the root servers. But also, I think, you know, more interestingly, to me at least, maybe we have a DNS resolution graph that involves forwarders and resolvers. Maybe we have things retrying based on serve fail because we don't have many things we can return. This would generate a serve fail because you can't actually follow the referral. And so maybe this would cause loops and extra traffic that is hard to see between, for example, forwarders and resolvers. And there were several people who said, we like the idea, but actually we thought about this and now we don't like it anymore. Now it's frightening. So, Wes, who's sitting in the front row and is willing to answer, I've decided all the questions that are difficult that I don't want to answer, Did some experiments. And these things have been written up. You can find a link on the slides, which works, to a PDF that contains some version of the results. And it was also presented at the IEPG in the last IETF meeting, and there are recordings online for that. And these are also now both referenced from the draft. And to summarize, Wes didn't find any signs that these concerns were serious or existed at all based on the observations he made from b route and what he expected the implications of these forwarding type problems to be on end users. And he ran experiments observing what the behavior of end users was. And I think the result was the DNS is about as broken as it normally is. Let's not pretend that the DNS always works. The DNS is filled with horrible things. We have this know, if we measure measure a variable which measures the amount of horrible in the DNS, it's basically the same with and without this hack in place. So it's a persistence of horrible. It's like a consistent, comforting level of horrible in the DNS. But we still have those earlier benefits. So if we had an idea to start with, was this has some benefits, and then we have some concerns, but then it turns out perhaps those concerns are not serious, we don't have to worry about them, are we back at the beginning and do we now have an idea that actually has some benefits? And can we just talk about the benefits? So that's kind of where we are. So the goal here is to ask the room, I guess, does the working group think that those benefits are worth considering that there's no camel's back is in jeopardy here. There's no new protocol changes or anything else. This is just a convention. If we think there are some benefits in this, and writing it down and saying it's allowed, just as we've done with other protocols like SMTP, with MX records, and things like that, should we perhaps ask ourselves that question? And is it worth moving this forward? It would be a pretty easy lift if we can get over the distaste of the horrible part. I think that's all I got to say. Yeah, that's it.

[00:49:14] **Wes Hardiker**: Wes Hertaker, mad scientist. So if if I was gonna summarize my results, I would say that when when nothing exists, you get some errors, and it's weird. If you put this in place, it is no worse than all the rest of the errors we see on the net with zero implementations. This is supposed to be a signal in the future so that as implementations get deployed, the amount of bad is actually going to go down. Right? So that's actually one of the benefits, is it turns out to be a signal. And the other thing to note is if you read my paper, it's long and very gruesome. You'd expect lots of advanced math, well, moderate math. The TTLs become a big deal. And so there's a TTL for different types of errors, and different types of errors produce different types of things. Mark's concern was around serve fail. I have just now finished that, but I haven't written it up. His concerns are valid. If you have a forwarding resolver, you end up in sort of a serve fail kind of ping pong game. And I think there's also a draft being eventually proposed to the NSOP to, you know, maybe return TTLs on on serve fails as well that would actually also, if that implementation got deployed, make things better as well. So Mark's concerns are valid, but but existing implementations do catch that as well.

[00:50:41] **Paul Hoffman**: Paul Hoffman, very briefly. It turns out that bind at acting as an authoritative name server requires an NS record in every damn zone even if it shouldn't need one. Throwing in an NSDOT fixed it for me in about thirty seconds. So thank you.

[00:51:01] **Joe Abley**: Actually, I suppose that's something else to mention. There's abs there's nothing at all stopping anybody from doing this Because it requires no changes in anything. In fact, anybody could be doing it. Everybody in this room could be doing it. All we're trying to do is make that signal conventional in the sense that you understand unambiguously what it means when you see it.

[00:51:20] **Tobias Fiebig**: Tobias- I'm just wondering, like I would personally, if I'm not allowed to see it, expect a refused. So would a refused not have a similar effect? So if I have a split view DNS and for dns records return refused? Can you

[00:51:36] **Joe Abley**: say that more loudly? Why refused? Yeah,

[00:51:44] **Wes Hardiker**: I can answer that. Because refused isn't a signal. It isn't something that implementations could depend on because refused doesn't give the querier a signal saying why it's refused. With an NSF dot, the name server or the resolver knows, go away, you know, I can't come back, and I know why I can't come back.

[00:52:07] **Benno Overeinder**: Hi.

[00:52:13] **Peter Thomassen**: Peter Thomassen, SSE. So no implementation, fine, as long as the root's name doesn't have an address, which it doesn't, right? And I think that would have to be explicitly written, or we would have to say that one actually must not follow such a delegation, and then there is the tail that would still do that if there was an address. So, yeah.

[00:52:43] **Benno Overeinder**: Yeah. I'm not saying it's a practical Can you repeat? Oh, Peter, can you repeat it?

[00:52:46] **Joe Abley**: So John just oh, Peter, you can repeat it if you want.

[00:52:49] **Peter Thomassen**: Yeah. So John just said that there is already use of the empty label essentially for, for example, no mail, MX records and stuff like that. And that hasn't been a problem there. I'm just saying that we need to write it down. And there's two ways. One way is to actually prohibit an address for the route. I don't know what the process for that would be. And the other would be to actually change the resolution logic to not allow following delegations to the route. So

[00:53:21] **Joe Abley**: I think the question of what goes in the root zone is often an annoying set of questions that involve an annoying set of organizations. I'm sure we could find a way of answering that question, but we could also probably just imagine that if anybody decided at any time in the future that putting in a record at the apex of the root zone was a good idea, there would be no shortage of people to explain why they were wrong.

[00:53:46] **Peter van Dijk**: Hi. Peter van Dijk, PowerDns. Peter already mentioned this on the mailing list some time ago. This the this is not an impediment for the document whatsoever, but there should be some guidance in there for people who use the Acme DNS challenge. Because if you do this, then suddenly you break all certificate requests for internal hosts that you can publish an Acme record for in the public zone. But then suddenly there's no delegation or there's a broken delegation that the resolver at the at, for instance, less encrypt cannot follow anymore be because you have a zone cut that's just impossible to to to

[00:54:28] **Joe Abley**: go through. So I we probably have to talk more about the details of the particular challenges that you mean. I think in the case where you want internal names which are definitively not resolvable in ACME challenges or otherwise in the world, then those challenges should fail. So I don't think this actually changes that behavior.

[00:54:51] **Peter van Dijk**: And then now the the idea is usually you have some internal host, but you want TLS certificates for them. So you publish the ACME data in your public DNS, but the name itself is not resolvable outside. So there's no a record, whatever. It it only runs internal on the network, but you still want proper certificates for them. And and this breaks it. It's not an impediment for the document itself, but it does require some extra words.

[00:55:15] **Joe Abley**: No. Fair enough. I mean, I've I've known enough about Acme to know that a lot of people use it in a lot of weird ways, so I'm not gonna say that's not gonna happen. But, yeah, it's worth thinking about for sure.

[00:55:22] **Johan Stenstam**: Alright.

[00:55:23] **Joe Abley**: Yeah. Yeah. So we're to adopt then?

[00:55:31] **Benno Overeinder**: Any last call? Yeah. No. Yeah. I think I made a note, but well, no. I well, of course, we take it to the mailing list. Okay. But, no, we got good feedback from the room, good questions, and good support. So we go to the mailing list for call for adoption, but we have to schedule a bit of other work. Oh, yeah. Okay. Thank you.

[00:55:55] **Joe Abley**: Alright. Thanks.

[00:56:00] **Andreii Robachevsky**: Philip.

[00:56:12] **Philip Homburg**: Okay. Well, it's nicely introduced by Joe. Maybe sometimes you want to return an error and you want to say something on how long you expect this error to last. Yep. And that that can happen with a number of errors. For for annex domain, this is solved because since the beginning of time, you get to show our records, you know how long this annex domain is supposed to be cached. But if you get serve fail or refused or any other error, then we have RFC that describes what you should do then. But it says, well, basically, pick some sort of value and not larger than five minutes. So so this draft proposes to to basically add the same thing that we do with annex domain and and do that for the other errors. So so here's a handcrafted example. So I probably made a mistake somewhere, but it looks reasonable. And it says, well, the the the error is serve fail. You have a normal question section. And then the only thing that is extra is in additional is a SOA records. It has a a weird label. And I said, well, we need to have a weird label to make sure that if some clients is really stupid and caches everything, then at least it doesn't do any harm. Okay. So and then I sent this announced the draft, on the mailing list, and I got a bit of feedback. One bit of feedback is, is this secure? Because this would be a very nice potential for for denial of service. You just somehow spoof a high value and then clients will just not do anything with that name for a while. And but there there's lots and lots of different cases you can consider. For example, you might have an authenticated connection over TLS between the step resolver and resolver. In that case, you do not expect a DOS because, well, the resolver can always DOS you if the resolver likes to do that. So so but going down to UDP to port 53, If you have an unsigned zone, then then basically the DOS effect for this means that the effect on sort of your unsigned zone would be way worse. For signed zone, it gets very complex because then it depends a bit on how you handle DNSSEC failures. I mean, DNSSEC itself is is very TOS prone. You only have to flip a certain single bit and bad things happen. But but validators that are also the cursors can retry with in any case, for this reason, the draft doesn't say anything on how the clients should behave. It just says, well, here's a signal client. Please look at this, decide on what you want to do, do something reasonable. And and we have that in in a lot of other places already where you get a reply. Then I made it as look like a next domain as much as possible, but with the tweaks to to to avoid confusion and putting it in additional section. And then what I said, like, well, that that's a a bad idea. You should get a dedicated type for that. And that has at all, this is a clear encoding. This advantage is it's it's a pseudo type. I don't really like pseudo type, so you have to define what happens if you see it in a query or in a reply or other stuff. Just before the session, somebody also said, well, maybe you could just put it in an e dns option. Would also work also has disadvantages because there could potentially be many e dns options. So you have to scan that, but maybe that's cheap because you don't expect many errors. So this is as far as I could tell, the main design thing, like like, which option do we pick? I think all of them are valid. It's just a bit of who shouts the loud stuff goes a bit problem. Then I got a bit of feedback, like, do you need to say something about what you could put in the TTL value? And for example, if you do NS dots and the resolver sees like, okay, we're really not going to resolve this domain. So I want to return a SURF fail, then you could easily just copy the TTL of your NSDOT record. So that's would be obvious value. If you do some sort of DNSSEC validation,

[01:01:13] **John Levine**: then

[01:01:13] **Philip Homburg**: you can look at sort of which resource records in the DNSSEC chain matched to this failure and say, well, for for at least this long, it's not going to improve probably. Or you could do the lowest TTL among everything in the chain if you're you're really saying, well, something might improve. But for other server fails, I have no clue. I don't know. Maybe we should say something. Maybe I don't know if there's anything sensible to say, but we could try. And that's it. Oh, yeah. There's there's one thing that I forgot to mention, and that is that on the mailing list, somebody's really said, okay. But, clients can be dozed, and we really have to limit the the value to five minutes. The plus one voice, I want to mention it here. And for me, that feels wrong because we already have this five limit, five minute limit in the existing RFC. But yeah. Don't know what to say about it. So so I think that there is quite a bit of enthusiasm for this. So I would ask chairs to adopt this. But I think there's also the room for feedback. I would still have quite a few minutes. So anybody has questions or remarks?

[01:02:37] **Andreii Robachevsky**: Andrei, with my bind hat this time. I like the idea, so not necessarily the details that needs to be hashed out, but the idea is solid from the implementer's point of view.

[01:02:58] **Benno Overeinder**: Ben? Yeah. Ben.

[01:03:01] **Ben Schwartz**: Hi. I support adoption once we have settled on some general technical direction. I'm not sure that we're quite there yet. In particular, I wanna voice my support for an EDNS option as being the most natural way to encode this information. I think it once we've settled on the which channel it is that we wanna encode this, whether it's EDNS or a new RR type or whatever, then, then maybe we're ready to adopt. Also about the the TTL limits, I would support guidance that says that clients should limit the TTL when not using an authenticated transport. If you're if you're authenticating your connection to the server, then you can trust whatever it's telling you.

[01:03:52] **Philip Homburg**: So question. So for for unsigned zones, if you're using an authenticated transport, then the damage that can be done if if you can spoof these error TTLs is is sort of the least of the damage you can do. Because for unsigned sounds, as soon as we assume that you can inject false replies, then you can inject a lot of other stuff. So so why would you rule out, for example, using this for unsigned sounds if it's an unauthenticated channel?

[01:04:28] **Ben Schwartz**: So I I'm not I I can't say I've thought about this in great detail. I think that, obviously, the thing people are worried about is that an attacker who has a brief window or a limited ability to execute the attack could essentially amplify their attack and turn it into a longer lasting attack. And so if we're convinced that there are essentially equally good attack amplification capabilities already in the protocol, then I think it's

[01:04:58] **Benno Overeinder**: Okay. I've sorry. As a chair, have one question to you, Ben. You said, first, which channel, which alternative, and then call for adoption. Is that not something for the working group to decide as as it is a working group document? This

[01:05:13] **Ulrich Wisser**: may be

[01:05:13] **Benno Overeinder**: a little bit too procedural, but just very brief your opinion why you have this kind of So

[01:05:20] **Ben Schwartz**: maybe maybe I wasn't clear. In general, I think that we adopt documents at the point that the working group has consensus on the general shape of the solution, and that if it's not enough to have a problem you want to solve, you need to have some agreement that we we have a way to solve it that that the working group is generally happy with. Okay. Essentially, the document forms a good starting point for solving the problem. I think in this case, that means deciding is this, you know, is this a TXT record? Is this a seller record? Is this an opt? I think that's that's table stakes.

[01:05:55] **Benno Overeinder**: Okay. Thanks for your perspective. Thanks.

[01:05:59] **Warren Kumari**: Warren, we're running running long time, so I'll go fast. I didn't really like the SOA thing, but I think the idea itself is so awesome that we should adopt it like real soon and then the working group can think over how we actually transport it. Right? Like there's many ways to transporting stuff, the actual concept is the important part.

[01:06:16] **Andreii Robachevsky**: Yep. I I agree with that.

[01:06:20] **Ralf Weber**: Raffi- welcome. So, I mean, the thing I think also we should should work on on this. The the question or the the thought that I had is the draft test from client to server. Now when you think an authoritative server on an on on the connected connection gets a pretty much, well, ignore this for an hour, and the the request was dubbed up google.com, and then the server takes its first phase value. I mean, we have to really work on the security and the kind of like possible implications that this could be abused. And then I I second a bit what I think Ben was going on to really maybe limited to secure transports.

[01:07:05] **Andreii Robachevsky**: Victor?

[01:07:06] **Victor Dukhovni**: My question is really about what is the scope of such a TTL? Are we supposed to not make the query against the specific server that provided the response or to any of the authoritative name servers or other name servers for the domain? Because perhaps, you know, if one server is not feeling well, it can say, well, don't ask me again, But maybe the others are perfectly fine, and how does it even know whether they are fine or not? So I'm concerned about the scope of the TTL in such a case when it's a failure.

[01:07:40] **Philip Homburg**: I think normal sort of resolve for logic is is to try different servers if if you get an error. So so that's I don't think this would would change anything. It it's it's just, like, currently, you compute basically statically how long you consider this error to be valid, and and then resolvers already have logic to deal with errors. And the only change that makes is, like, how long you consider this error to be valid can be explicitly suggested by the server instead of that the the client has to guess. But but, definitely, we we can make this kind of text way more explicit if there's concerns.

[01:08:25] **Benno Overeinder**: Okay. Thank you.

[01:08:29] **Andreii Robachevsky**: Okay. Now we begin the DNS dispatch function of this session. Again, the reminder is the goal is to get guidance where this should land and we should not discuss the contents of the drafts. For the people presenting, If you want to get any guidance, you need to leave time for it. There's ten minutes for each person. If you consume the full ten minutes, then it's done and you will not get any. So try to plan it like five plus plus five or something like this. Okay. You sure?

[01:09:18] **Benno Overeinder**: Oh. Yeah?

[01:09:21] **Paul Hoffman**: The first two only have five minutes each, not ten. It's it's this I I understand. But I'm saying just so he doesn't think he has 20. He only has 10 total.

[01:09:30] **Andreii Robachevsky**: True.

[01:09:30] **Benno Overeinder**: True. True. That's

[01:09:33] **Kishore**: Okay. Anybody from Spain here? Nobody? I guess they're all hungover.

[01:09:44] **Andreii Robachevsky**: Anybody

[01:09:47] **Kishore**: from Argentina? I guess they're too sad. Alright. I'm gonna present two topics, and I'll be brief. So the first one, this is about associating public keys with identifiers. And it turns out that email IDs are the single most common identifiers used across the Internet. And the 18% which says others, most of them are temporary tokens. About 8% are temporary tokens that are generated by credit cards. So if you take that out, permanent IDs are about 70% email IDs. So what I'm talking about, this has nothing to do with email encryption. This is about turning email IDs as identifiers and making them cryptographic. So if we can the what I'm proposing is a very decentralized approach or a distributed approach of associating each domain with a domain key authority, which manages the keys of email IDs belonging to that domain. So each domain authority is designated by that domain via the DNS. And then each domain authority is responsible for both collecting as well as distributing public keys for email identifiers associated with that domain. So for example, alice@example.com can have multiple keys associated with different selectors. And when she chooses to register a public key, the DKA verifies that she is in fact Alice through domain, through mailbox control, as well as DKIM signatures, okay, and then stores it. And then the lookup protocol or the the distribution protocol, there's simply an API. By the way, the DKA is a HTTP endpoint. Therefore, it it can deliver the keys with TLS protection. This thing. The there is a an open source implementation and a full demo of the domain authority framework at this point. And it also has, as an IPR disclosure, a recently issued US patent, which will be made available, royalty free. So this is where I am. And the general contribution of this is that it's a distributed framework. Nobody controls it, and it it provides verified association between email identifiers and public keys that can be used for authenticating a person, for encrypting any messages through any protocol, not just email, to a person or to an email identifier as well as for digital signatures. So and then unlike OpenPGP, this is purely deterministic discovery. So if it does not exist in the framework, then a key does not exist as opposed to as opposed to open open PGP repositories. So that's where I am. And Okay. What do we do?

[01:14:49] **Benno Overeinder**: We'll open the floor for the people. Any directions where this work should

[01:14:56] **Daniel Kahn Gillmor**: Hello there. This is Daniel Khan Gilmore. I'm cochair of the OpenPGP working group. The HKP draft, there's an update to HKP, which is the OpenPGP HTTPS key key server protocol is currently, an active draft. It's a working group draft in the OpenPGP working group, and it does very similar things to what this is doing. It uses SRV records to point an author so that the domain can point to an authoritative h k p server for email identifiers associated with that domain. So it smells very similar to this, and you might be interested in joining the OpenPG working group to discuss it. I the document is yeah, it's under it's under active discussion, and there are multiple implementations there as well. I wanna point out also that the DNS natively has what you're describing already with open PGP key and s mine records, which permit distribution of these email address, identifier. So I'm anyway, there's multiple ways to to skin this cat, but I think they're already in place. So I would recommend, joining one of those existing efforts or, trying to differentiate this from those.

[01:16:18] **Andreii Robachevsky**: Okay. Just be there there should have been another presentation in the same time slot, so be very brief.

[01:16:26] **Tobias Fiebig**: Well, luckily, beta for like poweriness, Daniel said 90% of what I had. But what I see in the draft is what Daniel described, slightly more generic, plus a promise of what lookup not found means. And I also think you should probably see if you can link your work to the work there. Thank

[01:16:44] **Benno Overeinder**: you. Thank you.

[01:16:49] **Paul Hoffman**: Paul Hoffman, very briefly, wherever it goes, I think it should be a security working group, not a DNS working group.

[01:16:56] **Benno Overeinder**: Okay.

[01:16:58] **Ralf Weber**: Yeah. If it was similar, I think we were we weren't supposed to talk about the contents of the draft, but this is something uses DNS as design. I mean, it's not the DNS thing. Can go anywhere.

[01:17:10] **Kishore**: Can I make can I make one point?

[01:17:14] **Benno Overeinder**: Yeah. In comments too. Yeah.

[01:17:16] **John Levine**: Yeah. Hi, John. Mean, I I have looked at I have I have looked at I have looked at your draft, and I have looked at the claims in your patent. And as as I read it, the the claim the point of the patent is that there's a DNS record pointing at the server where you where you make where you discover the the security information. And I don't think don't think that's an I don't think that's an original idea. I think that what what Dan what Dan referred to Mhmm. Is is very similar. In fact, half an hour ago, Google was discussing this thing called EVP, which is a way of producing cryptographic keys that that validate the email address, which also uses a similar pointer. So I think the the the problematic patent makes me want to just not go anywhere near this because I think we're just I don't understand what's new and what's protected, and I don't I don't see how we could reasonably have give the IATf change control over it.

[01:18:08] **Benno Overeinder**: Okay. Some final remarks. Yeah.

[01:18:12] **Kishore**: Yeah? I wanna make one point. The reason why I'm coming to DNS op I'll talk to you about the patent part later. Why I'm coming to DNS op is that it has a unique kind of delegation in that it's an arm's length a domain, and the domain and the user keys have have a relationship that is somewhat adversarial Mhmm. In that you you want domain designation, but you do not want the domain to control the user keys. So this this delegation is an arm's length delegation, and that is pretty unique. And the only similar one that I see is the MX delegation. So from that standpoint, I think this is integrally connected to DNS and not to security because this is completely crypto cryptographic agnostic. With that, I'll move on.

[01:19:23] **Andreii Robachevsky**: Okay. I'm afraid there's no time for the second presentation. So I will the summary of this is that the people from this working group suggest security area or open PGP working group, which is in the security area.

[01:19:45] **Johan Stenstam**: So Thank you. Okay. Yep.

[01:19:51] **Andreii Robachevsky**: There's no time for your second presentation.

[01:19:53] **Daniel Kahn Gillmor**: You used

[01:19:54] **Andreii Robachevsky**: you used your all your time.

[01:19:55] **Benno Overeinder**: Oh.

[01:19:56] **Andreii Robachevsky**: You had only ten minutes.

[01:19:57] **Kishore**: Okay. Yep.

[01:20:00] **Benno Overeinder**: Thank you. Thank you.

[01:20:07] **Ralf Weber**: Okay. This one. Okay.

[01:20:13] **Andreii Robachevsky**: Next one is. This is remote.

[01:20:18] **Benno Overeinder**: Yep. Okay.

[01:20:19] **Andreii Robachevsky**: Okay. Well,

[01:20:23] **Presenter**: I'm, and I'm glad to introduce our draft. Yep.

[01:20:28] **Benno Overeinder**: Yeah. So you can control the slides yourself if you like.

[01:20:33] **Presenter**: Oh, okay. Dns extensions to energy efficiency as a service.

[01:20:51] **Andreii Robachevsky**: We don't hear anything.

[01:20:57] **Benno Overeinder**: Should I control the slide?

[01:21:00] **Johan Stenstam**: Control.

[01:21:03] **Presenter**: There's some there's something wrong with the control.

[01:21:08] **John Levine**: Which Which

[01:21:11] **Benno Overeinder**: think do all the the clicking. Which slide do you want to see? Slide two?

[01:21:17] **Presenter**: Slide two, yes.

[01:21:19] **Benno Overeinder**: Okay. You say next, and I go to the next slide. Yes.

[01:21:22] **Presenter**: Okay. Okay. Next. To set the stage, let's look at the current landscape. Net energy savings and the green communication are crucial due to the effects of climate change and the global energy shortage. According to the International Energy Agency, between 2024 and 2030, data centers could account for half of electricity demand growth in some countries due to data center expansion, dark blue, including the scenario in which expansion happens faster, light blue, as well as from other sectors, gray. If data center electricity use rose in line with the IEA's fast growth scenario, the facility would be responsible for around 12% of global demand growth overall increased to 1,193 terawatt hour by 2035. Another factor, much of the commentary on AI revolutions threat threatening climate goals comes from advanced economies in the global, whereas IEA estimates that on average, a quarter of electricity demand growth by 2030 will be driven by data centers. Next. Someone that the rapid expansion of data centers could slow down or even reverse the global shift towards the net zero. At the finger shoes, a newly earlier global electricity generation tell expected to supply data centers globally over 2024 to 2035 broken down by generation type in the IEA center scenario, low carbon electricity source will increase fast. Enterprise with large data centers such as cloud providers are increasing efforts to tackle climate change. However, it's impossible to become greener overnight, especially for enterprise with a global presence. Consumer sentiment has drastically changed over the years with many paying attention to a company's sustainability efforts. Maxi and the Nielsen joint study reviews that 78% of US consumers value a sustainable lifestyle. Therefore, products and the service that are sustainable are likely to attack growth. So users who are more aware and the send sensitive toward the environment may prefer reducing their carbon footprint by choosing more renewable energy source than nonrenewable source for network service even if it means compromised service performance. Overall, reduction in energy usage and prioritizing usage of renewable energy sources over nonrenewable energy sources need a coordinated solution at both user and application levels from the perspective of end to end. DIS can play a important role in the whole process as a scheduling bridge. SaaS energy aware domain name resolution with the user's consent and awareness is the requirement for energy savings and the green energy usage. Next.

[01:25:25] **Benno Overeinder**: So you still have about two minutes to finish your slides because we also want to leave time for discussion. So please take that into account. Yes. Two minutes still.

[01:25:38] **Presenter**: Oh, okay. Based on this idea, we present a proposal of energy efficiency as a service in the dns. We divide energy efficiency record type, and that can be applied directly and efficiently to a wider range of service. Next. This is the e e EERR format. And the next, we also divide the client and the server behavior. Yeah. The next

[01:26:16] **John Levine**: I think

[01:26:17] **Ulrich Wisser**: we have

[01:26:17] **Joe Abley**: quite good on times. Yeah.

[01:26:20] **Benno Overeinder**: Yeah. Yeah.

[01:26:22] **Presenter**: We are are appreciate have received some comments and the feedback. I discussed some points. We've considered the SVCB parameter dividing IFC ninety four sixty, but still prefer to use a independent RR for the following reasons. SVCB includes the parameters such as the protocol information, which are IT software related negotiation item essential for connector setup. In contrast, we regard the energy information as a infrastructure information and may be sensitive for users to choose a green end point. And with the development of AI and the computing power, energy demand has grown significantly, and the energy types and the deployments have become more diverse. For example, satellites are equipped with photovoltaic panels and also wholesome MEC systems. These scenarios require coordinated evolution and consideration of networks and the data center infrastructure. And and as a service involved, we believe more operators and cloud providers will participate in buildings, energy, Internet, in which

[01:27:48] **Andreii Robachevsky**: I'm sorry.

[01:27:49] **Presenter**: But

[01:27:49] **Andreii Robachevsky**: but the time for presentation is over. If you need any guidance from the room, we need to stop now to gather the feedback from the room.

[01:27:59] **Presenter**: Oh, okay.

[01:28:01] **Tobias Fiebig**: Tobias? Tobias, you for bringing this forward. It's, of course, in general, very interesting to work on matters of making a greener Internet. I am not sure whether the proposed technical solution goes to the core of the solutions we can actually implement on the technical side. So I would personally suggest to rather dispatch this to sustain, which is now forming in the IRTF, which is a research group that will also look at the nontechnical aspects of technical solutions for making a greener Internet and might help develop this further first before bringing it back to the ITF.

[01:28:41] **Benno Overeinder**: Thank you. Paul? I

[01:28:44] **Paul Hoffman**: I thought I was gonna be the only person who knew what sustain was. I fully agree with with Tobias. It seems very logical there as a research to start with. Sustain will probably work on it a bit and pass it either to green or back to us once, like, they have they have said this has been researched and such. I think it could end up here, but it should not start here.

[01:29:08] **Jim Reid**: Jim? Jim Reed speaking for myself. I think just what Paul and Tobias have just said was summed up. If there's a need for anything for DNS site here, it looks as if it's just going to be a new resource record type. And if that's the case, it can be done using the likely process for assigning new type. I don't think there's anything here for the DNS- group to consider. Okay.

[01:29:31] **Andreii Robachevsky**: Thank you. So the summary is the recommendation to bring this to sustain. That's forming in IRTF, a research working group. It and feedback from Jim was that this doesn't have to be because in DNS or because it doesn't require any changes to DNS, you don't need DNS op to register new RR types.

[01:30:01] **Benno Overeinder**: So thank you, and we will follow-up with you for the next steps. Thank you. Hi. Hello. Hello. You want to control the slides yourself, or I can do that for you if you say next?

[01:30:33] **Yang Yang**: Well, maybe you can control it. I'll just turn next for transitions.

[01:30:38] **Benno Overeinder**: Yep. Excellent.

[01:30:39] **Yang Yang**: Cool. So hello, everyone. I'm Yang Yang. Today, on behalf of author, presenting I'm a DNS protocol extension proposal to DNS OP. So the UTXO domain name system, namely draft- draft-guorong-utxo-dns zero one. The core contribution of this proposal is to fill a gap that has remained unaddressed over fifty years since DNS was created, the unified naming of payment endpoints, but not to solely introduce blockchain technology. Next. So for fifty years, DNS resolves where. But for digital payments, we need not just where, we need who, what rules, and where to send value. DNS has thus a blind point. Our proposal is to upgrade to multidimensional map mapping. Next.

[01:31:32] **Benno Overeinder**: Sorry.

[01:31:34] **Yang Yang**: Yeah. Sorry. Okay. Sure. So in our new RR type, it is a general container with optional VRF proof, I p v six finger point, and virtual lane DID extension. Full bit layout is in the draft. So I will skip the details here. Next slide. So, critically speaking, it is pluggable, and the identity compliance and payments layers are independent, and the DNS community can evolve each without waiting for us to modify the IR. Okay. Next slide. And then we are also connote to W3C / W2HC CG. We define a wire format They define application usage at two independent layers, and we are building out ex entirely on existing IETF standards. So we are not reinventing the whole wheel, let's say. You can say that for each of the usage of the UTXO domains, we are building on existing IETF standards with the code here on this slide. So I will not repeat on the details. Next slide. Okay. So the IETf- workgroup focused a lot on the proven proven code, and so we are here to have a a validation on the tool. And the first thing is we are introducing a tour developed by Eric Vyncke, which is my IP color. The key takeaway of this mini tour is that the I p v six I address can already carry color data, so it can also carry UTXO ownership proofs. It's the same technical premise, but in a more more critical application scenario. So this is the basic the contribution of your domain by providing a general application for the program mobility of I p v six interface identifier. Next slide. And case a mini case for the end to end validation, we already have a running code. So, basically, the Go Green charging station micro payment user case has already proven that the end

[01:34:03] **Kishore**: to

[01:34:03] **Yang Yang**: end process from domain resolution to on chain on chain payment is feasible. And secondly, the TEE reverse verification proves that high frequency micro payment scenarios can be easily achieved. And, largely, the and lastly, the three tier global distributed resolution network makes sure that the architecture can be rolled out in large scale. So this contribution to DNS means the provided multidimensional operational code is already existing, so it's not only feasible on paper, but also deployable in actual systems in large scales. Next slide. Okay. So this is just a mini case compare comparison which we achieved. Basically, the impact we have is we have a settlement speed compared to conventional transaction interbank, which is usually one to three business days, we can improve it to three point eight seconds. And the liquidity, we can unlock for prefunded capital requirements for intermediaries reduced to 35%. And, also, we are reducing the counterparty risk by removing the overnight exposure to near zero via the very fast settlement speed. And lastly, for the endpoint certainty, we are upgrading from knowing only the beneficiary bank to precise identification of the beneficiary entity with compliance layer with on chain addresses. Next slide. And lastly, something we are currently requesting from DNSOP is the three things. So we are moving towards as adopted in a working draft. And secondly, we would need an IANA registration. And thirdly, it's we need some internal discussion in terms of UTXO resolution, etcetera. And a summary of the major contributions of this UTXO proposition is, firstly, we are transitioning from the existing single dimensional mapping to multidimensional mapping by including identity compliance layer and also the beneficiary entity legal registration. And secondly, we are introducing a new R type, the details of which you can find with the QR code we are showing the last slide. And, thirdly, we have a pluggable universal framework, which is open, neutral, can be transferable to different use cases, not limited to on chain payment, but also adapt to compatible with conventional interbank payment. And, firstly, it's fully aligned with existing IETF standards. It's an evolution of the current framework. It's not a revolutionary work, which makes it more feasible and can be more smoothly adapted to the current framework. And, fifthly, we already have a use case, and we proved that it can be very beneficial in terms of reducing the time lag in interbank payment and also the precision we provide by directly addressing to single individual with a certain legal framework. And lastly, the the code is already deployable. So here, the UTXO domains is just to expand and extend the DNS to a more payment native era.

[01:38:10] **Andreii Robachevsky**: We we have sorry. We have to stop you so you have a chance to have some feedback from the working group.

[01:38:16] **Yang Yang**: Just the last slide, we have some

[01:38:19] **Andreii Robachevsky**: No. We no, no last slide. Tobias, go ahead.

[01:38:22] **Tobias Fiebig**: Tobias Fiebig, Theovin speaking for myself and not my affiliation. I personally believe that CFRG might be the best place to discuss an idea like this.

[01:38:32] **Andreii Robachevsky**: Thank you. Yeah. Paul? Which which are you? C f CFRG.

[01:38:37] **Speaker 24**: Okay. CFRG.

[01:38:38] **Paul Hoffman**: Certainly not representing anyone. I propose this gets dispatched nowhere. It it it takes a new TLD. It expects resolvers to do things differently. This is an alternative to the DNS that just uses some of the DNS protocol. I propose this is not dispatched anywhere.

[01:38:59] **Joe Abley**: Okay. Joe? Well, Paul may have read more of the spec than I have, but based on what's on the screen, there's no work for DNS op here anyway. There's multiple RR types. There's RR type applications. You don't need DNS op for this. You can just apply for these. You don't even need you don't need an RFC. You don't need Internet draft. So there's nothing here that DNS officer needs in order for this to proceed on its own merits, I don't think.

[01:39:25] **Jim Reid**: Jim? Jim Reed speaking for myself yet again. I think I'm just about to repeat everything I said the last time I came to Mike. This is not something for DNS op. If you need a new type, you can use the the lightweight template process for that. You don't need the working group. And as far as the issue of guiding for a TLD, that's not something for this working group either. If you want a new TLD, go to iCANN. But I think before you even do that, I think you need to be very, very big clear about why you need a new TLD and why can't you use the existing namespace. So nothing for there's nothing here for the DNS out working group.

[01:40:00] **Andreii Robachevsky**: Okay. So from what I heard from the from the room was dispatch to research, IRTF or CFRG, or dispatched to nowhere, and it doesn't have to be in the NSOP. That's the feedback.

[01:40:17] **Benno Overeinder**: Thank you.

[01:40:18] **Andreii Robachevsky**: So we we still have some time, So, I think we might be able to do the time permitting presentation. And if there's a time after that, we can do the second one second dispatch from Kishore. So now Gochendong. Yep. Again, the format is the same. Please keep it to five, max seven minutes, and then get the guidance from the group.

[01:40:54] **Guochen Dong**: Okay. Hello, everyone. My name is Gordon. I come from China Telecom, and is a co answer. And my parent is the DNS best address mapping record for I p v four, I p v six mapping in I p v six only networks. Let's start with the scenarios. IPv4 only network needs to deliver IPv4 service. It is proposed in IPv6 only framework. So IPV six mapping prefix is considered as the mapping array of a game IPV four just blocks. In a multi domain IPV six only network architecture and showing and so below IPv4 packets enter y r the ingress p and the exist y r I egress p. As we as all we know, the traditional d dns has two model. About two model. One is forward resolution domain to IP. And another is reverse let alone IP to domain. So our question is, can we can we query the IP address but get back not a domain name but IPv6 mapping prefix. So our purpose is quarantine and as with IP IP address to get an IPv6 mapping prefix. So we define AMR, address mapping record. It stores the mapping between IPv4 address block and its cross across porting IPv6 mapping prefix. For example, in the on slide, it includes I p v four block, I p v six mapping prefix. So the a m r looks like the likes this. So the format is straightforward. It includes name type, v four prefix length, v six prefix length, and IPv six mapping prefix. And how that works? And there is two process. First is registration, and p generate mapping between its local IPv4 address block and its own IPv6 mapping prefix. And then sent sent these mapings to a d dns server and the the dns server validates the format and stores them as a AML record. We, ingress p u d saves a p v four packet. It constructs DNS core using the reserved address plus in a d d r m dot a r p a. And if a exact match is not filed, we do log in the prefix match. And if no record is filed, it drops the package or handle according to the local policy. So we believe it's a new and useful approach. So the authors have not yet formally clouded with the IR are regarding the delegation that we intended to initiate a discussion once the technical approach received the initial feedback from the working group. So finally, to make sure I give you accurate answers, I I would like to reply all of the questions offline or via email. So we we welcome comments and the statements and further refine it file the draft. Okay. Thank you.

[01:45:21] **Benno Overeinder**: Thank you. So we have some Ben?

[01:45:27] **Joe Abley**: Yeah.

[01:45:31] **Ben Schwartz**: I would just like to have a better understanding of what this is for. Who who's supposed to query this and why is it useful to them?

[01:45:41] **Guochen Dong**: Thanks. I will get I will give you a reply via email.

[01:45:47] **Andreii Robachevsky**: So so we Ben, we the goal here is to guidance where this lands in DNS op or elsewhere.

[01:46:00] **Benno Overeinder**: This is proposed.

[01:46:01] **Ben Schwartz**: Okay. I mean, it's Okay.

[01:46:03] **Andreii Robachevsky**: So okay. Then I'm sorry. I I got confused. Okay. So, no, you're alright, Ben. So you can answer, Ben.

[01:46:13] **Presenter**: Okay. Thank you.

[01:46:17] **Benno Overeinder**: No, no, no, no, Sorry. There are some questions.

[01:46:20] **Andreii Robachevsky**: And there are more questions.

[01:46:21] **John Levine**: Okay.

[01:46:26] **Benno Overeinder**: Okay. Okay. Yeah. Shane-

[01:46:28] **John Levine**: Shane Kerr, I don't have any questions. I think there are a lot of questions, but I think DNS op is a fine place to have this draft discussed.

[01:46:37] **Guochen Dong**: Okay. Great. Thank you. Remember it. Thank you. You. There you go, Terrence.

[01:46:43] **Andreii Robachevsky**: Toby s. Toby s. There's also Toby s. Okay. So let's take this to the mailing list, I guess. Kishore, if you want, we can have your other draft from the dispatch.

[01:46:58] **Johan Stenstam**: Thank you. Yeah.

[01:47:04] **Andreii Robachevsky**: And again, we can have a five plus five minutes if you if you want. That's we still have time.

[01:47:12] **Johan Stenstam**: Yep.

[01:47:15] **Andreii Robachevsky**: And and sorry for my confusion what the time permits was.

[01:47:20] **Johan Stenstam**: This is the correct deck? Yeah. Yeah. Okay.

[01:47:25] **Kishore**: Maybe you'll find this more interesting. Alright.

[01:47:32] **Benno Overeinder**: There we go.

[01:47:36] **Kishore**: Up till now, we've been overloading Port 53, adding a lot of features when what domains really need is a real control plane. We've been adding more and more features to the DNS. What I'm proposing with the domain authority is to focus on what the DNS is really good for, which is name resolution. It's extremely optimized for that. And then create a real, control play at the application level. The the proposal is that the domain designates a domain authority, which is a HTTP endpoint and from where it delivers TLS protected API domain info as APIs. This is a very minimal standard that, the specification proposes, which is a designation record to designate a domain authority and five and five namespaces for delivering APIs such as a bundle of coordinated records, DNS bundle, a host API to deliver any information that a domain wants. So for example, if you want to imagine a new record type, you don't need anybody's permission or any standardization process. Instead, you deploy through the through the domain authority, evaluate, and then standardize. And then a an author an authenticated Mhmm.

[01:49:54] **Benno Overeinder**: Yeah. I see.

[01:49:55] **Kishore**: Endpoint so that you can authenticate the DNS query, not the DNS query, the one that comes to the DA, and then deliver the DNS endpoints, and also a public key endpoint to deliver massive public keys like post quantum keys so that you are not bogged down by port 53 constraints. So that is a very minimal standard with five endpoints and a designation record. That's what I'm asking for.

[01:50:41] **Benno Overeinder**: Okay. Thank you. Okay. Tobias.

[01:50:48] **Tobias Fiebig**: Tobias Zivich, Thiovin. Not making a statement on merit, but from intention, I would say REGEXT.

[01:51:04] **Andreii Robachevsky**: John? I

[01:51:09] **John Levine**: agree that overloading port yeah, John. Let me I agree that oh oh oh, shut up. Shut up. Shut up.

[01:51:18] **Benno Overeinder**: Someone is pulling you a leg.

[01:51:22] **John Levine**: Sorry about that. It it it was watching the football game last night. I don't think this is a bad idea, but this is what RDAP does. I mean, we part you know, we we agreed Port 53 was ridiculously overloaded, and RDAP runs over HTTPS. It has you know, it it returns structured JSON data. It has a provision for delegation so that, you know, like, a a TLD if if you look up a domain name, you know, it'll ask the TLD that says, oh, actually, no. The rest of the the more there's more information down here, and it just uses the regular h t HTTP redirects. So I think we we have we have added more data to RDAP, but we certainly could add this stuff to RDAP. But I think, I mean, there's no point in doing this when RDAP already is is three quarters of the way there, and it's and it's universally implemented. I mean, like, for for the ICANN contracted top level domains, they've all turned off port 53 and they've already replaced it with RDAP.

[01:52:27] **Kishore**: Okay.

[01:52:38] **Peter Thomassen**: Peter. I'm looking forward to the first that only has port eight fifty three. Anyway, So Peter Thomassen I like this diagram because it shows what part of this is DNS and what isn't. And so the left hand side actually is DNS, and the right hand side is some application layer that this working group is not concerned with. And so as far as the left hand side is considered, the only new thing there is the DA record type. But you can apply for that without a working group document. Can just submit an application for record type. So if you do that, then the DNS part essentially is done. And the rest is outside of the scope of this group.

[01:53:15] **Benno Overeinder**: Outside scope? Suggestion for other working group or not directly?

[01:53:19] **Peter Thomassen**: More indirectly that it's not this one. I don't know.

[01:53:22] **Benno Overeinder**: Right. Okay.

[01:53:23] **Peter Thomassen**: Thanks. What else?

[01:53:26] **Andreii Robachevsky**: At both, perhaps.

[01:53:28] **Ralf Weber**: Yeah. We have Akamai. I think you're overloading Port 443 with this, if you want to actually put resolution into that. So some remarks. I mean, we have eight fifty three. We have four forty three that we're also using in ES. I think the the the reason that and we have drafts that actually have chain results that can give you sort sort of bundles. So I think a lot of the initial requirements that you put up for are actually no longer valid. And other than that, I agree with Peter. I mean, the record type is something you can do outside of the working group, and all the other stuff is really applications. Because in DNS, we have sort of these resolve stop resolvers, resolvers, forwarders. None of this is newer because it is a different world. It's an application. It's a client and a server somehow just discussing it. So it's out of scope for this working group.

[01:54:19] **Benno Overeinder**: Yep.

[01:54:22] **Andreii Robachevsky**: So Okay. So so the summary also Ben said on on the chat, dispatch to both. So I think that the general feeling of the room is that the DNS part that this group is interested is the, you know, left hand side only and the rest of it, it is outside of the DNS op. And we I didn't hear a clear guidance where this should land. So, perhaps something like both might be a good idea.

[01:55:03] **Benno Overeinder**: It's what I see.

[01:55:05] **Speaker 24**: Yeah. I think before considering above or not above for this one, I think I would just follow the proposal from John to first check with the reg ex whether there's something which is similar that the work they are doing there. If the conclusion that there is overlapping, so the answer is then. If there is no overlapping and the CF value to to put this, then we can consider next step. So next steps, go to REGEXT, please, check it, and then Yeah. We can see from there.

[01:55:29] **Benno Overeinder**: Yeah. So we will write a summary of the dispatch individually for each ID draft being written. And some there will be some action points. Some are for for you or for the ISG to think about, But that will be part of the the the memo we will send to the to the mailing list. So for all the dispatch presentations, there will be a summary, with suggestions from the room and maybe some follow-up actions, and either the I ISG will take up or someone else. Yeah? Okay. Thank

[01:56:07] **Andreii Robachevsky**: you. Yeah. That concludes the session, and see you on Friday if you're still here.

[01:56:29] **Benno Overeinder**: We

[01:56:35] **Philip Homburg**: need to

[01:56:36] **Andreii Robachevsky**: mark the time permitting.

[01:56:40] **Benno Overeinder**: Yeah. Okay. It's


---

**Session Date/Time:** 24 Jul 2026 09:30

[00:00:11] **Benno Overeinder**: I will use the clicker. It's the bot doesn't work. The bot doesn't work. Okay. The bot doesn't work. Good morning. This is the dnsop working group session two. Yes. Andre and I, the working group chairs, Schumann, Peter, the secretary over there in France, Matt is our AD, Jim, Jim Reed, our technical adviser. And did I forget someone? No, I think I Yeah, indeed. Paul will take the minutes. Thank you, Paul. This is the IGF note well. The chairs expect you that you have read the note well, understand the impact. We want to highlight the code of conduct. Everybody behaves respectfully and constructive. If someone thinks this kind of conduct is not followed, please contact working group chairs. We take it seriously. Good. There we go. The meeting tips, please scan the quote codes or register yourself on the on-site tool. This also works as the old fashioned blue sheet. So, also, if you go to the mic, raise your hand before you go to the microphone. Thank you. Brief overview of some of the working group document status we didn't discuss last last dnsop working group. Structured DNS error and 3901bis. Structured DNS error just sent for approval by the ISG. That's good. Thank you all for your work. 3901bis is in the RFC Editor queue for some days, and I think it makes good progress. We monitor that. Ready for working group last call. NS revalidation is on the agenda. Domain- sorry, domain verification techniques has been last edit, published or last revision being published. The authors and the working group chairs think it's ready for working group last call, so we will issue that also. And draft-ietf-dnsop-integration was presented on Monday and will also be scheduled for working group last call. There we go. draft-ietf-dnsop-dnssec-automation has been two edits in June and July recently. Also, the authors and the working group chairs want to issue working group last call to forward this document. And during the IT, the presentation on Monday, the author of, management also asked for working group last call. So we're making good progress in pushing forward the documents into the process. In the Delext working group this afternoon at 02:00. Right. Ongoing grease, dry-run, keyrestore has been presented on Monday. And the terminology draft -9364bis.

[00:04:01] **Wes Hardaker**: Not terminology.

[00:04:03] **Benno Overeinder**: Dnssec terminology. Thank you. Thank you, Paul. Right. And today, we will close or this week, we will close the call for adoption of, draft-noc-censorship-transparency. There we go. Yes, this is agenda for today. We will have, NS revalidation by Schumann, small updates before we go for working group last call. Then for consideration work, parent centric resolver, we have catalog zones, properties, XFR properties, optimistic DNS, and uses, routes system service. Route service. Please help me out here. The users considerations. Yeah. I'm hurrying up because we are really tight on time, but this will be the agenda. Then we also want to ask small updates on the hackathon. Can we ask, Andrew, confront and give a very, very brief update of your then we will go to the other DNS activities, at the hackathon. Yep. There you go.

[00:05:20] **Andrew**: Oh, yes. So a brief update on our MTL benefits hackathon project.

[00:05:26] **Benno Overeinder**: Yeah. You need to focus, man. Yeah. Oh, yeah.

[00:05:30] **Andrew**: Yeah. Oh, let's see. We we published a new draft just before IETf. It created a new SPECT MTL specification that's self contained for DNSSEC use in MLDSA and includes updated IPR. So we wanted to do some performance measurements against this and just If the clicker doesn't work

[00:05:47] **Benno Overeinder**: for some reason.

[00:05:48] **Andrew**: Next slide, please. Just some quick what we did at the hackathon for MTL, we evaluated against various metrics, including zone size of MTL with MLDSA versus MLDSA or classical cryptogrhythms. You can look at this slide later or these slides later, but you can see that if you look closely, ML-DSA is the highest one. MTL does quite a good job of amortizing some of these benefits. Next slide, Andre. Same thing with sign in time and verification time. This is part of our effort to show that MTL has benefits that can help amortize some of the PQC DNSSEC costs for its own size, sign in, and verification time as well. Next slide, please. And then Mike, who also presented on Thursday at the PQC DNSSEC research group, showed how MTL can have benefits for reducing the amount of time you need to fetch certain large signatures. So all in all, a successful hackathon helping us get some preliminary numbers on how MTL can amortize some of these benefits when using MLDSA 44. Thank you.

[00:06:47] **Benno Overeinder**: Thank you. Shumann? Yeah. Let's see. Yeah. Oh, it works. It works. Okay.

[00:06:58] **Willem Toorop**: Alright. I'm ready to go. Alright.

[00:07:02] **Shumon Huque**: So I'm I'm Shumon and I'm going to give a summary of the rest of the dns projects. Let's see. How do I do this?

[00:07:11] **Benno Overeinder**: It did work.

[00:07:14] **Shumon Huque**: Would you like to advance the slides for Yeah,

[00:07:15] **Gautam Akiwate**: we would.

[00:07:15] **Shumon Huque**: Right. So here's a list of the projects. I'll have one slide for each of them. Next slide please. And the first is, Delext. So there were multiple implementation efforts in the space. If, by chance you've been, living under a rock recently, so delext is the, attempt to define a new DNS delegation mechanism that is actively being worked on. And, the first project was, by me that was implementing full delegate support in a prototype authoritative DNS server, which was done. And in the course of doing so, I also discovered some incomplete specifications, specifically around the interaction of the delext extensions, downgrade resistance property, and compact denial of existence. So I figured out how to solve that problem and then this requires updates to both the spec and compact data of existence and later on I worked with Roy Arons in the week to make some updates. The next one is LDNS. So I heard from Benno the other day that LDNS was in maintenance only mode, but apparently Shane Kerr did not get that memo, or at least he was having none of it. So LDNS has a new feature. It has Delext support, which was implemented by Shane. And lastly, David Blacka also implemented support for the delec RR types in the dnsjava library. And not listed on this slide, I know that he's also worked on a signer, I think, to to deal with zones with with delec. Okay. Can you?

[00:08:59] **Benno Overeinder**: Yep. Excellent.

[00:09:00] **Shumon Huque**: Alright. Good. So Johan, Sarah, and Leon worked on implementation of aspects of these two draft for, for opportunistic transport signaling and the new SVC per per parameter for operator led signaling. There are implementations the rest of the slide, you can see implementations for NSD and Johan's prototype server and some test zones. And apparently, the unbound resolver will also be implementing support for this soon. And can you advance to the next slide? And and the last one I have is this new relatively new draft on a new EDNS option for DNS back end serial zone version. And that was worked on by Stefan, Karl, and Willem. And there was an implementation in NSD and work is progressing on not DNS. And I think that's it. Is there another slide? Okay. So PQ so this is out of order. We changed the order. So Yep. Andrew already addressed that.

[00:10:06] **Benno Overeinder**: There you go.

[00:10:07] **Shumon Huque**: Okay. And

[00:10:08] **Benno Overeinder**: Now apparently we start the regular agenda. Alright.

[00:10:12] **Shumon Huque**: And it's me again. Alright. So I will give

[00:10:16] **Benno Overeinder**: mhmm. Yeah. Try? Good.

[00:10:19] **Shumon Huque**: No. It works. Yeah.

[00:10:21] **Benno Overeinder**: You did some magic.

[00:10:22] **Shumon Huque**: I will give a brief update on the status of the NS revalidation draft and I'll also attempt to wrap it up because it's been close to done for a while. So this draft is almost six years old now. So the first revision was published in September 2020. However, the central idea in this draft goes back much further. So that's explicitly querying the NSRR set at the apex of the child zone and preferentially caching it. So, if you were around back then, you may remember Wouter Wijngaards's draft on resolver side mitigations of cache poisoning and also the well known RES improved draft by, I think it was Vixi, Joffe, and Neves. So some of the, features in this, method is that it comports better with the DNS protocol's own data ranking rules. So before you mention it, I'm going to preemptively state, yes, we are aware that DELag is coming in the future at some point, and it will materially change this in where the location of delegation data authoritatively resides. But this protocol is designed for the way the DNS works today. There are a bunch of security and privacy improvements in the areas of better defenses against cache poisoning and query redirection privacy attacks. And it makes name server infrastructure changes visible to resolvers much faster. So this is particularly beneficial if you are held hostage to longer unchangeable TTLs by your delegating parent zone. Okay. So in the intervening time between when the draft was first published, there's been many discussions about the pros and cons of this and alternative methods, and it turns out there are other ways of doing sort of referral processing. When I originally started working on this draft, I was under the positive delusion that I could delusion that I could get all resolvers to act this way. I quickly found out that resolvers are fiercely and famously independent. Right? So particularly in areas of the protocol where an actor can implement something unilaterally without causing interrupt problems, they kind of do their own thing. So things like referral processing, and the other one I can think of is name server selection algorithms. They're kind of all over the place, right? So what we did was we had extensive discussions with I'd like to thank Ralph Weber in particular for informing us that there are these other mechanisms in place and they have an alternative set of benefits. So what we did was and I guess an argument can be made that implementation diversity in this space is actually beneficial to the dns ecosystem at large. So that's the genetic diversity argument, I guess. So over time, we made accommodations by clearly indicating that this draft is optional, and in fact, there are layers of optionality. So there's subsections which you can implement and things you can. So for example, you may decide to implement the entire algorithm but not do the glue validation, which requires even more queries. And you could restrict the strict validation only to the upper layers of the hierarchy where you're less likely to encounter problems with poorly maintained child zones. The last thing we did was we encouraged proponents of other methods to write up their own drafts, which you will see in a moment, Andre will talk about. Alright. Okay, so what's the latest? The revision 12 draft, which we put out a while ago, as far as we know, had addressed all the working group last call comments, the first one at least. We did put out a dash-thirteen revision a couple of weeks ago. That was mostly editorial in nature, so fixing typos, grammars. There were places where we had inconsistent text and we had to add clarifying text, so we did that. But basically, we think the draft is done. I do, I must say, fairly frequently get comments from other IT efforts about when is this draft going to be finished? It's deployed in the field. You need to publish it. So most recently, I'm just going to pick on Paul Wouters who told me that to my face earlier this week. So, I guess my question to the working group and to you guys is, how can we wrap? There already has been a working group last call. Do we need another one because it's been a while, or can we move it on to the next stage?

[00:15:09] **Benno Overeinder**: Well, there are also some questions. So I would prefer propose for another working group last call Okay. Because of the time between the previous one and and today or soon. Yeah. Peter, very brief.

[00:15:24] **Peter Špaček**: I think the text is fine. What's missing for me is the implementation status section says that, oh, it's been running for years and years and years. But, actually, what was implemented and deployed doesn't match what the draft says. So I would prefer actual implementation of the strict mode, is being proposed

[00:15:43] **Gautam Akiwate**: Got it. Yeah.

[00:15:44] **Peter Špaček**: But I've never seen it in practice, and I'm not sure that it will actually work. So it would be good to actually test the protocol that actually works before we publish it, Right.

[00:15:53] **Shumon Huque**: Okay. So, Peter, I think what you're saying is the entire draft hasn't been implemented. Right? So some of the newer stuff like the Google validation stuff? That's a fair point. So, Willem and I, you and I should talk about that.

[00:16:04] **Benno Overeinder**: Yeah. Ben, fairly brief.

[00:16:07] **Ben Schwartz**: Hi. In the interest of reducing confusion for future readers, I would encourage the authors to consider how to make it as clear as possible that this draft and the draft we're about to talk about are essentially a matched pair. I would love them to have successive RFC numbers, but I think that's not gonna happen. Failing that, I think a different title could be clearer here. So, for example, if this draft were titled recommendations for child centric resolvers and the other draft were titled recommendations for parent centric resolvers, that would be very clear to readers about what is going on between these drafts.

[00:16:52] **Shumon Huque**: Yeah. Okay. That's an interesting idea. We can talk about it. So the the point that I want to make to you, Ben, is, I think that title is appropriate for the next draft. For our draft, our draft is not strictly child centric. Right? Because it strategically uses information from both the parent and the child side in the way that it works. Right? So but I think I get your point. We could probably come up with a more encompassing title to make it less confusing.

[00:17:20] **Ben Schwartz**: I I think you are describing child centric behavior. You you obviously cannot process the DNS without having some reliance on the parent.

[00:17:27] **Shumon Huque**: Right. What I'm saying is we rely on both aspects. Right? Because we need to keep track of the parent's side information to prevent ghost attacks and things.

[00:17:35] **Benno Overeinder**: Thank you, Shumon and Ben. Yes, please continue on the mailing list. Thank you for the input. We have to go to the next presentation.

[00:17:51] **Ondřej Surý**: Hi. This is Andre. I see. So this is the other idea that actually has been implemented, also implemented in a couple of resolvers already. So there's one cause and it has many symptoms. There was many attack on DNS on the protocol, like Ghost domains, Phoenix domains, that that abuse the fact that there's name servers in the parent and name servers in the child. And and there are other stuff like RPZ. So, if you have a RPZ rule for name, does it trigger when there's a name server from a parent and name server from a child, if they are inconsistent? Again, this is non deterministic because it depends on the state of the cache. And recently, at least in Bind, we had a problem that there was a security that abused the sibling glue and we had to just disable consuming the sibling glue. The other thing is that Delek is coming, and this it is parent site only. So using parent site delegations even with the top today's name server records makes it more consistent. So the difference is the split between the delegation data as the parent's side, name servers, and Glue or Delek in the future from the referrals. And it drives all delegations decisions. It's never overwritten by any child records, child NS records, and never returned to to the DNS clients. For the answer side, it's the child Apex name server records. It's returned to the queries, and it has a eight bit set, 80 bit set when the it's when it's DNS validated. So there's a clear split about the parent and child and its records. So and the thing is that it's only behavior. So there's no demand to change any cache architecture, data structure, or lookup it to the existing infrastructure. It just just works inside the implementation. So, if you use the parent side name servers, the delegation info is then self contained. It doesn't poison other delegations. It removes the attack that that was on bind. And it also, again, make makes this, you know, the the sibling glue loops work again because before, when we had to remove the sibling glue, this just stopped working, even though this is clearly wrong. All the ghost domain and the, you know, the variants are just nonexistent in in this. And and the delegations are stable and deterministic because there's only one one source where delegation info is being pulled from. And the implementation is also much simpler. So related work, this draft, obviously, then the one that Shimon just talked about. There's also the DELEC draft that will be talked about in the Delek working group. It's all related to this. There are already implementations. The development version of bind already implements this. There's Google public DNS that uses the the parent site. Akamai Aura, CNS-one zero, case server. Under all these names, they already had the parent centric delegations for many, many years. MaraDNS since forever as well. And we would like to see more implementations to this. So what are next steps? I think this needs more discussion on the mailing list. I've so far, I think only Shane gave feedback. There are some open issues. How what what happens with forwarders and stuff like this? It's it but that was always hairy area. How if you have a chain forwarders, how how and partial partial forward is how this works. If the limits are right, and I think this should be like complementary to the NSA relation draft. So on the the table shows, I had a presentation at IEPG and before that at RIPE ninety two to say to to show you the difference how many queries are needed when you have a cold cache for these names, and it drastically reduced the number of outgoing queries. Now it's time for questions, comments.

[00:22:57] **Wes Hardaker**: Well, I don't mind the publication of this draft, but I found the security consideration section inadequate. And in particular, the concern security consideration section of Schumann's draft adequately describes the the the issues with this draft. So you might cut and paste a lot of that. Sure.

[00:23:16] **Benno Overeinder**: Sure. Thank you. Ben?

[00:23:20] **Ondřej Surý**: But does does it have to happen, like, before the adoption or after the adoption? So that that's sorry.

[00:23:29] **Wes Hardaker**: No. That's okay. So I wouldn't I mean, obviously, before publication, I would probably reject adoption myself because it's not honest about the downsides based on the presentation I gave at DNS or the DNS security workshop. Okay.

[00:23:51] **Benno Overeinder**: Ben, please go ahead.

[00:23:54] **Ben Schwartz**: The so the draft has this to do and then this discussion of doing some weird things with the RD bit. I I I would just encourage anybody who's interested in this to take a very close look at the at the topic of what this draft proposes with the RD bit. I don't know. It seems to me like that that is complexity that isn't really necessary here, and I would prefer to try to leave the RD bit alone.

[00:24:28] **Ondřej Surý**: Sure.

[00:24:29] **Benno Overeinder**: Thank you. Shane? Hi.

[00:24:32] **Shane Kerr**: Shane Kerr. So as far as adoption, I think this is the right place, and I think it makes sense. And I think the goals and everything are good in the document. I I think I mentioned on the list my concern that I I think this document explicitly states that if you query for the NS record explicitly, you were you do the normal resolution process, which basically means that whatever the resolver is actually using for the NS is completely hidden and not visible, which is which could be problematic. But I realize that maybe that's a bigger problem than just this draft. Like, there's a lot in of internal state in a resolver, which is not currently available. So I I guess I wouldn't insist on making that part of this draft, but maybe maybe it does it make it would there be appetite for a separate work on exposing resolver internals in some way that's useful to for people debugging networks and things?

[00:25:27] **Ondřej Surý**: I personally, I never liked cache snooping, but I I I understand what you are saying. And and this is this is a problematic thing with even with the child centric resolvers. If you ask for the NS, it might you you know, it might mangle the internal state of the resolver and internal state of the cache because it might not give you the the NS record that were used for the delegations, but instead, it will re query the record for the child and give you the give you the child records. So I agree this is, like, this is useful for debugging, but at the same time, it doesn't work reliably even with the current implementations.

[00:26:15] **Shane Kerr**: That's fair.

[00:26:16] **Benno Overeinder**: Okay. Good.

[00:26:20] **Klaus Darilion**: Thanks a lot for doing this. I said the resolvers that I use have been doing this since 2002 and without problems for a lot of customers. There there is a thing if you are talking about security that we the I'm okay with adding stuff. It's not DNSSEC signed DNS records in the end, but the advantages over that for having not having vulnerabilities that are not DNSSEC related. So there are still domains out there without DNSSEC, and these are actually protected by these things. So we should also add that. Thank

[00:27:02] **Benno Overeinder**: you. Okay. Yes, before working group call for adoption, more discussion on the mailing list. That's my conclusion.

[00:27:09] **Ondřej Surý**: I'll update the draft with the feedback I got here, and I'll send the new version. Thank you.

[00:27:16] **Benno Overeinder**: Thank you. Thank you. Okay. There you go. Yes.

[00:27:32] **Willem Toorop**: So this is a proposal for additional properties for catalog zones and with the goal to reduce the amount of necessary pre provisioning to facilitate ad hoc changes and to facilitate exceptions for individual member zones. So this presentation is organized in a what section, a why section, and how. So let's go on to the what section. So dnscatalog zones is a method for automatic DNS zone provisioning among DNS primary and secondary name servers by storing and transferring the catalog of zones to be provisioned as one or more regular DNS zones. It's the RFC 9432 has been coautered with authors from BIND, NSD, Knot DNS, and PowerDNS. And so it works across implementations, which is very nice for operators. Let's work with multiple DNS implementations to get all their zones deployed. So how does it work? A catalog zone is just a regular DNS zone, nonpublic, transferred from the producer, which is the primary name server for the catalog zone to the consumers, which are secondary for the catalog zone. And the catalog zone con contains a list of so called member zones of the zones that need to be proficient on the name servers. So a producer is not necessarily a primary for the member zones and also consumers might be primary for the member zones or they might also be secondaries. So now the why section. So the catalog is distributed from producers to consumers. Consumers have configuration associated per catalog zone preconfigured or pre proficient with information from which primaries the zones need to be transferred with which T6 keys, etcetera. Or there's also option to associate certain configuration with individual member zones by the group property. So in the example on the slides, the example.com is associated with the configuration for group NSEC-three. So it might be that its secondary is DNSSEC signing that's sown s x three or something. An example of .net associated with group operator x. So that is where it gets its sown from. So the associated configuration among all those secondaries and primaries is pre proficient, and that's a bit inconvenient. So the goal of this draft is to reduce the amount of necessary pre provisioning to facilitate ad hoc changes and to facilitate exceptions for individual member zones for configuration involved with zone transfers. So there is a IAM registry for catalog zone properties. It does have a proper property called XT, which is custom used for custom implementation specific properties. And bind uses has has a bunch of custom properties for certain transfers. And the idea of the draft is just to take those properties that binds already provided and cut out the dot x label and make them actual properties that can be used with all the implementations. So this is now we are in the house section already in the pre on the previous slide, I guess. So standardized the bind custom properties plus some extras from feedback from what operators want to do with Catalog Zones. So there's a primaries property listing the primary name servers from which to fetch the zone. We have augmented it with a way to authenticate a transfer of TLS or transfer over quick upstream or primary. It also has properties for from which IP addresses transfers are allowed and from which IP addresses queries are allowed. We have extended that also with T6 in the draft. And there's another property, which was not is not in bind yet, is which other set further secondaries to notify with which TTEC key. And there's a section of placement of the properties. So catalog zones properties could already be placed at the apex, which makes them applicable to for all the member zones. You can also put them below the member labels to make them apply to for that member zone. And here in the draft is a groups property, which lists the groups that can be used with member zones and associates a bunch of properties with that group. Furthermore, a catalog zone is just a regular zone. So far, catalog zones have not been processing C names and D names as regular zones. But if they would do that, then a lot more flexibility with respect to templating, etcetera, will become possible. Well, you can have a look at the draft or at the slides for details. So that's what we proposed to. So a few weeks ago, there was a we had a panel discussion with a bunch of operators that use catalog zones in their operations, and it is recorded at the DNIS weekly call from Andrew Kempling. And operator was, for example, Klaus Darilion from Nick AT and our card CRO, Karl Dyson from Nomineet, Internet and sets, Alexey as well from CZ.NIC. And so operators find this a useful tool and would like to extend it for more things. And this is, I guess, the sort of the lowest hanging fruit to extend catalog zones to, again, reduce the amount of necessary pre provisioning, facilitate ad hoc changes and facilitate exceptions for individual member zones. That was the last slide.

[00:35:34] **Benno Overeinder**: Thank you. Queue is open. Peter?

[00:35:42] **Peter Thomassen**: Peter Thomassen, SSE. Unfortunately, I couldn't make it to the panel discussion. So here's my request. For replication, it's very useful not only to know which zones exist and which are new and which have been deleted, which you can derive from the list of member zones, but also to know what their serial is. And, yeah, so we've discussed this before, I think, for the original draft that is now RFC. And, I think that would still be a very useful property. I've discussed that with a few people and apparently not DNS. It's architecturally a little difficult to get the serial in the synthesized zone. And in PowerDNS, it might be easier. I don't know. I'm not saying that everybody should implement this, but I think this draft is an opportunity to define the format for such a property in case someone implements that. Because I think on the on the consumer side, it's very useful. This way, you do catalog zones with AXFR transfers, you can get rid of all the refresh queries of all the notifiers. Yeah. And I think that's actually

[00:36:42] **Willem Toorop**: Yeah. I I think the serial property is a really good idea, but but this is but it's also different semantically from this. This is just the bare basics. And I think we should do the serial property, but in in a separate draft.

[00:37:02] **Peter Thomassen**: I mean, I don't mind. Yep. Sure. Okay.

[00:37:05] **Benno Overeinder**: Just yeah. Okay. So thank you. So did got a lot of intention in the DNS org, the operations community. We think it's also relevant definitely for dnsop. So please continue discussion on the mailing list. And we will consider working group last call.

[00:37:26] **Willem Toorop**: Call? Adoption.

[00:37:27] **Benno Overeinder**: That is a new strategy. We do adoption in last call at the same time. Sorry, apologies. And following the discussion, we will inform the working group if we go further with the working group call for adoption.

[00:37:41] **Willem Toorop**: Okay. Yeah?

[00:37:41] **Benno Overeinder**: Yep. Thank you. Okay. Next is, Karen. Can you alright. Excellent. Yeah. Fifteen minutes. Ten ten minutes.

[00:37:58] **Gautam Akiwate**: Okay. Thank you. My name is Gautam Akiwate, and I'm going to be talking about our draft which discusses optimistic DNS. For folks who are wondering what optimistic DNS is, it's a client side stub resolver mechanism that uses expired cache records while at the same time kicking off DNS query to refresh it. And a lot of the draft deals with how do we do it in a way that doesn't break everything. And the because this is a stub resolver mechanism, this is sort of complementary to RFC 8067, which talks about serving stale data at the recursive resolver. And while RFC 8167 has a lot to do with its primary motivation is availability, in our case, the motivation is more performance. We have these records that last for, like, anywhere from twenty seconds to sixty seconds, like really low TTLs, even in the case that because of resolvers already don't cap it, like let's say you have a record that only lasts for sixty seconds, in the fraction, in the time that the record is alive, all of our requests go through fine, like we have low latency and every time that record has expired, we need to now pay this network cost only to reconfirm what we already knew. In majority of the cases, nothing has really changed. And one of the things that we had tried before we sort of thought about using expired answers is, like, can we do this proactive refresh? And that doesn't really work because the recursive resolver is, like, in lockstep with you. So here is the situation that we found ourselves in. We have an expired record and we have now sent off this DNS query to refresh the record. And we call this the why not try philosophy. So basically, we have sent this DNS query out, we are going to wait, why not try the expired record? It might work, it might not. If it works, then we have visibly better user experience. If it does not work, then we wait for the DNS query and use that to cut and start. No worse than basically just waiting for the DNS query to finish. And a key thing here, which I feel, not a lot of people, get, which is we are not saying that the client the user should see any, errors. We're saying that the client should gracefully fall back and use the fresh answer to connect if the expired answer does not work for any reason. It could be because the server is not accepting new traffic, a new server has taken its place, serving a different domain, whatever the reason might be, that might be okay. And the way we are going to sort of get the client to do this gracefully is if the client implements two enabling technology. And this is the only reason we believe that using expired answers is okay, is the first is asynchronous DNS, which is the application continues to get updates to the DNS query while the connection is still ongoing. And one, so basically the sub resolver is going to hand off the expired record while it fetches the new answer and then gives you back the updated answer. And Happy Eyeballs is going to try with the expired answer and when it gets the new answer, if the expired answer has not worked, it will try it with the new answer. And basically what we're saying is that if a client cannot gracefully use the new addresses, we should not be in the business of using expired records. So here is a rough description of how optimistic DNS works. An application that has opted into using optimistic DNS sends a query to the sub resolver, sub resolver sees that it has opted in, it's going to immediately return an expired answer. When it returns an expired answer, the application can now start connecting, but at the same time, the sub resolver is going to kick off a query for the the same answer. And when the query responds, the stable resolver can now take it and give it back to the application, and the application now knows, like, its expired answer is not making any progress. You can now use the fresh answer and start a connection attempt with it, but in majority of the cases, that's not really necessary. And if I were to put it succinctly, I would say asynchronous DNS is what makes optimistic DNS possible. It makes the use of expired answers possible, and it is happy eyeballs that makes optimistic DNS safe. Essentially allows us to use these expired answers without any user visible issues. So how long do we use expired cash records for? Because it seems like the general based on conversations in the last week, people seem to be generally okay with using So

[00:43:11] **Ondřej Surý**: there's a lot of people in the queue and you still have 10 slides, so I would

[00:43:16] **Ben Schwartz**: It's advise transitions.

[00:43:17] **Gautam Akiwate**: Okay. I will I will I expected this to be pretty spicy, so a spicy take. So I'm prepared, hopefully. Famous last words. But it seems like people are generally okay with the idea of using expired records, it's just how long. And our philosophy, going back to our why not try, is five seconds after, why not try? Five minutes after, why not try? Five hours later, why not try? Five days later, why not try? And even though the draft says seven days later, I'm actually aware of the opinion, why not try? And in practice, an expired record is used only once and refreshed immediately. So if you try to write again, you're not going to use the expired answer anyway. Like, you're going to use the new answer and caches are purged on network change. So in practice, you are not going to encounter this frequently, but it also means that you are going to see better performance for majority of the cases. This draft is based on our experience of implementing and deploying MDNS responder, which has been in place since September 2018. So if you use an Apple device, you're already using expired answers for the last eight years, and I hope we have not broken anything. Mozilla Firefox has been using expired records since 2013. Google is in works to sort of make this work right now. And they can talk a little bit more about that. In terms of operational considerations, we have seen optimistic DNS optimizes for the most common scenario. And because we can gracefully follow where servers will do the right thing, and they will use the expired answers. There is scenario which we can see maybe a domain wants to have some server outages. And then

[00:45:14] **Benno Overeinder**: Okay. Thanks.

[00:45:15] **Gautam Akiwate**: Yeah. So next step. And let the yes.

[00:45:20] **Benno Overeinder**: Thank you. The floor is open for questions. We have less than two well, almost two point five minutes, and we want to keep that in time. So please go ahead.

[00:45:31] **Peter Špaček**: Peter Špaček, I see. Do you have any data which compare what you are proposing with the prefetch which is implemented in the resolver? Because, for example, in binds, we have prefetched in 2014. And as far as we know, that gets rid of that latency spike, so this wouldn't be kind of necessary.

[00:45:49] **Gautam Akiwate**: So if the prefetching we did the step resolver prefetching and it doesn't work, so, like, our MDNS responder already does prefetching, We have a mechanism for that, but in practice, we we need to work with a range of resolvers, not just bind. So but we will look into that.

[00:46:10] **Benno Overeinder**: Thank you. Marwan?

[00:46:12] **Marwan Fayed**: I'm third in the queue. Is there anyone ahead? No. Marwan Fayed, Cloudflare, but speaking as an individual, let me say when I first saw this Gautam, I was deeply offended. But having reasoned through it all week, I think that, really, the outcome here should be if you're doing both of these things, happy eyeballs and the optimistic, ignore the TTL completely. It works in every case, and this and the authoritative gets exactly what it needs in every circumstance that that it can work out.

[00:46:37] **Gautam Akiwate**: I appreciate you, Marwan. Next.

[00:46:40] **Sebastian**: Sebastian Paramba, Google. I also want to come in support of this. We've been doing this in production for Google's own apps for a few years now. We're using TTL values of around twenty one days for some apps, seven for others, and we have not seen significant traffic being misrouted. It also is important to recognize that this is the same as the DNS service caching the value incorrectly in the middle and clamping it higher than your original TTL, and you have to deal with it anyway. I think happy eyeballs are a solution to all of this that actually make this work and safe. So thanks.

[00:47:14] **Benno Overeinder**: Thank you. Next one.

[00:47:16] **Mike Blanche**: Hi, Mike Blanche. Really quick. Similar to the the point before about clients clamping TTL higher. I'm trying to drain a server. I've got a bunch of traffic going to that server past the TTL I've got. I don't know how much of that traffic is people just doing bad things beyond TTL and how much is happy eyeballs that will gracefully fall over somewhere else. A solution to that would be great. Thank you.

[00:47:42] **Benno Overeinder**: Thank you. Erik, twenty seconds.

[00:47:45] **Erik Nygren**: For the short time frame, doing some expansion here seems reasonable. For the kind of longer time frame, when you start getting into days and such. Think that or even hours. That's, I think, a real problem operational operationally, as I've mentioned on the list. Yep.

[00:47:59] **Benno Overeinder**: So sorry. We're out of time. We have the next presentation. Thank you, Goran. And, we continue the discussion. There's a lot of interest. Continue discussion on the mailing list, and then we will follow-up. Thank you very much. You have 59 here. We just go ahead.

[00:48:18] **Wes Hardaker**: All right. Well, we're already a little bit behind, so we're going to dive through quickly. This is about we had a discussion in IETF 120 about local routes and cache. And that is sort of there was a lot of discussion on the mailing list, and I will invite Paul to add any extra words he wants to add afterwards. The upshot is there are four local root documents that we talked about. Paul presented his document about root cache. And the room at the time, we sort of ran into a discussion of like, well, what's the purpose of this? Isn't queue name minimization, ANSEC aggressive caching, and other things just as good? Valid questions. So I looked at a number of different technologies that are used to talk to the root and everything. This talk is going to be about the root mostly because that's what local root and root cache are targeting, but it really applies to most of the tree. So there's QNIM minimization, aggressive insect, encrypted DNS, serve stale, DNSSEC, and then local root. Right? A lot of different technologies for improving communication with the root. They're all DNS wide. Even local root, right, you can use with other. It's just really doing an AXFR and downloading a zone. It just happens to be that people use it mostly with the root. So today's goal, I went through sort of a detailed analysis of all these different things, trying to figure out how did they help stuff. So I will note that I'm obviously biased, but I tried very hard to be objective where I could. So I came up with a rating system. Some things can be measured very accurately in how much they help, and other things are a little bit more subjective. I tried to be beneficial to pretty much everybody. So I use this notion of they helped completely solve the problem. They significantly helped. They moderately helped. And then some things, you know, didn't help a particular problem at all. So we should debate the actual values on the list. Let's not do that with a microphone today. Instead, there's more important stuff. So what did I actually look at? So first off, I looked at privacy. Can we actually protect end user queries from leaking privacy? Right? And that includes both on path and it includes the authoritative servers themselves, be it RSOs or anything else. So key name minimization protects quite a bit. I've shown in the past that even if you only get the TLDs, you actually do sort of leak some sensitive information. I'm not sure everybody buys that argument, but I do. Aggressive NSEC reduces non TTL queries to one over n, where n is the size of the zone. Right? Because if you're querying for something that's not a TLD and there's an NSEC record covering it and you have it, then you've reduced the number of queries. So in theory, you could get one over 1,500 queries are sort of answerable without actually having to go to the root, for example, until the next round gets done. Encrypted and authentication reduces the on path eavesdropping quite a bit. Local root, because you have all the answers, you're never sending questions. So if you don't send questions, you are completely privacy focused. I'm not gonna go through all of these just because of short and time, but in terms of disconnected operations, you know, are you actually cut off from the authoritative server that you're trying to talk to, the root or otherwise? Serv stale helps a lot. Local root helps completely because you have everything. Serv stale helps if you happen to have that answer already available. If you wanna protect the authoritative resource records, if you are using encrypted and authenticated TLS or something like that, you have a a secure transport to the authoritative server, and you can validate its identity. I'll come back to that in a minute. You have complete protection. DNSSEC is significantly there's some things that are signed with DNSSEC and some things that aren't. We sort of just covered that in the two previous drafts on parent centric versus child centric. And then, of course, local root does everything, assuming you check the ZoneMD record. Nonauthoritative, like glue data and child NS records and things like that, sort of similar type of results. Encrypted authenticated connections are great. DNSSEC protects a lot of stuff, but not 100%. And then local root protects it all, assuming you check this on MD record. Bit flipping, which has been the latest thing that's been discussed. Right? Bit flipping is a little bit harder because it depends on when you're checking. So there's a bunch of technologies that, including local root, that you can check the contents of the data, but the instant you've verified it, it could be bit flipped after that point, either in memory, on your disk, or in transit to your client or something like that. So nothing is complete there because you only get protected up until the point that you actually do the security validation on the particular set of data. Latency. A lot of people don't agree. There's not wide agreement that latency is even a problem when it comes to the DNS, or especially to the root. Nonetheless, if you do believe it, aggressive NSEC actually does help because you get answers immediately assuming you have an NSEC record that's covering the the data that you're querying against. And again, local roots immediately is already in your cache or root root cache for that matter too. So since I wrote that draft and published it, a couple of people have pointed out to me that I'm being a little bit overly optimistic about how well encrypted authenticated communication to an authoritative server actually works. How do you check the identity? Right? We actually don't have a, first off, all of that all of the resolver to authoritative server is experimental at best. And b, we don't really have a great mechanism yet for actually doing the verification of the certificate that the authoritative server is using. If you have an IP address based certificate, that may work. The existing examples out deployed in the world are really, you know, self signed certificates or CAs or something like that. So I was told I was being too optimistic about whether you could actually deploy Resolver to authoritative TLS at scale. And I think that I was being trying to be very generous in my analysis, assuming that you we can solve these sorts of sorts of problems. But I did want to put up this slide because I had multiple people point out that I was being a little too optimistic. As I said, I was trying. So this is sort of what the results look like. If you look at all of the technologies which are across the top and all of the issues sort of on the left. And the dns works without any of these issues being solved, but it works better with MR. And you can see that sort of the local root and root cache kind of mechanisms actually protect you in a number of ways that the other technologies are often significant. You really have to deploy them all. Whether that's good or bad is subject to much debate. But that's where we ended up at the end of IETF 120, so this is sort of some of the analysis I did. In the end, the problem that we still have, so this is actually the document. I published it all in a draft. It was never intended to be an RFC. It was really to drive this discussion today or for people to think about. It could be an RFC, but that wasn't my original intent. But here's the real problem. RFC 8806 is wrong. Right? There is not any implementations that actually implement the concept of local root as it's written. The authors say that, right? We need to fix this regardless of whether you agree with the rest of my analysis, in my opinion. So I think that we should do something, whether that is adopting the draft that Warren started about oops. I listed it as extended error. That's way off. I copied the wrong thing from GitHub. Whether we whether we adopt the local root document that Warren started or whether we adopt Paul's root cache, one of these has to be done because 8806 doesn't match what people are doing. And for just as a refresher, Paul's document is explicit about how you do it. You actually do a cache injection, and then the one that the four other authors have done is a little bit more just defining the behavior. What should it look like if somebody was talking to something implementing local root? There are other documents. There's also, in the process of doing all of this, I created a schema document that defines AXFR and XFR and XOT schemas. I think people generally thought that this would be a good idea, regardless of whether we do anything else, that it would be nice to have a schema definition for URLs. And then there's also two documents that I ask Ayanna to please publish a list of where you can download the route. Whether that's a good thing or a bad thing, I don't know. My personal belief, of course, I wrote the documents. It's a good thing. So I think we should decide. In my opinion, I think I'd like the working group to do a call for adoption for three different things. One, replace 8806. I don't know why we wouldn't do this. Right? What's out there is wrong. Simply replacing it with one of the two other documents would be a good thing. The XFR schema, I think, is a no duh. I think people have said it would be a good thing. And whether or not we ask Guyana to publish a list of locations that you can download the root data, to me, that's a good thing. Why wouldn't we provide that hint to the world? I don't know. But not everybody thought it was necessary. I think it would be highly beneficial and helpful. That being said, Paul, as I said, I wanted Paul to trump the line. So but I

[00:58:12] **Paul Hoffman**: didn't till I saw the slide before this. Paul Hoffman, I don't think anything needs to be done. I think just let 8806 be wrong and dead.

[00:58:21] **Wes Hardaker**: But you wrote one of the documents.

[00:58:24] **Paul Hoffman**: I did, but that was in response to you trying to replace eighty eight zero six with something that I

[00:58:29] **Wes Hardaker**: thought was worse. So should we make it historic?

[00:58:32] **Benno Overeinder**: Mhmm. Sorry?

[00:58:33] **Paul Hoffman**: We it historic, obsolete, whatever, but I disagree with the we must do something.

[00:58:37] **Shumon Huque**: Okay.

[00:58:40] **Peter Špaček**: I agree what Paul said because the fact that, like, four different implementations do four different things and initially works in production, for me, an indication that we don't have to prescribe what to do because implementations figured it figured it out. It works in practice, so don't touch it, basically. Having said that, I agree that the URL schemas and list of publication points is a good idea, but I don't think that we need to prescribe what to do because this is purely an optimization. And, historically, we were not prescribing optimizations for everything we possibly can.

[00:59:19] **Wes Hardaker**: So do note that the one that we wrote doesn't prescribe how to do it. It describes the behavior you should expect if you're talking to something that is doing local root. Right? So there's a significant difference between Paul's, which says inject stuff to the cache, and mine, which says you should go get it. You should do something with it. And if you fail, the important thing of mine is if you fail to get it, you must fall back to regular DNS or if you haven't yet bootstrapped. I mean, those are some semantic differences. You should read the document for the full list.

[00:59:51] **Peter Špaček**: Yeah. Yeah. Well, the thing is that there is many ways to skin that cat, and there is, again, no reason to prescribe exactly what do you do because perhaps you want to inject it into the cache. Why not? Perhaps in your specific case, makes sense.

[01:00:03] **Wes Hardaker**: Mine doesn't prescribe exactly what you must do. That's my point. Roy?

[01:00:09] Speaker 17: Roy Arends. I work for ICANN. Two things. One is I would love to see some folks address experiences that they have with deploying local routes It would be very helpful in writing operational considerations. For instance, I know that that Google has has a a famous open resolver, I assume that in the past, Google have used this as well. So it would be great to have some experience added to the documents. Another thing is I I hear when I talk to people about local routes, and I'm actually a big fan of it, but but that doesn't that shouldn't influence you on on the contrary, actually. But the I hear a lot of criticism, Roy, this is only one query from a resolver would go to the roots, and then the root is not important anymore. Can we fix the bigger how do we get come as a local? My point is that, even a small amount of queries that go to a root server, right, if those fail, anything else that comes after it will fail as well. So even though a very, very small amount of your results will go to a root server, these queries are very important. And so it might be helpful, I'm not going to say better, it might be helpful to have additional braces such as local root here. Thank you.

[01:01:39] **Wes Hardaker**: So I'll remind everybody, I have a local root helpful web configuration client running at ISI that has about 400 people registered with it. A good percentage come back to me daily for AXFR. Local Root's not new. It's ten years old. It was the very first documentation quite a while ago. It's been published multiple times. Nobody has ever complained that it didn't work for them, that it failed.

[01:02:03] **Benno Overeinder**: You. And finally, Ben.

[01:02:07] **Ben Schwartz**: Hi. I'm a big supporter of local root. I but I what I see in these drafts is a lot of design complexity and fragmentation of the DNS protocol. One of my favorite things about DNS is that we have simple basic building blocks, and we combine them in different ways to get what we need. And so the introduction of these URI schemes to me, it seems like, an architectural red flag that we are taking the DNS system, and we're breaking it into different pieces and basically creating a lot of different ways to do things. I would much prefer that we think really carefully about the functionality we need and that we build them in build the minimum that we need and we build it in the most composable way that we can think of.

[01:02:58] **Wes Hardaker**: I'd love to hear comments about where the complexity could be improved. Thank

[01:03:03] **Benno Overeinder**: you. Yeah. Please continue on the mailing list. We're running two minutes late. It's our fault. Thank you, all the speakers and the people in the audience, to be strict in timekeeping or and see you in San Francisco. Thank you very much. Thank you.