Quick HOWTO _ Ch18 _ Configuring DNS - Linux Home Networking

3/27/2014 Quick HOWTO : Ch18 : Configuring DNS - Linux Home Networking

http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch18_:_Configuring_DNS#.UzQauq1dWi0 1/15

235

Quick HOWTO : Ch18 : Configuring DNSFrom Linux Home Networking

Contents1 Introduction2 Introduction to DNS

2.1 DNS Domains2.2 BIND2.3 DNS Clients2.4 Authoritative DNS Servers2.5 How DNS Servers Find Out Your Site Information2.6 When To Use A DNS Caching Name Server2.7 When To Use A Static DNS Server2.8 When To Use A Dynamic DNS Server2.9 How To Get Your Own Domain2.10 Basic DNS Testing of DNS Resolution

2.10.1 The Host Command2.10.2 The nslookup Command

2.11 Downloading and Installing the BIND Packages2.12 Managing the BIND Server2.13 The /etc/resolv.conf File

2.13.1 Table 18.1 Keywords In /etc/resolv.conf3 Important File Locations

3.1 RedHat / Fedora3.2 Table 18.2 Differences In Fedora And Redhat DNS File Locations3.3 Debian / Ubuntu

4 Configuring Your Nameserver4.1 Configuring resolv.conf4.2 Creating a named.conf Base Configuration

4.2.1 Table 18.3 The Primary BIND Configuration Files4.3 Configuring BIND Views in named.conf

4.3.1 Forward Zone File References in named.conf4.3.2 Reverse Zone File References in named.conf4.3.3 The Caching Nameserver localhost_resolver View4.3.4 The Internal View4.3.5 The External View

4.4 Configuring The Zone Files4.4.1 Time to Live Value4.4.2 DNS Resource Records4.4.3 The SOA Record4.4.4 Table 18.4 The SOA Record Format4.4.5 NS, MX, A And CNAME Records4.4.6 Table 18.5 NS, MX, A, PTR and CNAME Record Formats4.4.7 TXT Records

4.5 Sample Forward Zone File4.6 Sample Reverse Zone File4.7 Loading Your New Configuration Files4.8 Make Sure Your /etc/hosts File Is Correctly Updated4.9 Configure Your Firewall4.10 Fix Your Domain Registration

5 Troubleshooting BIND5.1 Configuration Troubleshooting Steps5.2 Network Troubleshooting Steps

6 Migrating Your Web Site In-House7 DHCP Considerations For DNS8 Simple DNS Security

8.1 Zone Transfer Protection8.2 Selectively Disabling Recursion8.3 Naming Convention Security

9 Conclusion

Introduction

Other Linux Home Networking Topics

Introduction to NetworkingLinux NetworkingSimple Network TroubleshootingTroubleshooting Linux with SyslogInstalling Linux SoftwareThe Linux Boot ProcessConfiguring the DHCP ServerLinux Users and sudoWindows, Linux and SambaSharing Resources with SambaSamba Security and TroubleshootingLinux Wireless NetworkingLinux Firewalls Using iptablesLinux FTP Server SetupTelnet, TFTP and xinetdSecure Remote Logins and File CopyingConfiguring DNSDynamic DNSThe Apache Web ServerConfiguring Linux Mail Servers

ShareShare More

HomePurchase PDFsForumsAbout



Domain Name System (DNS) converts the name of a Web site (www.linuxhomenetworking.com) to an IP address (65.115.71.34). This step is important,because the IP address of a Web site's server, not the Web site's name, is used in routing traffic over the Internet. This chapter will explain how toconfigure your own DNS server to help guide Web surfers to your site.

Introduction to DNSBefore you dig too deep in DNS, you need to understand a few foundation concepts on which the rest of the chapter will be built.

DNS DomainsEveryone in the world has a first name and a last, or family, name. The same thing is true in the DNS world: A family of Web sites can be looselydescribed a domain. For example, the domain linuxhomenetworking.com has a number of children, such as www.linuxhomenetworking.com andmail.linuxhomenetworking.com for the Web and mail servers, respectively.

BINDBIND is an acronym for the Berkeley Internet Name Domain project, which is a group that maintains the DNS-related software suite that runs underLinux. The most well known program in BIND is named, the daemon that responds to DNS queries from remote machines.

DNS ClientsA DNS client doesn't store DNS information; it must always refer to a DNS server to get it. The only DNS configuration file for a DNS client is the/etc/resolv.conf file, which defines the IP address of the DNS server it should use. You shouldn't need to configure any other files. You'll become wellacquainted with the /etc/resolv.conf file soon.

Authoritative DNS ServersAuthoritative servers provide the definitive information for your DNS domain, such as the names of servers and Web sites in it. They are the last word ininformation related to your domain.

How DNS Servers Find Out Your Site InformationThere are 13 root authoritative DNS servers (super duper authorities) that all DNS servers query first. These root servers know all the authoritative DNSservers for all the main domains - .com, .net, and the rest. This layer of servers keep track of all the DNS servers that Web site systems administrators haveassigned for their sub domains.

For example, when you register your domain my-site.com, you are actually inserting a record on the .com DNS servers that point to the authoritative DNSservers you assigned for your domain. (More on how to register your site later.).

When To Use A DNS Caching Name ServerMost servers dont ask authoritative servers for DNS directly, they usually ask a caching DNS server to do it on their behalf. These servers, through aprocess called recursion, sequentially query the authoritative servers at the root, main domain and sub domain levels to get eventually get the specificinformation requested. The most frequently requested information is then stored (or cached) to reduce the lookup overhead of subsequent queries.

If you want to advertise your Web site www.my-site.com to the rest of the world, then a regular DNS server is what you require. Setting up a cachingDNS server is fairly straightforward and works whether or not your ISP provides you with a static or dynamic Internet IP address.

After you set up your caching DNS server, you must configure each of your home network PCs to use it as their DNS server. If your home PCs get theirIP addresses using DHCP, then you have to configure your DHCP server to make it aware of the IP address of your new DNS server, so that the DHCPserver can advertise the DNS server to its PC clients. Off-the-shelf router/firewall appliances used in most home networks usually can act as both thecaching DNS and DHCP server, rendering a separate DNS server is unnecessary.

You can find the configuration steps for a Linux DHCP server in Chapter 8, "Configuring the DHCP Server".

When To Use A Static DNS ServerIf your ISP provides you with a fixed or static IP address, and you want to host your own Web site, then a regular authoritative DNS server would be theway to go. A caching DNS name server is used as a reference only, regular name servers are used as the authoritative source of information for your Website's domain.

Note: Regular name servers are also caching name servers by default.

When To Use A Dynamic DNS ServerIf your ISP provides your router/firewall with its Internet IP address using DHCP then you must consider dynamic DNS covered in Chapter 19, "DynamicDNS". For now, I'm assuming that you are using static Internet IP addresses.

How To Get Your Own DomainWhether or not you use static or dynamic DNS, you need to register a domain.

Dynamic DNS providers frequently offer you a subdomain of their own site, such as my-site.dnsprovider.com, in which you register your domain on theirsite.

If you choose to create your very own domain, such as my-site.com, you have to register with a company specializing in static DNS registration and thenpoint your registration record to the intended authoritative DNS for your domain. Popular domain registrars include VeriSign, Register Free, and Yahoo.

Monitoring Server PerformanceAdvanced MRTG For LinuxThe NTP ServerNetwork-Based Linux InstallationLinux Software RAIDExpanding Disk CapacityManaging Disk Usage with QuotasRemote Disk Access with NFSConfiguring NISCentralized Logins Using LDAP and RADIUSControlling Web Access with SquidModifying the Kernel to Improve PerformanceBasic MySQL Configuration

