This article mainly introduces how to build a highly available DNS environment under Tencent cloud platform to meet the needs of enterprises for internal and external domain name resolution on the cloud. This paper mainly introduces the implementation methods of two schemes. Scheme 1: build an intelligent analysis scheme based on the Bind software of Centos system; Scheme 2: build CoreDNS high availability scheme based on CoreDNS and ETCD. Before describing the implementation of the two schemes, let's review the basic concept and principle of DNS.

1. Basic concepts of DNS

1.1.DNS overview

DNS is a hierarchical distributed database. Its full name is Domain Name System. It stores information used for mutual mapping between Internet host names and IP addresses, as well as other data used by the Internet. DNS system is provided by bind software (Berkeley Internet Name Domain) developed by Berkeley University. At present, the of bind is 9 x. Now most of them are called BIND9 for short; BIND9 software distribution includes a name server, named, and quantity and parsing library, liblwres and libbind. If you want to learn more or download a higher version, you can query and download at this site: http://www.isc.org/software/bind

The difference between BIND and DNS: DNS is the communication protocol name of the Internet. BIND is the software that provides this DNS service; It plays a very important role in TCP/IP network and can provide domain name and IP address resolution services.

1.2. How DNS works

The domain name system DNS is similar to a tree data structure. Each node in the tree is essentially a server responsible for a specific area. Through these nodes, the whole domain name space is divided into a hierarchical structure, which is similar to the hierarchical structure of UNIX file system, the name of the root " The next level of the root domain is the top-level domain name. The top-level domain name is divided into two methods: geographical domain and general domain. The geographical domain is set for every country or region in the world, such as China is cn, Japan jp, the United States us and Taiwan tw. wait. The common domain is the top-level domain name set by different organization categories, such as org, edu and so on. As shown below:

1.3. List of common top-level domain names

With the rapid growth of the network, a Domain name distinguished by country or region appeared later.

1.4. Resolution principle and process of domain name service

• Step-1: the user makes a domain name request and sends the request to the local domain name server
• Step-2: when the local domain name server receives the request, it first queries the local cache. If there is this record information, the local domain name server will directly return the query result to the client
• Step-3: if there is no such record in the local cache, the local domain name server will directly send the request to the root domain name server, and then ask the root domain name server to return the address of the primary domain name server of the queried domain (root sub domain, such as cn) to the local domain name server
• Step-4: the local server sends a request to the domain name server returned in the previous step, and then the domain name server receiving the request queries its cache, returns the record corresponding to the request or the address of the relevant summer domain name, and the local domain name server saves the returned result to the cache
• Step-5: repeat step 4 until the correct record is found
• Step-6: the local domain name server saves the returned results to the cache for next use, and also returns the results to the client DNS resolution example

Step-1: client request resolution www.sina.com.cn Message

Step-2: after the local domain name server receives the request, check whether the local cache has the request www.sina.com.cn Analytical notes of

If yes, it will be fed back to the client. If not, it will be queried from the root domain name server as shown in the figure above

Step-3: “.” After receiving the request, the root domain name server determines that the domain name belongs to cn domain, query the NS record and the corresponding A record report

Step-4: after receiving relevant information, the local DNS server caches it first and then sends it to it DNS service of one of the domain names of cn

The server sends a request to resolve the domain name www.sina.com.cn Message

Step-5: . After receiving the request, the cn domain name server determines that the domain name belongs to com.cn domain, start to query local records, find 6 NS records and corresponding A records, and feed back the results to the local DNS server

Step-6: after receiving the feedback information, the local DNS server caches it first and then sends it to it com.cn domain name server

Query, request domain name resolution www.sina.com.cn Message

Step-7: . com. After receiving the request, the CN domain name server determines that the domain belongs to sina.com.cn domain, start to query local records, find NS records and corresponding A records, and then return the query results to the local DNS server

Step-8: after receiving the request, the local DNS server caches the above query results and sends them to the server again sina.com.cn domain name server to query and request domain name resolution www.sina.com.cn Message

Step-9: domain name server NS1 sina. com. After receiving the request, CN starts to query the local cache and feed back the resolution results to the local DNS server

Step-10: received by local DNS server www.sina.com.cn After the resolution of the domain name, first cache a copy locally and return the result to the client, so as to complete a domain name resolution process

1.5. Description of relevant records of DNS Service

