Cisco – Router as a DNS Server

As many didn’t know (me included) you can configure cisco router as DNS server.

A cisco router can:

• Reply to requests for locally defined DNS entries.
• Forward the request the public DNS servers (max 6)

In the cenario bellow we are going setup and test this.

 

Configs

-- R1 --

interface FastEthernet0/0
description *** LAN ***
ip address 192.168.1.254 255.255.255.0
no shutdown

interface FastEthernet0/1
description *** WAN ***
ip address 200.0.0.2 255.255.255.252
no shutdown
 
ip route 0.0.0.0 0.0.0.0 200.0.0.1 name DefaultRoute
 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! Enable the router as a DNS server
! and domain lookup on the router
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ip dns server
ip domain-lookup

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! Public name-servers, for the router to query
! the names it doesn't know
! Maximum 6x DNS servers
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ip name-server 4.2.2.5
ip name-server 4.2.2.6

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! Local DNS Entries
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ip host PC1 192.168.1.1
ip host PC2 192.168.1.2
ip host PC3 192.168.1.3

The big secret here is the “ip dns server”, because the rest of the config you could have it to solve name locally on the router.

With the “ip dns server” you extend the router’s local name resolution, to the hosts on the network.

 

-- PC1 --

The PCs on my topology are actually routers so here is my config:

-- PC1 (Router) --
interface FastEthernet0/0
ip address 192.168.1.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 192.168.1.254 name GW

ip domain-lookup
ip name-server 192.168.1.254

-- PC2 (Router) --
interface FastEthernet0/0
ip address 192.168.1.2 255.255.255.0
no shutdown
 
ip route 0.0.0.0 0.0.0.0 192.168.1.254 name GW

ip domain-lookup
ip name-server 192.168.1.254

-- PC3 (Router) --
interface FastEthernet0/0
ip address 192.168.1.3 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 192.168.1.254 name GW

ip domain-lookup
ip name-server 192.168.1.254

 

Tests

-- Test the Local Entries for The PCs on the LAN --

PC1#ping PC2
Translating "PC2"...domain server (192.168.1.254) [OK]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms

PC1#ping PC3
Translating "PC3"...domain server (192.168.1.254) [OK]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/5 ms
PC1#

-- Test Forwarding Request to Public DNS Servers--

PC1#ping www.google.com

Translating "www.google.com"...domain server (192.168.1.254) [OK]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 216.58.208.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/69/84 ms

 

Related Links:

• http://www.firewall.cx/cisco-technical-knowledgebase/cisco-routers/257-cisco-router-dns-server.html

DNS with a DD-WRT Router

Setup Local/Internal DNS with a DD-WRT Router

I’ve talked about some features of the DD-WRT router before, and one of the things I’ve been playing around with lately is DNSMasq. There’s a good chance you haven’t noticed this setting in DD-WRT because it’s not something most people would ever think to use. Plus DNSMasq can be found in two different areas within DD-WRT since it can be used for both DHCP assignments as well as internal/local DNS management. What I will be focusing on is the local DNS aspect.

When is using DNSMasq useful for controlling DNS? Here are some examples as to why you may want to use it:

 

• You have DNS pointing to something that is hosted on your home network and it is also accessible from outside your network. For example, you may have a security camera that has a domain attached to it (e.g. camera.example.com), and it’s accessed from both on and off your network. Using DNSMasq on your router you can make the domain, camera.example.com, point to the internal IP of the camera so that anyone who accesses that camera from within your network won’t have to rely on external DNS getting resolved. You should see at least a slight performance boost that way.

 

• You want to override public DNS entries, such as google.com. You can obviously pull off some great pranks by directing traffic to sites like google.com or facebook.com to some custom site you create, but there are other reasons this is legitimately useful. Maybe you are testing a new version of your own website, but want to make sure it will work fine with the live domain. DNSMasq can help you accomplish that.

 

