Introduction

This guide is intended to show a sipX sipXecs administrator how to utilize BIND DNS views to set network subnet specific DNS responses. This document assumes the following prerequisites:

You are familiar with DNS, in particular BIND (the default linux DNS daemon)
You are familiar with the way sipX sipXecs utilizes DNS
You have a multi-site organization and would like a survivable sipX sipXecs system in the event of a WAN failure
You let sipX sipXecs set up DNS for you and would like more control over your existing sipX sipXecs managed BIND DNS setup

Why BIND DNS Views?

Although every network is different, it is generally always a good idea to keep as little traffic as possible from traversing the WAN whenever possible to avoid saturating finite WAN bandwidth. This is why, for example, branch office locations usually have local supplemental servers to keep services like shared file and printer traffic tied to the location and to provide services when WAN connectivity is down. Telephony services are no different in this regard and are usually considered a higher priority in survivability situations than services such as shared files and printing.

Fortunately sipXsipXecs, if allowed to configure initial DNS settings, partially provides for a survivable solution. If a remote location's WAN connection is down and the phones at that location are registering evenly across three servers, approximately 2/3 of the users at the remote location will be unable to make or receive phone calls until their phones register with the local sipX sipXecs HA proxy. Phones caught in this scenario will eventually re-register to the local proxy when their current registration expires which could take up to an hour.

This is where BIND DNS views proves extremely valuable. With views, each subnet can be provided with a different version of the same DNS zone. This allows you to set different SRV priorities and weights for different locations so that first priority always goes to the local server.

Pros and Cons

There are a few pros and cons to this type of setup:

Pros

Allows for a robust failure-resistant installation of sipXsipXecs.
- If a WAN link fails, phones are by default registered to the local sipX sipXecs HA proxy so downtime is minimal
Keeps signaling traffic to a minimum over WAN links.
Provides greater network design flexibility.

Cons

Requires manual editing of BIND config files and zone files.
An addition/deletion/change in one view's zone file will require changes to all other view's zone files, possibly making management difficult.

Example Network Scenario

In order to demonstrate the application of BIND DNS views we will be basing our configuration scenario on the following visual network diagram:

For this scenario we will assume:

You have sipX sipXecs set up properly.
You have set up location based dialing rules properly
Your domain is example.com
You have three locations (one main office and two branch offices), each office with a redundant sipX sipXecs proxy, all connected through VPN over the internet
You let sipX sipXecs perform all of the initial DNS configuration.

Configuring BIND to Use Views

Configuring BIND to Allow Manual Updates

Whenever a primary sipX sipXecs system is installed and set up to provide DNS services, a DNS server is provisioned with the default DNS records and settings. If you make any custom changes to the configuration or zone files, sipX sipXecs will overwrite these changes whenever you make any significant changes to the system.

Change DNS Update Mode

Note
Make the following change on ALL sipX sipXecs servers, primary and secondary.

To prevent sipX sipXecs from changing the BIND configuration automatically you will need to change the mode in /etc/named.conf

Code Block

	HTML
	HTML
title	/etc/named.conf

// WARNING: Name server configuration is a sipXsipXecs automatically generated file.
//          Contents may be overwritten unless you change the mode to "Manual".
//          Available modes:
//          "Master"    - Master name server (on primary server).
//          "Slave"     - Slave named server (on distributed server).
//          "Caching"   - Caching only name server.
//          "Manual"    - Blocks future automatic updates.
// DNS_MODE="Manual"

Note
/etc/named.conf is actually a symlink to /var/named/chroot/etc/named.conf for security reasons

Default Configuration Generated By

sipX

sipXecs

Based on our example network scenario with the default sipX sipXecs DNS setup (before setting up views), you should have BIND configuration and zone files similar to the following:

Code Block

	HTML
	HTML
title	/etc/named.conf

// WARNING: Name server configuration is a sipXsipXecs automatically generated file.
//          Contents may be overwritten unless you change the mode to "Manual".
//          Available modes:
//          "Master"    - Master name server (on primary server).
//          "Slave"     - Slave named server (on distributed server).
//          "Caching"   - Caching only name server.
//          "Manual"    - Blocks future automatic updates.
// DNS_MODE="Manual"

options {
        directory  "/var/named";
        dump-file "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        forwarders {
                208.67.222.222;
//              uses OpenDNS for external DNS lookups
        };
};

