Home > Articles > Web Services > Cloud Computing

  • Print
  • + Share This
From the author of DNS Server Setup

DNS Server Setup

BIND is an open source DNS server software package. It's the most popular DNS server on the Internet and can be installed easily on Linux systems via the package management system. After that, some configuration is necessary to enable the server to listen for incoming requests and to act as an authoritative server for your domain. Several executable files are packaged with BIND; the main file that concerns us is the named DNS service. We'll also briefly describe the dig command for doing DNS lookup and the rndc management utility.


To follow the instructions in this section, you'll need the following things:

  • SCE user account. Sign up if you don't have an account, or you can probably perform similar steps on another cloud.
  • SSH key pair. The public key should be stored on the SCE server and the private key saved on your local workstation. If you created the SSH key through the SSH portal and saved the downloaded file, you have these.
  • SCE command-line toolkit. If you prefer to use the cloud web portal, you won't need this. The command-line instructions in this article are for Windows, but similar commands are available for Linux.
  • VLANs at each data center. All SCE accounts come with a VLAN at each data center, but you don't generally need a VLAN to run a DNS server. If you don't want to use a VLAN, you'll have to adapt some of the following steps to suit your own network configuration.

Step 1: Provision the Server and Install BIND

In this step, we provision a virtual machine for the DNS server. We also install and start the BIND named service.

Provision an instance of the IBM Firewall image with two IP addresses. The VPN server or firewall for the VPN is a good choice. It should be a hardened image like the IBM firewall in the image catalog. You can use either the SCE web user interface or API to create the virtual machine instance.

Reserve an IP address on the VLAN with the command in Listing 3. Execute the command on your local workstation.

Listing 3—Allocating an IP address with the SCE command-line tool.

> ic-allocate-address.cmd -u <user_id> -g <password_file>
 -w <passphrase> -x <vlan_id> -L 141 -O 20027868
Executing action: AllocateAddress  ...
The request has been submitted successfully.
ID: 344533
State: NEW
Executing AllocateAddress  finished

In the command in Listing 3, substitute your own username for <user_id>, password file for <password_file>, and password phrase for <passphrase>.

The -x parameter lists the VLAN ID (<vlan_id>); this is specific to your customer account. Use ic-describe-vlans to find it.

The -L parameter is the data center ID; 141 is the ID for the Singapore data center. If you don't want to use Singapore, use the ic-describe-locations command to find the ID for another data center.

The -O parameter is the offering ID; 20027868 is the ID for an IP address on a private VLAN in Singapore. Use the ic-describe-address-offerings command to find an alternative offering ID if you don't want to use the Singapore data center.

This command will give an address ID in the response output, as shown in Listing 3. The IP address will take a short period of time to be allocated. Use the ic-describe-addresses command to check the status of the request, and wait for the state to be FREE, indicating that the address is available to be associated with a virtual machine instance.

The command in Listing 4 shows how to create the virtual machine with the SCE command line.

Listing 4—Creating a DNS server with the SCE command-line tool.

> ic-create-instance.cmd -u <user_id> -g <password_file> -w
 <passphrase> -k 20036705 -n DNS_Server -t "COP32.1/2048/60"
 -L 141 -m "{secondary.ip.0:<address_id>}"
. . .
ID: 325599
. . .
Status: NEW

The -k parameter is the specific image ID for the IBM Firewall image in the Singapore data center. Search the image catalog or use the ic-describe-images command to find an alternative image.

The -n parameter is the name that you give the server. You can use any name you want here, but enclose it in double quotes (" ") if the name includes spaces or special characters.

The -t parameter is the server size—in this case, a single-CPU, 32-bit machine with 2048MB of memory and 60GB of disk space. If you want a different size, use the ic-describe-image command to find the supported server sizes.

The -L parameter is the data center, as described for Listing 3. The -m is the ID for the secondary address (<address_id>), which was obtained in the output of the ic-allocate-address command in Listing 3. The Internet-facing primary address will be assigned automatically.

The instance will take a short time to be provisioned. The instance ID is shown in the output of the ic-create-instance command, in this case 325599. Note this ID and use it in the ic-describe-instance command to check the status of the request, waiting for it to become ACTIVE:

> ic-describe-instance.cmd -u <user_id> -g <password_file> -w <passphrase> -l 325599
. . .
. . .
Status: ACTIVE
. . .