• NS: domain name server record becomes ns record
• A: address record is used to set the ip address relationship corresponding to the host name
• CNAME: alias record
• MX record: set the mail server name provided in the current domain

2.DNS high availability intelligent resolution scheme

The DNS high availability scheme is based on CVM cloud server. The DNS server is built in the VPC intranet, which can meet the requirements of Intranet domain name resolution. At the same time, this scheme design combines Tencent cloud CLB products to provide load balancing capability. It can also connect multiple RS nodes through multiple CLBs, share the front-end analysis pressure, and support the deployment of multiple availability zones.

2.1. Program features

• In the same region, multiple availability zones are used for DNS high availability construction;
• All are deployed in the Intranet environment without public IP exposure;
• Separation of Intranet and extranet domain name requests to reduce the impact of faults;
• Intranet LB connects multiple RS nodes and carries the front-end analytical access request;

2.2. Scheme implementation function

• Support Tencent cloud platform intranet reserved domain name resolution, such as: * tencentyun.com ;
• Support users to define their own business domain name and Intranet resolution, such as www.rocky.com com ;
• Support access to Internet domain name resolution, such as www.baidu.com com ;
• Support forwarding sub domain names to different DNS servers

2.3. Resolve process path

1) Client access enterprise internal domain name

• Client = > CLB = > self built DNS1 / self built DNS2

2) Client access Tencent intranet domain name

• Client = > CLB = > self built dns1 = > forward to 183 DNS = > unbonddns

3) Client access Internet domain name

• Client = > CLB = > self built dns1 = > forward to 183 DNS = > private DNS = > public recursive DNS

be careful:

• If the customer's UIN account in Tencent cloud is a non bandwidth up user (traditional user), CLB does not support hanging on the RS node across the availability zone. "
• According to relevant regulations, port 53 is not allowed to be opened without relevant qualification. If it is used internally, the access source shall be restricted. For details, please refer to the announcement on security group 53 port configuration on Tencent cloud official website, https://cloud.tencent.com/document/product/213/35533 .

3. Implementation of DNS high availability intelligent resolution scheme

This scheme adopts two nodes to practice this scheme. If the generation environment on the cloud needs to be combined with the detailed requirements of the customer's business, the number of nodes and CLB s can be adjusted according to different regions.

3.1. Host name setting

[root@VM-2-15-centos ~] hostnamectl set-hostname node4.rocky.com
[root@VM-2-16-centos ~] hostnamectl set-hostname node5.rocky.com

3.2. Configure / etc/hosts

[root@node4 ~]# cat /etc/hosts
127.0.0.1 VM-6-15-centos VM-6-15-centos
127.0.0.1 localhost.localdomain localhost
127.0.0.1 localhost4.localdomain4 localhost4
10.0.6.15 node4 node4.rocky.com
10.0.6.16 node5 node5.rocky.com

3.3. Install DNS software

[root@node4 ~]# yum -y install bind
[root@node5 ~]# yum -y install bind

3.4.DNS master profile

[root@node4 ~]# cat /etc/named.conf
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
// See the BIND Administrator's Reference Manual (ARM) for details about the
// configuration located in /usr/share/doc/bind-{version}/Bv9ARM.html
acl "trusted-recursion" { # Set acl
 localhost;
 10.0.0.0/16;
};
options {
 listen-on port 53 { any; }; #Set the listening port, or write specific network segments
 listen-on-v6 port 53 { any; };
 directory "/var/named";
 dump-file "/var/named/data/cache_dump.db";
 statistics-file "/var/named/data/named_stats.txt";
 memstatistics-file "/var/named/data/named_mem_stats.txt";
 recursing-file "/var/named/data/named.recursing";
 secroots-file "/var/named/data/named.secroots";
 allow-query { any; }; #Open query 
 allow-recursion { trusted-recursion; }; #Specify which hosts are allowed to get answers from the cache.
 allow-query-cache { trusted-recursion; }; # Specify which hosts are allowed to perform recursive queries through this server.
 /*
 - If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
 - If you are building a RECURSIVE (caching) DNS server, you need to enable
 recursion.
 - If your recursive DNS server has a public IP address, you MUST enable access
 control to limit queries to your legitimate users. Failing to do so will
 cause your server to become part of large scale DNS amplification
 attacks. Implementing BCP38 within your network would greatly
 reduce such attack surface
 */
 recursion yes;
 dnssec-enable no;
 dnssec-validation no; # Turn off dnssec security authentication
 /* Path to ISC DLV key */
 #bindkeys-file "/etc/named.root.key";
 managed-keys-directory "/var/named/dynamic";
 pid-file "/run/named/named.pid";
 session-keyfile "/run/named/session.key";
 forwarders {
 183.60.83.19; # Tencent cloud VPCGW DNS address
 183.60.82.98; # Tencent cloud VPCGW DNS address
 };
};
logging {
 channel default_debug {
 file "data/named.run";
 severity dynamic;
 };
};
zone "." IN {
 type hint;
 file "named.ca";
};
#include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
zone "rocky.com" { # domain name
 type master; #Primary DNS
 file "dynamic/rocky.com.zone"; # zone file path #Forward zone file
 notify yes;
};
zone "6.0.10.in-addr.arpa" in {
 type master;
 file "dynamic/6.0.10.in-addr.arpa.zone"; #Reverse zone file
 notify yes;
};