LHN Linux Forums - Latest Threads

Problem with Cisco EHWIC-4ESG (GeneralChat) Just wondering if the EHWIC-4ESG(URL be used in a Cisco 800 router.I want toadd at least one...Ubuntu 12.04 LTS Setting Up Networkbetween Xp/7 and Ubuntu 12.04LTS (Linux -Hardware, Networking & Security)Absolute Newbie at Linux i would like tohave it where the windows computers see andtransfer files with the linux box and see andtransfer...Cisco Catalyst 2960X Ethernet Switch(General Chat)series switches like WS-C2960X-24PS-L,WS-C2960X-24PD-L, buy I'm not very well knowabout c2960x series. Can someone...Linux vpn client (Linux - Software,Applications & Programming)has one vpn server,it is CISCO2901/K9 router.We can conntect it with cisco vpn tools inwindows machine.But about linux client, wehave...Norihan Talib Here! (General Chat)Everyone my name is Norihan Talib i joinedthis forum to make new connections on friendssee you all on the boards PenipuDr. Obaid Busit Legal Consultants! newmember post.. (General Chat)forum members.... I am Dr. Obaid Busit newmember here! Hope everyone is fine and enjoybeing here! Regards Dr. Obaid Busithani dalqamouni here! (General Chat)everybody! i am hani dalqamouni... i am newto this forum annd i am happy to join here tomeet new friends and to sahre interests withyou...Best way to know Cisco Catalyst 24-PortNetwork Switch WS-C2960-24TC-L (Linux -Hardware, Networking & Security)2960-S switches are the leading fixed-configuration Layer 2 edge access switchesand 2960-S most ports are GE.The Catalyst2960-S Series...hello..Robert Didiana here.. (General Chat)iam glad to be a part of this forum it seems likea pretty cool community that is ran here and Ican tell there's good administration just by...Jack Rafael Gorodezky Mirsky newbie here!(General Chat)Gorodezky as you can see i am a new memberof the forum. I am interested to meet new likeminded people Kind regards,...Nelia Guinsatao Laurel - Ladlad need help(General Chat)Ladlad Im looking for Dofollow blogs cananyone help me thanks. Regards: NeliaGuinsatao Laurel - Ladlad



If you want to use a dynamic DNS provider for your own domain, then you have to point your registration record to the DNS servers of your dynamicDNS provider. (More details on domain registration are coming later in the chapter.).

Basic DNS Testing of DNS ResolutionAs you know, DNS resolution maps a fully qualified domain name (FQDN), such as www.linuxhomenetworking.com, to an IP address. This is alsoknown as a forward lookup. The reverse is also true: By performing a reverse lookup, DNS can determining the fully qualified domain name associatedwith an IP address.

Many different Web sites can map to a single IP address, but the reverse isn't true; an IP address can map to only one FQDN. This means that forward andreverse entries frequently don't match. The reverse DNS entries are usually the responsibility of the ISP hosting your site, so it is quite common for thereverse lookup to resolve to the ISP's domain. This isn't an important factor for most small sites, but some e-commerce applications require matchingentries to operate correctly. You may have to ask your ISP to make a custom DNS change to correct this.

There are a number of commands you can use do these lookups. Linux uses the host command, for example, but Windows uses nslookup.

The Host Command

The host command accepts arguments that are either the fully qualified domain name or the IP address of the server when providing results. To perform aforward lookup, use the syntax:

[root@bigboy tmp]# host www.linuxhomenetworking.comwww.linuxhomenetworking.com has address 65.115.71.34[root@bigboy tmp]#

To perform a reverse lookup

[root@bigboy tmp]# host 65.115.71.3434.71.115.65.in-addr.arpa domain name pointer 65-115-71-34.myisp.net.[root@bigboy tmp]#

As you can see, the forward and reverse entries don't match. The reverse entry matches the entry of the ISP.

The nslookup Command

The nslookup command provides the same results on Windows PCs. To perform forward lookup, use.

C:\> nslookup www.linuxhomenetworking.comServer: 192-168-1-200.my-site.comAddress: 192.168.1.200

Non-authoritative answer:Name: www.linuxhomenetworking.comAddress: 65.115.71.34

C:\>

To perform a reverse lookup

C:\> nslookup 65.115.71.34Server: 192-168-1-200.my-site.comAddress: 192.168.1.200

Name: 65-115-71-34.my-isp.comAddress: 65.115.71.34

C:\>

Downloading and Installing the BIND PackagesMost RedHat and Fedora Linux software products are available in a package format. When searching for the file, remember that the BIND package'sfilename usually starts with the word bind followed by a version number, as in bind-9.2.2.P3-9.i386.rpm. (For more details on downloading RPMs,see Chapter 6, "Installing Linux Software").

Note: Unless otherwise stated, the sample configurations covered in this chapter will be for Redhat / Fedora distributions. If you use Debian / Ubuntu,dont worry, there will be annotations to make you aware of the differences.

Managing the BIND ServerManaging BIND's named daemon is easy to do, but the procedure differs between Linux distributions. Here are some things to keep in mind.

1. Firstly, different Linux distributions use different daemon management systems. Each system has its own set of commands to do similar operations.The most commonly used daemon management systems are SysV and Systemd.

2. Secondly, the daemon name needs to be known. In this case the name of the daemon is named.

Armed with this information you can know how to:

1. Start your daemons automatically on booting2. Stop, start and restart them later on during troubleshooting or when a configuration file change needs to be applied.

For more details on this, please take a look at the "Managing Daemons" section of Chapter 6 "Installing Linux Software" Note: Remember to configureyour daemon to start automatically upon your next reboot.

The /etc/resolv.conf File



DNS clients (servers not running BIND) use the /etc/resolv.conf file to determine both the location of their DNS server and the domains to which theybelong. The file generally has two columns; the first contains a keyword, and the second contains the desired values separated by commas. See Table 18.1for a list of keywords.

Table 18.1 Keywords In /etc/resolv.conf

Keyword Value

Nameserver IP address of your DNS nameserver. There should be only one entry per "nameserver" keyword. If there is more than one nameserver,youll need to have multiple "nameserver" lines.

Domain The local domain name to be used by default. If the server is bigboy.my-web-site.org, then the entry would just be my-web-site.org

Search

If you refer to another server just by its name without the domain added on, DNS on your client will append the server name to eachdomain in this list and do an DNS lookup on each to get the remote servers IP address. This is a handy time saving feature to have so thatyou can refer to servers in the same domain by only their servername without having to specify the domain. The domains in this list mustseparated by spaces.

Take a look at a sample configuration in which the client server's main domain is my-site.com, but it also is a member of domains my-site.net and my-site.org, which should be searched for shorthand references to other servers. Two name servers, 192.168.1.100 and 192.168.1.102, provide DNS nameresolution:

search my-site.com my-site.net my-site.orgnameserver 192.168.1.100nameserver 192.168.1.102

The first domain listed after the search directive must be the home domain of your network, in this case my-site.com. Placing a domain and search entry inthe /etc/resolv.conf is redundant, therefore.

Important File LocationsThe locations of the BIND configuration files vary by Linux distribution, as you will soon see.

RedHat / FedoraRedHat / Fedora BIND normally runs as the named process owned by the unprivileged named user.

Sometimes BIND is also installed using Linux's chroot feature to not only run named as user named, but also to limit the files named can see. Wheninstalled, named is fooled into thinking that the directory /var/named/chroot is actually the root or / directory. Therefore, named files normally found inthe /etc directory are found in /var/named/chroot/etc directory instead, and those you'd expect to find in /var/named are actually located in/var/named/chroot/var/named.

The advantage of the chroot feature is that if a hacker enters your system via a BIND exploit, the hacker's access to the rest of your system is isolated to thefiles under the chroot directory and nothing else. This type of security is also known as a chroot jail.

You can determine whether you have the chroot add-on RPM by using this command, which returns the name of the RPM.

[root@bigboy tmp]# rpm -q bind-chrootbind-chroot-9.2.3-13[root@bigboy tmp]#

There can be confusion with the locations: Regular BIND installs its files in the normal locations, and the chroot BIND add-on RPM installs its ownversions in their chroot locations. Unfortunately, the chroot versions of some of the files are empty. Before starting Fedora BIND, copy the configurationfiles to their chroot locations:

[root@bigboy tmp]# cp -f /etc/named.conf /var/named/chroot/etc/[root@bigboy tmp]# cp -f /etc/rndc.* /var/named/chroot/etc/

Before you go to the next step of configuring a regular name server, it is important to understand exactly where the files are located. Table 18.2 provides amap.

Table 18.2 Differences In Fedora And Redhat DNS File Locations

File Purpose BIND chroot Location Regular BIND Location

named.conf Tells the names of the zone files to be used for each of your website domains. /var/named/chroot/etc /etc

rndc.key

rndc.conf

Files used in named authentication /var/named/chroot/etc /etc

zone files Links all the IP addresses in your domain to their corresponding server /var/named/chroot/var/named /var/named

Note: Fedora Core installs BIND chroot by default. RedHat 9 and earlier don't.

Debian / UbuntuWith Debian / Ubuntu, all the configuration files, the primary named.conf file and all the DNS zone files reside in the /etc/bind directory.



Unlike in Redhat / Fedora, references to other files within these configuration files should include the full path. The named daemon won't automaticallyassume they are located in the /etc/bind directory.

Configuring Your NameserverFor the purposes of this tutorial, assume your ISP assigned you the subnet 97.158.253.24 with a subnet mask of 255.255.255.248 (/29).

Configuring resolv.confYou'll have to make your DNS server refer to itself for all DNS queries by configuring the /etc/resolv.conf file to reference localhost only.

nameserver 127.0.0.1

Creating a named.conf Base ConfigurationThe /etc/named.conf file contains the main DNS configuration and tells BIND where to find the configuration, or zone files for each domain you own.This file usually has two zone areas:

Forward zone file definitions list files to map domains to IP addresses.Reverse zone file definitions list files to map IP addresses to domains.

Some versions of BIND will come with a /etc/amed.conf file configured to work as a caching nameserver which can be converted to an authoritativenameserver by adding the correct references to your zone files. Please proceed to the next section if this is the case with your version of BIND.

In other cases the named.conf configuration file may be hard to find. Some versions of Linux install BIND as a default caching nameserver using a filenames /etc/named.caching-nameserver.conf for its configuration. In such cases BIND becomes an authoritative nameserver when a correctly configured/etc/named.conf file is created.

Fortunately BIND comes with samples of all the primary files you need. Table 18.3 explains their names and purpose in more detail.

Table 18.3 The Primary BIND Configuration Files

File Description

/etc/named.conf The main configuration file that lists the location of all your domain's zone files

/etc/named.rfc1912.zones Base configuration file for a caching name server.

/var/named/named.ca A list of the 13 root authoritative DNS servers.

The first task is to make sure your DNS server will listening of requests on all the required network interfaces. The options section of named.conf may beconfigured to listen exclusively on its internal hidden localhost interface with an IP address of 127.0.0.1 as we see in this example.

# File: /etc/named.conf

options { listen-on port 53 { 127.0.0.1; };};

If other devices are going to rely on your server for queries, then youll need to either change this or add a selected number of IP addresses on your server.In this example, we allow queries on any interface.

listen-on port 53 { any; };

In this example, we allow queries on localhost and address 192.168.1.100.

listen-on port 53 { 127.0.0.1; 192.168.1.100; };

Note: Always make sure localhost, 127.0.0.1 is included.

Though it is not required, it is a good practice to configure your DNS server's named.conf file to support BIND views. This will be discussed next.

Configuring BIND Views in named.confOur sample scenario assumes that DNS queries will be coming from the Internet and that the zone files will return information related to the external97.158.253.26 address of the Web server. What do the PCs on your home network need to see? They need to see DNS references to the real IP address ofthe Web server, 192.168.1.100, because NAT wont work properly if a PC on your home network attempts to connect to the external 97.158.253.26 NATIP address of your Web server. Dont worry. BIND figures this out using its views feature which allows you to use predefined zone files for queries fromcertain subnets. This means its possible to use one set of zone files for queries from the Internet and another set for queries from your home network.Heres a summary of how its done:

1. If your DNS server is also acting as a caching DNS server, then you'll also need a view for localhost to use. We'll use a view called localhost_resolverfor this.

2. Place your zone statements in the /etc/named.conf file in one of two other view sections. The first section is called internal and lists the zone files to beused by your internal network. The second view called external lists the zone files to be used for Internet users.

For example; you could have a reference to a zone file called my-site.zone for lookups related to the 97.158.253.X network which Internet users wouldsee. This /etc/named.conf entry would be inserted in the external section. You could also have a file called my-site-home.zone for lookups by home userson the 192.168.1.0 network. This entry would be inserted in the internal section. Creating the my-site-home.zone file is fairly easy: Copy it from the my-



site.zone file and replace all references to 97.158.253.X with references to 192.168.1.X.

3. You must also tell the DNS server which addresses you feel are internal and external. To do this, you must first define the internal and external networkswith access control lists (ACLs) and then refer to these lists within their respective view section with the match-clients statement. Some built-in ACLs cansave you time:

localhost: Refers to the DNS server itselflocalnets: Refers to all the networks to which the DNS server is directly connectedany: which is self explanatory.

Let's examine BIND views more carefully using a number of sample configuration snippets from the /etc/named.conf file I use for my home network. Allthe statements below were inserted after the options and controls sections in the file. I have selected generic names internal, for views given to trusted hosts(home, non-internet or corporate users), and external for the views given to Internet clients, but they can be named whatever you wish.

First let's talk about how we should refer to the zone files in each view.

Forward Zone File References in named.conf

Lets describe how we point to forward zone files in a typical named.conf file.

In this example the zone file is named my-site.zone, and, although not explicitly stated, the file my-site.zone should be located in the default directory of/var/named/chroot/var/named in a chroot configuration or in /var/named in a regular one. With Debian / Ubuntu, references to the full file path will have tobe used. Use the code:

zone my-web-site.org {

type master; notify no; allow-query { any; }; file my-site.zone;

};

In addition, you can insert more entries in the named.conf file to reference other Web domains you host. Here is an example for another-site.com using azone file named another-site.zone.

zone another-site.com {

type master; notify no; allow-query { any; }; file another-site.zone;

};

Note: The allow-query directive defines the networks that are allowed to query your DNS server for information on any zone. For example, to limitqueries to only your 192.168.1.0 network, you could modify the directive to:

allow-query { 192.168.1.0/24; };

Reverse Zone File References in named.conf

Heres how to format entries that refer to zone files used for reverse lookups for your IP addresses.

In most cases, your ISP handles the reverse zone entries for your public IP addresses, but you will have to create reverse zone entries for yourSOHO/home environment using the 192.168.1.0/24 address space. This isnt important for the Windows clients on your network, but some Linuxapplications require valid forward and reverse entries to operate correctly.

The forward domain lookup process for mysite.com scans the FQDN from right to left to get to get increasingly more specific information about theauthoritative servers to use. Reverse lookups operate similarly by scanning an IP address from left to right to get increasingly specific information about anaddress.

The similarity in both methods is that increasingly specific information is sought, but the noticeable difference is that for forward lookups the scan is fromright to left, and for reverse lookups the scan is from left to right. This difference can be seen in the formatting of the zone statement for a reverse zone in/etc/named.conf file where the main in-addr.arpa domain, to which all IP addresses belong, is followed by the first 3 octets of the IP address in reverseorder. This order is important to remember or else the configuration will fail. This reverse zone definition for named.conf uses a reverse zone file named192-168-1.zone for the 192.168.1.0/24 network.

zone 1.168.192.in-addr.arpa { type master; notify no; allow-query { any; }; file 192-168-1.zone;};

Your patience will soon be rewarded. It's time to talk about the views! Let's go!

The Caching Nameserver localhost_resolver View

The localhost_resolver view is used for your caching DNS server configuration and should look like this:

view "localhost_resolver"{/* This view sets up named to be a localhost resolver * ( caching only nameserver ). If all you want is a * caching-only nameserver, then you need only define this view: */ match-clients { localhost; }; match-destinations { localhost; };



// As your caching name server clients will be using this server // for DNS lookups to get to sites all over the Web youll need to // turn on recursion recursion yes; // All views used by caching nameserver clients must // contain the root hints zone. Recursive lookups to DNS domains // you dont own (non-authoritative) starts here. zone "." IN { type hint; file "named.ca"; };

/* these are zones that contain definitions for all the localhost * names and addresses, as recommended in RFC1912 - these names should * ONLY be served to localhost clients: */ include "/etc/named.rfc1912.zones"; /* * Include zonefiles for internal zones */ include "/var/named/zones/internal/internal_zones.conf";};

There are some quick facts you should be aware of with your caching name server configuration:

1. If you want your server to be only a caching DNS server, then delete all other views in named.conf and restart the named daemon.

[root@bigboy tmp]# systemctl restart named.service

2. Make all the other machines on your network point to the caching DNS server as their primary DNS server.

3. Remember that all DNS queries done on your DNS server appear to come from localhost. If your server is also an authoritative server for your domain,you will have to include a reference to your domain's zone files in this section for the server's own DNS lookups to work. If not, queries from clientsdefined by the internal and external ACLs will work correctly, but queries for the domain from the server itself will fail. In this example we have includeda reference to the internal_zones.conf zone file which we'll visit again soon. This line can be deleted if your server isn't an authoritative server for yourdomain.

Note: If you have a localhost only view like this, make sure you don't reference localhost in any of your other views as one view will take precedence overthe other for queries from your server. This could lead to unpredictable results.

The Internal View

In this example I included an ACL for network 192.168.17.0 /24 called safe-subnet to help clarify the use of ACLs in more complex environments. Oncethe ACL was defined, I then inserted a reference to the safe-subnet in the match-clients statement in the internal view. Therefore the local network(192.168.1.0 /24), the other trusted network (192.168.17.0), and localhost get DNS data from the zone files in the internal view.

// ACL statement

acl safe-subnet { 192.168.17.0/24; };

view internal { // What the home network will see match-clients { localnets; localhost; safe-subnet; }; match-destinations { localnets; localhost; safe-subnet; };

// As your caching name server clients will be using this server // for DNS lookups to get to sites all over the Web youll need to // turn on recursion recursion yes; // All views used by caching nameserver clients must // contain the root hints zone. Recursive lookups to DNS domains // you dont own (non-authoritative) starts here. zone "." IN { type hint; file "named.ca"; };

// These are your "authoritative" internal zones, and would probably // also be included in the "localhost_resolver" view above :

/* * Include zonefiles for internal zones */ include "/var/named/zones/internal/internal_zones.conf";

};

The question you may have on your mind is, "Where are the zone file definitions?". Don't worry, there is an include statement that refers to a file namedinternal_zones.conf that contains them all as we see here:

// File internal_zones.conf

zone "1.168.192.in-addr.arpa" IN { type master; file "/var/named/zones/internal/192.168.1.zone"; allow-update { none; };};

zone "my-web-site.org" IN { type master; file "/var/named/zones/internal/my-web-site.org.zone"; allow-update { none; };};

I'll discuss how to handle queries from clients outside your trusted networks in the next section where an external view can be used.



The External View

You can also setup an external view that will be used for DNS queries from clients outside your network, such as the Internet. In this case external queriesget results from zone files in the /var/named/zones/external directory.

view external { // What the Internet will see /* This view will contain zones you want to serve only to "external" * clients that have addresses that are not on your directly attached * LAN interface subnets: */

match-clients { any; }; match-destinations { any; }; // you'd probably want to deny recursion to external clients, so you don't // end up providing free DNS service to all takers recursion no;

// These are your "authoritative" external zones, and would probably // contain entries for just your web and mail servers:

zone "253.158.97.in-addr.arpa" IN { type master; file "/var/named/zones/external/97.158.253.zone"; allow-update { none; }; }; zone "my-web-site.org" IN { type master; file "/var/named/zones/external/my-web-site.org.zone"; allow-update { none; }; };};

Notice that the reverse zone file gives results for public internet addresses, and of course, the forward zone file should only provide responses with Internetaccessible addresses.

Note: In the external view, you may be tempted to use an exclamation mark (!) to eliminate networks used in the internal view like this. Be careful, it isbest to use "any;" for your external view as the exclamation mark (!) is not honored with some versions of BIND in views named "external".

; !!! CAUTION !!!

match-clients { !localnets; !localhost; !safe-subnet; };match-destinations { !localnets; !localhost; !safe-subnet; };

The views listed here are purely to illustrate their use. The sample home network we have been using doesnt need to have the ACL statement at all as thebuilt in ACLs localnets and localhost are sufficient. The sample network wont need the safe-subnet section in the match-clients line either as there is onlyone subnet in the configuration.

Views are also not just for NAT. If you run an Internet data center, you can set up your DNS server to act as a caching server to servers on all the Internetnetworks you own and no one else, and then provide authoritative responses to your customers' domains to everyone. Views can be very useful.

Configuring The Zone FilesYou need to keep a number of things in mind when configuring DNS zone files:

In all zone files, you can place a comment at the end of any line by inserting a semi-colon character then typing in the text of your comment.By default, your zone files are located in the /var/named or /var/named/chroot/var/named or /etc/bind directories depending on your Linuxdistribution.Each zone file contains a variety of records (SOA, NS, MX, A, and CNAME) that govern different areas of BIND.

Take a closer look at these entries in the zone file.

Time to Live Value

The very first entry in the zone file is usually the zone's time to live (TTL) value. Caching DNS servers cache the responses to their queries fromauthoritative DNS servers. The authoritative servers not only provide the DNS answer but also provide the information's time to live, which is the periodfor which it's valid.

The purpose of a TTL is to reduce the number of DNS queries the authoritative DNS server has to answer. If the TTL is set to three days, then cachingservers use the original stored response for three days before making the query again.

$TTL 3D

BIND recognizes several suffixes for time-related values. A D signifies days, a W signifies weeks, and an H signifies hours. In the absence of a suffix,BIND assumes the value is in seconds.

DNS Resource Records

The rest of the records in a zone file are usually BIND resource records. They define the nature of the DNS information in your zone files that's presentedto querying DNS clients. They all have the general format:

Name Class Type Data

There are different types of records for mail (MX), forward lookups (A), reverse lookups (PTR), aliases (CNAME) and overall zone definitions, Start ofAuthority (SOA). The data portion is formatted according to the record type and may consist of several values separated by spaces. Similarly, the name isalso subject to interpretation based on this factor.



The SOA Record

The first resource record is the Start of Authority (SOA) record, which contains general administrative and control information about the domain. It has theformat:

Name Class Type Name-Server Email-Address Serial-No Refresh Retry Expiry Minimum-TTL

The record can be long, and will sometimes wrap around on your screen. For the sake of formatting, you can insert new line characters between the fieldsas long as you insert parenthesis at the beginning and end of the insertion to alert BIND that part of the record will straddle multiple lines. You can alsoadd comments to the end of each new line separated by a semicolon when you do this. Here is an example:

@ IN SOA ns1.my-site.com. hostmaster.my-site.com. ( 2004100801 ; serial # 4H ; refresh 1H ; retry 1W ; expiry 1D ) ; minimum

Table 18.4 explains what each field in the record means.

Table 18.4 The SOA Record Format

Field Description

Name The root name of the zone. The @ sign is a shorthand reference to the current origin (zone) in the /etc/named.conf file for that particulardatabase file.

Class There are a number of different DNS classes. Home/SOHO will be limited to the IN or Internet class used when defining IP addressmapping information for BIND. Other classes exist for non Internet protocols and functions but are very rarely used.

Type The type of DNS resource record. In the example, this is an SOA resource record. Other types of records exist, which Ill cover later.

Name-server

Fully qualified name of your primary name server. Must be followed by a period.

Email-address

The e-mail address of the name server administrator. The regular @ in the e-mail address must be replaced with a period instead. The e-mailaddress must also be followed by a period.

Serial-no A serial number for the current configuration. You can use the date format YYYYMMDD with an incremented single digit number taggedto the end. This will allow you to do multiple edits each day with a serial number that both increments and reflects the date on which thechange was made.

Refresh Tells the slave DNS server how often it should check the master DNS server. Slaves arent usually used in home / SOHO environments.

Retry The slaves retry interval to connect the master in the event of a connection failure. Slaves arent usually used in home / SOHOenvironments.

Expiry Total amount of time a slave should retry to contact the master before expiring the data it contains. Future references will be directedtowards the root servers. Slaves arent usually used in home/SOHO environments.

Minimum-TTL

There are times when remote clients will make queries for subdomains that dont exist. Your DNS server will respond with a no domain orNXDOMAIN response that the remote client caches. This value defines the caching duration your DNS includes in this response.

So in the example, the primary name server is defined as ns1.my-site.com with a contact e-mail address of [email protected]. The serial number is2004100801 with refresh, retry, expiry, and minimum values of 4 hours, 1 hour, 1 week, and 1 day, respectively.

NS, MX, A And CNAME Records

Like the SOA record, the NS, MX, A, PTR and CNAME records each occupy a single line with a very similar general format. Table 18.5 outlines theway they are laid out.

Table 18.5 NS, MX, A, PTR and CNAME Record Formats

RecordType Name Field

ClassField2

TypeField Data Field

NS Usually blank1 IN NS IP address or CNAME of the nameserver

MX Domain to be used for mail. Usually the same as the domain of the zonefile itself.

IN MX Mail server DNS name

A Name of a server in the domain IN A IP address of server

CNAME Server name alias IN CNAME "A" record name for the server

PTR Last octet of servers IP address IN PTR Fully qualified server name

1. If the search key to a DNS resource record is blank it reuses the search key from the previous record which in this case of is the SOA @ sign.2. For most home / SOHO scenarios, the Class field will always be IN or Internet. You should also be aware that IN is the default Class, and

BIND will assume a record is of this type unless otherwise stated.

If you don't put a period at the end of a host name in a SOA, NS, A, or CNAME record, BIND will automatically tack on the zone file's domain name tothe name of the host. So, BIND assumes an A record with www refers to www.my-site.com. This may be acceptable in most cases, but if you forget toput the period after the domain in the MX record for my-site.com, BIND attaches the my-site.com at the end, and you will find your mail server acceptingmail only for the domain my-site.com.mysite.com.

TXT Records



There is also a less frequently used DNS TXT record that can be configured to contain additional generic information. The data section of the recordtypically has the format "name=value", where "name" is the name to be given to the type of data, and "value" is the value assigned to the name as seen inthis example.

my-web-site.org. TXT "v=spf1 -all"

TXT records are increasingly being used to help fight SPAM using the Sender Policy Framework (SPF) method. SPF TXT records are used by systemsreceiving mail to interrogate the DNS of the domain which appears in the email (the sender) and determine if the originating IP address of the mail (thesource) is authorized to send mail for the sender's domain.

Further description of the use of TXT records is beyond the scope of this book, but you should at least be aware that they can be up to 255 characters inlength and that this feature is often exploited in distributed denial of service (DDoS) attacks. The section on "Simple DNS Security" explains how toconfigure your DNS server to not participate in such an event.

Sample Forward Zone FileNow that you know the key elements of a zone file, it's time to examine a working example for the domain my-site.com.

;; Zone file for my-site.com;; The full zone file;$TTL 3D@ IN SOA ns1.my-site.com. hostmaster.my-site.com. ( 200211152 ; serial# 3600 ; refresh, seconds 3600 ; retry, seconds 3600 ; expire, seconds 3600 ) ; minimum, seconds

NS www ; Inet Address of nameservermy-site.com. MX 10 mail ; Primary Mail Exchanger localhost A 127.0.0.1bigboy A 97.158.253.26mail A 97.158.253.27ns1 CNAME bigboywww CNAME bigboy

Notice that in this example:

Server ns1.my-site.com is the name server for my-site.com. In corporate environments there may be a separate name server for this purpose. Primaryname servers are more commonly called ns1 and secondary name servers ns2.

The minimum TTL value ($TTL) is three days, therefore remote DNS caching servers will store learned DNS information from your zone for threedays before flushing it out of their caches.

The MX record for my-site.com points to the server named mail.my-site.com and this server has the IP address 97.158.253.27.

ns1 is actually a CNAME or alias for the Web server www. So here you have an example of the name server, and Web server being the samemachine. If they were all different machines, then you'd have an A record entry for each.

www A 97.158.253.26ns A 97.158.253.125

It is a required practice to increment your serial number whenever you edit your zone file. When DNS is setup in a redundant configuration, the slave DNSservers periodically poll the master server for updated zone file information, and use the serial number to determine whether the data on the master hasbeen updated. Failing to increment the serial number, even though the contents of the zone file have been modified, could cause your slaves to haveoutdated information.

Note: The DNS specification (RFC 2181) does not allow for an MX record to be a CNAME. It may work in most cases, but some mail servers mayrefuse to send to you because of this.

Sample Reverse Zone FileNow you need to make sure that you can do a host query on all your home network's PCs and get their correct IP addresses. This is very important if youare running a mail server on your network, because sendmail typically relays mail only from hosts whose IP addresses resolve correctly in DNS. NFS,which is used in network-based file access, also requires valid reverse lookup capabilities.

This is an example of a zone file for the 192.168.1.x network. All the entries in the first column refer to the last octet of the IP address for the network, sothe IP address 192.168.1.100 points to the name bigboy.my-site.com.

Notice how the main difference between forward and reverse zone files is that the reverse zone file only has PTR and NS records. Also the PTR recordscannot have CNAME aliases.

;; Filename: 192-168-1.zone;; Zone file for 192.168.1.x;$TTL 3D@ IN SOA www.my-site.com. hostmaster.my-site.com. ( 200303301 ; serial number 8H ; refresh, seconds 2H ; retry, seconds 4W ; expire, seconds 1D ) ; minimum, seconds

NS www ; Nameserver Address



100 PTR bigboy.my-site.com.103 PTR smallfry.my-site.com.102 PTR ochorios.my-site.com.105 PTR reggae.my-site.com.

32 PTR dhcp-192-168-1-32.my-site.com.33 PTR dhcp-192-168-1-33.my-site.com.34 PTR dhcp-192-168-1-34.my-site.com.35 PTR dhcp-192-168-1-35.my-site.com.36 PTR dhcp-192-168-1-36.my-site.com.

I included entries for addresses 192.168.1.32 to 192.168.1.36, which are the addresses the DHCP server issues. SMTP mail relay wouldn't work for PCsthat get their IP addresses via DHCP if these lines weren't included.

You may also want to create a reverse zone file for the public NAT IP addresses for your home network. Unfortunately, ISPs won't usually delegate thisability for anyone with less than a Class C block of 256 IP addresses. Most home DSL sites wouldn't qualify.

Loading Your New Configuration FilesMake sure your configuration files are in the correct locations and the serial numbers of the zone files you may have modified have been updated. If allseems correct, restart BIND named daemon for the configuration to become active.

[root@bigboy tmp]# systemctl restart named.service

Take a look at the end of your /var/log/messages file to make sure there are no errors.

Make Sure Your /etc/hosts File Is Correctly UpdatedChapter 3, "Linux Networking", explains how to correctly configure your /etc/hosts file. Some programs, such as sendmail, require a correctly configured/etc/hosts file even though DNS is correctly configured.

Configure Your FirewallThe sample network assumes that the BIND name server and Apache Web server software run on the same machine protected by a router/firewall. Theactual IP address of the server is 192.168.1.100, which is a private IP address. You'll have to use NAT for Internet users to be able to gain access to theserver via the chosen public IP address, namely 97.158.253.26. If your firewall is a Linux box, you may want to consider taking a look at Chapter 14,"Linux Firewalls Using iptables", describes how to do the network address translation and allow DNS traffic through to your name server.

Fix Your Domain RegistrationRemember to edit your domain registration for my-site.com, or whatever it is, so that at least one of the name servers is your new name server(97.158.253.26 in this case). Domain registrars, such as VeriSign and RegisterFree, usually provide a Web interface to help you manage your domain.

Once you've logged in with the registrar's username and password, you'll have take two steps:

1) Create a new name server record entry for the IP address 97.158.253.26 to map to ns.my-site.com or www.my-site.com or whatever your nameserver is called. (This screen prompts you for both the server's IP address and name.)

2) Assign ns.my-site.com to handle your domain. This screen will prompt you for the server name only.

Sometimes, the registrar requires at least two registered name servers per domain. If you only have one, then you could either create a second nameserver record entry with the same IP address, but different name, or you could give your Web server a second IP address using an IP alias, create asecond NAT entry on your firewall and then create the second name server record entry with the new IP address, and different name.

It normally takes about three to four days for your updated DNS information to be propagated to all 13 of the world's root name servers. You'll thereforehave to wait about this amount of time before starting to notice people hitting your new Web site.

You can use the chapter's troubleshooting section to test specific DNS servers for the information they have on your site. You'll most likely want to testyour new DNS server, which should be up to date, plus a few well known ones, which should have delayed values.

Troubleshooting BINDBIND troubleshooting is usually easy to do. The named daemon updates the /var/log/messages file with detailed status messages that are frequently easy tointerpret when you suspect a configuration error. The usual troubleshooting steps for network problems are also applicable. Both methodologies will becovered next.

Configuration Troubleshooting StepsAlways check your /var/logs/messages file and console output file for errors. Here are a couple examples you may come across:

The named daemon is started with an unedited version of the sample named.conf file which causes unusual errors on the screen. References to thenonexistent sample zone files create errors. References to both the named.rfc1912.zones and named.root files in the localhost_resolver section causeerrors related to duplicate definitions.

[root@bigboy tmp]# systemctl restart named.serviceStarting named: Error in named configuration:/etc/named.rfc1912.zones:10: zone '.': already exists previous definition: /etc/named.root.hints:12zone localdomain/IN: loaded serial 42zone localhost/IN: loaded serial 42zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 1997022700zone 255.in-addr.arpa/IN: loaded serial 42zone 0.in-addr.arpa/IN: loaded serial 42zone my.internal.zone/IN: loading master file my.internal.zone.db: file not found



internal/my.internal.zone/IN: file not foundzone my.ddns.internal.zone/IN: loading master file slaves/my.ddns.internal.zone.db: file not foundinternal/my.ddns.internal.zone/IN: file not foundzone my.external.zone/IN: loading master file my.external.zone.db: file not foundexternal/my.external.zone/IN: file not found[FAILED][root@bigboy tmp]#

The named.conf file refers to an undefined secret key in the ddns_key of named.conf. Use the dns-keygen or dnskeygen commands to create acorrect entry.

Feb 25 20:38:49 bigboy named[4593]: /etc/named.conf:99: configuring key 'ddns_key': bad base64 encodingFeb 25 20:38:49 bigboy named[4593]: loading configuration: bad base64 encoding

The named.root.hints file referred to in named.conf isn't present in the /etc or the chroot /etc directory.

[root@bigboy tmp]# systemctl start named.serviceStarting named: Error in named configuration:/etc/named.conf:58: open: /etc/named.root.hints: file not found[FAILED][root@bigboy tmp]#

The named.root file referred to in the named.root.hints file isn't present.

Feb 25 21:33:41 bigboy named[5007]: could not configure root hints from 'named.root': file not foundFeb 25 21:33:41 bigboy named[5007]: loading configuration: file not foundFeb 25 21:33:41 bigboy named[5007]: exiting (due to fatal error)

You are using a chroot version of BIND with a sample rndc.key file located in the /etc directory instead of the /var/named/chroot/etc/ directory.Copy the file to the correct location and restart named to fix the problem.

[root@bigboy tmp]# systemctl restart named.serviceStopping named: rndc: connect failed: connection refused[ OK ]Starting named: [ OK ][root@bigboy tmp]#

In your named.conf file you refer to a zone file that doesn't exist. This example includes both errors to the console screen and errors in the/var/log/messages file.

[root@bigboy tmp]# systemctl start named.serviceStarting named: Error in named configuration:zone localdomain/IN: loaded serial 42zone localhost/IN: loaded serial 42zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 1997022700zone 255.in-addr.arpa/IN: loaded serial 42zone 0.in-addr.arpa/IN: loaded serial 42zone 2.168.192.in-addr.arpa/IN: loaded serial 2006052301zone my-web-site.org/IN: loaded serial 2006052302zone my-web-site.com/IN: loading master file /var/named/zones/internal/my-web-site.com.zone: file not foundinternal/my-web-site.com/IN: file not foundzone 1.168.192.in-addr.arpa/IN: loaded serial 2006052301zone my-web-site.org/IN: loaded serial 2006052302[FAILED][root@bigboy tmp]#

Feb 26 01:47:10 smallfry named: zone my-web-site.com/IN: loading master file /var/named/zones/internal/my-web-site.com.zone: file not foundFeb 26 01:47:10 smallfry named: internal/my-web-site.com/IN: file not found

This is a tricky one that would occur in some early versions of Fedora. BIND would appear to start correctly, but none of the zone files would beloaded. In this scenario could be using a chroot version of BIND with a sample named.conf file located in the /etc directory instead of the/var/named/chroot/etc/ directory. Copy the file to the correct location and restart named to fix the problem. Delete the /etc and create a symbolic linkto /var/named/chroot/etc/named.conf from /etc to ensure you always edit the correct file.

Nov 9 17:35:41 bigboy named[1157]: starting BIND 9.2.3 -u named -t /var/named/chrootNov 9 17:35:41 bigboy named[1157]: using 1 CPUNov 9 17:35:41 bigboy named[1157]: loading configuration from /etc/named.confNov 9 17:35:41 bigboy named[1157]: listening on IPv4 interface lo, 127.0.0.1#53Nov 9 17:35:41 bigboy named[1157]: listening on IPv4 interface eth0, 10.41.32.71#53Nov 9 17:35:41 bigboy named[1157]: command channel listening on 127.0.0.1#953Nov 9 17:35:41 bigboy named[1157]: command channel listening on ::1#953Nov 9 17:35:41 bigboy named[1157]: running

If there are no named errors to the screen or /var/log/messages, and your domain doesn't resolve correctly when queried using the host commandwhen you are logged into your new nameserver, then the problem could be due to you forgetting to add a zone file entry for the domain innamed.conf; there could be a typographical error in your zone file; or you could have forgotten to update your zone file serial numbers.

This isn't a comprehensive configuration error list, but it covers some common mistakes with a new configuration.

Network Troubleshooting StepsOnce configuration troubleshooting this is completed, you can continue with the following troubleshooting steps:

1) Determine whether your DNS server is accessible on DNS UDP/TCP port 53. Lack of connectivity could be caused by a firewall with incorrect,permit, NAT, or port forwarding rules to your DNS server. Failure could also be caused by the named process being stopped. It is best to test this fromboth inside your network and from the Internet.

Troubleshooting with TELNET is covered in Chapter 4, "Simple Network Troubleshooting".



2) Linux status messages are logged to the file /var/log/messages. Use it to make sure all your zone files are loaded when you start BIND/named. Checkyour /etc/named.conf file if they fail to do so. (Linux logging is covered in Chapter 5, "Troubleshooting Linux with syslog".

Feb 21 09:13:13 bigboy named: named startup succeededFeb 21 09:13:13 bigboy named[12026]: loading configuration from '/etc/named.conf'Feb 21 09:13:13 bigboy named[12026]: no IPv6 interfaces foundFeb 21 09:13:13 bigboy named[12026]: listening on IPv4 interface lo, 127.0.0.1#53Feb 21 09:13:13 bigboy named[12026]: listening on IPv4 interface wlan0, 192.168.1.100#53Feb 21 09:13:13 bigboy named[12026]: listening on IPv4 interface eth0, 172.16.1.100#53Feb 21 09:13:14 bigboy named[12026]: command channel listening on 127.0.0.1#953Feb 21 09:13:14 bigboy named[12026]: zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700Feb 21 09:13:14 bigboy named[12026]: zone 1.16.172.in-addr.arpa/IN: loaded serial 51Feb 21 09:13:14 bigboy named[12026]: zone 1.168.192.in-addr.arpa/IN: loaded serial 51Feb 21 09:13:14 bigboy named[12026]: zone simiya.com/IN: loaded serial 2004021401Feb 21 09:13:14 bigboy named[12026]: zone localhost/IN: loaded serial 42Feb 21 09:13:14 bigboy named[12026]: zone simiya.com/IN: loaded serial 200301114Feb 21 09:13:14 bigboy named[12026]: running

3) Use the host (nslookup in Windows) command for both forward and reverse lookups to make sure the zone files were configured correctly.