zone "example.com" IN {
    type master;
    file "example.com.zone";
    allow-update {
        none;
	};
    allow-query {
	10.0.1.0/24;
        10.0.2.0/24;
        10.0.3.0/24;
	};
    allow-transfer {
	10.0.2.10;
        10.0.3.10;
	};
    notify yes;
};

Note
The following file has the comments created by sipX sipXecs stripped out for readability.

Note
/var/named/example.com.zone is actually a symlink to /var/named/chroot/var/named/example.com.zone for security reasons.

Code Block

	HTML
	HTML
title	/var/named/example.com.zone

$TTL 1800
@	IN	SOA	ns1.example.com. root.example.com. (
			200911091434
			1800
			1800
			1800
			1800 )

example.com.            IN     NS     sip1.example.com.
example.com.            IN     NS     sip2.example.com.
example.com.            IN     NS     sip3.example.com.

example.com.		IN	NAPTR	2 0 "s" "SIP+D2T" "" _sip._tcp.example.com.
example.com.		IN	NAPTR	2 0 "s" "SIP+D2U" "" _sip._udp.example.com.

_sip._tcp.example.com.	IN	SRV	1 0 5060 sip1.example.com.
_sip._udp.example.com.	IN	SRV	1 0 5060 sip1.example.com.

_sip._tcp.example.com.	IN	SRV	1 0 5060 sip2.example.com.
_sip._udp.example.com.	IN	SRV	1 0 5060 sip2.example.com.

_sip._tcp.example.com.	IN	SRV	1 0 5060 sip3.example.com.
_sip._udp.example.com.	IN	SRV	1 0 5060 sip3.example.com.

_sip._tcp.rr.sip1.example.com.	IN	SRV	1   0 5070 sip1.example.com.
_sip._tcp.rr.sip1.example.com.	IN	SRV	2 100 5070 sip2.example.com.
_sip._tcp.rr.sip1.example.com.	IN	SRV	3 100 5070 sip3.example.com.

_sip._tcp.rr.sip2.example.com.	IN	SRV	1   0 5070 sip2.example.com.
_sip._tcp.rr.sip2.example.com.	IN	SRV	2 100 5070 sip1.example.com.
_sip._tcp.rr.sip2.example.com.	IN	SRV	3 100 5070 sip3.example.com.

_sip._tcp.rr.sip3.example.com.	IN	SRV	1   0 5070 sip3.example.com.
_sip._tcp.rr.sip3.example.com.	IN	SRV	2 100 5070 sip1.example.com.
_sip._tcp.rr.sip3.example.com.	IN	SRV	3 100 5070 sip2.example.com.

sip1.example.com.	IN	A	10.0.1.10
sip2.example.com.	IN	A	10.0.2.10
sip3.example.com.	IN	A	10.0.3.10

Preparing Zone Files For Use With Views

One of the downsides to using views is that each view must contain a zone file for each domain you wish to present to the defined subnets even if the same domain with slight variations will be in multiple views. To accomplish this setup we must first duplicate each zone file and rename the duplicated zone files. Zone files are found in /var/named/chroot/var/named/ and according to our BIND configuration, the zone file for example.com is example.com.zone . Let's go ahead and duplicate the zone file for our views. From the console of the primary sipX sipXecs server run the following commands:

Code Block

# cd /var/named/chroot/var/named
# cp example.com.zone JohnSt.example.com.zone
# cp example.com.zone SanfordRd.example.com.zone
# cp example.com.zone LillyLn.example.com.zone
# chown named:named *.zone

For ease of administration, it is also advisable to create symlinks to these files in the /var/named directory:

Code Block

# cd /var/named
# ln -s /var/named/chroot/var/named/JohnSt.example.com.zone JohnSt.example.com.zone
# ln -s /var/named/chroot/var/named/SanfordRd.example.com.zone SanfordRd.example.com.zone
# ln -s /var/named/chroot/var/named/LillyLn.example.com.zone LillyLn.example.com.zone

Adding Views to named.conf

Now that we have created our view-specific zone files we can add them into our /etc/named.conf configuration file and begin using them.

Here is the our /etc/named.conf file with views added for all three subnets of our example network scenario:

Code Block

	HTML
	HTML
title	/etc/named.conf

// WARNING: Name server configuration is a sipXsipXecs automatically generated file.
//          Contents may be overwritten unless you change the mode to "Manual".
//          Available modes:
//          "Master"    - Master name server (on primary server).
//          "Slave"     - Slave named server (on distributed server).
//          "Caching"   - Caching only name server.
//          "Manual"    - Blocks future automatic updates.
// DNS_MODE="Manual"

