Session Date/Time: 20 Mar 2026 01:00
This is a transcript of the IETF 125 DELEG working group session.
The associated working group documents are:
- draft-ietf-deleg-requirements: Problem Statement and Requirements for an Improved DNS Delegation Mechanism
- draft-ietf-deleg: Extensible Delegation for DNS
The session presentations are:
Dwayne Wessels: Welcome everyone. It's 9:00 o'clock. We're going to get started here pretty soon. I'll give a couple of people who just walked in the room a minute to get settled. And yeah, if you're not—if you're here in the room and not signed into Meetecho, please do so. Of course, we'll use that for queue management and you don't want to miss all the exciting snark in the chat room. Yeah. If you thought you were coming to the session title session, you're in the wrong room. Unlike what it says on the screen here, this is the DELEG working group session. So, Eric. I see Tommy has joined. Thank you, Tommy.
Tommy Jensen: Of course. It feels familiar. I have chaired a session title working group before. Very relatable.
Dwayne Wessels: Alright. So we'll go ahead and get started. The doors have been closed. Proceed. We'll start with some perfunctory slides. This is the Note Well, which describes some of your obligations for participation and expected behaviors while you're here. This is stuff that we take seriously, and you've seen this before, so probably everybody is well aware of this. As I've said, please sign into the session via Meetecho and DataTracker if you're here. Please, you know, mute your audio and video unless you're me, unless you're chairing. Here are some resources for the meeting here at IETF if you haven't seen this already. And lastly, this is our agenda for today. Before we get into the agenda, would anybody be willing to help with note-taking today? If not, it's not a huge deal. We can listen to the recordings later and reconstruct the notes. But if someone would be willing to do note-taking, that would be wonderful. I want to make everyone aware, if you're not already, that recently we've had a change of Area Directors for this working group. So previously Eric Vyncke was our Area Director. So he's here with us today. And thank you, Eric, for what you've done for us so far. And going forward, Tommy Jensen will be our new Area Director for DELEG. And Tommy, I think you maybe wanted to say a couple words?
Tommy Jensen: Indeed. Good to see everyone. I don't think I'm a stranger here. You may note, if you look at the working group page right now, that you'll see an odd amount of my name present. I have stepped down as secretary in DELEG for obvious reasons. I just need to update the DataTracker and I've asked the chairs to select a new candidate for that role because I found it very valuable in prepping me for my first chairing position. And that's something that I'd like to see spread around the community. So if you know someone who wants to get more involved and doesn't know how or would like to learn what it means to volunteer in IETF leadership, send them to Dwayne and Brian, please.
Dwayne Wessels: Yeah. Yeah, definitely. We're looking for folks willing to serve as secretary for the working group. Anything else, Tommy?
Tommy Jensen: Not for me. I'm happy with how this group is running.
Dwayne Wessels: Okay, thanks. So our agenda today is pretty straightforward. We'll spend some time talking about the base protocol draft. Ralph has volunteered to give us a presentation on that. The slides are available. We'll talk about—Paul asked for some time on the agenda for test vectors. And then I'm guessing we'll have—we'll likely not use our whole two-hour time slot here. We only on the agenda here, we only allocated 90 minutes. But we've got plenty of extra time if we need it. I will say, before Ralph gets up, Brian and I, as chairs, think that the draft is getting pretty close to where we can start a working group last call. There's really kind of one main outstanding issue that we want to get consensus on or maybe more consensus on if we can, which is: how does a DELEG-aware server respond to a DELEG-unaware client when the delegation has only a DELEG record? So that's—that's kind of, for us, one of the main sticking points at this point. And hopefully we can have a good discussion here today and then follow up further discussion on the list to get consensus on that. The other thing that is on our plates for the near term is to begin the process of early allocation of code points. Ralph has a slide on that, and so we'll sort of save the discussion about that until the end of his presentation. But that's something that we are working on and will hope to start pretty soon. Okay, I think, Ralph, you're up. Yeah. Okay. Let's go.
Ralph Dolmans: Alright. So here's what I'm going to talk about. There's been a lot of work. I mean, we revved three versions of the draft, and we actually did, after the 08 draft, a couple of additional work that I'm also going to talk about briefly. In addition to the to NS or not to NS, which is the question that Dwayne mentioned, there also were some DNSSEC clarifications and we also have some to-dos which still have to be done. So between the last and this IETF there were a lot of changes to the draft. However, there were no semantic or wire format changes. So we implemented something after 06, and then 07 changed the name of one of the parameters, but it didn't matter because there was no change on the wire. So our implementation still runs as before. There were some bike-shedding, some naming, and a much better structure to the draft than it was before. And also would like to thank the working group because we had lots of people bringing text to us and helping us with how to formulate stuff better. So thanks a lot and please keep that coming. So we did some bike-shedding. And you cannot have an IETF presentation without any AI stuff, so I also did that. We think we now have the final names of how stuff are named in presentation format. DELEG is the actual record that creates the delegation and delegparam is the one that you can potentially point to. And we also, after 08, made, thanks to Roy, a clarification on how we call stuff because there was some stuff called at the parent zone, parent, and child. So there was no consistent naming on that and we now decided that there is a delegation point, which is where the delegation takes place. And then there's a delegated zone that kind of then takes over from there on. And there on that, also, there's a clarification on appearance. So delegparam cannot pretty much appear at the delegation point either if it's NS or DELEG that causes the delegation because that would be bad. And I think one of the best things we did is reorganize the draft. So we now have a much more better reading flow if you read the document as a whole. Because we start with a protocol overview, then we define the parameters, what they actually are, and we also added an operational section and more security considerations. So we are, I think, now also in the document covering what people might experience when they deploy this and what the security implications of that are. So we closed all the issues that were open from 104. I mean, this was mostly examples where we had kind of like errors or stuff like that. The test vectors, I mean, Paul will talk about that so I'm not going to steal his thunder. We also made a clarification on how we think the SPP processing works, and that mainly that the list of servers that you might ask is actually a set. So if you even if you discover a server twice in the discovery process, it should still only have one thing. And we added the mandatory parameter that was just kind of like stolen from SVCB and it behaves exactly like it behaves in SVCB. And also another clarification, the DELEG-aware responder, so if you're an authoritative name server and you get asked with D equals one, you should kind of like set that, but you also should set that when you are asked not with it. And the DNSSEC stuff we are coming through and yeah, the validating change, I think that's part of also what comes into the NS or not to NS. I mean, the thing is if you roll out a new protocol and that has different kind of like stuff than previous protocols, you cannot make it always in a way that the old stuff works with it. And that's a clarification. I mean, if you if you want to do validating change, then change, then you have to they all have to be DELEG-aware. So on DNSSEC, I mean one thing is, and we have maybe a bit too much text in the draft that now says: this behaves as DNS. But we have it in because lots of people asked: well, how will this behave? And the answer was: well, it behaves just like currently. And the AA bit is similar to what we have with DS. So if you ask directly for it at the parent, you get an authoritative answer. Otherwise, you get a referral. And then with DNSSEC, the initial draft said: well, if you want to prove the absence, you have to kind of like make the validator aware that there can be a DELEG record or in future even more records. So we need the DNSSEC key flag for that, the ADT flag. And the initial draft said: well, if you want to do DELEG as an authoritative server, you have to have the ADT flag. And while it is kind of like probably a good thing to have that, it's not absolute requirement because you cannot prove the absence. But you can prove a positive DELEG delegation without having the ADT set because that means that the server and the query and the responder are both DELEG-aware and they can prove that easily. So that was one of the clarification, I think Lieber provided a bit inside on that. So this is the big one now and it is something, one of the reasons or one of the motivators for DELEG was that we would like to have encrypted transport between recursive and authoritatives. And some people say: well, in a distant future you don't want to have any unencrypted connection on the internet anymore. So you only want to have encrypted connections. To have that, you pretty much have to disallow or I mean not have the name server because name server is defined as a name and the only thing that can then use to talk to something is DO53, which is unencrypted. So we think that to enable DELEG to do that, we have to allow delegations without NS in some distant future. And we describe the problems with that operationally and security-wise in the draft now. And it is something even today, so people asked that well, why don't we synthesize NS records out of DELEG or vice versa? And if you think about DELEG today, DELEG today has stuff that really you can't mimic in NS, like the delegparam's include, which kind of like goes to totally different part of the DNS tree to to get some information about that. And we discussed, and there was some discussion on the list, and we think that this is similar to something that is operationally also deployed in the DNS today, that is split-horizon. I mean a lot of people who have laptops from their companies have one view of the DNS that is their internal view and another view of the DNS which is the public view. And this is pretty much deployed today, works, and if they kind of like lose connections to their VPN or something, they can no longer see that internal view that they normally have on their laptops. So it is similar. We describe the problems with it and I think this is what we should do, allow DELEG delegation and not—I mean, the synthesizing if people want to do that, I'm no problem with that, but I don't think it's a protocol issue. So to-do, so there's one thing in the security section we describe that resolver should kind of like take care of not overwork stuff, like especially like when you follow include delegparams, that also can then include Cnames. So you can do indirection change and we have the similar problem that we have with Cnames. And with Cnames, it's currently: yeah, you should not do overwork, but there's no definition. We did a—we put in the draft: well, there's a number, the number currently is three. We can discuss the number, but the question, the real question back to the working group: should we put in a number or just say: well, you should not overwork? That's the question back to the working group. And then going forward, I mean we think we are nearing working group last call, so we'd love that. And we also need to allocate a lot of stuff for DELEG. We need to create a registry. There's an EDNS flag, the DE flag. There's DNSSEC key flag. There is DELEG with the particular interesting factor that there's a draft in DNSOP from Roy Arends and Peter, one of my co-authors, that talks about assigning a range for parent-centric types. And that of course should be best coordinated with DELEG. So delegparam and the EDE and the rest infocode point are probably easy because they are just standard allocations, but the other stuff might be a bit tricky. So I think that was it, right? Yeah, I think that's the last slide. Thanks. Thanks, Ralph.
Dwayne Wessels: Thank you. So let's open it up for discussion on anything that Ralph presented, but also again, particularly, we want discussion on the to NS or not to NS question and we need to get consensus on that. Queue is open. Brian is here with us, but in the interest of not having audio echo, he's said that he'll mostly participate via chat. And Brian is in the chat talking about how we need to come up with some answers or some address what we say about certain requirements H2 and S5, so if you're not following chat you might want to take a look at that and provide any input on that if you have it. It's good that we have two hours, Florian. You're going kind of slow. Yeah. Florian's up.
Florian Obser: Hi, this is Florian Obser, RIPE NCC. I don't think I've ever mentioned this concretely on the mailing list, so about the NS not NS. I think it's—the synthesis part, I don't think it's part of the protocol spec. And I was thinking an informational protocol—informational draft: this is how you can do that and these are the pitfalls, seemed reasonable to me if someone wants to write that. If I'm sufficiently bored, I might be willing to write that. And to the—the overwork number thing where you mentioned, oh, this is unusual. I was joking to you: oh, we can have an IANA registry so why don't we do that? But more seriously, so I'm arguing and you as well that the synthesis should not be in the protocol. So how is this number a—like how is this important for the protocol? Is it a must, it must be four, otherwise the protocol breaks? Probably not. I don't know what the actual word is, is it a may, should? But anyway, so because of that, I don't think a concrete number should be in there. Okay, thanks.
Paul Hoffman: Paul Hoffman talking on two things. Let's do the easy one first, which is: should we have a exact number? They didn't have an exact number in 1034. They said don't overwork. Um, and if they had a number, let's say that the number was five. We would have to decide: do we mean five, you know, for Cname, because that's where the overwork would happen? Do we mean five DELEG hops, five DELEG and or Cname hops, and such like that? I actually started writing that in my—I have a resolver that, you know, sort of a test resolver. I started writing those in and I was really glad when you ripped it out because my calculations were: oh, I had to keep Cnames over here and DELEG over here. I would say no number and I would say, in fact, as you have done in many places in this document where you said: this doesn't change from the old world, I think you can simply say that here as well, which is, you know, 1034 said don't overwork. We're saying don't overwork. 1034 didn't say how to determine that. We're not saying how to determine that because some people will already have don't overwork numbers for Cnames, and it's not clear how they would combine. So like let's not tell people how to do that, let's just alert them. Um, going back to, since Brian's not at the mic, but he's saying things in the chat about the requirements. Um, I said in the chat, and I'll say again here, we've already discussed: does the current way that the document speaks of, you know, not needing NS records meet the requirements? But the—those statements have come at various places in various threads, which this working group sucks as much as every other IETF working group about actually making the subject lines of threads be about what they're talking about. That this has come in many places. So Brian just said he will open up some threads on the mailing list for those two requirements. And that's great because I think, in fact, DELEG without NS meets both of the requirements that he has concerns about, but that should be discussed. I don't think the result of that should appear—assuming the working group agrees—I don't think the result of that should appear in this document because we're still not sure we're going to publish the requirements document. Um, and I don't think that if we say: if this was your requirement, this is okay, because that doesn't help somebody reading this document who's an implementer or is wondering how things go. I think the current, as you said on the previous slide, I think that the current wording that Ted Hardie contributed that helped here really helps a lot. Um, I really liked Ted's reframing of this as an operational consideration, not of a security or a whatever. And it keeps us out of the space of saying: we are different than the normal DNS with shadow zones or all these other things that we had a hard time coming up with definitions in 8499 and 9499 anyways because they weren't there. The less that—that the DELEG spec throws shade on like what everyone else is doing other than DELEG, the better off we are. At some point, if this becomes something where enough people really are pissed off about it, I believe someone can bring it to DNSOP. I mean, this is definitely a DNSOP question of: should you be able to have shadow zones? Um, and if DNSOP adopts the document and decides shadow zones are bad, then they can simply say in that: and shadow zones created by DELEG operations are also bad. And that way it keeps current DNS operations tied to DELEG operations. What I don't want us to do is to look too special. I want us to look like we—or not to look like, I want us to be extending operations of DNS in a predictable, you know, like forward-looking way without breaking anything that is currently done, but I don't want us to look like we're throwing shade on what's already being done because for one thing, a lot of people like them. I mean, I know Joe doesn't, but you know, a lot of people really like that. And if they like doing that and they don't care about DELEG, nothing from DELEG should come in and start attacking them. That's my feeling. Thanks.
Dwayne Wessels: Paul, can I—can I ask you a clarifying question? Sure. Because I want to make sure I understood what you were saying. So when you're talking about throwing shade, you—you're talking about the split-horizon situation?
Paul Hoffman: Correct. Exactly. That if we say split-horizon is bad and therefore we're not allowing it in DELEG, that indicates that everyone else's split-horizon outside of DELEG is a bad operation. And I don't think we should be doing that.
Dwayne Wessels: Okay. I see what you're saying. Okay. But I was confused because currently the draft kind of does the opposite, it kind of, you know, it doesn't throw shade at split-horizon, it says: this happens and we should be able to also...
Paul Hoffman: Well, it doesn't say we should be able to also, it says if you do this, it's like doing that.
Dwayne Wessels: But we're not currently, to my mind, we're not currently throwing shade on...
Paul Hoffman: No, no, but I think that that is one of the things, especially if we go through—which it sounds like we will—that we're about to go through the exercise again of: does this meet the requirements? And the requirements that Brian brought up are: do it like, you know, don't—don't make things that are on the internet not work. And if we say operationally this doesn't work, then we're saying operationally something else that's already on the internet doesn't work. And I don't think we should be doing that. Okay. I mean, I know—hopefully I hope the DNSOP doesn't do it as well, but if they do, we can be part of the DNSOP consideration for shadow zones or whatever we want to call them considered bad. Because we—at this point, again, I mean we might make a change, but at this point we are mimicking the operations. And I think that's exactly what we should be doing. Okay. Yeah. Thanks. Alright.
Dwayne Wessels: Do you want me to talk for the next hour and a half? Sorry. Um, well, I have—I have some questions that I can ask the working group in order to maybe provoke more discussion and—and use our time. So, again to the question of what you call to NS or not to NS, right, currently the draft proposes returning NXDOMAIN, right? Right. Rather than ServFail. So there are a number of options that we had heard presented on the list: NXDOMAIN, ServFail, synthesis, delegation to nowhere, maybe some others. Do we feel like we've, you know, exhausted the discussion on all these options and we're sitting on the best choice now?
Peter van Dijk: Hi, good morning. The I would like to correct you because you said that the draft proposes NXDOMAIN, but in fact the draft says: do what RFC 1034 would do. We don't define it. We just say do it the old way, and the old way accidentally results in NXDOMAIN if you ask for a name underneath the DELEG-only delegation. So it's not us defining the NXDOMAIN, we just say, you know, follow the previous spec, period.
Dwayne Wessels: Thanks for the clarification, Peter.
Ralph Dolmans: Yeah, and to add to that, there was a talk from Wes in IPG, I think it was IPG. So where he looked into the different kind of like failure cases what would happen for that was a split-horizon setup or an invalid thing where you kind of like cannot resolve a thing. And it was clear that I mean a positive and a negative proper answer had better properties than non-answering or sending the delegation into the abyss with NS dot because that caused a lot more traffic and a lot more disruption. So I think the result of what we have in the draft is also the best for the operational thing of the internet going forward. Okay.
Dwayne Wessels: Well, I failed to cause the queue to get long, so shucks. Um, any other discussion on this topic before we I guess close out this discussion and I can say a little bit about the next steps for the early allocation process if if we want to go there? Okay. It's going to be a short meeting. Um, so yeah, the can we go to the last slide here? So as Ralph said, there's a lot of code points that DELEG requires: two RR types, some flags, some other things. And there's all—of there's a different mix of of, you know, processes for allocating these. Some of these are expert review, some are specification required, some are—one is first-come-first-served. Um, but our plan is to, first, Brian and I need to gauge that we have consensus that the specifications are at a stable point, very unlikely to change in the future. And then we'll have sort of a—a formal, you know, call for consensus from the working group that it's time to request early allocation for these code points. We'll get help from the authors for from that. There are some—a lot of this is written down already. There are some specific values requested and so on. The main complication we have here is that this draft is requesting an RR type allocation from a range that formally does not yet exist, right? Roy Arends and Peter and other Peter have a draft that is requesting allocation of a range of types with new semantics, new behaviors. Um, and so we have to sort of just manage this carefully. In my discussions with IANA and the ADs, we think this is all doable. We just have to be very careful in how we proceed and very clear in what we're asking for. So it might take a little while to get it done, but—but we're going to get it done. Assuming again that the working group agrees this is the time to do it. So if you have thoughts about that at this time, that—that'd be great. Otherwise, again, we'll have this discussion on the list to have like a consensus call on starting this process.
Alright. I'm guessing nobody here thinks that this is not a good time to do this and we're all ready for—oh, there's a queue. Peter? Or is that an old hand? Mark? You're in the queue.
Mark Andrews: Um, delegation has—DELEG has implications on the update protocol. Um, I don't see anything in the—in this specification which addresses—addresses that. Um, the things like removing NS records from the top of the zone. That is prohibited by update at the moment. Um, there's discovery of where to send update requests. That is supposed to go to an NS—one of the name servers. Um, traditionally that's been—discovered by NS's, but there's a whole heap of—whole heap of changes that flow through from doing a DELEG zone without an NS record. Um, I'm just saying we need to address—at least address them, go through it and work out what—what breaks and what isn't going to break in update. Okay.
Dwayne Wessels: Mark, thanks for bringing this up. Maybe a question for the authors or the group is whether this needs to be addressed in the base protocol spec or there could be a separate document describing update processing for DELEG? Thoughts or if not we'll have a future discussion on that? Peter?
Peter van Dijk: Yeah, well, it's funny that I found out about this just yesterday and I think that we can deal with that in the same way as with AA bit and stuff like that because in many places we say: well, DELEG behaves the same as DS or creates a delegation as NS, which has implications for data occlusion and stuff like that for update. So I agree that we have to say something about it, but I think that it will be like, you know, one paragraph which says: well, it acts basically as NS for the purposes of DNS update with, you know, some fluffy words around it. But I don't think that we change semantics really, it's more like if you looked for NS now you have to look for NS and DELEG, which is basically the same as the other places. So I think that with small enough amount of work, this can be done. And I don't see a fundamental problem with that.
Mark Andrews: Okay, Peter, you've—you've added code to say that that's permitted, but you can't go from a non-DELEG zone to a DELEG zone with update. The update the current protocol spec prohibits that. Yes. So we've added code to say that that's permitted, but but nothing reference the update protocol to say: this is a change to update. There's a whole heap of things that are going to flow through. We need to go and do a real deep, in-depth look at everything. I'm not sure we've got everything captured everything yet. That's all.
Peter van Dijk: Yeah, yeah, sure. Of course. We have as I said, I realized myself just yesterday, so we have to go through it for sure. But I don't think that there is a fundamental problem. It should be just like, you know, doing the legwork.
Dwayne Wessels: Okay, thanks. Paul?
Paul Hoffman: So given what was just said, particularly that it's the same problem again as what you have with shadow zones or whatever, I propose this not necessarily be part of the base spec, but in fact that DNSOP needs to deal with what's wrong with update already or what—what the holes are because it sounds, Mark correct me if I'm wrong, that it sounds like BIND put a shim in for people are doing this, they didn't notice that there was a problem with update, and that in fact the new what I'm proposing is a DNSOP document talking about update for zones that are atypical would then absolutely cover these atypical zones with DELEG because a DELEG zone that does use NS for delegation will be exactly the same. So instead of adding this in as yet another thing why you might want to consider not doing DELEG without NS, just we leave it with the current wording which is: there's going to be some operational issues. Mark has brought up another operational issue, which I think is important. Updates one of those things that everyone forgets about like Peter did until it's sort of too late, but I think bringing that up in a DNSOP document about operations of update would be a really good thing. That would sort of nudge all of the developers to think about this and I suspect that the result will be um, nothing—no musts and shoulds, but that after that RFC is published there's going to be a whole lot more configuration knobs in all of the authoritative and maybe even the the resolvers. Okay, thanks Paul. Anyone else? Anyone on? Okay, we're in.
Dwayne Wessels: Yeah, we're getting—we're getting close to the end. Um, there's a little bit of activity in the chat. David, do you want to—we have lots of time. David, do you want to ask your question under AOB?
David Lawrence: Uh, sure. And are we at AOB right now or? Sure, we are. Okay. Yeah. So basically, one of the to-dos that we had outstanding was about if you have a DELEG-unaware resolver that sends QTYPE=ANY to a DELEG-aware auth, how should it reply? And there is already a section that says how it should reply in the case of a DELEG record depending on other data in the zone. What I—would is it helpful? Should like Peter often likes to completely reasonably defer to just do what the existing DNS does, but since we already have this special section that says here's what you should do if you get the explicit QTYPE=DELEG, what about if you get the metaquery ANY and your server that responds to ANY? And I think that we should probably call it out, but if for some reason we should not call it out, that's also another good thing to hear.
Dwayne Wessels: Thanks, David. If anyone has thoughts immediately, you know, jump up. Otherwise, we'll track this as a something to still discuss on the list.
Mark Andrews: My—my thoughts would be that if there is an NS record there you return a referral, if there isn't an NS record there you return the DELEG.
Dwayne Wessels: That's basically what 5.2.2.2 says for QTYPE=DELEG. And so presumably if there's a delegation point you shouldn't return the other occluded data with ANY, you would just treat it exactly like a normal ANY query.
Alright, thanks for that. Brian, do you want to have any closing words here? I know that you've been busy sending emails in the background. Maybe you want to draw people's attention to that or something. You just want to hear the disembodied voice from from afar. Yeah. No, I've started threads on the mailing list to see how we want to respond to the requirements and I will say here that we do have them broken up as hard requirements and soft requirements, so I am far more concerned about H2 than say S5, but we should be able to articulate why we think we satisfy those requirements if—if that's what if that's what everybody believes. And I think that is something that can either be a part of the the base spec as a as an appendix or it can be a part of the shepherd write-up when we do advance it to to the IESG. I think either approach works. But we could talk to our newly minted AD to see how he wants to see it presented to him, but that's—that's a discussion for a little bit later once we've once we've figured out what we want to say. So I think other than the making sure that we we work through the the early allocation process, we are close to having a working group last call. We've gotten a couple of early director reviews and I think we've done a good job of responding to those. So we now need to start thinking of getting this document at least into working group last call so we can we can start moving forward on other other work items. Yep. Yep.
Dwayne Wessels: Alright. Thanks a lot, Brian. I think we're done for today. So thank you everyone for coming and participating and hopefully you'll enjoy your free time before the next session starts. Alright, thank you.