If this fails, try:

Double check for your updated serial numbers in the modified files and also inspect the individual records within the files for mistakes.Ensure there isn't a firewall that could be blocking DNS traffic on TCP and/or UDP port 53 between your server and the DNS server.Use the dig command to determine whether the name server for your domain is configured correctly.

Here is an example of querying DNS server ns1.my-site.com for the IP address of www.linuxhomenetworking.com. (You can also replace the nameserver's name with its IP address.)

[root@bigboy tmp]# host www.linuxhomenetworking.com ns1.my-site.comUsing domain server:Name: ns1.my-site.comAddress: 192.168.1.100#53Aliases:

www.linuxhomenetworking.com has address 65.115.71.34

[root@bigboy tmp]#

Here is an example of querying your default DNS server for the IP address of www.linuxhomenetworking.com. As you can see, the name of the specificDNS server to query has been left off the end. Failure in this case could be due not only to an error on your BIND configuration or domain registration butalso to an error in your DNS client's DNS server entry in your Linux /etc/resolv.conf file or the Windows TCP/IP properties for your NIC.

[root@bigboy tmp]# host www.linuxhomenetworking.comwww.linuxhomenetworking.com has address 65.115.71.34[root@bigboy tmp]#

4) You can also use the dig command to determine whether known DNS servers on the Internet have received a valid update for your zone. (Remember ifyou decide to change the DNS servers for your domain that it could take up to four days for it to propagate across the Internet.)