3.5.DNS zone file configuration

3.5.1. Forward zone profile

3.5.2. Reverse zone profile

3.5.3. Area profile parameter description

3.5.4. Start DNS Service

Start the service on node4 and node5 respectively and check whether the service status is normal.

3.6.DNS service resolution verification

#Client access enterprise internal domain name
[root@node4 ~]# nslookup www.rocky.com
Server: 10.0.6.15
Address: 10.0.6.15#53
Name: www.rocky.com
Address: 10.0.6.100

[root@node4 ~]# nslookup 10.0.6.100
100.6.0.10.in-addr.arpa name = www.rocky.com.

#Client access Internet domain name
[root@node4 ~]# nslookup www.baidu.com
Server: 10.0.6.15
Address: 10.0.6.15#53
Non-authoritative answer:
www.baidu.com canonical name = www.a.shifen.com.
Name: www.a.shifen.com
Address: 110.242.68.3
Name: www.a.shifen.com
Address: 110.242.68.4
#Client access to Tencent cloud intranet service domain name
[root@node4 ~]# nslookup mirrors.tencent.com
Server: 10.0.6.15
Address: 10.0.6.15#53
Non-authoritative answer:
mirrors.tencent.com canonical name = mirrors.cloud.tencent.com.
mirrors.cloud.tencent.com canonical name = mirrors.cloud.tencent.com.cdn.dnsv1.com.
mirrors.cloud.tencent.com.cdn.dnsv1.com canonical name = 14io0gsu.sched.dma.tdnsv5.com.
Name: 14io0gsu.sched.dma.tdnsv5.com
Address: 113.240.69.235
Name: 14io0gsu.sched.dma.tdnsv5.com
Address: 113.240.69.180
[root@node4 ~]#

The service passed the verification and met the expectation. node5 also carried out relevant analysis and verification respectively.

3.7.LB configuration

3.7.1. New intranet LB

Create a new intranet LB, configure the listening port as UDP: 53, weighted polling.

3.7.2. Configure LB

Select the RS node bound to the board and confirm

3.8. Client authentication

[root@node6 ~]# cat /etc/resolv.conf
; generated by /usr/sbin/dhclient-script
#nameserver 183.60.83.19
#nameserver 183.60.82.98
nameserver 10.0.2.2 #Intranet LB address
#Resolve business domain name

