 Good afternoon. Welcome to this session. My name is Yang Tang. I'm a maintainer of CodingS project. In today's session, I'm going to do a deep dive on CodingS, discussed about building customer plugins with CodingS in Golan. This is my profile on GitHub handle. By the way, if you have any questions, you can always reach out to me on GitHub. I should be available most of the time every day. This is a agenda for today's session. I'm going to spend several minutes to introduce CodingS, discuss about its history and some of the interesting stories behind it. I will post some studies update of CodingS for the past year in 2020, discuss about the versions that has been released as well as the new features that has been added. I will also discuss about the Google Summer Code program with CodingS. The reason Google Summer Code is important to CodingS is because quite a few features in CodingS has been added through the contributions from Google Summer Code students. Things like a DNS tab and ACL are plugins that has been part of the default CodingS. In last year, the student of Google Summer Code successfully combined CodingS machine learning and security into a server application. It's fun to take a look. Finally, I will work through a demo plugin in Gola. This is a source-based service discovery. It allows you to set up a CodingS server to reply DNS queries with different response based on the source ID of the query. Finally, it's a Q&A session. If you have any questions, you can raise it up. I'll try my best to answer. As many of you know, CodingS is a flexible DNS server written in Go. It was developed and started in 2016. At the beginning, it was really a fork of a CodingXX server. Over the years, the relationship between CodingS and CodingS has been gradually decoupled. Although, even as of now, you can still find some matrices of CodingS reference including as code base. Unlike some other DNS servers, CodingS has a focus on service discovery. It is a plugin base, which means it can be easily extended for new functionalities. If you have a new feature you want to add and it's not available in default plugins, then you can write on your own if you know how to write in Go. Most importantly, CodingS at the moment is a default DNS server in Kubernetes, which means if you're using Kubernetes, you're probably already using CodingS. CodingS supports a wide range of DNS servers. It has different protocol support from DNS, DNS over TOS, and DNS over JRPC. By the way, DNS over JRPC is another true DNS standard. It is a customer implementation by CodingS. CodingS also has a wide range of support for different cloud vendors. We have support to allow you to sync up data from AWS Rotary 3, Microsoft Azure DNS, and Google Cloud DNS. This is a very interesting feature that allows you to consolidate a DNS record from different cloud vendors. This is very useful if you want to do a multi-cloud deployment where you need to consolidate a DNS record from AWS, Azure, or Google Cloud. And finally, CodingS has been started and lead by MakeJapan since 2016. As of 2020, two versions has been released by CodingS. 1.7.0 was released on June 2020. In this version, a new plugin, DNS64, was added to default. DNS64 used to be an external plugin, but we decided it was important enough to move into the default. We also removed the Federation plugin. Federation plugin was deprecated in 2019, mostly because it's of less usage. Finally, in 1.7, we removed that completely. In 1.7 release, there are some backward incompatible changes, mostly related to matrix names. If you're using this feature, you may want to double check and make sure that any update can be handled properly. In 2020, we also released a version of 1.8.0 to 1.8.3. 1.8.0 was released on October. The most important change is that we internalized CodingS. As I mentioned, CodingS was actually a fork at the beginning for Kati ATT server. Over the years, Kati has been migrated from version 1 to version 2. However, for CodingS, we feel like it's for the best entry to stay with Kati version 1. For that reason, we want to internalize Kati source code so that we are now going to be subject to changing Kati's upstream library dependency. The plugin that has been added in 1.8 is a transfer plugin. This allows you to do a zone transfer, which is an important feature in DNS. This is also a feature that has been requested by many users for the past several years. Finally, it was landed on 1.8. We also add another plugin that's a local plugin, which allows you to do the local query with response. Additional CodingS community update. As of now, we have 249 contributors. We certainly want to see this number to grow continuously. So first of all, big thanks to anyone who contributed to CodingS, and we welcome any additional contributions. We have 24 maintenance so far. By the way, it's very easy to become a maintainer in CodingS. If you can contribute to a significant pull request, and if you can get a sponsor of one existing maintainer, we will add you as a maintainer. We also have 30 public adopters. Those are the enterprise or institutions that are willing to share a name with us and make their name available across the board. Since CodingS now is a default DNS server for Kubernetes, so the usage of CodingS is much larger than 30, but those are the names that have been shared with us and willing to be public. We also have about 7,400 staff. It's a very important number, and we hope this number can be growing continuously. So if you haven't done so, I would really encourage you to start CodingS on GitHub. This can help the community already. If you're looking for help in CodingS, there are several places you can find. The GitHub is the most active one. Most of the maintenance are there and willing to help you whenever possible. There is also a Slack channel that's part of the CNCF Slack. You can find some help from some of the maintenance. We also have a web page, a blog, and you can also subscribe to Twitter handle CodingS IO. You should be able to get most of the news update and the releases update from those resources. For the past five years or so, CodingS has been participated in Google Summer Code continuously. Many features in CodingS are actually coming out of this Google Summer Code program. In 2017, DNS tab was added as part of the CodingS default plugins. In 2019, we have ACL plugin that's now being widely used in community. In 2020, Chanaya, who is a student of Google Summer Code, successfully combined machine learning, security, and CodingS into a server application. The purpose of his server application is to machine learning based DNS threat detection. In his server application, he is going to actually check any DNS queries from machine learning. He combined TensorFlow to analyze the DNS query and if the DNS query is malicious, the DNS will be blocked. This is a very interesting server application that can help a lot of areas. It's also very interesting to see the topics of DNS can be expanded into other areas of security and machine learning. By the way, in 2021, we are also participating in Google Summer Code. In this year, the topic of Google Summer Code for CodingS is ACME support. With ACME support, you should be able to obtain or renew your certificate automatically without any manual intervention. With ACME support, you should be able to just renew your certificate as long as you can identify yourself through the domain name you own. We'll see if this one can be successfully landed as part of the CodingS default plugins. We expect to 2020 Google Summer Code and CodingS. The student actually posts a very interesting webpage to list all his source code for this server application. He set up several components. The first component is a CodingS server plugin which is written in Gola. He set up another server which is a Python server exposing a RESTful API. The reason he set up independent server in Python is that in machine learning, most of the implementations are actually done in Python or C++. So he decided that it's not the best interest to reinvent the build to port everything into Gola. So instead, he set up an individual server so that it's easy to reuse existing infrastructure in machine learning and allow CodingS to talk to the machine learning server through the RESTful API. He also set up Elasticsearch server for data analytics. So that's very impressive implementation. He even has a webpage of mlbridge.github.io. You can definitely take a look. You can even see his UI which is pretty impressive as well. I'm going to discuss a little bit for server discovery with DNS. Over the past several years, many people ask me questions. In this day and age, we have SDN which allows you to assign an IP to any instance you like in any way. Is there still a need for DNS? My answer has also been, I think DNS is really important even in this day and age for several reasons. First, DNS is a nice indirection. And this is an indirection you may like at the beginning because this indirection gives you the maximum flexibility. Secondly, DNS is easy and simple to change. This is especially the case for core DNS because for core DNS, you want to make a change in DNS record. It could be just as simple as one or two lines of code. Another factor I take into consideration is that DNS by itself is actually distributed. It's distributed in nature and it scales to internet because the whole internet is based on DNS. Finally, DNS is very pervasive in IT infrastructure, which means you can find DNS from anywhere in any organization and in any way. For example, you can find DNS in your IT organization. You can find DNS in your deployment of Kubernetes. You can find the DNS in your cloud windows native services. This allows you to consolidate the survey discovery into different ways from different angles. Just to give you an example of why DNS could be important and why DNS gives you flexibility. Let's say you have a service or cluster deployed on the CIWS and you want to migrate to Google cloud or maybe migrate a part of service into Microsoft Azure. So how would you do that? If you don't have a DNS, which is an indirection in place at the beginning, you may need to do a lot of change. You may need to notify your users of all the ITs that you have transitioned. But with DNS, all you need to do is to update the DNS record and repoint the IP behind the DNS record from one cloud vendor to another. And your user may not even notice any difference. This is the flexibility we are talking about because DNS as an indirection give you the flexibility to allow you to accommodate any future changes you like. I think that's one reason why in this day and age DNS is actually even more important than ever. With respect to survey discovery, I'm going to walk through a demo plug-in in Golan in this session. The demo plug-in is a simple survey discovery based on society. This diagram describes the intention we have to do. We will try to set up core DNS as an edge of the network. The network consists of external networks that's publicly facing as well as internal networks that's internal facing. We also that the internal network will be within either 172.0.0.0.0.8 or 122.0.0.0.0.8. If it's internal, we will just reply IP address of 1.1.1.1. On the other hand, if a DNS query is from external, even though they are querying the same names, we are going to return differently. In this demo plug-in, we are going to return 8.8.8.8. So this is the basic setup we are trying to achieve. In order to write a demo plug-in, we will need to set up several functions. There are three functions that we absolutely need. The first function is a need function, which will perform a one-time initialization. This need function will register a set of functions with Kati. People may be wondering about why Kati is still in place. As I explained at the beginning of the session, QoDNS is actually a fork of Kati at the beginning. So that's why you see Kati appears from time to time in QoDNS codebase. The second function, which is a setup function, will do all the heavy lifting work of passing the configuration from the file and capture it in a struct and pass it further. The need and setup function are pretty straightforward, but the main processing of the DNS query is a sub-DNS function. This function takes the query message as well as a response writer. With this function, you should be able to process the DNS request and return the response. Or if you decide that your plugin is not going to process this DNS request, you will pass it down the chain, allow the next plugin to process it further. This is the setup function and the need function. As you can see, it's pretty straightforward. For the need function, since we named this plugin as demo, we pass a demo as a string. We also set the DNS as a server type. The setup is a function that will process a configuration. Since in this demo plugin, we are not going to pass any configuration parameters. We will just do the configuration the way, like any other plugins. So it's pretty straightforward. You can just copy and paste if you are going to do similar things in your code. The sub-DNS is the main body of the plugin. We take the DNS request as a DNS.msd. We will also pass a DNS response writer, which allows you to decide what to do for this plugin. The first thing you need to do is to construct a request state. This is done by the first line of state equals request start request. With this state, you are able to find the name of the query. Now you can start deciding what to do with the response. In our case, as we discussed, we want to process our request based on if the IP is internal or external. So we will pass the IP and check to see if the first object is 172 or 122. If it's from 172 or 122, that means the request is from internal interface. If they are from internal, we will try to reply a response of 1.1.1.1. Otherwise, we are going to response with 8.8.8.8. And now you can see the address is to construct the answers. We already decided what to do, so we will pass through the answers and go through the response writer to do that. If we decided that we don't want to reply, then all we need to do is to just pass through the plugin chain and allow the next plugin to pick up and process further. But in this case, we are going to do that, so we will return the answers ourselves. There are some time constraints to this session, so I'm not going to go through further. But for this demo plugin, it is available on GitHub. So I'll share the link of this demo plugin source code you can check on yourself. With the demo plugin in place, you can build the binary, but you also need a core file. By default, all the plugins are distributed initially, which means in order to enable demo, you should at least place demo in your core file. We set up the port number of 1053 so that we can listen to this port. If you want to listen to the default port number of 53, you should change the configuration accordingly. The next step is to build a plugin. Building a plugin is fairly simple. So first of all, you need to add the demo column demo to plugin.config. The next step is to build with Golang. Since sometimes if you're using Linux or using Mac, it may not be exactly straightforward to set up a Golang environment. If you don't want to bother and you already have Docker installed, you can actually use Docker to run this one line command to build the binary. If you execute this one line command of Docker, you should be able to see a binary coding as generated from your local directory. The next step is just run this binary dot slash coding as and your process is going to happen running listening to the request. If you try it yourself, you will find out that if you do the query from external networks, the returned IP will be 8.8.8.8. And if you query example.org from your internal network, the response will be 1.1.1.1.1. And that's exactly the survey discovery we talked about. It gives you a lot of flexibility and allow you to decide what to response and the point in service the way you want. The whole source code of demo plugin is available on GitHub. You should be able to check by yourself. It consists of readme as well as all the details. And if you take a further look, you can notice that the total line code is about less than 80 lines. So that give you enough detail to allow you to write on your own. And finally, we want to talk about the contribution of coding as. There are several ways if you want to contribute to coding as. First of all, you can start coding as in GitHub. This can certainly bump the number of stars of coding as in GitHub. You can also add the name of your enterprise or institution to adopt a star MD. This also give you the chance to open a pull request, which automatically allows you to become a contributor. I also mentioned that it's very easy to become a maintainer of coding as. In order to become a maintainer, you need to count with one significant pull request. This pull request could be a feature or could be a plugin as part of the default coding as plugin. If you can complete one significant pull request, and if you can find current maintainer as your sponsor, then we'll add you as a maintainer. To be a maintainer of coding as, give you some additional benefit. We'll give you a badge in GitHub, which I believe will help you in your career in the future. That's that's all from today's session. So next is going to be the Q&A. If you have any questions, you can raise up. I'll try my best to answer any questions.