At this point you can use your default SSH key to connect to the instance via the primary IP address, which is also the Internet-facing address. That IP address is also shown in the output from the ic-describe-instance command we just discussed.

The secondary IP address faces the VLAN. Initially, the network interface associated with the secondary IP is not active. The network interface for the secondary IP is typically eth1; you can check the status with the ifconfig -a command. SSH to the server and execute the ifup command shown in Listing 5 to activate the secondary network address.

Listing 5—Activating the network interface for the secondary IP address

$ sudo /sbin/ifconfig -a
eth1      Link encap:Ethernet  HWaddr DE:AD:BE:6A:71:45
          BROADCAST MULTICAST  MTU:1500  Metric:1
. . .
$ sudo /sbin/ifup eth1
$ sudo /sbin/ifconfig -a
eth1      Link encap:Ethernet  HWaddr DE:AD:BE:6A:71:45
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::dcad:beff:fe6a:7145/64 Scope:Link
. . .

Notice that the status of the network interface changes to UP in the output of the ifconfig command and the Internet address is displayed.

Follow the instructions in the Firewall image guide, located in the SCE image catalog, to enable routing from the Internet to virtual machines in the VLAN. If you didn't use the Firewall image, configure iptables to route between the Internet and the VLAN.

SSH to the server and install BIND from the yum repository with the following commands:

$ sudo yum install bind

Set the service to be on by default, and start it with these commands:

$ sudo chkconfig named on
$ sudo service named start

After the BIND server has started, verify installation against your local interface to make sure that the firewall is open on each end.

You can check that BIND is running properly by using the dig command:

$ dig @ http://www.yahoo.com
. . .
http://www.yahoo.com.          300     IN      CNAME   fd-fp3.wg1.b.yahoo.com.
fd-fp3.wg1.b.yahoo.com. 300     IN      CNAME   ds-fp3.wg1.b.yahoo.com.
ds-fp3.wg1.b.yahoo.com. 60      IN      CNAME   ds-sg-fp3-lfb.wg1.b.yahoo.com.
ds-sg-fp3-lfb.wg1.b.yahoo.com. 300 IN   CNAME   ds-sg-fp3.wg1.b.yahoo.com.
ds-sg-fp3.wg1.b.yahoo.com. 60   IN      A
. . .

The dig command is packaged with BIND and also installed by default on the Firewall image in the SCE image catalog. It's a Linux DNS client utility similar to nslookup, but it provides more useful information in the command output. The @ parameter specifies the DNS server to use. If it's not provided, the DNS server in resolv.conf will be used.

The output of the command shows a CNAME record that defines the domain name http://www.yahoo.com as an alias, and several other aliases are defined, which finally point at the address (A) record linking to the IP address We'll look at how to define the CNAME and A records for our own domain shortly.

On RHEL systems, BIND is configured by default to respond only to requests from the local system. We need to perform additional configuration to enable it to respond to external requests.

Step 2: Configure the DNS Server to Accept External Requests

In this step we configure BIND to accept requests from any incoming client. Open the main configuration file /etc/named.conf and edit the lines related to the listener and query restrictions, as shown in Listing 6.

Listing 6—Configuring BIND to accept outside requests for DNS queries.

# vi /etc/named.conf
listen-on port 53 { any; };
. . .
allow-query     { any; };

After saving the changes to named.conf, restart the named server:

# service named restart

At this point the BIND server is listening for outside requests, but the firewall is blocking those requests from being delivered.

Step 3: Configure the Firewall

In this step we configure the firewall and check the DNS service. Open port 53 in the firewall for both UDP and TCP with the commands in Listing 7.

Listing 7—Configuring iptablesto accept outside requests connections on port 53.

# vi /etc/sysconfig/iptables
# Add lines allowing any port if accessed from the local machine.
. . .
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
. . .
# /sbin/service iptables restart

After restarting the firewall, verify installation against all network interfaces to make sure that the firewall is open on each one:

$ dig @<private_ip> http://www.yahoo.com
$ dig @<public_ip> http://www.yahoo.com

The <private_ip> and <public_ip> parameters are the IP addresses of the two network interfaces with which you provisioned the server in the earlier section "Step 1: Provision the Server and Install BIND." If you only want to accept requests from within your VLAN, you should add a further restriction to the firewall rules above, based on source address range.