[root@node6 ~]# nslookup www.rocky.com
Server: 10.0.2.2
Address: 10.0.2.2#53
Name: www.rocky.com
Address: 10.0.6.100
#Resolve Tencent intranet domain name
[root@node6 ~]# nslookup mirrors.tencent.com
Server: 10.0.2.2
Address: 10.0.2.2#53
Non-authoritative answer:
mirrors.tencent.com canonical name = mirrors.cloud.tencent.com.
mirrors.cloud.tencent.com canonical name = mirrors.cloud.tencent.com.cdn.dnsv1.com.
mirrors.cloud.tencent.com.cdn.dnsv1.com canonical name = 14io0gsu.sched.dma.tdnsv5.com.
Name: 14io0gsu.sched.dma.tdnsv5.com
Address: 113.240.69.180
Name: 14io0gsu.sched.dma.tdnsv5.com
Address: 113.240.69.235
[root@node6 ~]# nslookup myqcloud.com
Server: 10.0.2.2
Address: 10.0.2.2#53
Non-authoritative answer:
Name: myqcloud.com
Address: 0.0.0.1
#Resolve Internet domain name
[root@node6 ~]# nslookup www.jd.com
Server: 10.0.2.2
Address: 10.0.2.2#53
Non-authoritative answer:
www.jd.com canonical name = www.jd.com.gslb.qianxun.com.
www.jd.com.gslb.qianxun.com canonical name = jd-abroad.cdn20.com.
Name: jd-abroad.cdn20.com
Address: 121.57.82.89
Name: jd-abroad.cdn20.com
Address: 36.111.141.54
Name: jd-abroad.cdn20.com
Address: 121.57.82.88
Name: jd-abroad.cdn20.com
Address: 121.57.82.17
Name: jd-abroad.cdn20.com
Address: 42.81.145.189
Name: jd-abroad.cdn20.com
Address: 113.24.194.72
Name: jd-abroad.cdn20.com
Address: 240e:918:1a00:201::33
Name: jd-abroad.cdn20.com
Address: 240e:928:101::1e
Name: jd-abroad.cdn20.com
Address: 240e:918:1a00:201::15
Name: jd-abroad.cdn20.com
Address: 240e:925:2:101::6

The verification passed and met the expectations.

3.9. Summary of DNS high availability intelligent resolution scheme

This scheme adopts the DNS software of Linux system to build the DNS high availability environment, and combines the intranet CLB to make its resolution and scheduling RS more flexible. At the same time, it realizes the resolution requirements of the client for the enterprise intranet domain name and Tencent cloud intranet domain name. In addition, it must be noted here that RS is built in the intranet, and the security group limits the source IP of port 53.

4.CoreDNS high availability solution

This article mainly introduces how to provide DNS internal and external domain name resolution through self built CoreDNS cluster and Tencent intranet DNS function. CoreDNS+ETCD cluster is adopted here. Scheme features:

• Multiple self built CoreDNS nodes avoid the situation that a single node cannot be used and improve availability
• Multi availability deployment, with high availability and avoiding single availability failure (although the probability is small)
• All are deployed in the Intranet environment without public IP exposure
• The domain name requests of Intranet and extranet are separated to reduce the radius of fault explosion

4.1CoreDNS

CoreDNS is based on a DNS server written in Go, which links plug-ins, and each plug-in performs one (DNS) function. Compared with other DNS} such as BIND, Knot, PowerDNS and Unbound, it is very flexible. Almost all functions are outsourced to plug-ins. Plug ins can also be independent or work together. You can use the plug-in to do what you want to do with your DNS data. If some functions are not ready-made, you can add them by writing plug-ins. They have the same model as Caddy Server: link plug-ins.

4.1.1 # features

• Plugins: Based on the Caddy server framework, CoreDNS implements the architecture of a plug-in chain, abstracting a large number of application logic into plug-in form and exposing it to users. CoreDNS connects different plug-ins into a chain in a pre configured way, and executes the logic on the plug-in chain in order.
• Simple configuration: introduce a more expressive DSL, that is, a configuration file in the form of Corefile.

4.1.2 CoreDNS architecture

4.1.3 CoreDNS} resolution method

Note that there are two different ports: 5300 and 53. Internally, each port generates a dnsserver Server. Even if there are four server blocks, we can only get two actual servers. CoreDNS will collect all server blocks related to the same port and merge them into the same dnsserver Server. The server will make multiple queries on the port and pass them to different plug-in chains according to the region. It selects the most specific matching server block for the region. If there is no matching server block, SERVFAIL is returned.

coredns.io:5300 {
file /etc/coredns/zones/coredns.io.db
}
example.io:53 {
errors
log
file /etc/coredns/zones/example.io.db
}
example.net:53 {
file /etc/coredns/zones/example.net.db
}
.:53 {
errors
log
health
rewrite name foo.example.com foo.default.svc.cluster.local
}

4.2 ETCD

ETCD is a highly consistent distributed key value storage. It provides a reliable way to store data that needs to be accessed by distributed systems or machine clusters. It gracefully handles leadership elections during network partitioning and can tolerate machine failures.

• Simple: simple installation and configuration, supporting HTTP API interaction;
• Security: support SSL certificate verification;
• Fast: according to the official benchmark data, a single instance supports 2k + reads per second;
• Reliability: adopt raft algorithm to realize the availability and consistency of distributed system data;

