This article was last updated 269 days ago. The information in this article may have developed or changed. If it is invalid, please leave a message in the comment section.

Contents

Preface

In some special scenarios, we may need a controllable DNS server of our own. For example, if a custom test domain name is needed to build an experimental environment in the intranet, we only need to point the DNS server of the test machine to the controllable DNS (when there are many test machines, we can't change the hosts file on each test machine, right?); or directly use it as the local DNS of the intranet device (first, it is convenient to add custom domain name resolution at any time, and second, it is convenient to add a separate forwarder for some "special" domain names polluted by DNS to send them to a safe DNS address for resolution); or use it as the authorized DNS server for the second-level and third-level domain names of our own top-level domain names, etc. Of course, dnsmasq on many routers can actually achieve most of the functions, but in the spirit of "if there are difficulties, we must do it, and if there are no difficulties, we must create difficulties and do it", we still need to build a DNS server for the home data center.

Deploy bind9

I use eafxx/bind on dockerhub to implement DNS, which is actually implemented through bind (version 9.1.6) on webmin (a web-based Linux system management tool with many built-in functions, which can also be regarded as a Linux panel). The command is as follows:

docker run --name bind9 -d --restart=always \ -p 53:53/tcp -p 53:53/udp -p 10000:10000/tcp \ -v /docker/bind9/data:/data \ -e WEBMIN_ENABLED=true \ -e ROOT_PASSWORD=password \ -e WEBMIN_INIT_SSL_ENABLED=false \ -e WEBMIN_INIT_REFERERS=bind.example.com \ -e WEBMIN_INIT_REDIRECT_PORT=443 \ -e TZ=Asia/Shanghai \ eafxx/bind:latest

Key parameter explanation:
-p 10000:10000
The access port of the webmin interface can be modified according to your actual situation.
-e WEBMIN_ENABLED=true
Enable webmin access
-e ROOT_PASSWORD=password
Set the password for logging into the webmin interface. The default username is root
-e WEBMIN_INIT_SSL_ENABLED=false
Disable SSL access to webmin, because I am behind a reverse proxy, so I need to disable it
-e WEBMIN_INIT_REFERERS=bind.example.com
To use with a reverse proxy, you need to specify the domain name corresponding to the reverse proxy, otherwise you will not be able to access it.
-e WEBMIN_INIT_REDIRECT_PORT=443
To use with a reverse proxy, you need to specify the reverse proxy port. If it is placed on a cloud server and has port 443 after filing, specify 443 here; if it is placed on a home broadband with a public network address, just specify the corresponding reverse proxy port here.

Initial configuration

After deployment, use http://host ip:10000 to access the webmin interface:

Under "Server" - "BIND DNS Server" is the bind configuration interface:

Next, I configure it according to the scenario of deploying a DNS server on the intranet:

Forwarding and Transmission

This is the configuration of the forwarder. Generally, you need to set the address of the upper-level DNS server you need, such as Alibaba's DNS address "223.5.5.5" or Google's address "8.8.8.8" (requires science or magic):

The option in the red box actually corresponds to the parameter forward in the configuration file option. "Yes" means forward first, which means that if the DNS server set by the forwarder does not respond, the DNS server will query itself; "No" means forward only, which means that if the DNS server set by the forwarder does not respond, the DNS server will not query itself. The default is first.

Address and topology

Set the listening address and port:

The default listening port and address are fine. If you want to specify a different port and address, you can specify it in the "list below". However, if the port is fine, do not change it. For the address, any means any address. You can also specify the IP address of a certain interface separately. It depends on your needs.Allow recursive queries from, here you need to select "Listed", and then enter your intranet IP segment in the box below, which is equivalent to the option field in the bind configuration file:

allow-recursion { 192.168.10.0/24; };

Of course, you can also directly fill in any here, which means accepting recursive queries from all source IP addresses, and finally select Save in the lower left corner.

Miscellaneous options

There is a very important option here:

This tells bind whether to respond to recursive queries submitted by the client. The default value is yes. If it is used as a local DNS in the intranet, keep the default value. If it is a DNS placed on a public cloud server and is only used as an authorized DNS for a domain, you need to change it to no. If it is placed on the public network and needs to accept recursive queries, change it to yes. At the same time, you need to add the allow-recursion parameter to specify the client IP range that accepts recursive queries (see the previous section) and use the recursive-clients parameter to specify the maximum number of concurrent recursive query clients.

DNSSEC Verification

There are mainly 2 options here that are DNSSEC related:

The above figure is the default configuration, it is recommended to change to:

Otherwise, the following may occur:server can't find xxx.com: SERVFAILThe error is reported.

After completing the above configuration, restart the bind9 container:

docker restart bind9

The above completes the initialization of bind9, which can be used as the local dns of the intranet. If you want to add a test domain name for resolution, you need to create the corresponding zone:

I won’t go into details here, just search for tutorials online.

In addition: directly building a DNS server is actually more suitable for the experimental environment. If you only need a local DNS forwarder, you don’t need to use such a troublesome method. You only need to use ADguard home to achieve it, and it can also provide DOH, DOT and filtering advertisements. For specific construction steps, please refer to the article:Docker series uses Docker to build its own ad-free, pollution-free and DOH (DOT)-supported DNS server based on ADguard home.

Configuring public network access

If you want to publish the management page to the public network for access, you need to choose the most suitable publishing method according to the actual environment and the reverse proxy you use. You can refer to my previous articles:
1,Docker series uses Docker to build its own reverse proxy based on NPM
2,Linux panel series configure reverse proxy and use non-443 port for publishing
3.Home data center series uses domestic cloud hosting to get free cloudflare to achieve fast access to domestic sites from abroad
4.Home Data Center Series: Use cloudflare to build a website quickly with no public IP in your home broadband (general purpose)

The first and second methods are suitable for environments with public IP but no legal 443 port (home broadband, unregistered cloud host). You need to add a non-standard port after the URL (if you use cloudflare to build a website, you don't need to add a port, but you need to customize the source station port. You can refer to:Home data center series uses cloudflare's Origin Rules to solve the problem of having a public IP but no legal ports 80 and 443 when building a websiteThe third method is suitable for cloud hosts with a record, and the fourth method is suitable for all environments (including environments without public IP), which is also the method I recommend (regardless of whether your environment has a public IP or not, because this method does not require running https traffic directly on the public network).