The format for the command is:

dig soa

The name server is optional. If you specify a name server, then dig queries that name server instead of the Linux server's default name server. It issometimes good to query both your name server, as well as a well known name server such as ns1.yahoo.com to make sure your DNS records havepropagated properly. The dig command only works with fully qualified domain names only, because it doesn't refer to the /etc/resolv.conf file.

This command uses the local DNS server for the query. It returns the SOA record information and the addresses of the domain's DNS servers in theauthority section.

[root@bigboy tmp]# dig linuxhomenetworking.com SOA......;; AUTHORITY SECTION:linuxhomenetworking.com. 3600 IN NS ns1.myisp.net.linuxhomenetworking.com. 3600 IN NS ns2.myisp.net.

;; ADDITIONAL SECTION:ns1.myisp.net. 3600 IN A 65.115.70.68ns2.myisp.net. 3600 IN A 65.115.70.69......[root@bigboy tmp]#

Here is a successful dig using DNS server ns1.yahoo.com for the query. As before, it returns the SOA record for the zone.

[root@bigboy tmp]# dig ns1.yahoo.com linuxhomenetworking.com SOA......;; AUTHORITY SECTION:linuxhomenetworking.com. 3600 IN NS ns2.myisp.net.linuxhomenetworking.com. 3600 IN NS ns1.myisp.net. ;; ADDITIONAL SECTION:ns1.myisp.net. 3600 IN A 65.115.70.68ns2.myisp.net. 3600 IN A 65.115.70.69......[root@bigboy tmp]#