options {
        directory  "/var/named";
        dump-file "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        forwarders {
                208.67.222.222;
//              uses OpenDNS for external DNS lookups
        };
};

view LillyLn {
        match-clients {
                10.0.1.0/24;
                };
        zone "example.com" IN {
                type master;
                file "LillyLn.example.com.zone";
                allow-update {
                        none;
                        };
                allow-query {
                      	10.0.1.0/24;
                        10.0.2.0/24;
                        10.0.3.0/24;
	                      }
                allow-transfer {
                        10.0.2.10;
                        10.0.3.10
                        };
                notify yes;
                };
        };

view SanfordRd {
        match-clients {
                10.0.2.0/24;
                };
        zone "example.com" IN {
                type master;
                file "SanfordRd.example.com.zone";
                allow-update {
                        none;
                        };
                allow-query {
                      	10.0.1.0/24;
                        10.0.2.0/24;
                        10.0.3.0/24;
	                      }
                allow-transfer {
                        10.0.2.10;
                        10.0.3.10
                        };
                notify yes;
                };
        };

view JohnSt {
        match-clients {
                10.0.3.0/24;
                };
        zone "example.com" IN {
                type master;
                file "JohnSt.example.com.zone";
                allow-update {
                        none;
                        };
                allow-query {
                      	10.0.1.0/24;
                        10.0.2.0/24;
                        10.0.3.0/24;
	                      }
                allow-transfer {
                        10.0.2.10;
                        10.0.3.10
                        };
                notify yes;
                };
        };

Modifying View-Specific Zone Files to Match Our Needs

In our example network scenario each location has it's own dedicated sipX sipXecs redundant proxy, so the most logical setup is to set SRV priorities for each location to set the local sipX sipXecs redundant proxy with the highest priority and if that server isn't responding, split the load between the remaining two servers:

John Street

sip3.example.com priority 1 weight 0
sip2.example.com priority 2 weight 1
sip1.example.com priority 2 weight 1

For these priorities, set the following SRV records in /var/named/JohnSt.example.com.zone

Code Block

_sip._tcp.example.com.	IN	SRV	2 1 5060 sip1.example.com.
_sip._udp.example.com.	IN	SRV	2 1 5060 sip1.example.com.

_sip._tcp.example.com.	IN	SRV	2 1 5060 sip2.example.com.
_sip._udp.example.com.	IN	SRV	2 1 5060 sip2.example.com.

_sip._tcp.example.com.	IN	SRV	1 0 5060 sip3.example.com.
_sip._udp.example.com.	IN	SRV	1 0 5060 sip3.example.com.

Note
Don't forget to increase the serial number in each zone file every time you make changes, otherwise they won't take effect

Sanford Road

sip2.example.com priority 1 weight 0
sip3.example.com priority 2 weight 1
sip1.example.com priority 2 weight 1

For these priorities, set the following SRV records in /var/named/SanfordRd.example.com.zone

Code Block

_sip._tcp.example.com.	IN	SRV	2 1 5060 sip1.example.com.
_sip._udp.example.com.	IN	SRV	2 1 5060 sip1.example.com.

_sip._tcp.example.com.	IN	SRV	1 0 5060 sip2.example.com.
_sip._udp.example.com.	IN	SRV	1 0 5060 sip2.example.com.

_sip._tcp.example.com.	IN	SRV	2 1 5060 sip3.example.com.
_sip._udp.example.com.	IN	SRV	2 1 5060 sip3.example.com.

Lilly Lane

sip1.example.com priority 1 weight 0
sip2.example.com priority 2 weight 1
sip3.example.com priority 2 weight 1

For these priorities, set the following SRV records in /var/named/LillyLn.example.com.zone

Code Block

_sip._tcp.example.com.	IN	SRV	1 0 5060 sip1.example.com.
_sip._udp.example.com.	IN	SRV	1 0 5060 sip1.example.com.

_sip._tcp.example.com.	IN	SRV	2 1 5060 sip2.example.com.
_sip._udp.example.com.	IN	SRV	2 1 5060 sip2.example.com.

_sip._tcp.example.com.	IN	SRV	2 1 5060 sip3.example.com.
_sip._udp.example.com.	IN	SRV	2 1 5060 sip3.example.com.

Going Live

