DNS

DNS is an Internet service that translates domain names into IP addresses. Each time you use a domain name, DNS translates the name into the corresponding IP address. As a service, DNS is critical to the operation of the Internet. When you enter www.some-domain.com in a Web browser, it's DNS that takes the www host name and translates it to an IP address. Without DNS, you could be connected to the Internet just fine, but you aren't going no where. Not unless you keep a record of the IP addresses of all of the resources you access on the Internet and use those instead of host/domain names.

So when you visit a Web site, you are actually doing so using the site's IP address even though you specified a host and domain name in the URL. In the background your computer quickly queried a DNS server to get the IP address that corresponds to the Web site's server and domain names. Now you know why you have to specify one or two DNS server IP addresses in the TCP/IP configuration on your System. A "cannot connect" error doesn't necessarily indicate there isn't a connection to the destination server. There may very well be. The error may indicate a failure in "resolving" the domain name to an IP address.

DNS Server Functions

You can set up a DNS server for several different reasons:

· Internet Domain Support: If you have a domain name and you're operating Web, e-mail, FTP, or other Internet servers, you'll use a DNS server ro respond to resolution queries so others can find and access your server(s). This is a serious undertaking and you'd have to set up a minimum of two of them. Here we'll refer to these types of DNS servers as authoritative DNS servers for reasons you'll see later. However, there are alternatives to having your own authoritative DNS server if you have (or want to have) your own domain name. You can have someone else host your DNS records for you. Even if someone else is taking care of your domain's DNS records you could still set up one of the following types of DNS servers.

· Local Name Resolution: Similar to the above scenario, this type of DNS server would resolve the hostnames of systems on your LAN. Typically in this scenario there is one DNS server and it does both jobs. The first being that it receives queries from workstations and the second being that it serves as the authoritative source for the responses (this will be more clear as we progress). Having this type of DNS server would eliminate the need to have (and manually update) a HOSTS file on each system on your LAN. Here we'll refer to these as LAN DNS servers.

· Internet Name Resolution: LAN workstations and other desktop PCs need to send Internet domain name resolution queries to a DNS server. The DNS server most often used for this is the ISP's DNS servers. These are often the DNS servers you specify in your TCP/IP configuration. You can have your own DNS server respond to these resolution queries instead of using your ISP's DNS servers.

Don't take from this that you need three different types of DNS servers. If you were to set up a couple authoritative DNS servers they could also provide the functionality of LAN and simple DNS servers. And a LAN DNS server can simultaneously provide the functionality of a simple DNS server.

Internet resources are usually specified by a domain name and a server hostname. The www part of a URL is often the hostname of the Web server (or it could be an alias to a server with a different host name). DNS is basically just a database with records for these hostnames. The directory for the entire telephone system is not stored in one huge phone book. Rather, it is broken up into many pieces with each city having, and maintaining, its piece of the entire directory in its phone book. By the same token, pieces of the DNS directory database (the "zones") are stored, and maintained, on many different DNS servers located around the Internet. If you want to find the telephone number for a person in XXXXX, you'd have to look in the XXXXX telephone book. If you want to find the IP address of the www server in the some-domain.com domain, you'd have to query the DNS server that stores the DNS records for that domain.

Records and Records

Don't confuse DNS zone records with domain records. Your domain record is created when you fill out a domain name registration application and is maintained by the domain registration service (like Network Solutions) you used to register the domain name. A domain only has one domain record and it contains administrative and technical contact information as well as entries for the authoritative DNS servers (aka "name servers") that are hosting the DNS records for the domain. You have to enter the hostnames and addresses for multiple DNS servers in your domain record for redundancy (fail-over) purposes.

DNS records (zone records) for a domain are stored in the domain's zone file on the authoritative DNS servers. Typically, it is stored on the DNS servers of whatever Web hosting (e-mail, ftp) service is hosting your domain's Web site. However, if you have your own Web server (rather than using a Web hosting service) the DNS records could be hosted by you using your own authoritative DNS servers, or by a third party like EasyDNS.

In short, the name servers you specified in your domain record host the domain's zone file containing the zone records. The name servers, whether they be your Web hosting provider's, those of a third party like EasyDNS, or your own, which host the domain's zone file are auhoritative DNS servers for the domain.

Because DNS is so important to the operation of the Internet, when you register a domain name you must specify a minimum of two name servers. If you set up your own authoritative DNS servers for your domain you must set up a minimum of two of them (for redundency) and these would be the servers you specify in your domain record. While the multiple servers you specify in your domain record are authoritative for your domain, only one DNS server can be the primary DNS server for a domain. Any others are "secondary" servers. The zone file on the primary DNS server is "replicated" (transferred) to all secondary servers. As a result, any changes made to DNS records must be made on the primary DNS server. The zone files on secondary servers are read-only. If you made changes to the records in a zone file on a secondary DNS server they would simply be overwritten at the next replication. As you will see below, the primary server for a domain and the replication frequency are specified in a special type of zone record.

Early on in this page we said that the DNS zone records are stored in a DNS database which we now know is called a zone file. The term "database" is used quite loosely. The zone file is actually just a text file which you can edit with any text editor. A zone file is domain-specific. That is, each domain has its own zone file. Actually, there are two zone files for each domain but we're only concerned with one right now. The DNS servers for a Web hosting provider will have many zone files, two for each domain it's hosting zone records for. A zone "record" is, in most cases, nothing more than a single line in the text zone file.

