This is Andre Suri, he will be telling you about the long history of byte 9 and I guess the continuing history of byte 9. Yeah, hopefully. Okay. Thank you. Hi, I'm Andre and I've worked at ISC since past year. You might have known me from CZNIC working on another DNS server, but that's the past. So let's talk about byte 9 now. By now, byte 9 started in 2000 and the other things that came from 2000 GCC 295, do you remember it? Linux kernel 2.4, GNOME 1.2, QT2.0, Windows 2000. It was the first camera phone, really. PlayStation 2 has launched it and new century started, well, only in pop culture in US. The rest of the world waited one year. So the history for byte is really long and as you can imagine, there's a technical debt. So these are the versions we had since 2018. And sometimes there was quite a lot of versions that the ISC had to support for some years. And there's quite a lot of maintenance burden. So we are trying also to change this and I will talk about this further. So now comes byte 912 that was released just last month. And it supports the new shiny things like and aggressive views that Petra from CZNIC will be speaking about in some next presentation. This was a response to it. If you remember the attack at Dyn where everything went black. So this is like stretching the TTL. If you can't reach the alternative servers, it will stay in the cache for a little while longer. There's an update in the response policy interface for response policy zones. Also major effectoring has been done on some, the most complex function. Somehow there's a link on this screen, but not on this screen. So if you look at the presentation in the archives, there's a link for the presentation from my colleague Evan Hunt. He gave on the DNSO arc about the effectoring done in 912. And I invite you to look at it. It's quite interesting. So and the effectoring also made us made it possible to speed up the bind by factor 6 for some cases. There are CDSC DNS tools contributed by Tony Finch. He's one of the biggest contributors along with Red Hat for bind source code. And there's a EDDSA support when available in open cell. And it's only in the development versions now. But once it lands in open cell, it will be available in bind as well. So let's talk about the future. There are a couple of things we want to do also for you as a DNS community. We want to make the development more open. Some steps have been already taken like opening the Git repository. The bug database is sort of open, but the default is confidential. And it needs a person to go and click move this to the public queue. And as you might imagine, it doesn't happen so often because it's an extra step. You need to think about it and sometimes you forget. So we will try to do better in the open development because I think this is important for the open source community and also for the DNS community to develop in the open. We want to have a faster release cycles. And well, along with that goes to reduce supported platforms. And also I will show you some new features we are planning and refactoring. So the open development. It will open the issue tracker by default. We will make it possible to have a public merge request, public wiki, public continuous integration. So everything that's possible. And it's not a security bug. You know this is bind. Security bugs might happen once in a lifetime. And in the future, along with the email mailing list, we would like to have a public web forum to discuss bind and maybe DNS in general. So I'm announcing this here for the first time. There's an IC GitLab running at gitlab.ic.org. Surprisingly, it's a self hosted instance and it's a work in progress. So not everything might work as expected yet. But we will be deploying this during February and making this our main development platform. So you are all, if you are interested in bind and helping with bind, invited to join our GitLab. And you will be able to fill new issues there, fill merge requests. And the usual stuff you would expect from an open source project. I'm speaking very quickly, I think. So I will have to slow down. Otherwise, we will be... Yeah, I will slow down. So again, the faster really cycle. This is something we decided already. So the odd numbers will be the development releases. And they will be released as we go and as needed. So 9.14, 9.15, 9.17 will be the development release. This is similar if you know what EngineX does. And the support for those releases will be best effort. So if you write a bug, we will fix it in the Git and release in the next cycle. That might be monthly, that might be quarterly. Depends on the severity of the bugs in those releases. So from those development releases, once the new features stabilize, we will spin off the stable release that will be just bump the number. And so from 9.14, the last release 9.14 will turn into 9.14. And this release will be supported until next stable release, which will roughly translate supporting it for any year. And then every second stable release will be the so-called extended support version. That will be supported for four years in total with some overlap. I think this is much better shown in the table. So if you look at the table, now this is 2018, this column. So now we have version 9.9 ESV. And there will be end of life for 9.9 and 9.10 this year. So 9.11 will turn into ESV. And it is a sort of exception before we switch to the new development model because it will be supported for six years in total. So the blue squares are the extended support version like years. So only a major bug fixes and security errors will be fixed in the extended support version. And the purple is the security-only support. So this is the one year it overlaps. So if you want stability, you would be using the ESV version. And during the last year, you would have to switch to the next ESV. And for the development release, this is 9.14, this is the orange box. And it will switch to being stable next year for 9.14. So 9.14 will be supported only for one year. And so it goes on indefinitely. So the inner decision we had to make because buying supports almost anything. At every start of the re-cycle, we will evaluate the life cycle of the major learning distributions, BSDs, and selected property operating system like Mac OS X, Windows, Solaris, maybe. It also depends on what system we have access to because it's hard to support something we don't run in our labs. So at the beginning of each re-cycle, we will say we will support these distributions and it will stay this way. So there will be a list for each release and you will be sure that nothing will break during the re-cycle. So any breakage could come only at the beginning of the re-cycle of each major bind version. And there will be several tiers. So the supported tier, this basically means we will patch it. If you send us a bug report, it doesn't work. We will fix it and we will patch it. And there will be best effort here. So it basically means if we have a time, we will patch it. It will be better if you send us the patch to support your favorite platform if we can. And if we can, we will incorporate the patch. And then there will be non-supported tier. So this means don't even bother sending a patch unless it's like an easy fix and it doesn't break anything else. So there's no guarantee that this will be incorporated if you send us a patch. So basically the reason why we want to do that is that this new list of the support platform will allow us to fully utilize some modern language standards. Because now bind 11 can still be compiled with the GCC 2.95, which I don't think is reasonable in 2018. So the LibIC, there is a whole set of libraries that are full of wrappers to fix the bugs that no longer exist in modern operating systems. So we should rely more on standard libraries, use the POSIX, use C11 language contracts. We will stick with the subset that's supported by Windows to just make things easier for us. And so we don't have to have some wrappers around it. But the visual compiler subset is well mostly complete. And for the things we want to use, we should also use external libraries that are appropriate. So not reinvent the wheel and focus on the things that's important. And the important thing in DNS server is the DNS, not the supporting library. So basically the reason is that the code base of bind is so huge that we need to reduce the code base. We have to maintain in bind to really have time to focus and maintain the DNS protocol. So some of the plan features for the development for this year is a local root zone copy, RFC 7706-like implementation that has been sponsored by ICANN. We also plan to add modules and hooks interface in bind. So this will allow us to do a few things. Well basically this means that you will be able to load your own dynamic module into the query response processing and modify the data that will be sent to the client. And it will also allow us, as I see, to refactor some non-core functionality into the modules and make the core, the bind core lighter and easier to maintain. So this is the main feature. So every DNS server will be mining nodes and it's called DNS smart contracts. And as you know, the DNS cache is a permanent storage if you haven't seen it. Again, there's a link for Jeff Houston presentation about the zombies in DNS. And the IC stocks will skyrocket of course if I show you the slide. This is of course a joke for the record. So the other thing we would like to do in the future is refactoring. I was surprised that this is a quote from Antoine de Saint-Exupéry. If anything at all perfection is finally attained, not when there's no longer anything to add, but when there's no longer anything to take away when a body has been stripped down to its nakedness. And I think that this applies to bind because the code base has grown a lot in years and it needs to be refactored and make it simpler. So the functions needs to be split and refactor and then this is something we really ought to do and we plan to do. So basically, I want to say that the bind is not dead yet, baby. Bind is not yet dead. Thank you. So if you have any questions, please go ahead and please state your name and affiliation so I know the context if you ask a question. Okay, a spawn of the evil. My name is Nezane. I work for Oracle Dine. No speaking for Oracle Dine. So I like the new release structure with the odd releases being chaos and the even ones being controlled chaos. But one thing that's happened, there was a time in the distant past when I was involved with bind 9 where we tried to not add changes to release versions. That kind of went away because I didn't have enough control over the developers. It would be nice if the even versions didn't introduce new features or change syntax or things like that. As an operator, it's quite frustrating when you put in what you think is just a security fix and all of a sudden you have to go through all your configs and double check things. That's basically the plan. Okay. And because if you look at the release cycles, they are quite short. It's just one year. The reason I was confused is because you said in the purple it will be only security fixes, which to me implies that all kinds of other weird stuff. No, it is like the blue is like the major backfixes. And maybe adding new records or stuff like this. But yeah, the developers are always the problem. Any other questions? Do you also provide, for example, the packages of the development versions? Do you used to love DBN, but the packages in DBN itself are quite old? There are several stuff that happened. I became the maintainer of the DBN package in DBN. So this will be hopefully in much better shape. And there are already experimental repository for DBN for 9, 11 and 912. But we haven't announced them yet because they are running on packages.suri.org, which is not. But if you want to try them, then you can go to packages.suri.org slash bind. And there are experimental packages that even change the packaging structure. So really don't deploy them in production yet. Mind coins. Yes, and the mind coins. May there be packages which I can use in production? Yes, there will be. But I did this like 14 days ago, so it needs to be put through some testing at least. I'm running this on my servers, but I'm not a good tester. I'm good at breaking things, but I'm not punctual enough to be a tester. So this needs to be put through testing. And then IC will announce the official repositories for basically these three class, the stable ESV and development. There will be like three repositories that could be used by external people. And that's not all for DBN. We plan to have a redhead sent off to repositories as well. And that's also work in progress that should be available soon. I think that Peter there helped. I noticed on your GitLab it's not possible to view any of the things that you're not loving. Will that change? It's a little thing down below at the door. Oh, wow. Can you tell us what just happened there from the screen? Oh, but Peter asked that something is not visible in a GitLab, the IC GitLab. And the response from the audience was that it is there, but you need to find it, well, look it for a harder. Go ahead. I don't know. Honestly, I don't know. Well, my goal at the moment is to stabilize the thing and make it more sustainable. And adding more exotic features goes against that goal. But if the exotic features is interesting enough, then it might happen. Also, we might have a contrived repository for modules contributed by other people because they are already. And also, the reason why we opened the GitLab is to invite more people to be involved with his bind and to be more open to the things we accept from the public. So to answer your question, I don't expect it to happen soon, very soon, from the ISC. But if somebody comes and says, hey, I wrote this school module, could you put it somewhere at the ISC GitLab so other people can find it, then yes, the answer would be yes. Sorry, I have to stop. One last question? Yes, sure. Would the ESV version be released in January, February time? I'm working on a column to release this in April and then... You mean the 9-11? Not the 9-11, but the 9-16, for example. Do you aim to release that in January time? We are not there yet. But basically... We are. Well, that's a good question. And we might talk to more maintainers about this, how it would be best for Canonical for the BN. That's the question I need to answer myself. And for Red Hat. And probably others, but I think those are the major ones we need to take care about. Okay, thank you very much. Thank you.