To activate all the changes we have made, we need to restart the BIND daemon on all three of our servers, starting with the primary server:

Code Block
# service named restart

Testing

To test if each subnet is receiving the proper responses to DNS queries, perform a dig test on each sipX sipXecs server:

Code Block
# dig _sip._udp.example.com SRV

On server sip1.example.com you should receive the following data:

Code Block

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5 <<>> _sip._udp.example.com SRV
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21876
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;_sip._udp.example.com. IN	SRV

;; ANSWER SECTION:
_sip._udp.example.com. 1800 IN SRV	1 0 5060 sip1.example.com
_sip._udp.example.com. 1800 IN SRV	2 1 5060 sip2.example.com.
_sip._udp.example.com. 1800 IN SRV	2 1 5060 sip3.example.com.

;; AUTHORITY SECTION:
example.com.	1800	IN	NS	sip1.example.com.
example.com.	1800	IN	NS	sip2.example.com.
example.com.	1800	IN	NS	sip3.example.com.

;; ADDITIONAL SECTION:
sip1.example.com. 1800	IN	A	10.0.1.10
sip2.example.com. 1800	IN	A	10.0.2.10
sip3.example.com. 1800	IN	A	10.0.3.10

On server sip2.example.com you should receive the following data:

Code Block

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5 <<>> _sip._udp.example.com SRV
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21876
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;_sip._udp.example.com. IN	SRV

;; ANSWER SECTION:
_sip._udp.example.com. 1800 IN SRV	1 0 5060 sip2.example.com.
_sip._udp.example.com. 1800 IN SRV	2 1 5060 sip1.example.com
_sip._udp.example.com. 1800 IN SRV	2 1 5060 sip3.example.com.

;; AUTHORITY SECTION:
example.com.	1800	IN	NS	sip1.example.com.
example.com.	1800	IN	NS	sip2.example.com.
example.com.	1800	IN	NS	sip3.example.com.

;; ADDITIONAL SECTION:
sip1.example.com. 1800	IN	A	10.0.1.10
sip2.example.com. 1800	IN	A	10.0.2.10
sip3.example.com. 1800	IN	A	10.0.3.10

On server sip3.example.com you should receive the following data:

Code Block

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5 <<>> _sip._udp.example.com SRV
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21876
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;_sip._udp.example.com. IN	SRV

;; ANSWER SECTION:
_sip._udp.example.com. 1800 IN SRV	1 0 5060 sip3.example.com.
_sip._udp.example.com. 1800 IN SRV	2 1 5060 sip1.example.com
_sip._udp.example.com. 1800 IN SRV	2 1 5060 sip2.example.com.

;; AUTHORITY SECTION:
example.com.	1800	IN	NS	sip1.example.com.
example.com.	1800	IN	NS	sip2.example.com.
example.com.	1800	IN	NS	sip3.example.com.

;; ADDITIONAL SECTION:
sip1.example.com. 1800	IN	A	10.0.1.10
sip2.example.com. 1800	IN	A	10.0.2.10
sip3.example.com. 1800	IN	A	10.0.3.10

GUI administration

One of the more comprehensive BIND DNS management tools available today is Webmin. Webmin offers a logical layout in the BIND DNS module that make administration much more simple. For details and to download Webmin, visit http://www.webmin.com

Version	Old Version 6	New Version 7
Changes made by	Former user	Former user
Saved on	Jan 10, 2010	Jan 10, 2010

Versions Compared

Key

Table of Contents

Introduction

Why BIND DNS Views?

Pros and Cons

Pros

Cons

Example Network Scenario

Configuring BIND to Use Views

Configuring BIND to Allow Manual Updates

Change DNS Update Mode

Default Configuration Generated By

sipXecs

Preparing Zone Files For Use With Views

Adding Views to named.conf

Modifying View-Specific Zone Files to Match Our Needs

John Street

Sanford Road

Lilly Lane

Going Live

Testing

GUI administration

Page Comparison

Versions Compared

Key

Table of Contents

Introduction

Why BIND DNS Views?

Pros and Cons

Pros

Cons

Example Network Scenario

Configuring BIND to Use Views

Configuring BIND to Allow Manual Updates

Change DNS Update Mode

Default Configuration Generated By

sipXecs

Preparing Zone Files For Use With Views

Adding Views to named.conf

Modifying View-Specific Zone Files to Match Our Needs

John Street

Sanford Road

Lilly Lane

Going Live

Testing

GUI administration