DNS clients

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 they belong. The file generally has two columns; the first contains a keyword, and the second contains the desired values separated by commas.

Keywords in /etc/resolve.conf

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 localhost.my-name.org, then the entry would just be my-name.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 DNS lookup 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.

e.g.,

search my-site.com my-site.net my-site.org

nameserver x.x.x.x

Important Files Paths

RedHat / 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. When installed, named is fooled into thinking that the directory /var/named/chroot is actually the root or / directory. Therefore, named files normally found in the /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 the files 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.

rpm -q bind-chroot

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 own versions in their chroot locations. Unfortunately, the chroot versions of some of the files are empty.

Location: /var/named/chroot/etc

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 be configured 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 you’ll 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.

Configuring BIND Views in named.conf

Our sample scenario assumes that DNS queries will be coming from the Internet and that the zone files will return 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, 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 figures this out using its views feature which allows you to use predefined 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:

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_resolver for 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 be used 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 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. 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 networks with access control lists (ACLs) and then refer to these lists within their respective view section with the match-clients statement. Some built-in ACLs can save you time:

localhost: Refers to the DNS server itself
localnets: Refers to all the networks to which the DNS server is directly connected
any: 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. All the 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

Let’s 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 to be 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 a zone 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 limit queries 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

Here’s 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 your SOHO/home environment using the 192.168.1.0/24 address space. This isn’t important for the Windows clients on your network, but some Linux applications 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 the authoritative servers to use. Reverse lookups operate similarly by scanning an IP address from left to right to get increasingly specific information about an address.

The similarity in both methods is that increasingly specific information is sought, but the noticeable difference is that for forward lookups the scan is from right 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 reverse order. This order is important to remember or else the configuration will fail. This reverse zone definition for named.conf uses a reverse zone file named 192-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.

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. Once the 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 you’ll 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 don’t 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 named internal_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; };

};

We'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 queries get 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 Internet accessible 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 is best 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 doesn’t need to have the ACL statement at all as the built in ACLs localnets and localhost are sufficient. The sample network won’t need the safe-subnet section in the match-clients line either as there is only one 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 Internet networks 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 Files

You 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 Linux distribution.
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 from authoritative DNS servers. The authoritative servers not only provide the DNS answer but also provide the information's time to live, which is the period for 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 caching servers 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 presented to 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 of Authority (SOA). The data portion is formatted according to the record type and may consist of several values separated by spaces. Similarly, the name is also 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 the format:

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 fields as 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 also add 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. (

2011032601 ; serial # based on date

4H ; refresh after 4 hours

1H ; retry after 1 hour

1W ; expiry after 1 week

1D ) ; minimum TTL 1 day

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 particular database 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 address mapping 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 I’ll 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-mail address 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 tagged to 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 the change was made.
Refresh	Tells the slave DNS server how often it should check the master DNS server. Slaves aren’t usually used in home / SOHO environments.
Retry	The slave’s retry interval to connect the master in the event of a connection failure. Slaves aren’t usually used in home / SOHO environments.
Expiry	Total amount of time a slave should retry to contact the master before expiring the data it contains. Future references will be directed towards the root servers. Slaves aren’t usually used in home/SOHO environments.
Minimum-TTL	There are times when remote clients will make queries for subdomains that don’t exist. Your DNS server will respond with a no domain or NXDOMAIN 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 hostmaster@my-site.com. The serial number is 2004100801 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.

NS, MX, A, PTR and CNAME Record Formats

Record Type	Name Field	Class Field	Type Field	Data Field
NS	Usually blank	IN	NS	IP address or CNAME of the name server
MX	Domain to be used for mail. Usually the same as the domain of the zone file 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 server’s 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 to the 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 to put 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 accepting mail 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 record typically 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 in this 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 systems receiving 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 (the source) 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 in length and that this feature is often exploited in distributed denial of service (DDoS) attacks. The section on "Simple DNS Security" explains how to configure your DNS server to not participate in such an event.

Sample Forward Zone File

Now 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 nameserver

my-site.com. MX 10 mail ; Primary Mail Exchanger

localhost A 127.0.0.1

localhost A 97.158.253.26

mail A 97.158.253.27

ns1 CNAME localhost

www CNAME localhost

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 value ($TTL) is three days, therefore remote DNS caching servers will store learned DNS information from your zone for three days 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 same machine. If they were all different machines, then you'd have an A record entry for each.

www A 97.158.253.26

ns 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 DNS servers periodically poll the master server for updated zone file information, and use the serial number to determine whether the data on the master has been updated. Failing to increment the serial number, even though the contents of the zone file have been modified, could cause your slaves to have outdated information.

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

Sample Reverse Zone File

Now 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 you are 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, so the IP address 192.168.1.100 points to the name localhost.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 records cannot 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 localhost.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 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, ISPs 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.

Loading Your New Configuration Files

Make 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 all seems correct, restart BIND named daemon for the configuration to become active.

[root@localhost tmp]# /etc/init.d/named restart

Or
If you don't want to restart named services use following command.

[root@localhost tmp]# reload_dns

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

Life with Linux

Search This Blog

DNS