Step 4: Set Up the Zone for the New Domain in the DNS System

In this step, we configure BIND to be the primary domain server for our new domain. A zone entry is used to specify a DNS domain. We'll make our server the primary name server for the domain sceexample.com. You should substitute your own domain for all occurrences of sceexample.com in the listings here. We'll add a zone statement for this purpose and include a zone file that will contain the individual resource records for the domain. Edit the main configuration file /etc/named.conf to add the section in Listing 8.

Listing 8—Zone entry in named configuration file.

zone "sceexample.com" {
        type master;
        file "sceexample.com";

Now we've defined the zone, but we don't have any DNS records for that zone.

Step 5: Add DNS Records

In this step we add DNS records for the zone. Create the zone file /var/named/sceexample.com for the domain, and add text as shown in Listing 9. It includes Time to Live ($TTL), root name ($ORIGIN), start of Authority (SOA) entries, and some Address (A) resource records. Use your own hostname <client> and IP address <linux_client_ip>. We also name this as a web server with a www prefix to the hostname, as an example of an alias.

Listing 9—DNS zone file.

$TTL 1h
$ORIGIN sceexample.com.
@ 1D   IN     SOA   ns hostmaster (
                        2006100201 ; se = serial number
                        1h         ; ref = refresh
                        15m        ; ret = update retry
                        3w         ; ex = expiry
                        3h         ; min = minimum
           IN    NS      ns.sceexample.com.
ns         IN    A       <nameserver_ip> <client>   IN    A       <linux_client_ip>
www        IN    CNAME   <client>

Substitute your own hostname for <client> and IP addresses for <nameserver_ip> and <linux_client_ip>. This should be another virtual machine instance on your VLAN. If you don't have one, leave out the two lines with <client>. The value for <client> is the primary hostname, such as vhost0915.sceexample.com. This is specified in an Address (A) record. The alias www is just an example, appropriate for a web server. It's what's known as a CNAME or alias record that defines an additional name by which you can refer to the machine . After saving the file, restart the server:

# /sbin/service named restart

Now that we've created the zone and entries for it, we can test it.

Step 6: Test Looking Up a Domain Name

In this step we use dig to test the definition of the domain in the BIND configuration files. Use the dig command on the machine with the BIND server:

# dig @ http://www.sceexample.com
. . .
http://www.sceexample.com. 3600 IN      CNAME   vm-10-128-105-48.sceexample.com.
vm-10-128-105-48.sceexample.com. 3600 IN A
. . .

The result of the command shows the alias (CNAME record) for the xx server referring to the primary hostname and the Address (A) record pointing to the IP address (<linux_client_ip> in Listing 9).

If you don't want to register your domain with a public domain registration provider or don't need a secondary server, then you can skip Steps 7–8 in the next two sections and jump directly to the later section "Managing the BIND Server." However, public domain registration providers require a minimum of two DNS servers when registering a self-managed domain. See how to define a secondary server in the next section.

Step 7: Set Up a Secondary Server

In this step we set up a secondary DNS server on another virtual machine instance, similar to the primary. Change the secondary BIND server file to be the same as the primary except for the lines in Listing 10.

Listing 10—Testing the domain definition with dig.

# vi /etc/named.conf
. . .
zone "sceexample.com" {
        type slave;
        file "sceexample.com";
        masters { <primary_ip>; };

This code defines the BIND server to be a slave for the domain. All the resource records will be copied from the primary server. Restart the server with the following command:

$ sudo /sbin/service named start

At this point we have a working DNS system, but it's not known to anyone other than us. We can perform a special client setup to refer to it, or we can make it publicly discoverable on the World Wide Web with the step in the next section.

Step 8: Register the Domain

This section explains how to register the DNS system that we have set up to be authoritative for our domain. You can do it by registering the domain with a public DNS registration service, such as GoDaddy.com. You'll need to set the nameservers for the domain to be the DNS servers that you set up earlier. You must configure at least two DNS servers if you're setting these as the DNS servers using a public service.

If you're using GoDaddy.com, first add the two DNS servers as hosts using their hostnames, such as vhostxxx. The domain will be appended. (It will take some time to process.) Then set the DNS servers for the domain.

  • + Share This
  • 🔖 Save To Your Account