Named Tutorial
From:
https://www.digitalocean.com/community/tutorials/how-to-configure-bind-as-a-private-network-dns-server-on-ubuntu-22-04
How To Configure BIND as a Private Network
DNS Server on Ubuntu 22.04
Published on August 4, 2022 · Updated on August 4, 2022
By Justin Ellingwood and Mark Drake
Introduction
An important part of managing server configuration and infrastructure involves
maintaining a way to find network interfaces and IP addresses by name. One way
to do this is to set up a proper Domain Name System (DNS). Using fully qualified
domain names (FQDNs), instead of IP addresses, to specify network addresses
optimizes the configuration of services and applications, and increases the
maintainability of configuration files. Setting up your own DNS for your private
network is a great way to improve the management of your servers.
In this tutorial, you will set up an internal DNS server using two Ubuntu 22.04
servers. You will use the BIND name server software (BIND9) to resolve private
hostnames and private IP addresses. This provides a central way to manage your
internal hostnames and private IP addresses, which is indispensable when your
environment expands to more than a few hosts.
Prerequisites
To complete this tutorial, you will need the following infrastructure. Be sure
to create each server in the same datacenter private networking enabled:
- A fresh Ubuntu 22.04 server to serve as the Primary DNS server, ns1.
(Recommended) A second Ubuntu 22.04 server to serve as a Secondary DNS server, ns2.
- At least one additional server. This guide assumes you have two additional
servers, which will be referred to as client servers. These client servers must
be created in the same datacenter where your DNS servers are located.
On each of these servers, configure an administrative sudo user and set up a
firewall by following our Ubuntu 22.04 initial server setup guide.
If you are unfamiliar with DNS concepts, we recommend that you read at least the
first three parts of our Introduction to Managing DNS
On DigitalOcean, all new Droplets created are placed into a Virtual Private
Cloud (VPC) by default. Check out our VPC product documentation to learn more.
Example Infrastructure and Goals
For the purposes of this article, we will assume the following:
- You have two servers which will be designated as your DNS name servers. This
guide will refer to these as ns1 and ns2.
- You have two additional client servers that will be using the DNS
infrastructure you create, referred to as host1 and host2 in this guide. You can
add as many client servers as you’d like.
- All of these servers exist in the same datacenter. This tutorial assumes
that this datacenter is called nyc3.
- All of these servers have private networking enabled and are on the
10.128.0.0/16 subnet (you will likely have to adjust this for your servers).
- All servers are connected to a project that runs on example.com. This guide
outlines how to set up an internal, private DNS system, so you can use any
domain name you’d like instead of example.com. The DNS servers will always
attempt to first route requests internally, meaning they won’t try to reach the
given domain on the public internet. However, using a domain you own may help
avoid conflicts with publicly routable domains.
With these assumptions in mind, the examples in this guide will use a naming
scheme based around the subdomain nyc3.example.com to refer to the example
private subnet or zone. Therefore, host1’s private Fully-Qualified Domain Name
(FQDN) will be host1.nyc3.example.com. The following table holds the relevant
details used in examples throughout this guide:
| Host | Role | Private FQDN | Private IP Address
|
| ns1 | Primary DNS Server | ns1.nyc3.example.com | 10.128.10.11
|
| ns2 | Secondary DNS Server | ns2.nyc3.example.com | 10.128.20.12
|
| host1 | Generic Host 1 | host1.nyc3.example.com | 10.128.100.101
|
| host2 | Generic Host 2 | host2.nyc3.example.com | 10.128.200.102
|
Note: Your setup will be different, but the example names and IP addresses will
be used to demonstrate how to configure a DNS server to provide a functioning
internal DNS. You should be able to adapt this setup to your own environment by
replacing the host names and private IP addresses with your own. It is not
necessary to use the region name of the datacenter in your naming scheme, but we
use it here to denote that these hosts belong to a particular datacenter’s
private network. If you run servers in multiple datacenters, you can set up an
internal DNS within each respective datacenter.
By the end of this tutorial, you will have a primary DNS server, ns1, and
optionally a secondary DNS server, ns2, which will serve as a backup.
As you follow this tutorial, there will be times when you must run certain
commands on a specific server in this setup. Any commands that must be run on
ns1 will have a blue background, like this:
ns1$
Likewise, any commands that must be run on ns2 will have a red background
ns2$
And any commands that must be run on one of your client servers will have a
green background:
$
And any commands that must be run on multiple servers will have a standard
navy background:
ns1$ and ns2$
Lastly, be aware that any time a command or code block contains text that is
highlighted like this, it means that text is important. This type of
highlighting will be used throughout this guide to denote details that need to
be replaced with your own settings or that the highlighted text must be modified
or added to a configuration file. For example, if an example contains something
like host1.nyc3.example.com, replace it with the FQDN of your own server.
Let’s get started by installing BIND on both your primary and secondary DNS
servers, ns1 and ns2.
Step 1 — Installing BIND on DNS Servers
On both DNS servers, ns1 and ns2, update the apt package cache by typing:
sudo apt update
Then install BIND on each machine:
sudo apt install bind9 bind9utils bind9-doc
DigitalOcean’s private networking uses IPv4 exclusively. If this is the case for
you, set BIND to IPv4 mode. On both servers, edit the named default settings
file using your preferred text editor. The following example uses nano:
sudo nano /etc/default/named
Add -4 to the end of the OPTIONS parameter:
/etc/default/named
OPTIONS="-u bind -4"
Save and close the file when you are finished. If you used nano to edit the file
,you can do so by pressing CTRL + X, Y, then ENTER.
Restart BIND to implement the changes:
sudo systemctl restart bind9
Now that BIND is installed, let’s configure the primary DNS server.
Step 2 — Configuring the Primary DNS Server
BIND’s configuration consists of multiple files that are included from the main
configuration file, named.conf. These file names begin with named because that
is the name of the process that BIND runs (with named being short for “name
daemon”, as in “domain name daemon”). We will start with configuring the
named.conf.options file.
Configuring the Options File
On ns1, open the named.conf.options file for editing:
sudo nano /etc/bind/named.conf.options
Above the existing options block, create a new ACL (access control list) block
called trusted. This is where you will define a list of clients from which you
will allow recursive DNS queries (i.e. your servers that are in the same
datacenter as ns1). Add the following lines to add ns1, ns2, host1, and host2 to
your list of trusted clients, being sure to replace the example private IP
addresses with those of your own servers:
/etc/bind/named.conf.options — 1 of 3
acl "trusted"
{
10.128.10.11; # ns1
10.128.20.12; # ns2
10.128.100.101; # host1
10.128.200.102; # host2
};
options {
. . .
Now that you have your list of trusted DNS clients, you can edit the options
block. This is currently the start of the block:
/etc/bind/named.conf.options — 2 of 3
. . .
};
options {
directory "/var/cache/bind";
. . .
}
Below the directory directive, add the highlighted configuration lines (and
substitute in the appropriate ns1 private IP address):
/etc/bind/named.conf.options — 3 of 3
. . .
};
options {
directory "/var/cache/bind";
recursion yes; # enables recursive queries
allow-recursion { trusted; }; # allows recursive queries from "trusted"
# clients
listen-on { 10.128.10.11; }; # ns1 private IP address - listen on
# private network only
allow-transfer { none; }; # disable zone transfers by default
forwarders {
8.8.8.8;
8.8.4.4;
};
. . .
};
Notice the forwarders block, which includes two IP addresses: 8.8.8.8 and
8.8.4.4. This block defines forwarders, a special mechanism that BIND uses to
reduce traffic over links to external nameservers. BIND can also use forwarders
to allow queries by servers that don’t have direct access to the internet. This
can help to make the responses to these queries faster by reducing the load on
the local network.
The two IP addresses in this block represent Google’s public DNS resolvers, but
the IP address of any public recursive name server will work here. For example,
you could use the IP address of Cloudflare’s DNS server (1.1.1.1) instead.
When you are finished, save and close the named.conf.options file. The above
configuration specifies that only your own servers (the trusted ones) will be
able to query your DNS server for outside domains.
Next, you will specify your DNS zones by configuring the named.conf.local file.
Configuring the Local File
On ns1, open the named.conf.local file for editing:
sudo nano /etc/bind/named.conf.local
Aside from a few comments, the file will be empty. Here, you will specify your
forward and reverse zones. DNS zones designate a specific scope for managing and
defining DNS records. Since this guide’s example domains will all be within the
nyc3.example.com subdomain, we will use that as our forward zone. Because our
example servers’ private IP addresses are each in the 10.128.0.0/16 IP space,
the following example will set up a reverse zone so that we can define reverse
lookups within that range.
Add the forward zone with the following lines, substituting the zone name with
your own and the secondary DNS server’s private IP address in the allow-transfer
directive:
/etc/bind/named.conf.local — 1 of 2
. . .
zone "nyc3.example.com" {
type primary;
file "/etc/bind/zones/db.nyc3.example.com"; # zone file path
allow-transfer { 10.128.20.12; }; # ns2 private IP address -
# secondary
};
Assuming that our private subnet is 10.128.0.0/16, add the reverse zone by with
the following lines (note that our reverse zone name starts with 128.10 which is
the octet reversal of 10.128):
/etc/bind/named.conf.local — 2 of 2
. . .
};
zone "128.10.in-addr.arpa" {
type primary;
file "/etc/bind/zones/db.10.128"; # 10.128.0.0/16 subnet
allow-transfer { 10.128.20.12; }; # ns2 private IP address - secondary
};
If your servers span multiple private subnets but are in the same datacenter, be
sure to specify an additional zone and zone file for each distinct subnet. When
you are finished adding all of your desired zones, save and close the
named.conf.local file.
Now that your zones are specified in BIND, you need to create the corresponding
forward and reverse zone files.
Creating the Forward Zone File
The forward zone file is where you define DNS records for forward
DNS lookups. That is, when the DNS receives a name query,
host1.nyc3.example.com for example, it will look in the forward zone
file to resolve host1’s corresponding private IP address.
Create the directory where your zone files will reside. According to the
named.conf.local configuration, that location should be /etc/bind/zones:
sudo mkdir /etc/bind/zones
We will base our example forward zone file on the sample db.local zone file.
Copy it to the proper location with the following commands:
sudo cp /etc/bind/db.local /etc/bind/zones/db.nyc3.example.com
Now edit your forward zone file:
sudo nano /etc/bind/zones/db.nyc3.example.com
Initially, it will contain content like the following:
/etc/bind/zones/db.nyc3.example.com — original
$TTL 604800
@ IN SOA localhost. root.localhost. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost. ; delete this line
@ IN A 127.0.0.1 ; delete this line
@ IN AAAA ::1 ; delete this line
First, you will want to edit the SOA record. Replace the first localhost with
ns1’s FQDN, then replace root.localhost with admin.nyc3.example.com. Every time
you edit a zone file, you need to increment the Serial value before you restart
the named process. Here, increment it to 3:
/etc/bind/zones/db.nyc3.example.com — updated 1 of 3
. . .
;
$TTL 604800
@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. (
3 ; Serial
. . .
Next, delete the three records at the end of the file (after the SOA record).
If you’re not sure which lines to delete, they are marked with comments reading
delete this line in the previous example.
At the end of the file, add your name server records with the following lines
(replace the names with your own). Note that the second column specifies that
these are NS records:
/etc/bind/zones/db.nyc3.example.com — updated 2 of 3
. . .
; name servers - NS records
IN NS ns1.nyc3.example.com.
IN NS ns2.nyc3.example.com.
Now, add the A records for your hosts that belong in this zone. This includes
any server whose name you want to end with .nyc3.example.com (substitute the
names and private IP addresses). Using our example names and private IP
addresses, we will add A records for ns1, ns2, host1, and host2 like so:
/etc/bind/zones/db.nyc3.example.com — updated 3 of 3
. . .
; name servers - A records
ns1.nyc3.example.com. IN A 10.128.10.11
ns2.nyc3.example.com. IN A 10.128.20.12
; 10.128.0.0/16 - A records
host1.nyc3.example.com. IN A 10.128.100.101
host2.nyc3.example.com. IN A 10.128.200.102
Our final example forward zone file will contain the following content:
/etc/bind/zones/db.nyc3.example.com — updated
$TTL 604800
@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; name servers - NS records
IN NS ns1.nyc3.example.com.
IN NS ns2.nyc3.example.com.
; name servers - A records
ns1.nyc3.example.com. IN A 10.128.10.11
ns2.nyc3.example.com. IN A 10.128.20.12
; 10.128.0.0/16 - A records
host1.nyc3.example.com. IN A 10.128.100.101
host2.nyc3.example.com. IN A 10.128.200.102
Save and close the db.nyc3.example.com file.
Now let’s move onto the reverse zone file(s).
Creating the Reverse Zone File(s)
Reverse zone files are where you define DNS PTR records for reverse DNS lookups.
That is, when the DNS receives a query by IP address, 10.128.100.101 for
example, it will look in the reverse zone file(s) to resolve the corresponding
FQDN, host1.nyc3.example.com in this case.
On ns1, for each reverse zone specified in the named.conf.local file, create a
reverse zone file. We will base our example reverse zone file(s) on the sample
db.127 zone file. BIND uses this file to store information for the local
loopback interface; 127 is the first octet of the IP address that represents
localhost (127.0.0.1). Copy this file to the proper location with the following
commands (substituting the destination filename so it matches your reverse zone
definition):
sudo cp /etc/bind/db.127 /etc/bind/zones/db.10.128
Edit the reverse zone file that corresponds to the reverse zone(s) defined in
named.conf.local:
sudo nano /etc/bind/zones/db.10.128
Initially, the file will contain content like the following:
/etc/bind/zones/db.10.128 — original
$TTL 604800
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost. ; delete this line
1.0.0 IN PTR localhost. ; delete this line
In the same manner as the forward zone file, you will want to edit the SOA
record and increment the serial value:
/etc/bind/zones/db.10.128 — updated 1 of 3
@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. (
3 ; Serial
. . .
Now delete the two records at the end of the file (after the SOA record). If
you’re not sure which lines to delete, they are marked with a delete this line
comment in the previous example.
At the end of the file, add your name server records with the following lines
(replace the names with your own). Note that the second column specifies that
these are NS records:
/etc/bind/zones/db.10.128 — updated 2 of 3
. . .
; name servers - NS records
IN NS ns1.nyc3.example.com.
IN NS ns2.nyc3.example.com.
Then add PTR records for all of your servers whose IP addresses are on the
subnet of the zone file that you are editing. In our example, this includes all
of our hosts because they are all on the 10.128.0.0/16 subnet. Note that the
first column consists of the last two octets of your servers’ private IP
addresses in reversed order. Be sure to substitute names and private IP
addresses to match your servers:
/etc/bind/zones/db.10.128 — updated 3 of 3
. . .
; PTR Records
11.10 IN PTR ns1.nyc3.example.com. ; 10.128.10.11
12.20 IN PTR ns2.nyc3.example.com. ; 10.128.20.12
101.100 IN PTR host1.nyc3.example.com. ; 10.128.100.101
102.200 IN PTR host2.nyc3.example.com. ; 10.128.200.102
Your final example reverse zone file will be similar to the following:
/etc/bind/zones/db.10.128 — updated
$TTL 604800
@ IN SOA nyc3.example.com. admin.nyc3.example.com. (
3 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
; name servers
IN NS ns1.nyc3.example.com.
IN NS ns2.nyc3.example.com.
; PTR Records
11.10 IN PTR ns1.nyc3.example.com. ; 10.128.10.11
12.20 IN PTR ns2.nyc3.example.com. ; 10.128.20.12
101.100 IN PTR host1.nyc3.example.com. ; 10.128.100.101
102.200 IN PTR host2.nyc3.example.com. ; 10.128.200.102
Save and close the reverse zone file. If you need to add more reverse zone
files , repeat this section.
You’re done editing your files, so next you can check your files for errors.
Checking the BIND Configuration Syntax
Run the following command to check the syntax of the named.conf* files:
sudo named-checkconf
If your named configuration files have no syntax errors, there won’t be any
error messages and you will return to your shell prompt. If there are problems
with your configuration files, review the error message and the Configure
Primary DNS Server section, then try named-checkconf again.
The named-checkzone command can be used to check the correctness of your zone
files. Its first argument specifies a zone name, and the second argument
specifies the corresponding zone file, which are both defined in
named.conf.local.
For example, to check the nyc3.example.com forward zone configuration, run the
following command (change the names to match your forward zone and file):
sudo named-checkzone nyc3.example.com /etc/bind/zones/db.nyc3.example.com
Output
zone nyc3.example.com/IN: loaded serial 3
OK
And to check the 128.10.in-addr.arpa reverse zone configuration, run the
following command (change the numbers to match your reverse zone and file):
sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128
When all of your configuration and zone files have no errors in them, you will
be ready to restart the BIND service.
Restarting BIND
Restart BIND:
sudo systemctl restart bind9
If you have the UFW firewall configured, open up access to BIND by typing:
sudo ufw allow Bind9
Your primary DNS server is now set up and ready to respond to DNS queries. Let’s
move on to configuring the secondary DNS server.
Step 3 — Configuring the Secondary DNS Server
In most environments, it is a good idea to set up a secondary DNS server that
will respond to requests if the primary becomes unavailable. Luckily,
configuring the secondary DNS server is much less complicated than setting up
the primary.
On ns2, edit the named.conf.options file:
sudo nano /etc/bind/named.conf.options
At the top of the file, add the ACL with the private IP addresses of all of your
trusted servers:
/etc/bind/named.conf.options — updated 1 of 2 (secondary)
acl "trusted" {
10.128.10.11; # ns1
10.128.20.12; # ns2
10.128.100.101; # host1
10.128.200.102; # host2
};
options {
. . .
Below the directory directive, add the following lines:
/etc/bind/named.conf.options — updated 2 of 2 (secondary)
. . .
recursion yes;
allow-recursion { trusted; };
listen-on { 10.128.20.12; }; # ns2 private IP address
allow-transfer { none; }; # disable zone transfers by default
forwarders {
8.8.8.8;
8.8.4.4;
};
. . .
Save and close the named.conf.options file. This file should be identical to
ns1’s named.conf.options file except it should be configured to listen on ns2’s
private IP address.
Now edit the named.conf.local file:
sudo nano /etc/bind/named.conf.local
Define secondary zones that correspond to the primary zones on the primary DNS
server. Note that the type is secondary, the file does not contain a path, and
there is a primaries directive which should be set to the primary DNS server’s
private IP address. If you defined multiple reverse zones in the primary DNS
server, make sure to add them all here:
/etc/bind/named.conf.local — updated (secondary)
zone "nyc3.example.com" {
type secondary;
file "db.nyc3.example.com";
primaries { 10.128.10.11; }; # ns1 private IP
};
zone "128.10.in-addr.arpa" {
type secondary;
file "db.10.128";
primaries { 10.128.10.11; }; # ns1 private IP
};
Now save and close the named.conf.local file.
Run the following command to check the validity of your configuration files:
sudo named-checkconf
If this command doesn’t return any errors, restart BIND:
sudo systemctl restart bind9
Then allow DNS connections to the server by altering the UFW firewall rules:
sudo ufw allow Bind9
With that, you now have primary and secondary DNS servers for private network
name and IP address resolution. Now you must configure your client servers to
use your private DNS servers.
Step 4 — Configuring DNS Clients
Before all of your servers in the trusted ACL can query your DNS servers, you
must configure each of them to use ns1 and ns2 as name servers.
Assuming your client servers are running Ubuntu, you’ll need to find what device
is associated with your private network. You can do this by querying the private
subnet with the ip address command. Run the following command on each of your
client machines, replacing the highlighted subnet with your own:
ip address show to 10.128.0.0/16
Output
3: eth1: mtu 1500 qdisc fq_codel state UP group default qlen 1000
altname enp0s4
altname ens4
inet 10.128.100.101/16 brd 10.128.255.255 scope global eth1
valid_lft forever preferred_lft forever
In this example, the private interface is eth1. The examples throughout this
section will refer to eth1 as the private interface, but you should change these
examples to reflect your own servers’ private interfaces.
On Ubuntu 22.04, networking is configured with Netplan, an abstraction that
allows you to write standardized network configuration and apply it to
compatible backend networking software. To configure DNS, you need to write a
Netplan configuration file.
Create a new file in /etc/netplan called 00-private-nameservers.yaml:
sudo nano /etc/netplan/00-private-nameservers.yaml
Inside, add the following contents. You will need to modify the interface of the
private network, the addresses of your ns1 and ns2 DNS servers, and the DNS zone:
Note: Netplan uses the YAML data serialization format for its configuration
files. Because YAML uses indentation and whitespace to define its data
structure, make sure that your definition uses consistent indentation to avoid
errors.
You can troubleshoot your YAML file using a YAML checker like YAML Lint.
/etc/netplan 00-private-nameservers.yaml
network:
version: 2
ethernets:
eth1: # Private network interface
nameservers:
addresses:
- 10.128.10.11 # Private IP for ns1
- 10.132.20.12 # Private IP for ns2
search: [ nyc3.example.com ] # DNS zone
Save and close the file when you are finished.
Next, tell Netplan to attempt to use the new configuration file by using netplan
try. If there are problems that cause a loss of networking, Netplan will
automatically roll back the changes after a timeout:
sudo netplan try
Output
Warning: Stopping systemd-networkd.service, but it can still be activated by:
systemd-networkd.socket
Do you want to keep these settings?
Press ENTER before the timeout to accept the new configuration
Changes will revert in 120 seconds
If the countdown is updating correctly at the bottom, the new configuration is
at least functional enough to not break your SSH connection. Press ENTER to
accept the new configuration.
Now, check that the system’s DNS resolver to determine if your DNS configuration
has been applied:
sudo resolvectl status
Scroll down until you find the section for your private network interface. The
private IP addresses for your DNS servers should be listed first, followed by
some fallback values. Your domain should be listed after DNS Domain:
Output
. . .
Link 3 (eth1)
Current Scopes: DNS
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 67.207.67.3
DNS Servers: 10.128.10.11 10.128.20.12 67.207.67.3 67.207.67.2
DNS Domain: nyc3.example.com
Your Ubuntu client is now configured to use your internal DNS servers.
Step 5 — Testing Clients
Use nslookup to test if your clients can query your name servers. You should be
able to do this on all of the clients that you have configured and are in the
trusted ACL.
You can start by performing a forward lookup.
Forward Lookup
To perform a forward lookup to retrieve the IP address of
host1.nyc3.example.com, run the following command:
nslookup host1
Querying host1 expands to host1.nyc3.example.com because the search option is
set to your private subdomain, and DNS queries will attempt to look on that
subdomain before looking for the host elsewhere. The previous command will
return output like the following:
Output
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: host1.nyc3.example.com
Address: 10.128.100.101
Next, you can check reverse lookups.
Reverse Lookup
To test the reverse lookup, query the DNS server with host1’s private IP address:
nslookup 10.128.100.101
This should return output like the following:
Output
11.10.128.10.in-addr.arpa name = host1.nyc3.example.com.
Authoritative answers can be found from:
If all of the names and IP addresses resolve to the correct values, that means
that your zone files are configured properly. If you receive unexpected values,
be sure to review the zone files on your primary DNS server (e.g.
db.nyc3.example.com and db.10.128).
As a final step, this tutorial will go over how you can maintain your zone
records.
Step 6 — Maintaining DNS Records
Now that you have a working internal DNS, you need to maintain your DNS records
so they accurately reflect your server environment.
Adding a Host to DNS
Whenever you add a host to your environment (in the same datacenter), you will
want to add it to DNS. Here is a list of steps that you need to take:
Primary Name Server
- Forward zone file: Add an A record for the new host, increment the value of Serial
- Reverse zone file: Add a PTR record for the new host, increment the value of Serial
- Add your new host’s private IP address to the trusted ACL (named.conf.options)
Test your configuration files:
sudo named-checkconf
sudo named-checkzone nyc3.example.com /etc/bind/zones/db.nyc3.example.com
sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128
Then reload BIND:
sudo systemctl reload bind9
Your primary server should be configured for the new host now.
Secondary Name Server
Add your new host’s private IP address to the trusted ACL (named.conf.options)
Check the configuration syntax:
sudo named-checkconf
Then reload BIND:
sudo systemctl reload bind9
Your secondary server will now accept connections from the new host.
Configure New Host to Use Your DNS
- Configure /etc/resolv.conf to use your DNS servers
- Test using nslookup
Removing a Host from DNS
If you remove a host from your environment or want to just take it out of DNS,
just remove all the things that were added when you added the server to DNS
(i.e. the reverse of the previous steps).
Conclusion
Now you may refer to your servers’ private network interfaces by name, rather
than by IP address. This makes configuring services and applications more
straightforward because you no longer have to remember the private IP addresses,
and the files will be less difficult to read and understand. Also, now you can
change your configurations to point to a new server in a single place, your
primary DNS server, instead of having to edit a variety of distributed
configuration files, which optimizes maintenance.
Once you have your internal DNS set up, and your configuration files are using
private FQDNs to specify network connections, it is critical that your DNS
servers are properly maintained. If they both become unavailable, your services
and applications that rely on them will cease to function properly. This is why
it is recommended to set up your DNS with at least one secondary server, and to
maintain working backups of all of them.
If you’d like to learn more about DNS, we encourage you to check out our article
An Introduction to DNS Terminology, Components, and Concepts.