Systems Administration Lab Sheet 10 – DNS Page 1 of 10 Domain Name Service An important part of managing server configuration and infrastructure includes maintaining an easy way to look up network interfaces and IP addresses by name, by setting up a proper Domain Name Service or System (DNS). Using fully qualified domain names (FQDNs), instead of IP addresses, to specify network addresses eases 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. DNS is a protocol designed to provide name - to - IP address resolution. It is part of the standard TCP/IP protocol suite and one of several protocols that can provide this functionality; others include Network I nformation Service (NIS) and LDAP. In this lab, you will configure an internal (private network) DNS server using the BIND name server software (BIND9) using your three virtual machines. When configured correctly this can be used to resolve private host n ames and private IP addresses. This provides a central way to manage your hostnames and private IP addresses, which is indispensable when your environment expands to more than a few hosts. BIND is open - source software that stands for “Berkeley Internet Nam e Domain”, because the software originated at the University of California at Berkeley. Let’s get Started To complete this lab, you will use all three VM’s: Linux server , Linux client and Windows client . By the end of the lab you will have set the Linux server up as the Primary DNS server with a hostname of ns 2 and configured the client s with hostname s of host 2 ( L inux client) and host3 ( W indows client ) NOTE: In industry it is recommended to have a Secondary DNS server to act as a backup. Therefore, to appreciate what is involved in configuring DNS in an organisation , we would have a t least one more server to act as the Secondary DNS server , but this is beyond the resources available for the module Let’s say we decided that it makes sense to use the following naming scheme " abc tech .ie" to refer to our private subnet or zone. Therefore, the priv ate Fully - Qualified Domain Name (FQDN) of our Linux server is “ns2 abc.tech .ie ” , the FQDN of our Linux client will be "host 2 abc.tech .ie" and the FQDN of our Windows client will be “host3.abc.tech.ie” Here is a table with a clear breakdown of t hose details : Host name Role Private FQDN Private IP Address ns 2 Primary DNS Server ( linux server) ns 2 abc.tech .ie 192.168.56.101 host 2 Generic Host ( linux client) host 2 abc.tech .ie 192.168.56.102 host3 Generic Host ( win dow s client) h ost 3 abc.tech .ie 192.168.56.103 Now that you are familiar with sudo you should use this command when higher privileges are required (rather than operate directly under the root account which is not recommended). Therefore make sure labuser is added to the sudoers file, as we covered previously, on both your linux server and client. Systems Administration Lab Sheet 10 – DNS Page 2 of 10 STEP 1 : Setting the server’s hostname First, we need to configure our Linux Server to set the host’s name. To do this: Launch your Linux server VM and l ogin with the labuser account. Notice how the command prompt currently the username you are logged on under as well as the hostname of the server CentOSServe r as follow s : [labuser@CentOSServer ~]$ Check the current hostname (computer name) of your server by typing: hostnamectl status It will respond with details including the Static hostname: CentOSServer As per the table above, we want to rename our server’s hostname to ns2 To rename the hostname of the DNS server, you can either type the command below : hostnamectl set - hostname ns2 Log out and log in again to allow the hostname to be changed. Then c heck the hostname again Your command prompt should now look like the following: [labuser@ ns2 ~]$ Now that our server has been renamed to ns 2 , Let's begin by installing our Primary DNS server. STEP 2: Install BIND on the Server On your ns2 server install BIND and some relevant utilities with yum Confirm the prompt by entering y sudo yum install bind bind - utils Now that BIND is installed, let's configure the primary DNS server. Remember: From now on you will be required to edit existing configuration files on the server and client. It is recommended and good practice that you always make a copy of the original file and save it in the same location. Therefore, if things go wrong or you need to refer to the original settings you have a copy of the original file . So, for example if you are asked to edit a file called /etc/named.conf then you should ma ke a copy of it first and save it with .old or .bckup appended to t he end of the file name. For example : cp /etc/named.conf /etc/named.conf.old STEP 3: Basic BIND Configuration NOTE: This lab covers a basic configuration of BIND. Configuring BIND in an organisation involves many more components. Which of these components you would configure depends on several factors, such as the type of BIND server (caching, forwarder, or authoritative) and what features you would want the BIND server to have (security features for example). Systems Administration Lab Sheet 10 – DNS Page 3 of 10 The primary configuration file for the BIND server is the /etc/named.conf file. A sample version of the configuration file is provided by default when you install B IND The file is read by the DNS server (called named because that is the name of the process that BIND runs ) when it is started. Have a look at the current default settings in the /etc/named.conf file before we begin editing it. sudo cat /etc/named.conf Don’t be intimidated by all the settings you see in the default file ! Most of them are straightforward once you understand how the DNS server works. T he options section of the named.conf file is used to provide general settings for the DNS server such as the location zone files. I have added a link on Blackboard, which describes the different settings in the named.conf file. Now on your server (ns2) edit the named.conf file a bove the existing options block, and create a new ACL block called "trusted". This is where we will define a list of clients and their private IPs that we will allow recursive DNS queries from (i.e. your clients that are in the same private network as ns2 ). acl "trusted" { 192.168.56.101; # ns 2 - can be set to localhost 192.168.56.102; # host 2 192.168.56.10 3 ; # host 3 }; Now save and exit. Now that we have our list of trusted DNS clients, we will want to edit the contents of the options block. Add the private IP address of ns 2 to the listen - on port 53 directive, and comment out the listen - on - v6 line by adding the hash symbol # before it: options { listen - on port 53 { 127.0.0.1; 192.168.56.101; }; # listen - on - v6 port 53 { ::1; }; Below those entries, change allow - query directive from "localhost" to "trusted": allow - quer y { trusted; }; # allows queries from "trusted" clients A dd the following line to the very bottom of the file, below two other ‘include’ lines : include "/etc/named/named.conf.local"; Save and Exit the file. Next, we will configure the local file, to specify our DNS zones. Systems Administration Lab Sheet 10 – DNS Page 4 of 10 STEP 4: Configure Local File On ns 2 , create a new file called named. conf.local in the /etc/named directory as follows : sudo vi / etc /named/na med.conf.local Here, we will specify our forward and reverse zones. Add the forward zone in the first 4 lines seen below and a ssuming that our private subnet is 192.168.56.0/24, add the reverse zone by adding the last 4 lines (note that our reverse zone name starts with "56.168.192" which is the octet reversal of "192.168. 56") Take extreme care when typing - : semicolons, double quotes , curly brackets etc. where specified and spacing is also important. zone " abc.tech.ie " { type master; file "/etc/named/zones/db. abc.tech.ie "; # zone file path }; zone "56.168.192.in - addr.arpa" { type master; file "/etc/named/zones/db.192.168.56"; # 192.168.56.0/24 subnet }; When you are finished adding all of your desired zones, save and exit the named.conf.local file. Note : If you did have more servers which span multiple private subnets but were in the same datacenter, you would have to be sure to specify an additional zone and zone fil e for each distinct subnet. Now that our zones are specified , we need to create the corresponding forward and reverse zone files. STEP 5: Create Forward Zone File (for name to IP resolution) The forward zone file is where we define DNS records for forward DNS lookups. That is, when the DNS receives a name query, "host 2 abc.tech. ie" for example, it will look in the forward zone file to resolve host 2 's corresponding private IP address. C reate the directory where our zone files will reside. According to our named.conf.local configuration, that location should be /etc/named/zones : sudo chmod 755 /etc/named sudo mkdir /etc/named/zones Now let's create and edit our forward zone file: sudo vi /etc/named/zones/db. abc.tech. ie Systems Administration Lab Sheet 10 – DNS Page 5 of 10 Type the following EXACTLY as below ( I recommend using the tab key to create spacing between columns ) : $TTL 1D @ IN SOA ns 2 abc tech .ie. admin. abc.tech .ie. ( 0 ; Serial 3H ; Refresh 15 M ; Retry 1W ; Expire 1D ) ; Negative Cache TTL ; name servers - NS records IN NS ns 2 abc.tech .ie. ; name servers - A records ns 2 abc.tech .ie. IN A 192.168.56.101 ; 192.168.56.0/24 - A records host 2 abc.tech .ie. IN A 192.168.56.102 h ost 3 abc.tech.ie IN A 192.168.56.10 3 Save and exit the db.abc.tech.ie file. What does all that mean? The first line shows default TTL (time to live) for records when no ttl is defined. Y ou then add ed the SOA record. Every time you edit a zone file, you should increment the serial value before you restart the named process. The @ symbol represents our zone name which is abc.tech.ie and we are saying that fo r abc.tech.ie SOA (Start of Authority), authoritative DNS is ns2.abc.tech.ie. admin.abc.tech.ie would be the email address. The next entries are used by slave DNS servers. Whenever Serial number is incremented, the slave DNSes will know that zone data has changed and will download it. Every three hour s the slave will check with this master server to see if zone data has been changed by looking at serial number. If, for some reasons, it cannot contact master, then it will retry every 15 minutes until 1 week has passed. When that happens and slave is still unable to contact master, it will expire the zone data and will stop answering name resolution queries for this zone. Next is negative caching TTL. This is how long a remote name server can cache negat ive responses about the zone. These are answers that say that a particular domain name or the type of data sought for a particular domain name doesn’t exist. Then you add ed your nameserver records. Note that the second column specif ies that these are "NS" records. There are different record types. First is NS, name server type. Names server for our zones is defined here which we have only one here (at least two name servers are required for internet domains). Then you add ed the A records for your hosts tha t belong in this zone. This includes any server whose name we want to end with ". abc.tech.ie ". Using our example names and private IP addresses, we add A records for ns 2 , host 2 and host3 . The A record type (name to IP mapping) is for our authoritative dns server. We have to set this record because if our DNS server name cannot be resolved, how come someone could contact it for name resolutions of other hosts. Next , we added A records for host2.abc.tech.ie and host3.abc.tech.ie. T hat’s it for configuring DNS for this zone. Now let's move onto the reverse zone file(s). Systems Administration Lab Sheet 10 – DNS Page 6 of 10 STEP 6: Create Reverse Zone File (for IP to name resolution) Reverse zone file is where we define DNS PTR records for reverse DNS lookups. That is, when the DNS receives a query by IP address, "192.168.56.102" for example, it will look in the reverse zone file(s) to resolve the corresponding FQDN, "host 2 abc.tech.ie " in this case. On ns 2 , for each reverse zone specified in the named.conf.local file, create a reverse zone file. Edit the reverse zone file that corresponds to the reverse zone(s) defined in named.conf.local : sudo vi /etc/named/zones/db.192.168.56 Type the following so it looks EXACTLY like below : $TTL 1D @ IN SOA ns 2 abc tech .ie. admin. abc.tech .ie. ( 0 ; Serial 3H ; Refresh 15M ; Retry 1W ; Expire 1D ) ; Negative Cache TTL ; name servers - NS records @ IN NS ns 2 abc.tech.ie @ IN PTR abc.tech.ie. ; name server hostname to IP resolve ns2 IN A 192.168.56.101 ; PTR Records 101 IN PTR ns 2 abc.tech. ie. ; 192.168.56.101 102 IN PTR host 2 abc.tech .ie. ; 192.168.56.102 10 3 IN PTR host 3 abc.tech .ie. ; 192.168.56.10 3 Remember every time you edit a zone file, you should increment the serial value before you restart the named process, for example you could in increment it to "3" the next time you edit it Much like the forward zone file except you add PTR records instea d of A records for all of your clients whose IP addresses are on the subnet of the zon e file that you are editing. T his includes all of our hosts because they are all on the 192.168.56.0/24 subnet. Note that the fi rst column consists of the last number of your private IP addresses. Save and exit the reverse zone file Systems Administration Lab Sheet 10 – DNS Page 7 of 10 STEP 7: Check 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, 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 steps above, then try 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 " abc.tech.ie " f orward zone configuration, run the following command : sudo named - checkzone abc.tech.ie /etc/named/zones/db. abc.tech. ie And to check the "56.168.192.in - addr.arpa" reverse zone configuration, run the following command: sudo named - checkzone 56.168.192.in - ad dr.arpa /etc/named/zones/db.192.168.56 If there are no errors with the files it will respond with “loaded serial 0 OK ” When all of your configuration and zone files have no errors in them, you are ready to restart the BIND service. STEP 8 : Start BIND To start BIND: systemctl start named Now you will want to enable it, so it will start on boot: systemctl enable named Confirm it is now running by checking its status : systemctl status named When it highlights in green font Active: active (running) y our primary DNS server is now setup and ready to respond to DNS queries. Let's move on to configuring the client. Systems Administration Lab Sheet 10 – DNS Page 8 of 10 STEP 9 : Configure Linux client The first thing we need to do on the client s is to rename the ir hostname s to host 2 (on linux client) and host3 (on windows client) F ollow the same steps you did earlier to rename the linux client to host2 and see if you can figure out how to change it on the windows client yourself. Before your server in the "trusted" ACL can query your DNS server, you must configur e each of them to use ns 2 as nameserver. This process varies depending on OS, but for most Linux distributions it involves adding your name servers to the /etc/resolv.conf file. On CentOS and RedHat simply edit the resolv.conf file : s udo vi /etc/resolv.conf Then add the following line to the TOP of the file: search abc.tech. ie # your private domain nameserver 192.168.56.101 # ns 2 private IP address Now save and exit. Your client is now configured If you find when these settings revert to the original after logging out/rebooting then see possible resolution on Blackbo ard under ‘ Troubleshooting ’ **You will also need to edit the resolv.conf file on the server with the same settings as above. STEP 10 : Configure Windows client Very simply, on the windows client, open up your IP v4 configuration settin gs (which you edited in Lab 08 ) and add the DNS Server IP address. Don ’ t forget to rename the Windows machine to host3. Systems Administration Lab Sheet 10 – DNS Page 9 of 10 STEP 1 1 : Test clients Use nslookup ( included in the "bind - utils" package ) to test if your client can query your name server. You should be able to do this on all clients that you would have configured and are in the "trusted" ACL. Forward Lookup (name to IP) For example, we can perform a forward lookup to retrieve the IP address of host 2 abc.tech .ie by running the following command on the linux client: nslookup host 2 Querying "host 2 " expands to "host 2 abc.tech .ie because of 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 successful output of the command above look s like the following: Server: 192.168.56. 101 Address: 192.168.56.101#53 Name: host 2 abc.tech.ie Address: 192.168.56.102 Reverse Lookup (IP to name) To test the reverse lookup, query the DNS server with the private IP address o f host2 : nslookup 192.168.56.102 You should see output that looks like the following: 102.56.168.192.in - addr.arpa name = host 2 abc.tech. ie. You can also use the dig command to test that it works. dig ns 2 abc.tech .ie If successful, output should be: Systems Administration Lab Sheet 10 – DNS Page 10 of 10 If all of the names and IP addre sses 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. abc.tech.ie and db.192.168.56). You can test DNS from all m achines using the nslookup and dig commands. Conclusion 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 server in a single place, your primary DNS server, instead of having to ed it 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 server(s) is properly mainta ined. 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. Troubleshooting DNS R estart services Do any ports n eed to be added to the firewall? What is the port number of the DNS service? Check the following files/settings: /etc/sysconfig/networking - scrip ts/ifcfg - ens32 or ifcfg - ens192 for example /etc/resolv.conf /etc/named.conf /etc/named/named.conf.local /etc/named/zones /etc/named/zones/db. abc.tech.ie /etc/named/zones/db.192.168.56 What else can you do to troubleshoot? Google! Use Google to search for keywords specific to the OS, the service, the version of service, the software in use etc. to find the most relevant articles, webpages, solutions etc. Look at the most up - to - date results; 201 9 or 201 8 etc For example, for this lab I would Google some like: “ CentOS 7 Setup DNS BIND ” Improvements What can you do to improve or further this setup?