Sometimes your SOA dig will fail. This command uses the DNS server ns1.yahoo.com for the query. In this case the authority section doesn't know of thedomain and points to the name server for the entire .com domain at VeriSign.



[root@bigboy tmp]# dig ns1.yahoo.com linuxhomeqnetworking.com SOA......;; QUESTION SECTION:;linuxhomeqnetworking.com. IN SOA;; AUTHORITY SECTION:com. 0 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1077341254 1800 900 604800 900......[root@bigboy tmp]#

Possible causes of failure include:

Typographical errors. In this case the misspelling "linuxhomeqnetworking.com" was entered on the command line.Incorrect domain registration.Correct domain registration, but there is a lag in the propagation of the domain information across the Internet. Delays of up to four days are notuncommon.A firewall could be blocking DNS traffic on TCP and/or UDP port 53 between your server and the DNS server.

Migrating Your Web Site In-HouseIt is important to have a detailed migration plan if you currently use an external company to host your Web site and wish to move the site to a server athome or in your office. At the very least your plan should include these steps:

1. There is no magic bullet that will allow you to tell all the caching DNS servers in the world to flush their caches of your zone file entries. Your bestalternative is to request your existing service provider to set the TTL on my-site.com in the DNS zone file to a very low value, say one minute. Asthe TTL is usually set to a number of days, it will take at least three to five days for all remote DNS servers to recognize the change. Once thepropagation is complete, it will take only one minute to see the results of the final DNS configuration switch to your new server. If anything goeswrong, you can then revert to the old configuration, knowing it will rapidly recover within minutes rather than days.

