 Hello, welcome by the Koordinus deep dive. My name is Mikriven. I started Koordinus in 2018, I believe. I'm still the project lead and I'm, of course, maintaining Koordinus. I'm here with Jom to talk about Koordinus and some details about plugins. Jom, can you introduce yourself? Sure. Hey, everyone. Thanks for coming to this session. My name is Yang Tao. I'm a maintainer of Koordinus. In today's Koordinus session, there are several things we want to cover. First, we are going to give a brief introduction about Koordinus. And then we are going to discuss about the project update and what features has been added since last year. Next, we are going to discuss about the survey discovery with DNS and how Koordinus can play an important role in this field. Next, we are going to showcase a small plugin. And finally, we're going to discuss about the Koordinus community as well as a Q&A. As many of you know, Koordinus is a flexible DNS server written in Go. It has a focus on the discovery. One interesting feature, one interesting thing about Koordinus is that Koordinus is plugin based, which means it can be easily extended. If there's any new feature you're interested, you can always add new features yourself and then you'll know how to write in Go. Since Kubernetes is 1.13, Koordinus is in the default DNS server, which means nowadays Koordinus is used by many people and many institutions around the world in production systems. Koordinus has many features. Koordinus support DNS, DNS over TOS, DNS over JRPC. And also, Koordinus has a wide range of support for cloud DNS data sync up. For example, we have AWS ROK33, Azure DNS and Google cloud DNS sync up. Okay, now let's come to the project update. Just last year, we have released 1.8 of Koordinus. 1.8.0 was released on October 22, 2020. There are several plugins introduced in 1.8. Transfer plugin unifies all-zone transfer code. Local plugin answers local queries. And finally, minimal plugin provide minimal answers, which could be very, very useful if you want to reduce the traffic of the DNS response. In 1.8.0, there are also several backward incompatibility changes. In transfer and DNS type plugins, if you're ever touchable to plugins, you probably want to take a look to make sure your update will configure file in case of the need. And also, we have some other new upstream features in Kubernetes plugin that you want to take a look, since like endpoint slices could be very useful. I'm going to discuss a little bit about server discovery and the code DNS. As many of you know, in this day and age, you have a DN which can give you all kind of ability for networking. With a DN, you can assign any endpoint to any IP address as needed. So some people ask the question, is DNS still needed? There are several reasons DNS is important. First of all, DNS is nice in direction, and this is in direction you probably want when you deploy a production system. This in direction give you the maximum flexibility, and it's easy and simple to change. The reason why the flexibility is important is that as your company or your system grow, you probably face a question of scale up over time. When you try to scale up, DNS give you a very nice tool to achieve that goal. One interesting setup with database is that in many enterprises, the database has been configured in a way such as read write and read access point are separated. This gives you the ability to scale up as needed in the future if you have more customers and more customers that are reaching to your read only database. But when your startup is small and you want to get started, you can actually set a DNS to be pointing to the same IP address. Essentially only need one database, but when your database, when your user base is getting bigger, you actually can just split up the read write endpoint with a read endpoint, essentially scaling up nicely without any interruptions. This brings another feature of DNS. DNS is distributed in nature and it scales to internet. And finally, DNS is important in that DNS is very pervasive in IT infrastructure, even if you have your IT system admin that's still maintaining a legacy system, they still probably need DNS anyway. Many people ask a question about if there's a need to set up a DNS server yourself. While nowadays you have a DNS service provided by cloud vendors, sometimes you may still want to consider about if it's needed to set up a DNS server. There are several reasons for that. DNS is a critical service, but at the same time it's simple. DNS has different uses for public facing where you need your customer, your customer may need to reach to you. DNS, it also could be internal, which means your service will need DNS to find another service endpoint. For DNS, the core DNS has a diversified source of information. With core DNS, you can consolidate different sources, like Kubernetes, like the cloud vendors, like IT infrastructures, all those DNS records can be consolidated into one DNS server that's called DNS. And finally, while all the cloud vendors are supported by the DNS service, and all cloud vendors claim that they have 100% SLA. This 100% SLA could be misleading. While the SLA has been specified with 100%. The money you spend on DNS service for those cloud vendors are actually very small, which means in case there's a service interruption, the service credit refund you're going to receive is also going to be very small. I'll just give my personal experience, which the company I worked for. Last year, we have a downtime related to AWS Office 3. Of course, after the downtime is over, we request a service credit, but to our surprise, we only get less than 50% of the money back. Of course, that's better than nothing, but it does not help us anyway. And that actually is one thing we are currently exploring. That is, we are considering about the set of our own DNS server, potentially with core DNS, because DNS is too critical, and we cannot afford to have a downtime with no service credit refund guaranteed to recover our financial losses. Okay, I'm going to hand over the slide to Mick. Mick will go over demo planning for us. Yeah, thank you. We're going to look at a small plugin, the demo plugin, and basically, depending on the client source address, it will reply with IP 1111 or IP 888. So it makes a tiny decision and then writes back this reply to the client. So we're going to see how we're going to set this up in core DNS and how this all works from code to actually running this. Next slide, please. So if you want to write a plugin for core DNS, you need three methods for three functions to be implemented. An init function, which basically tells core DNS that this plugin exists, a setup function that takes a catty controller, which is basically the core file, the config file that we have. It parses the configuration and sets up internal structures. It adds a handler to the config object, which is internal state in core DNS that not only does the plugin exist, but it's actually used in the current process. And these functions are called ones for each plugin in the core file. And the most important method is serve DNS, which is actually the meat of the plugin. It takes a context, a DNS response writer, which is basically the client calling into core DNS, and a DNS message, which is the request. The DNS protocol also uses the same, well, the library we use also uses this structure to write back to the client. This function, though, this method returns to values and into an error. The int is basically a signal to core DNS if something has been written and an error is returned if something goes horribly wrong. Next slide, please. So at the top of this slide, we see the init function, which is fairly simple. We call plugin register with the name of this plugin, which is demo and setup, which is the setup function that we have, which you see below this. The setup function itself, as we saw on the previous slide, takes a catty controller. It's fairly simple because the demo plugin doesn't use a lot of configurations. It's just demo in the core file. So we skip that word demo. We don't expect any other arguments if they are rewritten error. If it all looks good, we will tell core DNS that this plugin needs to be added to the plugin chain for this server. So we can run the demo plugin. And we return nil, saying there are no further errors. Next slide, please. So as said, the server DNS method is the meat of the plugin. So this thing needs to check what the source IP is, and then basically make a decision on what to return to the client. State will get some handy struct you can use. In this case, we will get the query name from the client question, which is used in the login you see the printf later down. You should reply to 888 because that's the default that we want to return to all clients, except if the client source IP starts with 172, or the client source IP starts with 127. In that case, we should reply to 1111. And something not shown here, but we will then make another DNS message, put that stuff in there, and we'll write that back to the client. So depending on your source address, you will see 888 or 1011. And that's basically it. Next slide, please. We're going to use a demo. So we want to write a core file. The core file that you see here says that it's authoritative for dots. We're running on a port 1053. We don't have any other plugins in here, except the one that we got showcasing, which is demo. So this is all that we need. We save this under the name core file. And then we can next slide, please. Next slide, Jo. Yes, thank you. Then we can compile coordinates with our new demo plugin. To do this, we need to add demo to plugin.config and then either build a docker or do a go generate and a go build. And then we will hopefully give you a coordinates binary. And if we just start dot slash coordinates, it will pick up a core file in the current directory, which we just made, which will be a coordinates on port 1053 with our demo plugin. If you would now query, we would see either returning 1011 or 888 depending on our source address. This plugin is online in the Core DNS organization on GitHub. And the documentation can be found on Core DNS IO in the X plugins. And with that, I want to hand back to Jung, who's going to tell a bit about the Core DNS community. Thanks, Meg. Okay, I'm going to discuss about the Core DNS community. As of now, we have a 307 contributors. Big thanks to everyone who contributed to Core DNS repo. We also have 26 maintenance and this number is increasing. I'm going to discuss a little bit about how to become a tenant later on. We have 32 public doctors so far. And we also have 8,000 stars for the moment. Which is a bit of a treatment, by the way. For the past several years or so, we have coding has been engaging in several programs. The first program is UFX by Link Foundation. UFX program originally was named Community Bridge Program. For the past three years, we participate in this program and this program generally has several interesting plugins. As you can see, we have a Google Cloud DNS plugin, which actually is one of the different plugins as of today. This year, there's also another student that's currently working on ACME support, which is a very interesting feature that has been requested by the community for a long time. We hope this ACME support can land this year. Another program we participated for the past several years is the Google Summer Code. There are also several plugins that's very important to code DNS has been landed in this program. The DNS type plugin is used by many nowadays in production systems. The ACME plugin has been used by many people at will just to give a very easy to set up a firewall type of access control. And the last year, there was a student wrote a machine learning based DNS threat detection, which actually could be very fun and easy to see. Finally, I'm going to discuss about what you can do if you want to be involved in the community. The first thing you can do is to start coding as in GitHub if you haven't done so. As I mentioned, we have 8,000 or so stars now. Nowadays, stars is the most important thing. So if you haven't done so, try to start in coding as the second way you can help coding as is to add the name to adopt a style that be the if your institution or enterprise use coding as and if your institutional enterprise does not mind to share the name, you can add a greater pull request, add entry to adoptive.md, which will give a bigger list of our public adopter as well at the same time, allow you to be the coding as contributor, which is the nice thing. And also, if you're interested, you can participate in GitHub or Slack channel discussions in Slack, the channel name is coding as slack.cnsf.io. You can also create a PR to become a contributor. As I mentioned just moments ago, if you can add entry in adopters.md, you already became a contributor. And finally, you can also consider to be a maintainer as well. In order to be a maintainer, you need to have one significant pull request to be merged. And at long you can find, you can get one pull request merge, significant pull request merge, and you can find a maintainer to support you. We will add you as a maintainer and this coding as maintainer will be, will be kind of like, like a nice badge for you and help you to advance your career and hopefully to get more recognition from the community. I think that's that's it for today. So next we're going to discuss about the Q&A. If you have any questions you can ask out.