= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
In This Chapter Chapter 6 Configuring DNS An Introduction to DNS How To Download and Install The BIND Packages How To Get BIND Started The /etc/resolv.conf File Configuring A Caching Nameserver Important File Locations - (Non Caching DNS) Configuring A Regular Nameserver Troubleshooting BIND How To Migrate Your Website In-House DHCP Considerations For DNS (c) Peter Harrison, www.linuxhomenetworking.com = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = You can make your Linux box into your home network's DNS name server, here's how.
An Introduction to DNS What Is DNS? chapter, the Domain Name System (DNS) is the way in which a website like www.linuxhomenetworking.com is converted to an IP address. What's a Domain? Everyone in the world has a first name and a last or "family" name, DNS is similar. Domains can be simply described as the name given to a family of websites. For example the domain linuxhomenetworking.com has a number of children such as www.linuxhomenetworking.com and mail.linuxhomenetworking.com. We'll see how you can get your very own domain in the sections that follow. What Is BIND? BIND is an acronym for the "Berkeley Internet Name Domain" project which maintains the DNS related software suite that runs under Linux. The most well known program in BIND is "named", the daemon that responds to DNS queries from remote machines. What's A DNS Client? A DNS client doesn't store DNS information; it always has to 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 can learn more about the /etc/resolv.conf file in the sections that follow.
What's An Authoritative DNS Server? These are the servers that provide the definitive information for your DNS domain such as the names of servers and websites in it.
How DNS Servers Find Out Your Site Information There are thirteen "root" (super duper) authoritative DNS servers which all DNS servers query first. These servers know all the authoritative DNS servers for all the main domains such as ".com", ".net" etc. These servers keep track of all the sub domains beneath them. When you register a domain such as "my-site.com" you are actually inserting a record on the ".com" DNS servers that points to the authoritative DNS servers for your domain. We'll discuss how to register you site later.
When To Use A DNS Caching Name Server Most servers don't ask authoritative servers for DNS directly, they usually ask a caching DNS server to do it on their behalf. The caching DNS servers then store (or cache), the most frequently requested information to reduce the lookup overhead of subsequent queries. If you want to advertise your website www.my-site.com to the rest of the world, then a regular DNS server is what you require. Setting up a caching DNS server is fairly straightforward and will work whether or not your ISP provides you with a static or dynamic Internet IP address. Once you have set up your caching DNS server you will then have to configure each of your home network PCs to use it as their DNS server. If your home PCs get their IP addresses using DHCP, then you will have to configure your DHCP server to make it aware of the IP address of your new DNS server so that it can advertise it to its PC clients. Off the shelf router/firewall appliances used in most home networks will usually act as both the caching DNS and DHCP server. In this case a separate DNS server is unnecessary.
When To Use A Static DNS Server If your ISP provides you with a "fixed" or "static" IP address, and you want to host your own website then a regular authoritative DNS server would be the way to go. A caching DNS name server is only used as a reference, 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 Server If your ISP provides your router/firewall with its Internet IP address using DHCP then you must consider dynamic DNS. This chapter assumes that you are using "static" Internet IP addresses.
How To Get Your Own Domain You will still need to register a domain whether or not you use static or dynamic DNS. Dynamic DNS providers frequently offer you a sub-domain of their own site, such as "my-site.dnsprovider.com", in which you register your domain on their site. If you choose to create your very own domain, such as "my-site.com", you will have to register with a company specializing in static DNS registration and then point your registration record to the intended authoritative DNS for your domain. Popular domain registrars include Verisign, Register Free and Yahoo. If you want to use a dynamic DNS provider for your own domain then you will have to point your registration record to the DNS servers of your dynamic DNS provider. Domain registration is covered in a later section, we'll cover how to configure Linux DNS first.
How To Download and Install The BIND Packages Most RedHat and Fedora Linux software products are available in the RPM format. Downloading and installing RPMs isn't hard. If you need a refresher, the chapter on RPMs covers how to do this in detail. When searching for the file, remember that the BIND RPM's filename usually starts with the word "bind" followed by a version number like this: bind-9.2.2.P3-9.i386.rpm.
How To Get BIND Started g>You can use the chkconfig command to get BIND configured to start at boot: [root@bigboy tmp]# chkconfig named on > To start/stop/restart BIND after booting [root@bigboy tmp] # /etc/init.d/named start [root@bigboy tmp]# /etc/init.d/named stop [root@bigboy tmp]# /etc/init.d/named restart > Note: Remember to restart the BIND process every time you make a change to the configuration file for the changes to take effect on the running process.
RedHat 9 Errors When Restarting BIND RedHat 9 doesn't shutdown BIND cleanly and will give a "named: already running" error like the one below when you try to restart it. [root@bigboy tmp]# /etc/init.d/named restart Stopping named: named: already running[root@bigboy tmp]# You may have to use brute force to get it restarted by using the "pkill" command followed by restarting the named init script. [root@bigboy tmp]# pkill -KILL named pkill: 29988 - No such process pkill: 29991 - No such process pkill: 29992 - No such process [root@bigboy tmp]# /etc/init.d/named start [root@bigboy tmp]#
The /etc/resolv.conf File This file is used by DNS clients (servers not running BIND) to determine both the location of their DNS server and the domains to which they belong. It generally has two columns, the first contains a keyword and the second contains the desired value(s) separated by commas. Here is a list of keywords:
| 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, you'll need to have multiple "nameserver" lines. |
|
Domain |
The local domain name to be used by default. If the server is bigboy.my-site.com, then the entry would just be my-site.com |
|
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 each domain in this list and do an nslookup on each to get the remote servers' IP address. This is a handy time saving feature to have so that you can refer to servers in the same domain by only their servername without having to specify the domain. The domains in this list must separated by spaces. |
|
File |
Purpose |
Location Fedora Core |
Location RedHat 9 and Older |
|
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 |
Fedora BIND adds to the confusion by correctly installing the files in their non chroot locations but never uses them.
Before starting Fedora BIND, copy the configuration files to their chroot locations like this:
[root@bigboy tmp]# cp -f /etc/named.conf /var/named/chroot/etc/
[root@bigboy tmp]# cp -f /etc/rndc.* /var/named/chroot/etc/
+ Forward zone file definitions which list files to map domains to IP addresses
+ Reverse zone file definitions which list files to map IP addresses to domains
In this example the forward zone for www.my-site.com is being set up by placing the following entries at the bottom of the named.conf file. The zone file is named my-site.zone and, though not explicitly stated, the file my-site.zone should be located in the default directory of /var/named/chroot/var/named in Fedora Core and in /var/named in RedHat 9 and older.
zone "my-site.com"
{
type master;
notify no;
allow-query { any; };
file "my-site.zone";
};
You can also insert additional entries in the named.conf file to reference other web domains you host. Here is an example for my-other-site.com using a zone file named my-other-site.zone.
zone "my-other-site.com"
{
type master;
notify no;
allow-query { any; };
file "my-other-site.zone";
};
The reverse zone definition below is optional for a home / SOHO
DSL based web site. It just makes you able to do an nslookup query on the
97.158.253.x IP address and get back the true name of the server assigned that
IP address. This is rarely done for home based sites. It is especially
difficult to do this with your DSL ISP if you have less than 256 static IP
addresses (also known as a "Class C" block of addresses).
Note: the reverse order of the IP address in the zone section
is important.
zone "253.158.97.in-addr.arpa"
{
type master;
notify no;
file "253.158.97";
};
Caching DNS servers cache the responses to their queries from authoritative DNS servers. The authoritative servers not only provide the DNS answer but the valid lifetime or time to live (TTL) of the information.
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, which is usually the default, then caching servers will use the original stored response for this length of time before making the query again.
The TTL value for the zone is usually the very first entry in the zone file. In the example below, it is set to three days.
$TTL 3D
The very first record is the Start of Authority (SOA) record which contains general administrative and control information about the domain. Though you would normally think a record would be a single line, the SOA format spans several. It is the most counter-intuitive of them all, the rest of the records are relatively straight forward.
|
Line # |
Column # |
Name |
Description |
|
1 |
1, 2, 3 |
@ IN SOA | > Signifies that the SOA record is about to begin |
| 4 | Nameserver | > Fully qualified name of your primary nameserver.
> It's best to name your name servers ns1.domain.com and/or ns2.domain.com to prevent confusion. > Must be followed by a "." | |
| 5 |
>The email address of the nameserver administrator. >The regular "@" in the e-mail address must be replaced with a "." instead. >The email address must also be followed by a "." | ||
| 6 | " ( " |
> Signifies that we're about to define some performance related variables.
> Also signifies that the record is about to stretch to the next line | |
| 2 | 1 | Serial |
> A serial number for the current configuration.
> Usually in the date format YYYYMMDD with single digit incremented number tagged to the end. |
| 3 | 1 | Refresh | > Tells the slave DNS server how often it should check the master DNS server. Slaves aren't really used in home / SOHO environments. |
| 4 | 1 | Retry | > The slave's retry interval to connect the master in the event of a connection failure. Slaves aren't really used in home / SOHO environments. |
| 5 | 1 | Expire | > Total amount of time a slave will retry to contact the master before expiring the data it contains. Slaves aren't really used in home / SOHO environments. |
| 6 | 1 | Minimum TTL | > The amount of time the DNS server will cache negative responses from the authoritative DNS server. |
| 2 | " ) " | > Signifies that we're all finished with the variables. |
Unlike the SOA record, the NS, MX, A and CNAME records each occupy a single line and the records each have a very similar layout.
NS, MX, A and CNAME Record Formats
|
Record |
Description |
First Column |
Second Column |
Third Column |
Fourth Column |
|
NS |
Lists the name of the name server for the domain |
Blank |
"NS" |
IP address or CNAME of the name server |
N/A |
|
MX |
Lists the mail servers for your domain such as my-site.com |
Domain, followed by a "." |
"MX" |
Mail server priority |
CNAME of mail server or the mail server's FQDN** followed by a "." |
|
A |
Maps an IP address to each server in your domain. There must always be an entry for localhost 127.0.0.1 |
Server name |
"A" |
IP address of server |
N/A |
|
CNAME |
Provides additional alternate "alias" names for servers listed in the "A" records. |
"alias" or "nickname" for server |
"CNAME" |
"A" record name for server |
N/A |
**The Fully Qualified Domain Name (FQDN) is the full DNS name of the server such as mail.my-site.com Note: If you don't put a "." at the end of a host name in a SOA, NS, A or CNAME record, BIND will automatically tack on the domain name. So an "A" record with "www" will be assumed to refer to www.my-site.com. This may be OK in most cases, but if you forget to put the "." after the domain in the MX record for my-site.com, BIND will attach the my-site.com at the end, and you will find your mail server only accepting mail for the domain my-site.com.mysite.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 nameserver my-site.com. MX 10 mail ; Primary Mail Exchanger ; localhost A 127.0.0.1 www A 97.158.253.26 mail CNAME www ns1 CNAME www
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. Primary name servers are more commonly called "ns1" and secondary name servers "ns2". The minimum TTL is set to 3600 seconds, but the overriding $TTL value is 3 days. So remote DNS caching servers will store learned DNS information from your zone for 3 days before flushing it out of their caches. The MX record for my-site.com points to the server named mail.my-site.com "ns1" and "mail" are actually CNAMEs or "aliases" for the web server "www". So here we have an example of the name server, mail server and web server being the same machine. If they were all different machines, then you'd have an "A" record entry for each like the example below. www A 97.158.253.26 mail A 97.158.253.134 ns A 97.158.253.125 The serial number is extremely important. You MUST increment it after editing the file or else BIND will not apply the changes you made when you restart "named".Sample Reverse Zone File
Now we need to make sure that we can do an nslookup query on all our home network's PCs and get their correct IP addresses. This is very important if you are running a mail server on your network as sendmail typically will only relay mail from hosts whose IP addresses resolve correctly in DNS. Here is a sample reverse zone file for our network. ; ; 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. Note: I have included entries for addresses 192.168.1.32 to 192.168.1.36 which are the addresses our DHCP server issues. SMTP mail relay wouldn't work for PCs that 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 ISP's won't usually delegate this ability for anyone with less than a "Class C" block of 256 IP addresses. Most home DSL sites wouldn't qualify.What You Need To Know About NAT And DNS
The above examples assume that the queries will be coming from the Internet with the zone files returning information related to the external 97.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 of the web server, 192.168.1.100. This is because NAT won't work properly if a PC on your home network attempts to connect to the external 97.158.253.26 NAT IP address of your web server. Don't worry. BIND has a way around this called "views". The views feature allows you to force BIND to use pre-defined zone files for queries from certain subnets. This means it's possible to use one set of zone files for queries from the Internet and another set for queries from your home network. Here's a summary of how it's done: Place your zone statements in the /etc/named.conf file in one of two "views" sections. The first section will be called "internal" and will list the zone files to be used by your internal network. The second view called "external" will list the zone files to 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 would see. 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 users on the 192.168.1.0 network. This entry would be inserted in the "internal" section. The creation of the my-site-home.zone file is fairly easy. Just copy it form the my-site.zone file and replace all references to 97.158.253.X with references to 192.168.1.X You must also tell the DNS server which addresses you feel are "internal" and "external". This is done by first defining access control lists (ACLs) and then referring to these lists within each view section with the match-clients statement. There are some built-in ACLs: + "localhost" refers to DNS server itself; + "localnets" refers to all networks to which DNS server is directly connected; + "any" which is self explanatory. Note: You must place your "localhost", "0.0.127.in-addr.arpa" and "." zone statements in the "internal" views section. Remember to increment your serial numbers! Here is a sample configuration snippet for the /etc/named.conf file I use for my home network. All the statements below were inserted after the "options" and "controls" sections in the file. // ACL statement acl "trusted-subnet" { 192.168.17.0/24; }; view "internal" { // What home network will see match-clients { localnets; localhost; "trusted-subnet"; }; zone "." IN { type hint; file "named.ca"; }; zone "localhost" IN { type master; file "localhost.zone"; allow-update { none; }; }; zone "0.0.127.in-addr.arpa" IN { type master; file "named.local"; allow-update { none; }; }; zone "1.168.192.in-addr.arpa" IN { type master; file "192-168-1.zone"; allow-update { none; }; }; zone "my-site.com" { type master; notify no; file "my-site-home.zone"; allow-query { any; }; }; zone "my-other-site.com" { type master; notify no; file "my-other-site-home.zone"; allow-query { any; }; }; }; view "external" { // What the Internet will see match-clients { any; }; recursion no; zone "my-site.com" { type master; notify no; file "my-site.zone"; allow-query { any; }; }; zone "my-other-site.com" { type master; notify no; file "my-other-site.zone"; allow-query { any; }; }; }; Note: In the above example I included an ACL for network 192.168.17.0/24 called "trusted-subnet" to help clarify the use of ACLs in more complex environments. Once the ACL was defined, I then inserted a reference to the "trusted-subnet" in the match-clients statement in the "internal" view. So in this case the local network (192.168.1.0 /24), the other trusted network (192.168.17.0) and localhost will get DNS data from the zone files in the "internal" view. Remember, this is purely an example. The home network we have been using doesn't need to have the ACL statement at all as the built in ACLs "localnets" and "localhost" are sufficient. Our network won't need the "trusted-subnet" section in the match-clients line either.Loading Your New Configuration Files
Make sure your file permissions and ownership are OK in /var/named [root@bigboy tmp]# cd /var/named [root@bigboy named]# ll total 6 -rw-r--r-- 1 named named 195 Jul 3 2001 localhost.zone -rw-r--r-- 1 named named 2769 Jul 3 2001 named.ca -rw-r--r-- 1 named named 433 Jul 3 2001 named.local -rw-r--r-- 1 root root 763 Oct 2 16:23 my-site.zone [root@bigboy named]# chown named * [root@bigboy named]# chgrp named * [root@bigboy named]# ll total 6 -rw-r--r-- 1 named named 195 Jul 3 2001 localhost.zone -rw-r--r-- 1 named named 2769 Jul 3 2001 named.ca -rw-r--r-- 1 named named 433 Jul 3 2001 named.local -rw-r--r-- 1 named named 763 Oct 2 16:23 my-site.zone [root@bigboy named]# The configuration files above will not be loaded until you issue the following command to restart the named process that controls DNS (Make sure to increment your configuration file serial number before doing this): [root@bigboy tmp]# /etc/init.d/named restartMake Sure Your /etc/hosts File Is Correctly Updated
The chapter covering Linux networking topics explains how to do this. Some programs such as sendmail require a correctly configured /etc/hosts file even though DNS is correctly configured.Configure Your Firewall
The sample network we're using assumes that the BIND nameserver and Apache web server software run on the same machine protected by a router/firewall. The actual IP address of the server is 192.168.1.100, which is a private IP address. You'll have to employ NAT in order for Internet users to be able to gain access to the server via the Public IP address we chose, namely 97.158.253.26. If your firewall is a Linux box, you may want to consider taking a look on the iptables chapter on how to do the NAT and allow DNS traffic trough to your nameserver.Fix Your Domain Registration
Remember 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 to do the following two steps: First, you'll have to 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 name server is called. (This screen will prompt you for both the server's IP address and name) Then you'll have to assign ns.my-site.com to handle your domain. (This screen will prompt you for the server name only) Sometimes, the registrar will require at least two registered name servers per domain. If you only have one, then you could either: Create a second name server record entry with the same IP address, but different name. Give your web server a second IP address using an IP alias , create a second 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 3-4 days for your updated DNS information to be propagated to all 13 of the world's root ("super duper") name servers. You'll therefore have to wait about this amount of time before you'll start noticing people hitting your new website site. You can use the troubleshooting section below to test specific DNS servers for the information they have on your site. You'll most likely want to test your new DNS server (which should be up to date) plus a few well known ones (which should have delayed values).Troubleshooting BIND
> The very first step is to 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 from both inside your network and from the Internet. Troubleshooting with Telnet is covered in the Network Troubleshooting chapter. >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. Check your /etc/named.conf file if they fail to do so. Linux logging is covered in the Syslog chapter. Feb 21 09:13:14 bigboy named: named startup succeeded Feb 21 09:13:14 bigboy named[12026]: loading configuration from '/etc/named.conf' Feb 21 09:13:14 bigboy named[12026]: no IPv6 interfaces found Feb 21 09:13:14 bigboy named[12026]: listening on IPv4 interface lo, 127.0.0.1#53 Feb 21 09:13:14 bigboy named[12026]: listening on IPv4 interface wlan0, 192.168.1.100#53 Feb 21 09:13:14 bigboy named[12026]: listening on IPv4 interface eth0, 172.16.1.100#53 Feb 21 09:13:14 bigboy named[12026]: command channel listening on 127.0.0.1#953 Feb 21 09:13:14 bigboy named[12026]: zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700 Feb 21 09:13:14 bigboy named[12026]: zone 1.16.172.in-addr.arpa/IN: loaded serial 51 Feb 21 09:13:14 bigboy named[12026]: zone 1.168.192.in-addr.arpa/IN: loaded serial 51 Feb 21 09:13:14 bigboy named[12026]: zone simiya.com/IN: loaded serial 2004021401 Feb 21 09:13:14 bigboy named[12026]: zone localhost/IN: loaded serial 42 Feb 21 09:13:14 bigboy named[12026]: zone simiya.com/IN: loaded serial 200301114 Feb 21 09:13:14 bigboy named[12026]: running > Use the nslookup command for both forward and reverse lookups to make sure the zone files were configured correctly. If nslookup fails, try some of the following: 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 as explained below to determine whether the name server for your domain is configured correctly. > The host command will probably replace nslookup in the near future. You can use it to query any DNS server for information on your site. 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 name server's name with its IP address.) [root@bigboy named]# host www.linuxhomenetworking.com ns1.my-site.com 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 specific DNS server to query has been left off the end. [root@bigboy named]# host www.linuxhomenetworking.com > The dig command can also be used to determine whether known DNS servers on the Internet have received a valid update for your zone. Remember if you decide to change the DNS servers for your domain that it could take up to 4 days for it to propagate across the Internet. The format for the command is: dig "name-server" "zone" 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 is sometimes good to query both your name server as well as a well known name server like ns1.yahoo.com to make sure your DNS records have propagated properly. Successful "dig" for the zone Linuxhomenetworking.com 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 the "Authority Section". [root@bigboy tmp]# dig linuxhomenetworking.com SOA ... ... ;; AUTHORITY SECTION: linuxhomenetworking.com. 3600 IN NS ns1.homenet.net. linuxhomenetworking.com. 3600 IN NS ns2.homenet.net. ;; ADDITIONAL SECTION: ns1.homenet.net. 3600 IN A 65.115.70.68 ns2.homenet.net. 3600 IN A 65.115.70.69 ... [root@bigboy tmp]# Successful "dig" using DNS server ns1.yahoo.com This command uses the 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.homenet.net. linuxhomenetworking.com. 3600 IN NS ns1.homenet.net. ;; ADDITIONAL SECTION: ns1.homenet.net. 3600 IN A 65.115.70.68 ns2.homenet.net. 3600 IN A 65.115.70.69 ... ...[root@bigboy tmp]# Unsuccessful SOA "dig" This command uses the DNS server ns1.yahoo.com for the query. In this case the "Authority Section" doesn't know of the domain 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 misspelled "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 not uncommon. 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.How To Migrate Your Website In-House
It is important to have a detailed migration plan if you currently use an external company to host your website and wish to move the site to a server at home or in your office. At the very least it should include the following steps: >There is no magic bullet which will allow you to tell all the caching DNS servers in the world to flush their caches of your zone file entries. Your best alternative will be 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 1 minute. As the TTL is usually set to 3 days, it will take at least 3-5 days for all remote DNS servers to recognize the change. Once the propagation is complete, it will take only 1 minute to see the results of the final DNS configuration switch to your new server. If anything goes wrong, you can then revert to the old configuration, knowing it will rapidly recover within minutes rather than days. > 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 site that 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 mail server. > Test your applications on the server. Mail, web, etc. Note: 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 file would be C:\WINDOWS\system32\drivers\etc. 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 mail server. > Once testing is completed, coordinate with your web hosting provider to update your domain registration's DNS records for www.my-site.com to point to your new web server. > As the TTLs were set to 1 minute previously, you'll be able to see results of the migration within minutes. >Once complete, you can set the TTL back to 3 days to help reduce the volume of DNS query traffic hitting your DNS server. >Fix your /etc/hosts files by deleting the test entries you had before. >Once completed, 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 co-operate then you could explain to them that you want to test their failover capabilities to 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 few times.DHCP Considerations For DNS
If 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 to use. If your Linux box is the DHCP server, then you may need to refer to the DHCP server chapter.