2. Set up your test server in house. Edit the /etc/hosts file to make www.my-site.com refer to its own IP address, not that of the www.my-site.com sitethat is currently in production. This file is usually given a higher priority than DNS, therefore the test server will begin to think that www.my-site.com is really hosted on itself. You may also want to add an entry for mail.my-site.com if the new Web server is going to also be your new mailserver.

3. Test your server based applications from the server itself. This should include mail, Web, and so on.4. Test the server from a remote client. You can test the server running as www.my-site.com even though DNS hasn't been updated. Just edit your

/etc/hosts file on your Web browsing Linux PC to make www.my-site.com map to the IP address of the new server. In the case of Windows, the filewould be C:\WINDOWS\system32\drivers\etc\hosts. You may also want to add an entry for mail.my-site.com if the new Web server is going to alsobe your new mail server. Your client will usually refer to these files first before checking DNS, hence you can use them to predefine some DNSlookups at the local client level only.

5. Once testing is completed, coordinate with your Web hosting provider to update your domain registration's DNS records for www.my-site.com topoint to your new Web server. As the TTLs were set to one minute previously, you'll be able to see results of the migration within minutes.

6. Once complete, you can set the TTL back to the original value to help reduce the volume of DNS query traffic hitting your DNS server.7. Fix your /etc/hosts files by deleting the test entries you had before.8. You may also want to take over your own DNS. Edit your my-site.com DNS entries with VeriSign, RegisterFree or whoever you bought your

