 OK, first of all, thanks for coming to this session. My name is Yang Tang. I'm a maintainer of Coding S project. John and me today is John Bellamurg. He is a committed member of Coding S project, and we'll join maybe with John. OK, yeah, in today's session, we are going to discuss several things. First, we are going to discuss about some community update of Coding S, as well as interesting progress in some of the features that have been recently added. And then I'm going to introduce a little bit of survey discovery at the Coding S and show an example of how Coding S can be used to consolidate the different information from different cloud vendors. And finally, I'm going to do a deep dive of Coding S and go through a demo plugin that allows anyone with the knowledge of Golang to write a Coding S plugin in potentially like less than 100 lines of Golang code. And also, by the way, if you have any question, you can certainly raise your hand. I'll try to answer as much as possible. And also, John is here. Maybe John can answer some more questions as well. OK, let's first discuss about Coding S. So as many of you know, Coding S is a CNCF project. It's a flexible DNS server written in Go. And like other DNS servers, DNS project, Coding S has a focus on survey discovery. It is a plugin base, which means it can be easily extended. In other words, if you have any features you're looking for, you can either look for external plugin or internal plugin, or if you know how to write in Golang, then you can write a plugin by yourself. One of the most important features of Coding S is that Coding S is a default DNS server in Kubernetes. So I guess anyone using Coding S, anyone using Kubernetes, probably will use Coding S by default. In addition to be served as a default DNS server, Coding S also support different protocols. It supports DNS, DNS over TOS, DNS over GIPC. It also supports additional protocol like DNS over ATP. In addition to those different protocols, another thing Coding S excels with is consolidation of different cloud-related DNS information. For example, with Coding S, you can sync up with the AWRF history, you can sync up with Azure DNS, or you can sync up with Google Cloud DNS. That gives you plenty of flexibility and allows you to consolidate it in case you're doing a multi-cloud deployment. And finally, Coding S was started by Mikjibon several years ago. As of recently, Mikjibon decided to step down from the project lead position. So we changed the structure a little bit. Now Coding S is organized as a community-based organization. So this is a project Coding S update. Since last Kui Khan, early this year, there are several version has been released from 1.9.3 to 1.10. The latest release is 1.10.0. It was released last month. There are several plugins has been added since last Kui Khan. TSEC and the VIEWs are both interesting plugins, especially for VIEW. The VIEW plugin is highly sorted after plugins requested by many community members. It is a feature that has been supported by other DS servers. So finally, Coding S will be able to bring this feature into the default plugin so you can give a try if you're interested in the VIEWs. We also have for the past several months, we also stress a lot of focus on security. As many of you know, for the past several years, security has been a big concern for tech industry. Since several years ago, it seems like a ransom attack, like the log4j, and also for increased security related events that all put everyone to be on high alert whenever there is a security event or whenever you are using a software that can be exposed to vulnerabilities. We fix the two issues that's actually related upstream now to the coding itself. But one is related to Golan's crypto library. Another one is the YAML package. And another thing that's related to security is that since 1.10.0, coding has been built with Golan 1.19 or higher. Why is that so important? Because I believe in 1.9, coding has still built with, sorry, a little bit of distraction with the background noise. In coding as 1.9, earlier on, coding was built with Golan 1.17.6 or early. And unfortunately, Golan 1.17.6 or early consists of quite a few security issues. So because of that, I highly encourage everyone, if you're using coding as a please, please upgrade to the latest version to make sure your only usage is not going to be subject to security vulnerabilities. Here is the summary of coding as community progress. As of right now, we have 300 and 302 contributors. A big thank to everyone who contributed to coding as a repo. We also have 28 maintenance. I'm going to discuss about how to become a maintenance later on in this session. But coding as by itself is in a very much flat structure. If you contribute enough, you can easily become a maintenance. So I also encourage everyone who has interest in Golan. Maybe you can give it a try. We have 33 public adopters. Those are the companies or institutions that are willing to share their name and make their name public. So those are the adopters. We also have 9,800 stars. As you can see, it's closer to 10,000. So let's make a finishing touch. Let's try to reach to 10,000. No, so. As I mentioned earlier, Amig decided to step down from the project-lead position earlier this year. So after some discussion, we reorganized the coding as so now it's in a still committing model. Every committed member will be reelected. You have to become a maintainer to be considered as a candidate for a committed member. But like I said, to be a maintainer is very easy in coding as a community. So if you are willing to give a try, I highly encourage you to do so. Let me see. OK, so next thing I'm going to discuss is about survey discovery with coding. Why I bring this topic about survey discovery. In many cases, even as of right now, every time I discuss about DNS with someone, I always heard a lot of questions about DNS. The first question is that, OK, in this day and age, you have the SDN. You can even assign an IP anywhere you want. So what's the purpose of DNS? Why do we still need DNS? And I see this question as a valid question, but there is some logical reasons. So DNS is a nice thing you want to use. So first of all, DNS is an indirection. And this indirection is something going to help you in the future. With SDN, you can easily manipulate in IPs. But even as of right now, it's not exactly straightforward to always modifying the IP. For example, your IP might be associated with one cloud vendor. Now, if you're going to move from a Google cloud to AWS or vice versa, you may not have a lot of freedom to move public IPs easily. In this case, a DNS can help you to shield away from the IPs that are not so easy to change. But you can expose your customer with a DNS entry that will always be available. And so that your customer will only need to reach to the DNS name that will not change over time. And also, DNS is flexible. You can use different ways to configure DNS. You can use cloud vendors DNS. Or you can use code DNS locally. You can use a bind file. Or you can use some other things. Another feature of DNS is that DNS can be both public-facing and internal. That can be very useful in many organizations. In case you have a VPN, and you don't want to share public DNS record. Another feature of DNS that's very interesting is that DNS is easy and simple to change, yet DNS itself is distributed. What does that mean? Because DNS by itself is a massively scalable distributed system. Many people didn't realize that because the whole internet is backed by DNS, right? And also DNS, I guess most of the guys here actually in the SIE or DevOps organization or interested in Kubernetes or infrastructure. But there is another field, like IP organization. They also need to have a way to expose services. And the DNS, it's more like a bridge in between infrastructure guys or SIE guys and the ID guys. So it's more like a communication channel. So they can share the same interface, exposing to both corporate ID and to infrastructure that's exposing your service to your customers. We discuss about a code DNS and how code DNS can be deployed with a multi-cloud. So why multi-cloud deployment can be interesting and can be useful? And there are several reasons you want to use multi-cloud. Not necessarily say you have to use, but there are several reasons you may want to consider. One, you may have a limitation on data sovereignty and the data residency. As we all know, now different countries have different legal considerations. And a different country may put a lot of restriction on what kind of data can be exposed or how the data should be read into certain countries. And in this case, you may not have a choice with respect to certain countries because not all the cloud vendors are available in certain countries. Another thing that's actually come to me is that I realized that a multi-cloud deployment might be a necessity if you ever engage in merger and acquisitions. I know that may not be a very pleasant topic, but with a potential economic slowness, I mean, it might be a conversation you may encounter if you happen to be in operations or happen to be a devout. If a company has been merged or one company is quite another company, you may notice that the choice of which vendor to use does not depend on just one vendor. You may be forced to operate on multiple vendors. And after the MAA has been complete, it may not necessarily be true that you have an option to always migrate from one vendor to another because of a cost issue. If you try to talk to a CEO, say, hey, our company acquired one company, but this is the other company. Now it's one company, we have two vendors. One is AWS, another is Azure. Sometimes your CEO may not be willing to spend a huge resource or money to say, hey, let's make a move from one vendor to another because there's no additional revenue or no additional benefit other than just give you a slight advantage or simplify simplification. Sometimes your CFO or CEO may just say, hey, you know what? Let's just leave it alone. And in this case, unfortunately, you do have to come up with a multi-cloud strategy. OK, another thing with multi-cloud is under CodingS. CodingS fits a gap of multi-cloud deployment because CodingS can consolidate diversified information. And you can consider CodingS as more like a single source of truth with different DNS information scattered around in AWS and Google Cloud or Azure as well as the ID infrastructure and some local Kubernetes clusters. That's why CodingS can easily fill in the gap, allow you to work in a heterogeneous environment. And finally, some people may argue that because nowadays everyone is talking about cloud. You may want to just use a cloud vendor's DNS solution. For example, you can use rough history. Why would you want to use your local DNS? But there is one important thing that's actually from lessons I learned for the past year or so is that as of right now, as far as I know, all three cloud vendors all claim to have 100% SEO for their DNS service. Rough history, Google Cloud, DNS, and Azure DNS. However, the SEO is kind of misleading. What does SEO mean? SEO does not mean if there is, let's say, a breach of the SEOA, let's say there is a downtime. What's the outcome of this downtime? The outcome of this downtime doesn't mean AWS or Azure or Google will reimburse you your loss. It only means they are going to reimburse you the downtime of DNS service you paid during that period of time. Now you'll probably get the idea. I think last year, or maybe early this year, I cannot remember, the company I worked for has downtime due to one cloud vendor that I'm not going to reveal. After the downtime, we come to the cloud vendor and say, hey, that's not acceptable. DNS is a highly sensitive service. What's going on? What should we do? Oh, we are going to reimburse you. Fortunately, the money we spend on DNS is like $100 during that period of time. And the offer was like, OK, do you guys want us to reimburse you the $100? Or do you guys want to give you some Uber gift card? But that was a conversation I had early, like a year ago. So as you can imagine, why you have to treat DNS very seriously and you cannot always count on cloud vendors? Because that's always misleading. So that's why at least for the company I work for, we are in serious discussion about the potential set of DNS server ourselves with additional backup plans. So at least we can control what's going on. We don't need to wait for cloud vendor to fix some critical issues. OK, we talk about the multi-cloud, we talk about DNS. Another thing I'm going to discuss is about how we can see coding, why coding can be a great choice if you're going to do a cloud integration. I mean, because many people may think, OK, if you're going to do the cloud integrations, what the coding is through? So when coding is through cloud integrations, instead of using UDP transportation, we actually use a secure communication, like ATP. So if a coding has a need to fetch information from Roffit history, it will go through AWS API in ATP S. And the data will be transferred through TCP. The only UDP part is actually the front end of coding S. If you send a query to coding S, coding S, you will receive your UDP query, and it will pass the information to Roffit history, so secure ATP, get the information back, and send back the UDP response. So why this is a better model? Because it's much secure, and it's reliable, it has better error handling. And more importantly, we realize that in many situations, even though UDP has been simple enough, TCP might give you a better optimization in many situations. That's because now there's not a lot of people using UDP. So all the optimization at a different level, at your kernel level, at your hardware level, may have been geared toward TCP, because nobody care about UDP. I'm going to give you an example. This is an example I talk about, how you can connect coding S to allow coding S to connect to multiple cloud vendors and serve as one frontend. In this example, the coding S, behind coding S, there are three types of information. The first is Roffit history. You can set up your Roffit history in certain records. And then another part is the Google clouding S. So let's imagine you'll deploy your services in Roffit history in AWS in Google cloud. And also you have some additional information locally. That's actually served by your local DNS server or maybe your buying server, or maybe your DNS, maybe coding itself. And in this case, you want to consolidate the information. You want to make sure they appear as a frontend as just one within one subdomain and to a user or your customers, they don't notice it's coming from Google cloud or coming from AWS or coming from the local IT. So the way it works is that you can just simply set up a profile. This is the exact profile you need. The first entry is Roffit history. You can use Roffit history to specify the zones you wanted to capture. Then you can specify the force rule, which means that if a record is not available, it will force you to the next plugin, which is the cloud DNS. You also set up a force rule so that it can continue if the record that's carried by the user, it's not hitting Google cloud DNS. And of course you can set up your local coding as with different plugins or with different information or even connecting to some external DNS resolvers as many ways as you like. And you should be able to connect all the information and serving them in one frontend through coding as. That's what I'm talking about. You can use coding as a single source of truth for your users. Okay, now let's go a little deeper to discuss about how to write a code DNS plugin in Golan. We're also going to discuss also discovery, but in this case, the set up is gonna be simple. Let's say we have a VNet or VPN or VPC. And internally, you want your DNS to reply IP, let's say 1.1.1.1. But externally, if it's public facing, if it's a query by the user outside of your organization, you want to reply another IP address. And it can be easily done in this setup. So let's say some user is query you to say, okay, I'm going to query example.org. You're going to say, oh, is this user coming from a private network or from public network? If you're a public network, I'm going to reply one thing. Private network is going to be another thing. The demo plugin is available in GitHub. So you can certainly take a look, but in this session, I'm going to only briefly walk through several functions to show you how simple it is. To just come up with your own plugin. And in case you want to implement any complicated feature, you can expand it a little further. But I highly encourage you to use a demo plugin as a starting point if you want to achieve anything slightly sophisticated than just a core file. Because most of the time, if you use a core file, you probably already achieve your goal. But in case there are some features, just not possible to come up with a simple core file, you can try to write your plugin in Gola. So demo plugin consists of three functions. And that's the only thing you need to cover. The first thing you need to function, which is pretty standard, just perform a one-time initialization and reach the setup function. It's a part of the CADD system. It will pass the configuration and decide what to do for this plugin. And finally, the serve DNS is the core component of the plugin. Anything happened about your DNS query and the response will be inside the serve DNS. I'm going to show the code here. As you can see, it's fairly simple. They need plug-in. It's not doing anything other than just do a standard regression for plug-in self with setup. Setup function will pass the configuration. In our configuration, we want to make it simple. We just want the hard code 1.1.1.1 or 8.8.8. In this case, we don't need to pass anything. So we just say, okay, we're going to make sure the plug-in name is demo, and we're going to move on. If you decide to do additional parsing, you'll have to modify the setup. But that's a separate topic. And here comes the core components of the plugin, the serve DNS. The serve DNS will take a message, which is the request, the DNS message. With the DNS message, that's our DNS message, right? With the DNS message, you'll try to construct the request and figure out the query name. You can do a state.name, the first two lines of state equals request.request, which you construct request. And then you can figure out the name of the query, which is simple enough. And now you're going to say, let's figure out the IP of the query, which as you can see the next line, if an IP starts with 172.something, or 127.something, it means it's a private network, within private network. The reply will be 1.1.1.1. Of course, you can use if else to decide what will be the other reply. So let's say the other reply is going to be 8.8.8.8. And that's all you need. You can construct the answers. After you construct the answers, you use the DNS response writer, the second argument in the function. You use that one to write down the response. And that's pretty much it for the whole plugin. And you can certainly, continue to construct a core file, as I mentioned in the previous setup section. The, we don't take any argument. We only accept the plugin name and demo. So the core file will be just a demo. It will invoke the plugin. The plugin has to be compiled. It has to be compiled as part of the coding as repo. So into factory coding as repo, you add a demo to plugin.config. And there is some easy way to build. You can, you know, the, you see the drag command, darker run. This will give you a way to easily build everything. If you run this command, somehow the binary will be available. You will see a coding as a binary on your local directory. You can just invoke a coding as, and that's all. Okay, that's demo plugin. And again, like I said, the source code is available. If you're interested in start writing all plugins, I highly encourage you to use this demo plugin as a starting point. And also if you check the whole repo, the whole repo only consists of like 80 lines of a goal. So it should be simple enough. It's nothing complicated. Okay, now we are almost to the end of the session. So I'm going to say, if anyone want to contribute to coding as, you have several ways to help coding as one. You may want to start coding as in GitHub to reach 10,000 stars sooner. And two, if your institution or organization are willing to share the name publicly, you can add the name to adopters.md file in the repo. That also means that you'll automatically became a contributor because you're going to create a PR, right? And also if you want to go step further, you want to be a maintainer, it's also not that difficult. Normally the policy is that if you create a significant pull request, now small pull request has to be something meaningful, it has to be something important, just one. And if you can find an existing maintainer to sponsor you, you can be added as a maintainer. Again, there are 28 maintainers at the moment. So I don't think you have any trouble to find someone to sponsor you if you can make one significant pull request contribution. Okay, so I think that's it for the whole session. Is there any questions or anything anyone want to ask? It's, okay, so I'm trying to refer to the question. The question is, is code DNS like authoritative? So in the way DNS works, you normally have a resolver, right? Is the code DNS, it's not a DNS resolver. So you can consider code DNS as a front end of DNS. It needs to be backed by a resolver. You need to have some other way to pass information from the back end to the front end, but coding itself is not a resolver. Sorry, I probably missed your early comment. I mean, yeah, can I repeat the question again? Yeah, it's okay. So if you say you don't want to talk to outside, you just want to use coding as self everything. It's not that it's possible. I mean, you can associate with, let's say a bind or associate with, you know, or maybe like a host file. I know some people use a host file with like a 10,000 record as they serve that view. But yeah, maybe you can comment on it. So it is actually the forging of the resolver. You have different back ends. So most people here are probably using it in Kubernetes. That's just one particular way to use it. And we can actually use it if you accept ordinary standard DNS file, bind like main file, right? So you can use it as an ordinary authoritative name sort of just like anywhere you do bind. Absolutely no problem. What it doesn't do is it doesn't do recursive resolution. So authoritative resolution, meaning it reads the data from the slope of files or it reads the data from somewhere else and serves it up directly as the authoritative name server. It can do, but if you give it a name that isn't part of its authoritative domain that it understands, it has to forward that theory onto another name server. So it's what you wanna do is you look up from internet or internet services that aren't within your domain, then you need another name server to handle it. Because like a recursive name server like bind will navigate, it'll break the query into its constituent labels and it'll navigate. It'll look up the root name server, it'll look up the column name server, it'll look up the Google name server, it'll look up the food.google.com and it'll find those name servers. According to us, won't do that process. It'll, if you, but for an air gap situation, yes, absolutely it would 100% serve your domains. You just have to give it the records in an ordinary main deep file format or post files that you can use. There's like, you can sort of think of our plug-ins as we have, we have back ends that are, we sort of differentiate between the source of the data and then how we serve the data. So the source of the data can be back by Google Cloud, it can be back by Route 53, it can be back by a file, it can be back by a Postgres database, it can be back by Kubernetes API server, all of those things, but it's all just served up as DNS. Or maybe I can say another way, if you have a Google.com, if you say, I don't know what Google.com will resolve to IP by Google, then you can say, you can set up, set up according to response for any Google.com request as 1.00, 2.00, or 2.00, 3.00, 4.00, whatever you want. But if you say, I don't know what it is, I want to look into dot, and then look into com, then look into Google and see what it's actually is. Quoting as we now do that, so it's not a resolve one. But it can serve all the information, if you want all the information to be within Quoting as, it definitely can do that. Here, you're writing your own profile, there's no, the only place an external reference shows up is in the forward plugin. So you actually have to explicitly use the forward plugin to do those actual little flight, but it probably doesn't do that. Now, if you're in Kubernetes, then you're using a particular way to configure it that either a Helmcher or your service provider is exposing to you as a service. But the actual Quoting as itself doesn't care about any of that, that's all external about how it is configured. It's just a core file, that's how it is configured. We can talk about it in a little bit. Okay. You mentioned the Quoting as you were talking about. Yeah. If there is a payload that's beyond 512 bytes, which is the one to, is there a way that we can... You want me to repeat the question or do you get most of what I said? So, you mentioned UDP was the front-side protocol that's used for request response to a client. If the payload happens to be much larger than 512 bytes, is there a mechanism in Core DNS to allow for that kind of payloads? Do you guys, DNS supports both, you can use what's called E-DNS or E-DNS 0. Easy to have to accept it, but I'm not sure. But basically it allows you to use up to $4,996. I don't know, I don't remember. Is it actual buffering? Yes, yes, they're actual buffering, but I don't remember the exact... Yeah, that's an extension to DNS that supports the Quoting as it is. Any other question? Do you want to ask a question? No? Okay. Okay, look, I don't have a question. Sounds loud. Okay, have a great day. Ha ha ha. Thank you.