• You want to create DNS for a site that is accessible using only a single word, such as intranet. Companies do this kind of thing all the time where an internal-only website can be reached without needing or wanting a publicly-accessible URL.

 

I know what you may be thinking… why wouldn’t you just update the HOSTS file on your local machine? Well, you could, but not all devices support that feature. By using DNSMasq the DNS change will work for anything connecting to your router, including mobile devices such as phones and tablets.

So what do you have to change in DD-WRT? Here’s what you need to do:

1. Go to the Services tab once you’ve logged into the administration interface.
2. Find the section labeled DNSMasq, and make sure the DNSMasq option is enabled.
3. This is the fun part. In the Additional DNSMasq Options box type out your local DNS configurations in the format of one entry per line:
   • address=/machine_or_domain_name/ip_address – where machine_or_domain_name is what you want to create/change DNS for (e.g. camera.example.com, google.com, intranet) and ip_address is the new IP address you want it to point to.
4. Apply the settings to DD-WRT, and you should be all set.

This is an example of what your DNSMasq settings may look like:

If your devices don’t see the changes after they’ve been made you may need to try restarting them since that is often the simplest way to clear the DNS cache.

Taken From: http://cybernetnews.com/local-internal-dns-ddwrt/

Windows Server 2008 Domain Controller and DNS Server Setup

This tutorial will explain how to setup Windows Server 2008 Domain Controller and DNS
Server.

Click on Start > Run

Now type dcpromo > Click OK

The system will start checking if Active Directory Domain Services ( AD DS) binaries are installed, then will start installing them. The binaries could be installed if you had run the dcpromo command previously and then canceled the operation after the binaries were installed.

The Active Directory Domain Services Installation Wizard will start, either enable the checkbox beside Use Advanced mode installation and Click Next , or keep it unselected and click on Next

The Operating System Compatibility page will be displayed, take a moment to read it and click Next

Choose Create a new domain in a new forest, Click Next

Enter the Fully Qualified Domain Name of the forest root domain inside the textbox, click Next

If you selected Use advanced mode installation on the Welcome page, the Domain NetBIOS Name page appears. On this page, type the NetBIOS name of the domain if necessary or accept the default name and then click Next.

Select the Forest Functional Level, choose the level you desire and click on Next.

Make sure to read the description of each functional level to understand the difference between each one.

In the previous step, If you have selected any Forest Functional Level other than windows Server 2008 and clicked on Next , you would then get a page to select the domain Functional Level. Select it and then click on Next

In the Additional Domain Controller Options page, you can select to install the domain Name Service to your server. Note that the First domain controller in a forest must be a Global Catalog that’s why the checkbox beside Global Catalog is selected and it cannot be cleared. The checkbox is also selected by default when you install an additional domain controller in an existing domain, however you can clear this checkbox if you do not want the additional domain controller to be a global catalog server. The first domain controller in a new forest or in a new domain can not be a Read Only Domain Controller (RODC), you can later add a RODC but you must have at least one Windows Server 2008 Domain Controller.

I want to set my DC as a DNS Server as well, so I will keep the checkbox beside DNS server selected and click on Next

If you don’t have static ip assigned to your server you will see similar to the following screen now you need to assign static ip and start the above process.

If the wizard cannot create a delegation for the DNS server, it displays a message to indicate that you can create the delegation manually. To continue, click Yes

Now you will have the location where the domain controller database, log files and SYSVOL are stored on the server.

The database stores information about the users, computers and other objects on thenetwork. the log files record activities that are related to AD DS, such information about an object being updated. SYSVOL stores Group Policy objects and scripts. By default, SYSVOL is part of the operating system files in the Windows directory either type or browse to the volume and folder where you want to store each, or accept the defaults and click on Next

In the Directory Services Restore Mode Administrator Password (DSRM) page, write a password and confirm it. This password is used when the domain controller is started in Directory Services Restore Mode, which might be because Active Directory Domain services is not running, or for tasks that must be performed offline.Make sure that you memorize this password when you need it.