From the above architecture diagram, we can see that ETCD is mainly divided into four parts.

HTTP Server: used to process API requests sent by users and requests for synchronization and heartbeat information from other etcd nodes. Store: used to handle transactions of various functions supported by etcd, including data index, node state change, monitoring and feedback, event processing and execution, etc. it is the specific implementation of most API functions provided by etcd to users. Raft: the concrete implementation of raft strong consistency algorithm is the core of etcd. WAL: Write Ahead Log is the data storage method of etcd. In addition to storing the state of all data and the index of nodes in memory, etcd is persisted and stored through WAL. Before submitting all data in WAL, logs will be recorded in advance. Snapshot is a status snapshot to prevent excessive data. Entry indicates the specific log contents stored.

4.3 configure ETCD cluster

Here, three ECs are used as the back-end database of the CoreDNS node. The ETCD architecture logic has the mechanism of electing master, which are node1 ~ node3 respectively

4.3.1 ETCD installation and startup

[root@node1~]# yum -y install etcd
[root@node11 ~]# systemctl enable etcd; systemctl start etcd
Created symlink from /etc/systemd/system/multi-user.target.wants/etcd.service to /usr/lib/systemd/system/etcd.service.

4.3.2 node1# etcd configuration

[root@node1 etcd]# egrep ^[A-Z] etcd.conf
ETCD_DATA_DIR="/var/lib/etcd/node1.etcd"
ETCD_LISTEN_PEER_URLS="http://10.0.2.4:2380"
ETCD_LISTEN_CLIENT_URLS="http://10.0.2.4:2379,http://127.0.0.1:2379"
ETCD_NAME="node1"
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://10.0.2.4:2380"
ETCD_ADVERTISE_CLIENT_URLS="node1=http://10.0.2.4:2379"
ETCD_INITIAL_CLUSTER="node1=http://10.0.2.4:2379,node2=http://10.0.2.8:2379,node3=http://10.0.2.15:2379"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
ETCD_INITIAL_CLUSTER_STATE="new"

4.3.3 node2# etcd configuration

[root@node2 ~]# egrep ^[A-Z] /etc/etcd/etcd.conf
ETCD_DATA_DIR="/var/lib/etcd/node2.etcd"
ETCD_LISTEN_PEER_URLS="http://10.0.2.8:2380"
ETCD_LISTEN_CLIENT_URLS="http://10.0.2.8:2379,http://127.0.0.1:2379"
ETCD_NAME="node2"
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://10.0.2.8:2380"
ETCD_ADVERTISE_CLIENT_URLS="http://10.0.2.8:2379"
ETCD_INITIAL_CLUSTER="node1=http://10.0.2.4:2380,node2=http://10.0.2.8:2380,node3=http://10.0.2.15:2380"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
ETCD_INITIAL_CLUSTER_STATE="new"
[root@node2 ~]#

4.3.4 node3# etcd configuration

[root@node3 ~]# egrep ^[A-Z] /etc/etcd/etcd.conf
ETCD_DATA_DIR="/var/lib/etcd/node3.etcd"
ETCD_LISTEN_PEER_URLS="http://10.0.2.15:2380"
ETCD_LISTEN_CLIENT_URLS="http://10.0.2.15:2379,http://127.0.0.1:2379"
ETCD_NAME="node3"
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://10.0.2.15:2380"
ETCD_ADVERTISE_CLIENT_URLS="http://10.0.2.15:2379"
ETCD_INITIAL_CLUSTER="node1=http://10.0.2.4:2380,node2=http://10.0.2.8:2380,node3=http://10.0.2.15:2380"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
ETCD_INITIAL_CLUSTER_STATE="new"

Start and verify etcd service

