Translation(s): English — French
Install the package.
Start/enable the named.service systemd unit.
This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.
Reason: Numerous style and content issues. (Discuss in Talk:BIND)
BIND (or named) is the most widely used Domain Name System (DNS) server.
- Debian Jessie and later
- TSIG Signature
- File /etc/bind/named. conf
- File /etc/bind/named. conf. default-zones
- File /etc/bind/named. conf. options
- File /etc/bind/named. conf. local
- File /etc/bind/named. conf. log
- Install and configure DNS
- Configure the /etc/named. conf file
- Define the forward and reverse zones
- Create forward and reverse zone files
- Add the nameserver IP to /etc/resolv. conf
- Start/restart and enable the named service
- Install Bind on the DNS Server
- Network Layout
- Install BIND on DNS Servers
- IPv4 Mode
- Debian Wheezy and earlier
- Our Goal
- Maintaining DNS Records
- Adding Host to DNS
- Primary Nameserver
- Secondary Nameserver
- Running BIND in a chrooted environment
- Creating the jail house
- Test Clients
- Forward Lookup
- Where does DNS get IP addresses?
- Serve the root zone locally
- Example Hosts
- Resource Records (RR)
- Files in /var/lib/bind/
- Configure as a Forwarding DNS Server
- How DNS works
- Automatically listen on new interfaces
- Wrap up
- Verify the DNS name resolution
- Query with nslookup
- Prerequisites and Goals
- Caching DNS Server
- Configure Secondary DNS Server
- /etc/resolv. conf File
- Configure as a Caching DNS Server
- Configuring BIND to serve DNSSEC signed zones
- Configure Primary DNS Server
- Configure Options File
- Configure Local File
- Create Forward Zone File
- Create Reverse Zone File(s)
- Check BIND Configuration Syntax
- Restart BIND
- Configure DNS Clients
- Ubuntu Clients
- CentOS Clients
- A configuration template for running a domain
- Creating a zonefile
- Configuring master server
- Links and Resources
- Making Client DNS Settings Permanent
- Client Manage
- Forward and reverse lookups
Putting a DNS server on a network allows for the replacement of IP addresses of individual machines by a name. As a result, it’s even possible to associate multiple names to the same machine to update the different available services. For example, www.example.com and pop.example.com, could both point to the primary server where the mail server and the business intranet reside, and the domain could be example.com. It’s easy to remember that these two services are running on the same machine whose IP address is 192.168.0.1.
DNS, or the Domain Name System, is often a difficult component to get right when learning how to configure websites and servers. While most people will probably choose to use the DNS servers provided by their hosting company or their domain registrar, there are some advantages to creating your own DNS servers.
In this guide, we will discuss how to install and configure the Bind9 DNS server as a caching or forwarding DNS server on Ubuntu 14.04 machines. These two configurations both have advantages when serving networks of machines.
The Domain Name System (DNS) is used to resolve (translate) hostnames to internet protocol (IP) addresses and vice versa. A DNS server, also known as a nameserver, maps IP addresses to hostnames or domain names.
In this article, you will learn the basics of DNS, from how DNS gets the IP address and hostname, to the concepts of forward and reverse lookup zones. It will also show you how to install and configure DNS, define and edit zone files, and verify whether the DNS can resolve to the correct address with the help of commands. If you are new to DNS, this article will help you play with it on your system using basic configurations.
If you are running your own DNS server, you might as well use it for all DNS lookups, or even #Serve the root zone locally by yourself. The former will require the ability to do recursive lookups. In order to prevent DNS Amplification Attacks, recursion is turned off by default for most resolvers. The default Arch /etc/named.conf file allows for recursion only on the loopback interface:
The factual accuracy of this article or section is disputed.
Reason: LAN networking is not recursive. (Discuss in Talk:BIND)
If you want to provide name service for your local network; e.g. 192.168.0.0/24, you must add the appropriate range of IP addresses to /etc/named.conf:
Debian Jessie and later
Create the file /etc/systemd/system/bind9.service with options «-t /var/bind9/chroot»:
However, at least by Debian 9 stretch, one could use the package maintainer’s version of the systemd unit file, and add the chroot overrides in: /etc/systemd/system/bind9.service.d/bind9.conf (or setting one’s chroot dir accordingly), e.g.:
However, at least as of Debian 10 buster, it’s probably better to remove such a /etc/systemd/system/bind9.service.d/bind9.conf file (as the manner in which systemd now starts bind9’s named, has changed, and will typically conflict with override done as the above), and now is best to have the overrides in /etc/default/bind9, e.g.:
OPTIONS=»-u bind -t /var/bind9/chroot»
and systemd will now incorporate the OPTIONS from /etc/default/bind9 and use those (as will at least also sysvinit).
Update the symlink to the unit file with:-
systemctl reenable bind9
Also advised to run:
for systemd (default) systems, to pick up any changes to systemd configuration files.
Now create the chroot directory structure:
Create the required device special files and set the correct permissions:
Move the current config directory into the new chroot directory:
mv /etc/bind /var/bind9/chroot/etc
Now create a symbolic link in /etc for compatibility:
ln -s /var/bind9/chroot/etc/bind /etc/bind
If you want to use the local timezone in the chroot (e.g. for syslog):
cp /etc/localtime /var/bind9/chroot/etc/
Change the ownership on the files you’ve just moved over and the rest of the newly created chroot directory structure:
Without that change, bind would terminate immediately on startup with error message «open: /etc/bind/named.conf: permission denied». To make these AppArmor changes effective:
systemctl reload apparmor
Finally tell rsyslog to listen to the bind logs in the correct place:
Restart rsyslog and start bind:
systemctl restart rsyslog
systemctl restart bind9
Also, alternative chroot approach to copying many files, etc., and more compatible for interacting utilities, etc. outside of chroot. One can relocate some directory(/ies), create some directories/files as/where needed, and use bind mounts, e.g.: included in /etc/fstab:
and we then also have:
in fact it’s possible to set up a configuration that not only works within chroot, but also works without using chroot — only changing how bind9/named is invoked, and nothing else, and between symbolic links and bind mounts, utilities outside the chroot will also interact with bind fine, «as if» it were outside the chroot — as they find the needed bind components logically in the same place, even though most are physically within the chroot stucture (and some, via bind mounts, are outside of the chroot and equally accessible inside and outside the chroot).
After installation, you might want to get familiar with some of the configuration files. They are in the directory /etc/bind/
The purpose of this signature is to authenticate transactions with BIND. Thus, the DHCP server cannot update the example.com domain if it loses this key. Copy and paste an existing key
The footprint associated with the key is 53334. We get two files, one with an extension key and the other with a private extension. This substitutes the key in the file ns-example-com_rndc-key with the one in one of these two files.
The file ns-example-com_rndc-key should not be made world readable for security reasons. This should be inserted into the bind configuration by an include because the bind configuration itself is world-readable. Also, it’s a good idea to delete the key and private files generated before.
File /etc/bind/named. conf
This file is the main configuration file for the DNS file.
File /etc/bind/named. conf. default-zones
Note: as of Debian 7 «Wheezy» bind9 ships with a file containing default forward, reverse, and broadcast zones.
File /etc/bind/named. conf. options
This file contains all the configuration options for the DNS server
The port associated with the query-source option must not in any case be frozen because it jeopardizes the DNS transactions in the case of a resolver.
M. Rash wrote an interesting article about this and how to force the source port randomly via the iptables: Mitigating DNS Cache Poisoning Attacks with iptables
To reduce the delay timeout for UDP connections, and thus highlight the randomization, which by default is 30s by tuple, simply update the parameter net.netfilter.nf_conntrack_udp_timeout
# sysctl -w net.netfilter.nf_conntrack_udp_timeout=10
to get timeout of 10s.
File /etc/bind/named. conf. local
This file contains the local DNS server configuration, and this is where you declare the zones associated with this server’s domain(s).
NOTE: if you create a local non-FQDN and call it .local it clashes with some other packages (which?). Edit /etc/nsswitch.conf and move dns right after the files on the host line makes .local domains work.
File /etc/bind/named. conf. log
With Debian Jessie, you need to create this file in /etc/bind
Install and configure DNS
BIND is a nameserver service responsible for performing domain-name-to-IP conversion on Linux-based DNS servers.
The BIND package provides the named service. It reads the configuration from the /etc/named and /etc/named.conf files. Once this package is installed, you can start configuring DNS.
Configure the /etc/named. conf file
First, add or edit the two values in the options field. One is the DNS server address, and the other is the allow-query to any.
Here are the values from the above file:
Define the forward and reverse zones
Define the forward and reverse zones in the /etc/named.conf or /etc/named.rfc1912.zones (you can define zones in either of those files). In this example, I am appending zone definition details to the /etc/named.rfc1912.zones file.
Create forward and reverse zone files
You also need to create forward and reverse zone files in the /var/named directory.
Note: By default, the named.conf file includes the /var/named directory for checking zone files. Sample zone files named.localhost and named.loopback are created during the installation of the BIND package.
(Ashish Bharadwaj, CC BY-SA 4.0)
Add the nameserver IP to /etc/resolv. conf
Save the file and reload (restart) NetworkManager.
# systemctl reload NetworkManager
After you reload NetworkManager, it won’t update /etc/resolv.conf. Now, you can manually add the nameserver’s IP address to the /etc/resolv.conf file.
Start/restart and enable the named service
If the named service is not running or is disabled, then start and enable it. If it is already active (running) and you made all these configurations, you need to restart the service to make changes.
Install Bind on the DNS Server
Regardless of which configuration choice you wish to use, the first step in implementing a Bind DNS server is to install the actual software.
The Bind software is available within Ubuntu’s default repositories, so we just need to update our local package index and install the software using apt. We will also include the documentation and some common utilities:
sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-doc
Now that the Bind components are installed, we can begin to configure the server. The forwarding server will use the caching server configuration as a jumping off point, so regardless of your end goal, configure the server as a Caching server first.
We get internet access through an xxxbox (192.168.1.1), two DNS servers provided by our ISP (18.104.22.168, 22.214.171.124). In fact, these two latter servers will ever be referred to in the configuration because the xxxbox will be in charge of resolving names if the packet destination isn’t known. Consequently, I consider the xxxbox like a primary server outside of our domain. The “sid” server (192.168.1.10) is connected to the xxxbox via its primary network card. It’s also connected to the LAN (192.168.0.0/24) by its secondary network interface(192.168.0.1). It’s on this that we are going to install the primary DNS server for our domain example.com (rfc2606) All the computers on the LAN are automatically assigned a single address by the DHCP service. The DHCP also provides the primary DNS server’s address for our domain, and updates the host names for the zone example.com so they can be associated with an ip address.
Install BIND on DNS Servers
Note: Text that is highlighted in red is important! It will often be used to denote something that needs to be replaced with your own settings or that it should be modified or added to a configuration file. For example, if you see something like host1.nyc3.example.com, replace it with the FQDN of your own server. Likewise, if you see host1_private_IP, replace it with the private IP address of your own server.
On both DNS servers, ns1 and ns2, update apt:
Now install BIND:
Before continuing, let’s set BIND to IPv4 mode. On both servers, edit the bind9 service parameters file:
OPTIONS=»-4 -u bind»
Save and exit.
Now that BIND is installed, let’s configure the primary DNS server.
Debian Wheezy and earlier
This option is found in the bind service config file /etc/default/bind9
The bind start script /etc/init.d/bind9 reads this config file when the service is started.
To begin, start by stopping the bind service:
Then edit /etc/default/bind9:
OPTIONS=»-u bind -4 -t /var/bind9/chroot»
Edit the PIDFILE variable in /etc/init.d/bind9 to the correct path:
/etc/init.d/rsyslog restart; /etc/init.d/bind9 start
By the end of this tutorial, we will have a primary DNS server, ns1, and optionally a secondary DNS server, ns2, which will serve as a backup.
Here is a table with example names and IP addresses:
Let’s get started by installing our Primary DNS server, ns1.
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 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:
Then reload BIND:
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 steps above).
Running BIND in a chrooted environment
Running in a chroot environment is not required but improves security.
This article or section needs expansion.
Reason: /srv/ is an odd place for chroots, /var/lib/ would be a more common place. (Discuss in Talk:BIND)
Creating the jail house
In order to do this, we first need to create a place to keep the jail, we shall use /srv/named, and then put the required files into the jail.
Copy over required system files:
Set up required nodes in /dev/:
# mknod /srv/named/dev/null c 1 3
# mknod /srv/named/dev/random c 1 8
Set ownership of the files:
# chown -R named:named /srv/named
This should create the required file system for the jail.
Next we need a replacement unit file so that the service calls bind which will allow force bind into the chroot:
ExecStart=/usr/bin/named -4 -f -u named -t «/srv/named»
Now, reload systemd with daemon-reload, and start the named-chroot.service.
The package bind9 will be used for installation.
# apt-get install bind9
and then if you want to also install the documentation (very useful):
# apt-get install bind9-doc
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.
To test the reverse lookup, query the DNS server with host1’s private IP address:
126.96.36.199.in-addr.arpa name = host1.nyc3.example.com.
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).
Congratulations! Your internal DNS servers are now set up properly! Now we will cover maintaining your zone records.
Where does DNS get IP addresses?
You might wonder how DNS gets the IP of the corresponding hostname or domain name. How does DNS search among different IP addresses and associate your domain name correctly? Who stores those mappings between domain names and IP addresses?
The DNS workflow illustrates how communication happens within DNS and how it resolves the addresses.
Serve the root zone locally
To manage a recursive resolver, you typically need to configure a root hints file. This file contains the names and IP addresses of the authoritative name servers for the root zone.
Grab the file from IANA website and place it into /var/named.
Edit your server config, adding the respective file:
Recursion also should be allowed in the config. See #Allow recursion.
If you are unfamiliar with DNS concepts, it is recommended that you read at least the first three parts of our Introduction to Managing DNS.
Note: Your existing 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 easily 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 utilize multiple datacenters, you can set up an internal DNS within each respective datacenter.
Resource Records (RR)
DNS is made up of several registrations, RR or Resource Records, defining the various domain information. The first is dedicated to name resolution, in our case, it is the file db.example.com. The second will be used for reverse name resolution, it is the file db.example.com.inv.
Files in /var/lib/bind/
In the first example, we can see the directive $TTL (Time To Live), which expresses the duration (in seconds) validity, by default, of the information contained in the RRs. Once this time expires, it is necessary to recheck the data.
Then, we have each RR specified with its type. Some examples are:
For a complete list, please refer to the iana list
Configure as a Forwarding DNS Server
If a forwarding DNS server is a better fit for your infrastructure, we can easily set that up instead.
We will start with the configuration that we left off in the caching server configuration. The named.conf.options file should look like this:
We will be using the same ACL list to restrict our DNS server to a specific list of clients. However, we need to change the configuration so that the server no longer attempts to perform recursive queries itself.
To do this, we do not change recursion to no. The forwarding server is still providing recursive services by answering queries for zones it is not authoritative for. Instead, we need to set up a list of caching servers to forward our requests to.
Afterward, we should set the forward directive to “only” since this server will forward all requests and should not attempt to resolve requests on its own.
The configuration file will look like this when you are finished:
One final change we should make is to the dnssec parameters. With the current configuration, depending on the configuration of forwarded DNS servers, you may see some errors that look like this in the logs:
To avoid this, change the dnssec-validation setting to “yes” and explicitly enable dnssec:
. . .
auth-nxdomain no; # conform to RFC1035
. . .
Save and close the file when you are finished. You should now have a forwarding DNS server in place. Continue to the next section to validate your configuration files and restart the daemon.
How DNS works
When a client requests information from a nameserver, it usually connects to port 53, and then the nameserver resolves the name requested.
Automatically listen on new interfaces
By default bind scan for new interfaces and stop listening on interfaces which no longer exist every hour. You can tune this value by adding :
parameter into named.conf options section. Max value is 28 days. (40320 min)
You can disable this feature by setting its value to 0.
Then restart the service.
In this article, you learned what DNS is and how it works. Also, you now know what forward and reverse lookup zones are and how they work. You also learned how to install the BIND package, which is responsible for setting up DNS on the system and configuring the named files and lookup zones. Finally, you learned two commands, nslookup and dig, to interrogate DNS resolutions.
Verify the DNS name resolution
You have installed the BIND package, configured named files, created lookup zones, and restarted the service to make configurations take effect. Now use the nslookup and dig commands to check whether DNS is working properly and verify whether you are getting the intended results.
Query with nslookup
Here is a forward lookup, where DNS responds with 192.168.11.132 as an IP for servera.example.com:
This example displays a reverse lookup, where the DNS server responds with servera.example.com as the domain name for 192.168.25.132:
Prerequisites and Goals
To complete this guide, you will first need to be familiar with some common DNS terminology. Check out this guide to learn about some of the concepts we will be implementing in this guide.
We will be demonstrating two separate configurations that accomplish similar goals: a caching and a forwarding DNS server.
We will show you how to configure the client machine to use the DNS server for queries. We will show you how to configure the DNS server in two different configurations, depending on your needs.
Caching DNS Server
The first configuration will be for a caching DNS server. This type of server is also known as a resolver because it handles recursive queries and generally can handle the grunt work of tracking down DNS data from other servers.
When a caching DNS server tracks down the answer to a client’s query, it returns the answer to the client. But it also stores the answer in its cache for the period of time allowed by the records’ TTL value. The cache can then be used as a source for subsequent requests in order to speed up the total round-trip time.
Almost all DNS servers that you might have in your network configuration will be caching DNS servers. These make up for the lack of adequate DNS resolver libraries implemented on most client machines. A caching DNS server is a good choice for many situations. If you do not wish to rely on your ISPs DNS or other publicly available DNS servers, making your own caching server is a good choice. If it is in close physical proximity to the client machines, it is also very likely to improve the DNS query times.
The second configuration that we will be demonstrating is a forwarding DNS server. A forwarding DNS server will look almost identical to a caching server from a client’s perspective, but the mechanisms and work load are quite different.
A forwarding DNS server offers the same advantage of maintaining a cache to improve DNS resolution times for clients. However, it actually does none of the recursive querying itself. Instead, it forwards all requests to an outside resolving server and then caches the results to use for later queries.
This lets the forwarding server respond from its cache, while not requiring it to do all of the work of recursive queries. This allows the server to only make single requests (the forwarded client request) instead of having to go through the entire recursion routine. This may be an advantage in environments where external bandwidth transfer is costly, where your caching servers might need to be changed often, or when you wish to forward local queries to one server and external queries to another server.
Configure 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, the secondary DNS server is much easier to configure.
On ns2, edit the named.conf.options file:
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)
/etc/bind/named.conf.options — updated 2 of 2 (secondary)
Save and exit named.conf.options. This file should look exactly like 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:
Define slave zones that correspond to the master zones on the primary DNS server. Note that the type is “slave”, the file does not contain a path, and there is a masters directive which should be set to the primary DNS server’s private IP. 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)
Now save and exit named.conf.local.
Once that checks out, restart bind
Now you have primary and secondary DNS servers for private network name and IP address resolution. Now you must configure your servers to use your private DNS servers.
/etc/resolv. conf File
It’s no more complicated than that !
Configure as a Caching DNS Server
First, we will cover how to configure Bind to act as a caching DNS server. This configuration will force the server to recursively seek answers from other DNS servers when a client issues a query. This means that it is doing the work of querying each related DNS server in turn until it finds the entire response.
The Bind configuration files are kept by default in a directory at /etc/bind. Move into that directory now:
We are not going to be concerned with the majority of the files in this directory. The main configuration file is called named.conf (named and bind are two names for the same application). This file simply sources the named.conf.options file, the named.conf.local file, and the named.conf.default-zones file.
For a caching DNS server, we will only be modifying the named.conf.options file. Open this in your text editor with sudo privileges:
sudo nano named.conf.options
With the comments stripped out for readability, the file looks like this:
To configure caching, the first step is to set up an access control list, or ACL.
We explicitly turned recursion on, and then configured the allow-query parameter to use our ACL specification. We could have used a different parameter, like allow-recursion to reference our ACL group. If present and recursion is on, allow-recursion will dictate the list of clients that can use recursive services.
However, if allow-recursion is not set, then Bind falls back on the allow-query-cache list, then the allow-query list, and finally a default of localnets and localhost only. Since we are configuring a caching only server (it has no authoritative zones of its own and doesn’t forward requests), the allow-query list will always apply only to recursion. We are using it because it is the most general way of specifying the ACL.
When you are finished making these changes, save and close the file.
This is actually all that is required for a caching DNS server. If you decided that this is the server type you wish to use, feel free to skip ahead to learn how to check your configuration files, restart the service, and implement client configurations.
Otherwise, continue reading to learn how to set up a forwarding DNS server instead.
Configuring BIND to serve DNSSEC signed zones
DNSSEC validation is enabled by default. Do not forget to check that «edns» is not disabled.
On master DNS server:
$ dnssec-keygen -a NSEC3RSASHA1 -b 2048 -n ZONE example.com
$ dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE example.com
Now bind will sign zone automatically. (This example assumes that all required files are in /var/named/master/)
Then you should pass DS records (from dsset-example.com. file) to parent zone owner probably using your registrar website. It glues parent zone with your KSK.
KSK (and corresponding DS records) should be changed rarely because it needs manual intervention, ZSK can be changed more often because this key is usually shorter to be faster in signature checking.
You can schedule old ZSK key expiration and generate new one using:
$ dnssec-settime -I +172800 -D +345600 Kexample.com.+000+111111.key
$ dnssec-keygen -S Kexample.com.+000+111111.key -i 152800
Bind should automatically use new ZSK key at appropriate time.
There are external mechanisms such as OpenDNSSEC with fully-automatic key rollover available.
see: DNSSEC Howto for BIND 9.9+
Configure Primary DNS Server
BIND’s configuration consists of multiple files, which are included from the main configuration file, named.conf. These filenames begin with “named” because that is the name of the process that BIND runs. We will start with configuring the options file.
Configure Options File
On ns1, open the named.conf.options file for editing:
/etc/bind/named.conf.options — 1 of 3
/etc/bind/named.conf.options — 2 of 3
Below the directory directive, add the highlighted configuration lines (and substitute in the proper ns1 IP address) so it looks something like this:
/etc/bind/named.conf.options — 3 of 3
Now save and exit named.conf.options. The above configuration specifies that only your own servers (the “trusted” ones) will be able to query your DNS server.
Next, we will configure the local file, to specify our DNS zones.
Configure Local File
On ns1, open the named.conf.local file for editing:
Aside from a few comments, the file should be empty. Here, we will specify our forward and reverse zones.
/etc/bind/named.conf.local — 1 of 2
/etc/bind/named.conf.local — 2 of 2
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 exit the named.conf.local file.
Now that our zones are specified in BIND, we need to create the corresponding forward and reverse zone files.
Create Forward Zone File
The forward zone file is where we 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.
Let’s create the directory where our zone files will reside. According to our named.conf.local configuration, that location should be /etc/bind/zones:
Now let’s edit our forward zone file:
/etc/bind/zones/db.nyc3.example.com — original
/etc/bind/zones/db.nyc3.example.com — updated 1 of 3
Now 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 a “delete this line” comment above.
/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.
Then add the A records for your hosts that belong in this zone. This includes any server whose name we 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
Save and exit the db.nyc3.example.com file.
Now let’s move onto the reverse zone file(s).
Create Reverse Zone File(s)
Reverse zone file are where we 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.
Edit the reverse zone file that corresponds to the reverse zone(s) defined in named.conf.local:
/etc/bind/zones/db.10.128 — original
In the same manner as the forward zone file, you will want to edit the SOA record and increment the serial value. It should look something like this:
/etc/bind/zones/db.10.128 — updated 1 of 3
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 above.
/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
Save and exit the reverse zone file (repeat this section if you need to add more reverse zone files).
Check BIND Configuration Syntax
If your named configuration files have no syntax errors, you will return to your shell prompt and see no error messages. 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.
named-checkzone nyc3.example.com db.nyc3.example.com
named-checkzone .in-addr.arpa /etc/bind/zones/db.10.128
When all of your configuration and zone files have no errors in them, you should be ready to restart the BIND service.
Your primary DNS server is now setup and ready to respond to DNS queries. Let’s move on to creating the secondary DNS server.
Configure 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 nameservers. This process varies depending on OS, but for most Linux distributions it involves adding your name servers to the /etc/resolv.conf file.
On Ubuntu and Debian Linux VPS, you can edit the head file, which is prepended to resolv.conf on boot:
search nyc3.example.com # your private domain
nameserver 10.128.10.11 # ns1 private IP address
nameserver 10.128.20.12 # ns2 private IP address
Now run resolvconf to generate a new resolv.conf file:
Your client is now configured to use your DNS servers.
On CentOS, RedHat, and Fedora Linux VPS, simply edit the resolv.conf file:
Now save and exit. Your client is now configured to use your DNS servers.
A configuration template for running a domain
A more elaborate example is DNS server with BIND9, while this shows how to set up internal network name resolution.
Creating a zonefile
$ORIGIN defines the default suffix for all names which do not already end with a . (dot), e.g. mail will be expanded to mail.$ORIGIN ⇒ mail.domain.tld. everywhere.
$TTL defines the default time-to-live (i.e. cache expiry time) for all records which do not have their own TTL specified. Here it is 2 hours.
Serial must be incremented manually before reloading named every time you change a resource record for the zone. Otherwise secondary servers (replicas or slaves) will not re-transfer the zone: they only do it if the serial is greater than that of the last time they transferred the zone. This example uses the somewhat common YYYYMMDDXX format, but this is not required; the serial number can also just start at 1.
Configuring master server
Add your zone to /etc/named.conf:
Reload the named.service unit to apply the configuration change.
Links and Resources
Now that you have your server up and running, you can configure your client machine to use this DNS server for queries.
Log into your client machine. Make sure that the client you are using was specified in the ACL group you set for your DNS server. Otherwise the DNS server will refuse to serve requests for the client.
We need to edit the /etc/resolv.conf file to point our server to the name server. Changes made here will only last until reboot, which is great for testing. If we are satisfied with the results of our tests, we can make these changes permanent.
Open the file with sudo privileges in your text editor:
sudo nano /etc/resolv.conf
The file will list the DNS servers to use to resolve queries by setting the nameserver directives. Comment out all of the current entries and add a nameserver line that points to your DNS server:
# nameserver 188.8.131.52
# nameserver 184.108.40.206
# nameserver 220.127.116.11
Now, you can test to make sure queries can resolve correctly by using some common tools.
You can use ping to test that connections can be made to domains:
ping -c 1 google.com
PING google.com (18.104.22.168) 56(84) bytes of data.
64 bytes from sea09s01-in-f1.1e100.net (22.214.171.124): icmp_seq=1 ttl=55 time=63.8 ms
— google.com ping statistics —
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 63.807/63.807/63.807/0.000 ms
This means that our client can connect with google.com using our DNS server.
We can get more detailed information by using DNS specific tools like dig. Try a different domain this time:
You can see that the query took 36 milliseconds. If we make the request again, the server should pull the data from its cache, decreasing the response time:
As you can see, the cached response is significantly faster.
We can also test the reverse lookup by using the IP address that we found (126.96.36.199 in our case) with dig’s -x option:
dig -x 188.8.131.52
As you can see, the reverse lookup also succeeds.
Back on your DNS server, you should see if any errors have been recorded during your tests. One common error that may show up looks like this:
These indicate that the server is trying to resolve IPv6 information but that the server is not configured for IPv6. You can fix this issue by telling Bind to only use IPv4.
To do this, open the /etc/default/bind9 file with sudo privileges:
sudo nano /etc/default/bind9
Inside, modify the OPTIONS parameter to include the -4 flag to force IPv4 only behavior:
OPTIONS=»-u bind -4″
Restart the server:
sudo service bind9 restart
You should not see these errors in the logs again.
Making Client DNS Settings Permanent
As mentioned before, the /etc/resolv.conf settings that point the client machine to our DNS server will not survive a reboot. To make the changes last, we need to modify the files that are used to generate this file.
If the client machine is running Debian or Ubuntu, open the /etc/network/interfaces file with sudo privileges:
sudo nano /etc/network/interfaces
Look for the dns-nameservers parameter. You can remove the existing entries and replace them with your DNS server or just add your DNS server as one of the options:
. . .
iface eth0 inet static
. . .
Save and close the file when you are finished. Next time you boot up, your settings will be applied.
If the client is running CentOS or Fedora, you need to open the /etc/sysconfig/network/network-scripts/ifcfg-eth0 file instead:
sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0
Inside, look for the lines that begin with DNS. Change DNS1 to your DNS server. If you don’t want to use the other DNS servers as a fallback, remove the other entries:
Save and close the file when you are finished. Your client should use those settings at next boot.
option domain-name «example.com»
option domain-name-server sid.example.com
It must be added to the file (I think) the areas for which DHCP should automatically perform updates.
— example.com. : for the direct zone of this article,
— 0.168.192.in-addr.arpa. : for the inverse zone of this article.
Forward and reverse lookups
The forward lookup zone uses the domain name to search for IP addresses, whereas the reverse lookup zone uses IP addresses to search for the domain name.
Now you may refer to your servers’ private network interfaces by name, rather than by IP address. This makes configuration of services and applications easier because you no longer have to remember the private IP addresses, and the files will be easier to read and understand. Also, now you can change your configurations to point to a new servers in a single place, your primary DNS server, instead of having to edit a variety of distributed configuration files, which eases 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.
You should now have either a caching or forwarding DNS server configured to serve your clients. This can be a great way to speed up DNS queries for the machines you are managing.
If you want to create a DNS server that is authoritative for your own domain zones, you can configure an authoritative-only DNS server or combine these solutions.