Summary page will be displayed showing you all the setting that you have set . It gives you the option to export the setting you have setup into an answer file for use with other unattended operations, if you wish to have such file, click on the Export settings button and save the file.

DNS Installation will start

Followed by installing Group Policy Management Console, the system will check first if it is installed or not.

Configuring the local computer to host active directory Domain Services and other operations will take place setting up this server as a Domain Controller active Directory Domain Services installation will be completed, click Finish.

Click on Restart Now to restart your server for the changes to take effect.

Once the server is booted and you logon to it, click on Start > Administrative Tools
you will notice that following have been installed :
Active Directory Domains and Trusts
Active Directory Sites and Services
Active Directory Users and Computers
ADSI Edit
DNS
Group Policy Management

That’s it now your new win server 2008 domain controller with dns server setup was completed.

Taken From: http://www.windowsreference.com/windows-server-2008/step-by-step-guide-for-windows-server-2008-domain-controller-and-dns-server-setup/

Turning Your PC into a DD-WRT Wired Router - From Windows

Normally, when we cover DD-WRT and other firmware replacements for wireless routers, we discuss flashing (or uploading) the firmware to a router. However, DD-WRT also has an X86 version that can be installed onto just about any generic PC.

This is great if you don’t have a compatible router lying around and don’t want to track one down with the right model and version number. Plus it lets you exceed the usual 16MB of RAM and slow CPU in the off-the-shelf consumer-level routers.

In this tutorial, we’ll build and set up a DD-WRT machine.

Features on a normal dd-wrt firmware (wifi router):
http://www.dd-wrt.com/wiki/index.php/What_is_DD-WRT%3F

Limitations of the X86 version

Keep in mind; if you want to go the free route, you’ll only have a wired router—but you can add separate access points. Wi-Fi support is only available in the registered version by purchasing a Professional Activation for € 20.00 ($28.36).

You also lose these features for any X86 version of DD-WRT:

• USB Support. For example, you can’t connect USB drives or printers to share them on the network.
• Journaling Flash File System (jffs). Normally this would let you store files directly on the router, such as for NoCatSplash hotspot captive portal pages and other custom configuration.
• Itsy Package Management System (Ipkg). This would have let you add features from OpenWRT that aren’t already in DD-WRT.

Putting the DD-WRT machine together

First, make sure you have an X86 compatible PC, i386 or greater, which is just about any old PC. You need only 16MB or more of RAM. However, you do need at least two network (Ethernet) cards, one for the Internet and others for the LAN.

Don’t forget a spare hard drive. It must be dedicated to the cause as it will be reformatted and repartitioned.

Though a monitor and keyboard aren’t required, they’re useful if you run into problems, so you can access the console.

Getting ready for the installation

We’re going to use a Windows-based program to upload the DD-WRT disk image to the spare hard drive. So you need to take the drive out of the DD-WRT machine and temporarily put it into a working computer.

On your working computer, you need to download the transfer utility, physdiskwrite, and the desired X86 version of DD-WRT. At the time of this writing, the most current release is v24 Service Pack 1. If going the free route download dd-wrt_public_vga.image or dd-wrt_full_vga.image if you’re purchasing a license.

It’s easier to download the DD-WRT file to the physdiskwrite folder.

Verify the drive assignments

When you upload the disk image to the drive, the utility will be referencing the computer’s drives using the disk numbers. So you’re absolutely sure you have the right disk—and not the one you use every day—you should verify the drive assignments.

You can open the Computer Management program to view the Disk Management utility in Windows:

In Vista, click Control Panel > System and Maintenance > Administrative Tools > Computer Management.

In XP, Control Panel > Performance and Maintenance > Administrative Tools > Computer Management.

The disk numbers (Disk0, Disk1, Disk2, etc.) are shown on the graph of drives and partitions.

Transferring the image using physdiskwrite

When you’re ready, here’s how to install DD-WRT X86 onto your hard drive from your working computer:

1.    Bring up a Command Prompt. If using Vista, click the Start button, type cmd into the search box, right-click the cmd icon, and select Run as administrator. In XP, simply click Start > Run, type cmd and hit Enter.

2.    Navigate to the directory where you have the physdiskwrite utility and disk image. It might be easier to browse to the location in Windows and copy the location from the address bar. Then in the Command Prompt you’d type cd, paste in the path, and hit Enter.

3.    Type physdiskwrite -u dd-wrt_public_vga.image and hit Enter. Adjust the image file name if you’re using a different one.

4.    Type the disk number of the spare drive. WARNING: Remember, this completely erases everything from the drive and you’ll lose any files on it.

5.    After it completes, shut down and unplug the computer to remove the drive and put it back in the DD-WRT machine.

Getting started with DD-WRT X86

After DD-WRT boots up, the router should start working. You should hook the WAN/Internet cable up to the ether0 interface, which is usually the built-in or on-board Ethernet port, if any. The remaining interfaces are for the LAN/network. You can connect them to computers or to a switch.

You can figure out which interface is which by referencing the console screen after hooking up a cable to the interfaces. It tells you the status, which includes the interface number.

The default IP address is of the router is 192.168.1.1. The DHCP server is enabled, just like with the firmware versions, so users will automatically receive an IP. To access the Web GUI, type the IP of the router into a browser. To access the console on the machine, hit Enter. The default username is root and the password is admin.

Read our other DD-WRT tutorials

Now that you have a DD-WRT router up and running—hopefully—take a look at all the tutorials we have on the subject. Maybe extend your range with WDS, build a wireless bridge, use multiple SSIDs, and much more.

Eric Geier is the author of many networking and computing books, including Home Networking All-in-One Desk Reference For Dummies (Wiley 2008) and 100 Things You Need to Know about Microsoft® Windows Vista (Que 2007).

Taken From: http://www.wi-fiplanet.com/tutorials/article.php/3835526

Configure a Linux DNS Server - Cache and Private DNS

Configure a Linux DNS Server - Part I (Caching Name Server)


Not everybody's a Linux hacker straight out of the womb. For those who need a solid example or just want a little advice--no heckling involved--here's another how-to to get you going. We've helped you set up your home web server, so now let's get DNS working so you can have your very own domain.



How to set up a home DNS server
by Shannon Hughes



Domain Name System

The Domain Name System (DNS) is the crucial glue that keeps computer networks in harmony by converting human-friendly hostnames to the numerical IP addresses computers require to communicate with each other. DNS is one of the largest and most important distributed databases the world depends on by serving billions of DNS requests daily for public IP addresses. Most public DNS servers today are run by larger ISPs and commercial companies but private DNS servers can also be useful for private home networks. This article will explore some advantages of setting up various types of DNS servers in the home network.



Why set up a private DNS server?

This question is valid and the answer may vary depending on your home network environment. Maintaining a host file on each client with IP/hostname mappings in a home network that contains a router and a few machines may be sufficient for most users. If your network contains more than a few machines, then adding a private DNS server may be more attractive and worth the setup effort. Some advantages may include:

*

Maintenance: keeping track of the host file for every client in your network can be tedious. In fact, it may not even be feasible for roaming DHCP laptops or your occasional LAN party guests. Maintaining host information in one central area and allowing DNS to manage host names is more efficient.
*

Cache performance: DNS servers can cache DNS information, allowing your clients to acquire DNS information internally without the need to access public nameservers. This performance improvement can add up for tasks such as web browsing.
*

Prototyping: A private internal DNS server is an excellent first step to eventually setting up a public accessible DNS server to access a web server or other services hosted on your internal network. Learning from mistakes on an internal network can help prevent duplicate errors on a public DNS server that could result in loss of service for external users. Note: Some ISPs require customers to have a static IP or business subscription when hosting services in a home network environment.
*