[root@node1 ~]# systemctl start etcd.service
[root@node1 ~]# systemctl status etcd.service
etcd.service - Etcd Server
   Loaded: loaded (/usr/lib/systemd/system/etcd.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2022-02-15 13:50:16 CST; 10h ago
 Main PID: 10451 (etcd)
   CGroup: /system.slice/etcd.service
           └─10451 /usr/bin/etcd --name=node1 --data-dir=/var/lib/etcd/node1.etcd --listen-client-urls=http://10.0.2.4:2379,http://127.0.0.1:2379

4.3.5 etcd cluster health

[root@node1 ~]# etcdctl member list
5432b0f7395992d2: name=node1 peerURLs=http://10.0.2.4:2380 clientURLs=http://10.0.2.4:2379 isLeader=true
589358f881fe72a1: name=node2 peerURLs=http://10.0.2.8:2380 clientURLs=http://10.0.2.8:2379 isLeader=false
bb72602d9eb35069: name=node3 peerURLs=http://10.0.2.15:2380 clientURLs=http://10.0.2.15:2379 isLeader=false

[root@node1 ~]# etcdctl cluster-health
member 5432b0f7395992d2 is healthy: got healthy result from http://10.0.2.4:2379
member 589358f881fe72a1 is healthy: got healthy result from http://10.0.2.8:2379
member bb72602d9eb35069 is healthy: got healthy result from http://10.0.2.15:2379
cluster is healthy

4.4 multi node CoreDNS deployment

4.4.1 installing coredns

The environment of CoreDNS server can be built according to the needs of customers' business. CoreDNS1.0 is adopted here Version 6.4, the latest version on the official website is 1.9 x

[root@dns1 ~]# tar zxvf coredns_1.6.4_linux_amd64.tgz
[root@dns1 ~]# mv coredns /usr/bin/
[root@dns1 ~]# mkdir /etc/coredns

4.4.2 coredns core configuration file

[root@node1 ~]# cat /etc/coredns/Corefile
. {  # Listen to port 53 of tcp and udp
    etcd node1.rocky.com node2.rocky.com node3.rocky.com 10.in-addr.arpa { # Configure and enable etcd plug-in. You can specify the domain name later
        stubzones # Enable stub area function
        path /skydns # The default path in etcd is / skydns. All dns records in the future are stored under the stub path
        endpoint http://10.0.2.4:2379   http://10.0.2.8:2379   http://10.0.2.15:2379 #Etcd access address, separated by multiple spaces
        upstream  183.60.83.19:53  183.60.82.98:53 # Set the upstream resolver to use to resolve the external domain name found in etcd (considered CNAME) pointing to the external domain name.
    }
    cache 600  # Cache for 600 seconds
    loadbalance # Load balancing, enable DNS record polling policy
    forward . 183.60.82.98:53  183.60.83.19:53 # The requests not found in etcd above are forwarded to the DNS server for resolution
}

myqcloud.com {
    cache 600 myqcloud.com 
    loadbalance
    forward . 119.29.29.29:53
}

tencent-cloud.com {
 hosts { 
  10.210.104.113 cls-i0fxloot.ccs.tencent-cloud.com
  10.210.49.4 cls-88b89rhb.ccs.tencent-cloud.com
  10.210.104.35 cls-o4rn1235.ccs.tencent-cloud.com
  fallthrough
    }
}

4.4.3 configure systemd} management coredns service

[root@node1 ~]# cat /usr/lib/systemd/system/coredns.service
[Unit]
Description=CoreDNS DNS server
Documentation=https://coredns.io
After=network.target

[Service]
PermissionsStartOnly=true
LimitNOFILE=1048576
LimitNPROC=512
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
NoNewPrivileges=true
User=coredns
WorkingDirectory=~
ExecStart=/usr/bin/coredns -conf=/etc/coredns/Corefile
ExecReload=/bin/kill -SIGUSR1 $MAINPID
Restart=on-failure

[Install]
WantedBy=multi-user.target
[root@node1 ~]#

4.4.4 start coredns

[root@node1 ~]# systemctl status coredns
● coredns.service - CoreDNS DNS server
   Loaded: loaded (/usr/lib/systemd/system/coredns.service; disabled; vendor preset: disabled)
   Active: active (running) since Tue 2022-02-15 16:13:43 CST; 4s ago
     Docs: https://coredns.io
 Main PID: 30288 (coredns)
   CGroup: /system.slice/coredns.service
           └─30288 /usr/bin/coredns -conf=/etc/coredns/Corefile