domain from to point to your new DNS servers.

Remember, you don't have to host DNS or mail in-house, this could be left in the hands of your service provider. You can then migrate these services in-house as your confidence in hosting becomes greater.

Finally, if you have concerns that your service provider won't cooperate, then you could explain to the provider that you want to test its failover capabilitiesto a duplicate server that you host in-house. You can then decide whether the change will be permanent once you have failed over back and forth a fewtimes.

DHCP Considerations For DNSIf you have a DHCP server on your network, you'll need to make it assign the IP address of the Linux box as the DNS server it tells the DHCP clients touse. If your Linux box is the DHCP server, then you may need to refer to Chapter 8, "Configuring the DHCP Server".

Simple DNS SecurityDNS can reveal a lot about the nature of your domain. You should take some precautions to conceal some of the information for the sake of security.

Zone Transfer ProtectionThe host command does one DNS query at a time, but the dig command is much more powerful. When given the right parameters it can download theentire contents of your domain's zone file.

In this example, the AFXR zone transfer parameter is used to get the contents of the my-site.com zone file.

[root@smallfry tmp]# dig my-site.com AXFR; DiG 9.2.3 my-site.com AXFR;; global options: printcmdmy-site.com. 3600 IN SOA www.my-site.com. hostmaster.my-site.com. 2004110701 3600 3600 3600 3600my-site.com. 3600 IN NS ns1.my-site.com.my-site.com. 3600 IN MX 10 mail.my-site.com.192-168-1-96.my-site.com. 3600 IN A 192.168.1.96192-168-1-97.my-site.com. 3600 IN A 192.168.1.97192-168-1-98.my-site.com. 3600 IN A 192.168.1.98bigboy.my-site.com. 3600 IN A 192.168.1.100gateway.my-site.com. 3600 IN A 192.168.1.1localhost.my-site.com. 3600 IN A 127.0.0.1mail.my-site.com. 3600 IN CNAME www.my-site.com.ns1.my-site.com. 3600 IN CNAME www.my-site.com.ntp.my-site.com. 3600 IN CNAME www.my-site.com.smallfry.my-site.com. 3600 IN A 192.168.1.102www.my-site.com. 3600 IN A 192.168.1.100my-site.com. 3600 IN SOA www.my-site.com. hostmaster.my-site.com. 2004110701 3600 3600 3600 3600;; Query time: 16 msec