Cool factor: Ok, I may be stretching it, but the "cool" factor did have some influence when I set up my first home network DNS server. Creating an internal domain that reflects an individual's personality without paying a domain registrar and issuing hostnames to your clients is cool. The cool factor doubles when your customized hostname glows from your friend's laptop screen.

Let's start out simply by setting up a caching-only nameserver to handle client DNS requests. A caching-only nameserver won't allow references to internal clients by hostname, but it does allow clients to take advantage of frequently requested domains that are cached.
Caching nameserver

Fortunately, setting up a caching nameserver is easy using RHEL (Red Hat Enterprise Linux) or Fedora RPMs. The following RPMs need to be installed on the machine acting as the nameserver (use rpm -q to determine if these packages are installed):

*

bind (includes DNS server, named)
*

bind-utils (utilities for querying DNS servers about host information)
*

bind-libs (libraries used by the bind server and utils package)
*

bind-chroot (tree of files which can be used as a chroot jail for bind)
*

caching-nameserver (config files for a simple caching nameserver)

A caching nameserver forwards queries to an upstream nameserver and caches the results. Open the file /var/named/chroot/etc/named.conf and add the following lines to the global options section:


forwarders { xxx.xxx.xxx.xxx; xxx.xxx.xxx.xxx; }; #IP of upstream ISP nameserver(s)
forward only; #rely completely on our upstream nameservers


The block above will cause the caching name server to forward DNS requests it can't resolve to your ISP nameserver. Save the named.conf file and then assign 644 permissions:

$ chmod 644 named.conf

Check the syntax using the named-checkconf utility provided by the bind RPM:
named-checkconf named.conf
Correct any syntax errors (watch those semicolons) named-checkconf reports. Monitoring the /var/log/messages file may also be helpful in debugging any errors.


We now need to set the local resolver to point to itself for DNS resolution. Modify the /etc/resolv.conf file to the following:

nameserver 127.0.0.1

If you are running a DHCP server on your router make sure your /etc/resolv.conf file does not get overwritten whenever your DHCP lease is renewed. To prevent this from happening, modify /etc/sysconfig/network-scripts/ifcfg-eth0 (replace eth0 with your network interface if different) and make sure the following settings are set:


BOOTPROTO=dhcp
PEERDNS=no
TYPE=Ethernet


Go ahead and start the nameserver as root and configure to start in runlevels 2-5:

service named start
chkconfig named on
Testing

The bind-utils RPM contains tools we can use to test our caching nameserver. Test your nameserver using host or dig and querying redhat.com:

dig redhat.com
.
.
;; Query time: 42 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)


From the above dig query you can see it took 42 msec to receive the DNS request. Now test out the caching ability of your nameserver by running dig again on the redhat.com domain:

dig redhat.com
.
.
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)


We dropped from 42 msec to 1 msec after the previous DNS query was cached. Caching is working! Let's now put the cache to work by configuring the clients to use the new caching nameserver.
Client Configuration

For Linux and Windows clients you may have a couple of options for your resolver configuration depending on your network environment:

1.

If you have a router and your client's IP address is assigned via DHCP from the router, then you can use the router to assign the primary nameserver during the DHCP lease requested from the client. Log in to your router and make sure your primary nameserver points to your caching nameserver IP address in the router DHCP settings.



2.

For Linux clients, you can set up the resolver in the same procedure as the nameserver by modifying the /etc/resolv.conf file. For Windows clients you will need to set the nameserver IP address in the Control Panel -> Network Connections -> TCP/IP -> Properties -> Use the DNS Server Address option. NOTE: The Windows DNS server option may vary depending on your version.

Test your new client configuration(s) using dig. You can use the nslookup command for Windows clients. Your DNS requests should have similar response times as we saw earlier when testing the nameserver directly.

NOTE: If you are running a firewall on the nameserver system, make sure clients have access to port 53. An example iptables rule for the 192.168.15.0/24 subnet would be:
iptables -A INPUT -s 192.168.15.0/24 -p udp --dport 53 -j ACCEPT
service iptables save