Feb 15 16:13:43 node1.rocky.com systemd[1]: Started CoreDNS DNS server.
Feb 15 16:13:43 node1.rocky.com coredns[30288]: .:53
Feb 15 16:13:43 node1.rocky.com coredns[30288]: myqcloud.com.:53
Feb 15 16:13:43 node1.rocky.com coredns[30288]: tencent-cloud.com.:53
Feb 15 16:13:43 node1.rocky.com coredns[30288]: ______                ____  _   _______
Feb 15 16:13:43 node1.rocky.com coredns[30288]: / ____/___  ________  / __ \/ | / / ___/        ~ CoreDNS-1.6.4
Feb 15 16:13:43 node1.rocky.com coredns[30288]: / /   / __ \/ ___/ _ \/ / / /  |/ /\__ \         ~ linux/amd64, ...dirty
Feb 15 16:13:43 node1.rocky.com coredns[30288]: / /___/ /_/ / /  /  __/ /_/ / /|  /___/ /
Feb 15 16:13:43 node1.rocky.com coredns[30288]: \____/\____/_/   \___/_____/_/ |_//____/
Hint: Some lines were ellipsized, use -l to show in full.
[root@node1 ~]# ^C
[root@node1 ~]# systemctl enable coredns
Created symlink from /etc/systemd/system/multi-user.target.wants/coredns.service to /usr/lib/systemd/system/coredns.service.

4.4.5 coredns configuration analysis record

root@node1 ~]# etcdctl put /skydns/com/rocky/node1 '{"host":"10.0.2.4","ttl":10}'
No help topic for 'put'
[root@node1 ~]# export ETCDCTL_API=3
[root@node1 ~]# etcdctl put /skydns/com/rocky/node1 '{"host":"10.0.2.4","ttl":10}'
OK
[root@node1 ~]# vim .bashrc
[root@node1 ~]#
[root@node1 ~]#
[root@node1 ~]# etcdctl put /skydns/com/rocky/node2 '{"host":"10.0.2.8","ttl":10}'
OK
[root@node1 ~]# etcdctl put /skydns/com/rocky/node3 '{"host":"10.0.2.15","ttl":10}'
OK
[root@node1 ~]# etcdctl put /skydns/com/rocky/node1 '{"host":"www.tam3.com","ttl":10}'
OK
[root@node1 ~]#

Due to the test environment adopted here, relevant settings need to be made in combination with specific businesses.

4.6 coredns verification

[root@node1 ~]# dig @node1 www.tam3.com

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.7 <<>> @node1 www.tam3.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1734
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.tam3.com.                  IN      A

;; ANSWER SECTION:
www.tam3.com.           160     IN      CNAME   tam3.com.
tam3.com.               160     IN      A       3.33.152.147
tam3.com.               160     IN      A       15.197.142.173

;; Query time: 622 msec
;; SERVER: 10.0.2.4#53(10.0.2.4)
;; WHEN: Tue Feb 15 16:25:24 CST 2022
;; MSG SIZE  rcvd: 123

Verify that it meets expectations.

5. Summary

In this paper, two different forms of self built high availability DNS environment on the cloud are used to solve the needs of enterprises' internal and external domain name resolution on the cloud. The above two schemes are for reference only. The production environment is adopted, and the relevant configuration needs to be adjusted in combination with the specific needs of the business. At the same time, the DNS hosting service of Tencent cloud is preferred here. If there are special business needs, you can refer to the above two schemes and cooperate with the hosted DNS service.

6. Appendix

6.1.DNS common tools

dig usage

Dig domain information Explorer (DIG) is the most powerful query tool. The commonly used simple form of dig is as follows:

• dig @server domain query-type query-class
• dig @dns domain name or ip area record type
• dig @10.0.2.2 rocky.com NS/A/MX

nslookup usage

nslookup has two modes: interactive and non interactive; Interactive mode allows users to send query requests for various host and domain name information to the name server, or print out a list of hosts under the domain The non interactive mode can only be used to print the name and request information of a host or domain queried, as described in the article.

whois tool

• https://www.internic.net/whois.html
• https://whois.cloud.tencent.com/

Dial test tool

• 17ce.com
• mdig.com

6.2. Other references

• https://www.isc.org/bind/
• https://coredns.io/
• https://etcd.io/
• https://coredns.io/plugins/
• https://coredns.io/2017/06/08/how-queries-are-processed-in-coredns/
• https://github.com/coredns/deployment/blob/master/systemd/coredns.service
• https://cloud.tencent.com/document/product/1338
• https://cloud.tencent.com/developer/article/1748028
• https://cloud.tencent.com/developer/article/1945211