If you are wondering how is it that the Slave DNS server is easy to setup, well you need to remember that all the Slave DNS server does is update its database from the Master DNS server (zone transfer) so almost all the files we configure on the Master DNS server are copied to the Slave DNS server, which acts as a backup in case the Master DNS server fails.

Setting up the Slave DNS Server

Let's have a closer look at the requirements for getting our Slave DNS server up and running.

Keeping in mind that the Slave DNS server is on another machine, we are assuming that you have downloaded and successfully installed the same BIND version on it. We need to copy 3 files from the Master DNS server, make some minor modifications to one file and launch our Slave DNS server.... the rest will happen automatically :)

So which files do we copy ?

The files required are the following:

• named.conf (our configuration file)
• named.ca or db.cache (the root hints file, contains all root servers)
• named.local (local loopback for the specific DNS server so it can direct traffic to itself)

The rest of the files, which are our db.DOMAIN (db.firewall.cx for our example) and db.in-addr.arpa (db.192.168.0 for our example), will be transferred automatically (zone transfer) as soon as the newly brought up Slave DNS server contacts the Master DNS server to check for any zone files.

How do I copy the files ?

There are plenty of ways to copy the files between servers. The method you will use depends on where the servers are located. If, for example, they are right next to you, you can simply use a floppy disk to copy them or use ftp to transfer them.

If you're going to try to transfer them over a network, and especially over the Internet, then you might consider something more secure than ftp. We would recommend you use SCP, which stands for Secure Copy and uses SSH (Secure SHell).

SCP can be used independently of SSH as long as there is an SSH server on the other side. SCP will allow you to transfer files over an encrypted connection and therefore is preferred for sensitive files, plus you get to learn a new command :)

The command used is as follows: scp localfile-to-copy username@remotehost:desitnation-folder. Here is the command line we used from our Gateway server (Master DNS): scp /etc/named.conf root@voyager:/etc/

In the previous articles, we spoke about the Internet Domain Hierarchy and explained how the ROOT servers are the DNS servers, which contain all the information about authoritative DNS servers the domains immediately below e.g firewall.cx, microsoft.com. In fact, when a request is passed to any of the ROOT DNS servers, they will redirect the client to the appropriate authoritative DNS server, that is, the DNS server in charge of the domain.

For example, if you're trying to resolve firewall.cx and your machine contacts a ROOT DNS server, the server will point your computer to the DNS server in charge of the .CX domain, which in turn will point your computer to the DNS server in charge of firewall.cx, currently server with IP 74.200.90.5.

The Big Picture

As you can see, a simple DNS request can become quite a task in order to successfully resolve the domain. This also means that there's a fair bit of traffic generated in order to complete the procedure. Whether you're paying a flat rate to your ISP or your company has a permanent connection to the Internet, the truth is that someone ends up paying for all these DNS requests ! The above example was only for one computer trying to resolve one domain. Try to imagine a company that has 500 computers connected to the Internet or an ISP with 150,000 subscribers - Now you're starting to get the big picture!

All that traffic is going to end up on the Internet if something isn't done about it, not to mention who will be paying for it !

This is where DNS Caching comes in. If we're able to cache all these requests, then we don't need to ask the ROOT DNS or any other external DNS server as long as we are trying to resolve previously visited sites or domains, because our caching system would "remember" all the previous domains we visited (and therefore resolved) and would be able to give us the IP Address we're looking for !

Note: You should keep in mind that when you install BIND, by default it's setup to be a DNS Caching server, so all you need to do it startup the service, which is called 'named'.

Almost all Internet name servers use name caching to optimise search costs. Each of these servers maintains a cache which contains all recently used names as well as a record of where the mapping information for that name was obtained. When a client (e.g your computer) asks the server to resolve a domain, the server will first check to see whether it has authority (meaning if it is in charge) for that domain. If not, the server checks its cache to see if the domain is in there and it will find it if it's been recently resolved.

The db.192.168.0 zone data file is the second file we are creating for our DNS server. As outlined in the DNS-BIND Introduction, this file's purpose is to provide the IP Address -to- name mappings. Note that this file is to be placed on the Master DNS server for our domain.

Constructing db.192.168.0

While we start to construct the file, you will notice many similarities with our previous file. Most resource records have already been covered and explained in our previous articles and therefore we will not repeat on this page.

The first line is our $TTL control statement, followed by the Start Of Authority (SOA) resource record:

Name server resource records are next, follwed by the PTR resource record that creates our IP Address-to-name mappings. The syntax is nearly the same as the db.domain file, but keep in mind that we don't enter the full reversed IP Address for the name servers but only the first 3 octecs which represent the network they belong to:

It's time to start creating our zone files. We'll follow the standard format, which is given in the DNS RFCs, in order to keep everything neat and less confusing.

First step is to decide on the domain we're using and we've decided on the popular firewall.cx. This means that the first zone file will be db.firewall.cx. Note that this file is to be placed on the Master DNS server for our domain.

We will progressively build our database by populating it step by step and explaining each step we take. At the end of the step-by-step example, we'll grab each step's data and put it all together so we can see how the final version of our file will look. We strongly beleive, this is the best method of explaining how to create a zone file without confusing the hell out of everyone!

Constructing db.firewall.cx - db.domain