Summary

Your new caching nameserver offers a performance improvement with a minimal amount of set up effort. Clients can now ask the caching nameserver for DNS information, and it only needs to ask the upstream ISP nameserver for cache misses. In the next issue we will setup a master nameserver that is responsible for the authoritative information for our internal client hostnames. An authoritative nameserver also caches by default but additionally allows managing both static and DHCP clients using personalized hostnames set up in zone files. In the meantime, enjoy your new caching nameserver and be thinking about a creative domain and hostname theme for your future authoritative nameserver.


Configure a Linux DNS Server - Part II (Private DNS Server)


Welcome back
In the first part of this series on the Domain Name System (DNS), we set up a caching nameserver that allowed our clients to take advantage of faster network operations by caching frequently requested DNS queries. In this article, we will extend our caching nameserver to a master nameserver that is responsible for managing the authoritative information for our internal client hostnames.



Overview

As with our caching-only nameserver, we will see that BIND RPMS packaged by Red Hat® Enterprise Linux® and Fedora ease the process of configuring our master nameserver. Adding authoritative responsibility to the caching-only nameserver only requires us to add two more files and modify the existing named.conf file. For the purpose of this article we will assume the following:


* The BIND 9.x RPMS discussed in Part 1 are installed on the machine that will serve as a nameserver.
* Our internal network is in the 192.168.15.0/24 subnet. You will need to substitute your subnet if different.
* The master nameserver will only allow DNS queries from internal clients in the 192.168.15.0/24 subnet.
* The master nameserver will continue to forward any DNS requests it can't answer to your upstream ISP nameserver(s).
* We will use the domain hughes.lan as our internal domain name.


You might notice that we selected a mock top-level domain (sometimes referred as a TLD) named lan. Our internal domain name can be as creative as we wish since the domain is only known inside our home network. The naming convention for a public nameserver is not as relaxed, since we would need to follow certain rules that would allow our nameserver to respond to other nameservers requesting host information from around the world.



Zones

Nameservers store information about a domain namespace in files called zone data files. A zone data file contains all the resource records that describe the domain represented in the zone. The resource records further describe all the hosts in the zone. We will need to modify our existing named.conf to reference two zone files for our domain name:

* Forward zone definitions that map hostnames to IP addresses.
* Reverse zone definitions that map IP addresses to hostnames.

Open /var/named/chroot/etc/named.conf and add the following forward and reverse zone file directives:

# Forward Zone for hughes.lan domain
zone "hughes.lan" IN {
type master;
file "hughes.lan.zone";
};

# Reverse Zone for hughes.lan domain
zone "15.168.192.in-addr.arpa" IN {
type master;
file "192.168.15.zone";
};

Both the forward and reverse zones contain the type master indicating that our nameserver is the master or primary nameserver for the hughes.lan domain. The file keyword indicates which zone file contains the resource records for the corresponding zone. Note that the reverse zone contains a special domain named in-addr-arpa. DNS uses this special domain to support IP to hostname mappings. Reverse lookups are backwards since the name is read from the leaf to the root (imagine a domain name as a tree structure) so the resultant domain name has the topmost element at the right-hand side. For a home network the reverse lookup zones can be considered optional but we will include them for completeness.

Included with the BIND RPMs is a root zone nameservers use when a query is unresolvable by any other configured zones. The root zone directive is named ".", has a type of hint and references a file named named.ca that contains a list of 13 root name servers located around the world. We will not directly use the root servers since we are forwarding any unresolvable queries to our ISP nameservers.

We need to modify the named.conf global options to allow our internal clients to query the nameserver. Modify the existing global options block to the following:

acl hughes-lan { 192.168.15.0/24; 127.0/8; };
options {
directory "/var/named";
allow-query { hughes-lan; };
forwarders { xxx.xxx.xxx.xxx; xxx.xxx.xxx.xxx; }; # ISP primary/secondary
forward-only; # Rely completely on ISP for cache misses
};