Hey there, I wanted to share my vs setup with you. Sorry, this isn't in a doc or easy to digest I've got a short amount of time before I go out and leave tomorrow So I thought I would just quickly show you what I do so First of all, I'm showing you my command prompt. I use a thing called commander I don't use the built-in PowerShell UI just because I love to have tabs Although I've heard that Windows 10 is adding tabs soon I work with Repos in the ace peanut core github organization and I'll show you how I use vs on one of those which is called the extensions repo In this repo. We have a file called start vs This is something that we found was necessary because we are dogfooding early builds of dotnet core and we have to set some environment variables to teach vs how to actually launch Or how to use new versions of dotnet core That's something that would be nice to see improved in visual studio in the future But I think most people outside of Microsoft probably won't care too much about that because they use stable releases of dotnet core Which usually just work fine I'll show you first my window layout and then I'll go over some of the extensions that I typically use I'm also actually a pretty heavy vs code user So I like the consistency of having solution explorer on the left that aligns with how things work when you're in vs code I I Let's see. I always keep the test explorer hidden over here and only pop it out when I'm running tests Use task-grown explorer. I don't use it in this repo But I use it in some of the other ones that have like npm tasks that I need to run more often I also use an extension called build logging when I'm debugging things in the project system This produces bin logs, which are super useful. Let me actually show you some of the full list of extensions. I have Okay, so this is the thing I just mentioned the project system tools as I also mentioned they use vs code quite a bit So I like to launch that We use editor config in our team. It's nice to have some intelligence there As I'm looking at these I realize these are created by Mads Let's see I Occasionally do markdown editing in visual studio, but to be honest, I've mostly done that in vs code lately This is my favorite extension add new file I Really love how simple and easy this one is to use if you haven't used it You should give it a try basically you can just do I think it's shift f2 And it asks you the file name and based on the file name like dot CS or to h2ml or things like that It infers which item template you want to use it's a lot easier than needing to right click Go to add a file navigate in the UI to the right template I love that I can do most of that through the keyboard. I Use live share quite a bit when I want to share my environment with other people I occasionally do pull requests from the GitHub extension, but to be honest it's mostly done through command line these days and I think that's it. There's some other ones that are just installed by default that I don't use like the snapshot debugger Anyways, I hope that answers your questions. I hope you're able to use this somehow Feel free to ping me on Twitter if you have any questions about this. Thanks much