It is important at this point to make it clear that we are setting up a primary DNS server. For a simple DNS caching or secondary name server, the setup is a lot simpler and covered on the articles to come.

The first entry for our file is the Default TTL - Time To Live. This is defined using the $TTL control statement. $TTL specifies the time to live for all records in the file that follow the statement and don't have an explicit TTL. We are going to set ours to 24 hours - 86400 seconds.

The units used are seconds. An older common TTL value for DNS was 86400 seconds, which is 24 hours. A TTL value of 86400 would mean that, if a DNS record was changed on the authoritative nameserver, DNS servers around the world could still be showing the old value from their cache for up to 24 hours after the change.

Newer DNS methods that are part of a DR (Disaster Recovery) system may have some records deliberately set extremely low on TTL. For example a 300 second TTL would help key records expire in 5 minutes to help ensure these records are flushed world wide quickly. This gives administrators the ability to edit and update records in a timely manner. TTL values are "per record" and setting this value on specific records is normally honored automatically by all standard DNS systems world-wide.   Dynamic DNS (DDNS) usually have the TTL value set to 5 minutes, or 300 seconds.

Next up is the SOA Record. The SOA (Start Of Authority) resource record indicates that this name server is the best source of information for the data within this zone (this record is required in each db.DOMAIN and db.ADDR file), which is the same as saying this name server is Authoritative for this zone. There can be only one SOA record in every data zone file (db.DOMAIN).

Let's explain the above code:

BIND (Berkely Internet Name Domain) is a popular software for translating domain names into IP addresses and usually found on Linux servers. This article will explain the basic concepts of DNS BIND and analyse the associated files required to successfully setup your own DNS BIND server. After reading this article, you will be able to successfully install and setup a Linux BIND DNS server for your network.

Zones and Domains

The programs that store information about the domain name space are called name servers, as you probably already know. Name Servers generally have complete information about some part of the domain name space (a zone), which they load from a file. The name server is then said to have authority for that zone.

The term zone is not one that you come across every day while you're surfing on the Internet. We tend to think that the "domain" concept is all there is when it comes to DNS, which makes life easy for us, but when dealing with DNS servers that hold data for our domains (name servers), then we need to introduce the zone term since it is essential so we can understand the setup of a DNS server.

The difference between a zone and a domain is important, but subtle. The best way to understand the difference is by using a good example, which is coming up next.

The COM domain is divided into many zones, including the hp.com zone, sun.com, it.com. At the top of the domain, there is also a com zone.

The diagram below shows you how a zone fits within a domain:

The trick to understanding how it works is to remember that a zone exists "inside" a domain. Name servers load zone files, not domains. Zone files contain information about the portion of a domain for which they are responsible. This could be the whole domain (sun.com, it.com) or simply a portion of it (hp.com + pr.hp.com).

In our example, the hp.com domain has two subdomains, support.hp.com and pr.hp.com. The first one, support.hp.com is controlled by its own name servers as it has its own zone, called the support.hp.com zone. The second one though, pr.hp.com is controlled by the same name server that takes care of the hp.com zone.

The hp.com zone has very little information about the support.hp.com zone, it simply knows its right below. If anyone requires more information on support.hp.com, it will be requested to contact the authoritative name servsers for that subdomain, which are the name servers for that zone.

So you see that even though support.hp.com is a subdomain just like pr.hp.com, it is not setup and controlled the same way as pr.hp.com.

On the other hand, the Sun.com domain has one zone (sun.com zone) that contains and controlls the whole domain. This zone is loaded by the authoritative name servers.

BIND? Never heard of it !

This article aims to explain the configuration required for a Cisco 880W series router (e.g Cisco 887W, Cisco 886W, Cisco 881W, Cisco 888W, etc), in order to setup the integrated Cisco access point with multiple encrypted SSIDs, each SSID belonging to a different VLAN with specific access to the local network and Internet.

The most common setup of this type is one SSID that connects to the local network and another SSID serving guests that require Internet access only. The commands shown in this article are applicable on all Cisco 880W series models.

Configuring VLANs on the Cisco 880W (881W, 886W, 887W, 888W) Series Router

First step is to examine the VLANs required. In our example we assume two VLANs - one for the local network and one for guest Internet access. By default VLAN 1 is already created as it is the first VLAN on the router, so we will need to create the second VLAN that will serve the guest wireless network, or second SSID:

Once VLAN2 is created (cover later in this article), we can connect to the integrated access point and begin its configuration. If the integrated access point has no IP address assigned to it yet in order to telnet directly to it, you can connect from within the existing session of your Cisco 880 series router using the service-module wlan-ap 0 session command.  

Cisco Access Point Multiple - Dual SSID Configuration 

Configuring multiple SSIDs on a Cisco access point is a straightforward process, however, it does contain a few details we will analyse as we progress.

We need to now create the two SSIDs by defining their names which will be broadcast so users can find them, the encryption method to be used, wireless secret keys and lastly the VLAN assignment for each SSID:

The above configuration is quite different from setups with one SSID. The reason being the multiple SSID and VLAN configuration required to ensure each SSID is assigned to the correct VLAN. The 'Private' wireless network is assigned to VLAN 1 and the 'Guest' wireless network to VLAN 2.

Notice that when using multiple SSIDs on a Cisco access point it is imperative to use the mbssid guest-mode command otherwise the SSID name of the wireless network will not be broadcast correctly.