The acl statement above sets up a range of IP addresses we can reference throughout the named.conf file. The allow-query specifies IP addresses of hosts that can query our nameserver. The forwarders statement tells our nameserver to forward any unresolvable queries to our upstream nameservers. The forward-only statement restricts our nameserver to only rely on our ISP nameservers and not contact other nameservers to find information that our ISP can not provide. It's very rare for a primary and secondary ISP nameserver to be down at the same time but you can comment forward-only if you want your nameserver to try the root nameservers when the upstream ISP nameservers cannot resolve a hostname.



Zone files

We are now ready to start defining our hostname mappings in the zone files we referenced in the named.conf configuration. Zone files need to be placed in the /var/named/chroot/var/named directory, have 644 permissions with an owner and group of named:

$ cd /var/named/chroot/var/named
$ touch hughes.lan.zone
$ chown named:named hughes.lan.zone
$ chmod 644 hughes.lan.zone

Let's take a look at an example zone file for the hughes.lan forward zone and then dive into the various parts:

$TTL 1D

hughes.lan. IN SOA velma.hughes.lan. foo.bar.tld. (
200612060 ; serial
2H ; refresh slaves
5M ; retry
1W ; expire
1M ; Negative TTL
)

@ IN NS velma.hughes.lan.

velma.hughes.lan. IN A 192.168.15.10 ; RHEL server
fred.hughes.lan. IN A 192.168.15.1 ; router
scooby.hughes.lan. IN A 192.168.15.2 ; upstairs WAP
shaggy.hughes.lan. IN A 192.168.15.3 ; downstairs WAP
scooby-dum.hughes.lan. IN A 192.168.15.4 ; Fedora desktop
daphne.hughes.lan. IN A 192.168.15.5 ; network printer
mysterymachine IN A 192.168.15.6 ; mail server
scrappy IN A 192.168.15.7 ; Windows box
; aliases
www IN CNAME velma.hughes.lan. ; WWW server
virtual IN CNAME velma ; virtual WWW tests
mail IN CNAME mysterymachine ; sendmail host

; DHCP Clients
dhcp01.hughes.lan. IN A 192.168.15.100
dhcp02.hughes.lan. IN A 192.168.15.101
dhcp03.hughes.lan. IN A 192.168.15.102
dhcp04.hughes.lan. IN A 192.168.15.103
dhcp05.hughes.lan. IN A 192.168.15.104

@ IN MX 10 mail.hughes.lan.

The very first line in the hughes.lan.zone contains the TTL (Time To Live) value and is set to one day. TTL is used by nameservers to know how long to cache nameserver responses. This value would have more meaning if our nameserver was public and had other external nameservers depending on our domain information. Notice the 'D' in the TTL value stands for Day. Bind also uses 'W' for weeks, 'H' for hours, and 'M' for minutes.

The first resource record is the SOA (Start Of Authority) Record which indicates that this nameserver is the best authoritative resource for the hughes.lan domain. The IN stands for Internet Class and is optional. The first hostname after the SOA is the name of our master or primary nameserver. The second name, "foo.bar.tld.", is the email address for the person in charge of this zone. Notice the '@' is replaced with a '.' and also ends with a '.'. The third value is the serial number that indicates the current revision, typically in the YYYYMMDD format with a single digit at the end indicating the revision number for that day. The fourth, fifth, sixth, and seventh values can be ignored for the purposes of this article.

The NS record lists each authoritative nameserver for the current zone. Notice the first '@' character in this line. The '@' character is a short-hand way to reference the domain, hughes.lan, that was referenced in the named.conf configuration file for this zone.

The next block of A records contains our hostname to address mappings. The CNAME records act as aliases to previously defined A records. Notice how fully qualified domains end with a '.'. If the '.' is omitted then the domain, hughes.lan, is appended to the hostname. In our example the hostname, scrappy, will become scrappy.hughes.lan