;; SERVER: 192.168.1.100#53(192.168.1.100);; WHEN: Sun Nov 14 20:21:07 2004;; XFR size: 16 records[root@smallfry tmp]#

This may not seem like an important security threat at first glance, but it is. Anyone can use this command to determine all your server's IP addresses andfrom the names determine what type of server it is and then launch an appropriate cyber attack.

In a simple home network, without master and slave servers, zone transfers should be disabled. You can do this by applying the allow-transfer directive tothe global options section of your named.conf file.

options { allow-transfer {none;};};

Once applied, your zone transfer test should fail.

[root@smallfry tmp]# dig my-site.com AXFR...... ; DiG 9.2.3 my-site.com AXFR ;; global options: printcmd ; Transfer failed. [root@smallfry tmp]#

Selectively Disabling RecursionYour caching DNS server can unknowingly participate in a form of DDoS attack if recursive lookups are globally allowed.

Say for example that for political, religious, competitive or otherwise malicious reasons your web site is targeted for an attack. First, a hacker breaks intothe authoritative DNS server for a sub domain, like my-web-site.org, and adds a large TXT record to the sub domain. The hacker then sends thousands ofqueries to unsecured caching DNS servers requesting the TXT record, but there is a catch. The queries use a false source IP address that corresponds to theIP address of the DNS server for your website. The queries are small, but the responses are amplified by the size of the TXT information, and your DNSserver quickly becomes overwhelmed by the flurry of replies. Without DNS, your web site goes off the air. For the administrator of the caching DNSservers, the additional load of the queries can be unnoticeable, but when multiplied by thousands of other poorly configured servers, the attack on your sitebecomes lethal.

The allow-recursion directive placed in the options section of your named.conf file can be used to restrict the networks to which recursive lookups areallowed. In this example an ACL is also used to limit lookups to localhost and the 192.168.1.0/24 network.

acl "recursive_subnets" { 192.168.1.0/24; localhost;};

options { allow-recursion { "recursive_subnets"; };};

Note: This does not restrict forward or reverse lookups defined by the zone files on the server. The server will answer all queries for my-web-site.org if itowns that domain, but it won't respond to queries for servers in another domain such as google.com.

Naming Convention SecurityYour my-site.com domain will probably have a www and a mail subdomain, and they should remain obvious to all. You may want to adjust your DNSviews so that to external users, your MySQL database server doesn't have the letters "DB" or "SQL" in the name, or that your firewall doesn't have theletters "FW" in its name either. This may good for ease of reference within the company, but to the Internet these names provide rapid identifiaction of thetypes of malicious exploits a hacker could use to break in. Web site security refers to anything that helps to guarantee the availability of the site, this is justone of many methods you can use.

ConclusionDNS management is a critical part of the maintenance of any Web site. Fortunately, although it can be a little complicated, DNS modifications are usuallyinfrequent, because the IP address of a server is normally fixed or static. This is not always the case. There are situations in which a server's IP address willchange unpredictably and frequently, making DNS management extremely difficult. Dynamic DNS was created as a solution to this and is explained inChapter 19, "Dynamic DNS".

Retrieved from "http://www.linuxhomenetworking.com/wiki/index.php?title=Quick_HOWTO_:_Ch18_:_Configuring_DNS&oldid=4322"

This page was last modified on 10 August 2012, at 06:01.Content is available under Attribution-NonCommercial-NoDerivs 2.5 .

Documents

Quick HOWTO _ Ch18 _ Configuring DNS - Linux Home Networking