If you want to reference an internal mail server, then add a MX record that specifies a mail exchanger. The MX value "10" in our example indicates the preference value (number between 0 and 65535) for this mail exchanger's priority. Clients try the highest priorty exchanger first.

The reverse zone file, 192.168.15.zone, is similar to our forward zone but contains PTR records instead of A records:


$TTL 1D

@ IN SOA velma.hughes.lan. foo.bar.tld. (
200612060 ; serial
2H ; refresh slaves
5M ; retry
1W ; expire
1M ; Negative TTL
)

IN NS velma.hughes.lan.
10 IN PTR velma.hughes.lan.
1 IN PTR fred.hughes.lan.
2 IN PTR scooby.hughes.lan.
3 IN PTR shaggy.hughes.lan.
4 IN PTR scooby-dum.hughes.lan.
5 IN PTR daphne.hughes.lan.
6 IN PTR mysterymachine.hughes.lan.
7 IN PTR scrappy.hughes.lan.

100 IN PTR dhcp01.hughes.lan.
101 IN PTR dhcp02.hughes.lan.
102 IN PTR dhcp03.hughes.lan.
103 IN PTR dhcp04.hughes.lan.
104 IN PTR dhcp05.hughes.lan.



Testing

Save your zone files, make sure you have the correct permissions and check the syntax using named-checkzone:

named-checkzone hughes.lan hughes.lan.zone
named-checkzone 15.168.192.in-addr.arpa 192.168.15.zone

Correct any syntax errors reported by named-checkzone.



Restart the nameserver:

service named restart

Browse through the tail of the /var/log/messages file and confirm the domain loaded successfully.



Make the following DNS queries (substituting your domain):

dig scooby.hughes.lan
dig -x 192.168.15.2


Your output should be similar to the following:

.
.
.

;; QUESTION SECTION:
;scooby.hughes.lan. IN A

;; ANSWER SECTION:
scooby.hughes.lan. 86400 IN A 192.168.15.2

;; AUTHORITY SECTION:
hughes.lan. 86400 IN NS velma.hughes.lan.

;; ADDITIONAL SECTION:
velma.hughes.lan. 86400 IN A 192.168.15.10
.
.
.

Continue to test each host you added to the zone file and then enjoy your new master nameserver.



Conclusion

The goal of this series of DNS articles was to pick the high-level features DNS can offer to improve the efficiency and management of the home network. In addition to the performance improvement we saw with the caching nameserver, the master nameserver helps manage both static and dynamic clients using human-friendly hostnames instead of IP addresses. For readers interested in learning more about DNS or expanding the nameservers discussed in this series, checkout the following resources:

* BIND user documenation located in /usr/share/doc/bind-9.x.x
* DNS and BIND (5th Edition)


About the author

Shannon Hughes is a Red Hat Network (RHN) engineer who enjoys using open source software to solve the most demanding software projects. When he is not cranking out code, tweaking servers, or coming up with new RHN projects, you can find him trying to squeeze in yet another plant in the yard/garden with his wife, watching Scooby Doo reruns with his two kids and dog, or incorporating the latest open source projects for his church.

Copyright © 2006 Red Hat, Inc. All rights reserved.
Privacy Policy : Terms of Use : Patent promise : Company : Contact
Log in to Your Account


Taken From: http://www.redhat.com/magazine/025nov06/features/dns/
http://www.redhat.com/magazine/026dec06/features/dns/



A much more complete howto can be found at: http://www.aboutdebian.com/dns.htm

Seeing and changing your DNS servers

To see which dns server that as been assingned to your by dhcp or inputed manualy, just do:

cat /etc/resolv.conf

To alter (and also see) your dns servers you can always edit /etc/resolv.conf using a text editor like vi or gedit or any other for vi do the following:

# vi /etc/resolv.conf

for gedit the following:

# gedit /etc/resolv.conf