userguide dnsbox300.pdf

8/18/2019 UserGuide DNSbox300.pdf

1/142

DNSBOX050/300

DNS and DHCPManagement Appliance

USER GUIDE


2/142

Published By:ApplianSys LimitedUniversity of Warwick Science ParkBusiness Innovation CentreBinley Business ParkCoventry, CV3 2TX

Copyright © 2010 ApplianSys Ltd. All Rights Reserved. No part of the contents of this document may be reproduced or

transmitted in any form or by any means electronic or otherwise without the written permission of ApplianSys Limited.

Copyright and licence details for software products included in DNSBOX050/030 are available online at

www.appliansys.com/company/copyright.doc

V6.23 - 14 Dec 2010


3/142

DNSBOX050/300 User Guide

Contents

Using This Guide 2

SECTION 1: PLANNING DEPLOYMENT 5

Introduction to DNS and DHCP 6 DNSBOX300 Overview 17

SECTION 2: USING DNSBOX300 27

Getting Started 28

Online Help and Documentation 37 Deployment Guide 38 Configuration Scenarios and Options 56

SECTION 3: CONFIGURATION REFERENCE 65

DNS Menu 66 SYSTEM Menu 93 CONFIGURE Menu 94

SECTION 4: FREQUENTLY ASKED QUESTIONS 97

Appliance Management 98

Troubleshooting 99 Hardware 100

APPENDICES 101

Appendix A: Resource Records Types 101 Appendix B: Advanced DHCP Configuration 109 Appendix C: Using the Command Line Interface 128


4/142


2 I Using This Guide

Using This Guide

Products CoveredThis guide will help you deploy and configure your DNSBOX050 or DNSBOX300 appliance.

It applies to these current models:

DNSBOX050 DNS/DHCP master – small form factor (SFF) model

DNSBOX310 DNS/DHCP master – light duty

DNSBOX320 DNS/DHCP master – standard duty

DNSBOX330 DNS/DHCP master heavy duty

These models all share the same software and core feature set. Where this guide refers

to DNSBOX300, it applies equally to DNSBOX050 unless explicitly stated otherwise.

How This Guide is OrganisedThis guide has been organised into sections to fit the different ways you will needinformation at different times:

‘PLANNING DEPLOYMENT’ – understand in advance key principles about how towork with DNSBOX300, to make sure your deployment follows a sensibleapproach:

- Understand different deployment scenarios for DNS and DHCP in your

network, and how DNSBOX300 combines with DNSBOX slaves to deliver

these

- Be familiar with the main features of DNSBOX300. As a result, you will have

a good idea of the range of tasks you can carry out with this appliance

‘USING DNSBOX300’ – detailed ‘how-to’ instructions for the main tasks you willtypically have with DNSBOX300:

- Install and start the appliance. Basic configuration to gain access to the

admin interface and then to allow DNSBOX300 to communicate with other

DNS/DHCP servers in your deployment

- Complete configuration of the appliance to operate in one (or more) of

the main deployment scenarios. These tasks you would typically only carry

out in initial deployment or when changing your system architecture.

-

Configure the appliance to carry out key tasks you would usually carry outon an ongoing basis

The remaining sections are for you to refer to whenever you need a specificpiece of information:

- ‘CONFIGURATION REFERENCE’ - describes in detail each of the screens

you can find in your appliance’s web administration interfaces

- ‘FREQUENTLY ASKED QUESTIONS’ – on deployment, support, managing the

appliance, performance, security and hardware

- ‘APPENDICES’ – further information you might need in specific scenarios


5/142


Using This Guide I 3

Who This Guide Is ForDNSBOX300 is typically used by different administrators with different roles:

If you are involved in planning or carrying out deployment, Sections 1 and 2 areparticularly relevant to you

If you are a network administrator tasked with ongoing management of theDNSBOX300 device in your network, you are likely to use most of the guide

regularly, with particular emphasis on ‘Configuration Scenarios and Options’ inSection 2, and on reference material in Sections 3 and 4.

If your main role is limited to working with the application – editing DNS records –you may need to use this guide occasionally. However, you will find your mainreference and help material in the NameSurfer Guide and in online help.

Any user will find reading this guide helpful in increasing their understanding of

DNSBOX300, and how it interacts with other elements of your DNS system.

Conventions Used in This GuideThe following formats have been used to help you use this guide:

[KEYSTROKE]

Something you have to type or select from a drop down or radiobutton setting (fixed width font)

DNSBOX commands (fixed width font)[console display]

‘Menu option'

Fieldname

ON SCREEN BUTTON

URLs: www.example.com

Alert: be aware of a potential issue - something you should avoid or something you are

advised to do. You will find a description of the risk and how to resolve or avoid it in the

Alert format.

Critical Alerts are written in a bold, red font. It is very important that you pay attention to

these.

Note: extra information, not directly part of the instructions or reference material, but

which may still be useful for you to know

Tip: advice to help you make faster or more efficient use of the product with

workarounds and timesaving techniques


6/142


7/142


PLANNING DEPLOYMENT I 5

SECTION 1:PLANNING DEPLOYMENT

IN THIS SECTIONMake sure you can start to use DNSBOX300 with

confidence. Understand in advance keyprinciples about how to work with it. Make sureyour deployment follows a sensible approach

Understand different deploymentscenarios for integrating DNS and DHCP inyour network, and how DNSBOX300combines with DNSBOX slaves to deliver

these

Be familiar with the main features of

DNSBOX300. As a result, you will have agood idea of the range of tasks you cancarry out with this appliance.

Introduction to DNS and DHCP 6

Key DNS Concepts 6

Deployment Options and Scenarios 7

Authoritative DNS: Master-Slave 8 Recursive DNS and Caching 9

DHCP and Dynamic DNS 10 High Availability Slaves 10 DNS Views 11

Failover Master 12

Enterprise Deployment – External DNS 13

Enterprise Deployment – MixedBIND/Windows DNS 14 ISP Deployment 15

DNSBOX300 Overview 17

User Interfaces 18

DNS Management Application 20

Managing DNS Data 20 Managing other DNS / DHCP Servers 22 Controlling multiple users 22

Appliance Management 23

Operating System 24

Hardware 24

Hardware Models 25


8/142


6 I PLANNING DEPLOYMENT - Introduction to DNS and DHCP

Introduction to DNS and DHCP

DNS (Domain Name System) and DHCP (Dynamic Host Configuration Protocol) are basic

building blocks of modern Internet Protocol (IP) networks.

In order for devices (‘hosts’) to be able to connect to each other on networks, each hasa numerical identifier (IP address) such as 192.201.188.12 which is unique on that network -

either a private network or the internet.

For humans to work more easily with these devices, many of them are given hostnames

such as www.example.com or printer.accounts.london.

DNS was introduced in 1983 to facilitate the translation between host names and IP

addresses. In this system, individual domain names and their associated IP addresses are

passed around a hierarchically organised network of name servers. This translation

system is defined as a protocol in the Internet Protocol Suite (TCP/IP).

Today, there are two widely used Domain Name Systems: BIND and Windows DNS. BIND

is the predominant DNS server used on the internet and the de facto standard on Unixsystems. It is the DNS server used in DNSBOX.

Since DNS and BIND were invented in the 1980s, the networks they are used in have

become much larger and more complex. The way BIND is designed, the task of setting

up and maintaining DNS records is very labour-intensive. It is easy to make mistakes or

forget steps, causing the network to stop working. As the task has grown bigger and

more complex, so the need for tools such as DNSBOX300 has become greater. These

DNS management tools manage BIND, allowing you to edit the data with less effort and

more control.

Key DNS ConceptsThe hierarchical structure of DNS is designed to make it distributed and fault tolerant.

Key elements of the design are described below.

A DNS server is authoritative for a domain when it is configured to hold a complete set of

data for the zone.

With BIND, authoritative data is normally held on both master and slave servers.

A Master (also known as ‘primary’) is the server where the original copy of theauthoritative data is held and edited.

A Slave (‘secondary’) holds a copy of the authoritative data. It obtains the zonedata by doing zone transfers from a master. It periodically queries the master tosee if the zone’s serial number has changed. If it has, it copies the updated data.

A server authoritative for a domain may not always hold all the authoritative data for a

sub-domain, but instead may delegate it to another authoritative server.

While a DNS lookup relating to the local domain can be answered directly by an

authoritative local DNS server within the domain (or a delegated authoritative server)

other DNS lookups will relate to names outside the domain.

A DNS server which can carry out a lookup outside the domain is a recursive name

server. To resolve an address, the lookup is cascaded up the DNS hierarchy, typically

querying several distant name servers before arriving at the final result.


9/142


PLANNING DEPLOYMENT - Introduction to DNS and DHCP I 7

For example, finding the IP address of www.example.com may require a series of three DNS

queries:

1 To a root name server, which will point to a server authoritative for .com

2 To the server authoritative for .com, which will point to a server authoritative for.example.com

3 To the server authoritative for .example.com, which will supply the IP address forwww.example.com

This hierarchical lookup process would not be physically possible if all requests started at

a root server – the servers at the bottom of the ‘tree’ would be swamped with trillions of

requests a day. This problem is overcome by caching – storing locally the results on a

recursive resolver of any lookup it has carried out, for a period of time, for instant re-use if

the same lookup is requested again. Typically, recursive names servers are configured to

perform caching.

Deployment Options and ScenariosOverall deployment scenarios for DNS and DHCP can be highly complex in large

networks, because of:

The hierarchical architectures of DNS and networks themselves

Interactions across network boundaries and between technologies, for example:

- Between Windows DNS (and Active Directory) and BIND

- Between DHCP and DNS

- Between private networks and the Internet

However, we can understand the main options by thinking first about the basic

deployment options – building blocks for overall architectures in different scenarios.

These options are:

Authoritative DNS: Master-Slave

Recursive DNS and Caching

DHCP and Dynamic DNS

DNS Views

High Availability Slaves Failover Master

After that, we will look at how these options are typically combined in some example

scenarios:

Enterprise deployment - external DNS

Enterprise deployment – mixed BIND/ Windows DNS

Service provider deployment


10/142



Authoritative DNS: Master-Slave

DNS is a vital network service and so its reliability is critical. This in turn means security and

redundancy of DNS servers are key goals. To achieve these goals, the orthodox Best

Practice for authoritative DNS is a master-slave architecture.

The master is hidden securely behind a firewall. It isused to edit DNS records. It holds the originalauthoritative records, but does not resolve DNSqueries

A minimum of two slaves serve queries, forredundancy. Each slave only carries a copy ofzone data, with the original held securely on themaster. Data on the slave is not propagated toany other device. If a slave somehow became

compromised, any amended DNS data could notinfect the entire installation. Any damaging resultswould be more temporary and more containedthan if compromises were made to the masterauthoritative data

The DNSBOX range has been designed to maximise the benefits of DNS Best Practice

master-slave architectures.

In some situations, where security concerns are lower

(eg for purely internal networks), a two-serverarchitecture will still offer the basic level of

redundancy.

The master is not deployed behind a firewall, and

responds to DNS queries alongside a single slave.

The threat of attack on DNS services exists even on purely internal networks. Research

show a significant threat of malicious attack to organisations comes from inside those

organisations.


11/142



Recursive DNS and Caching

Most recursive resolvers are set up to cache lookups, so typically ‘DNS cache’ and

‘recursive resolver’ refer to the same server. Two different scenarios are typical for DNS

caches:

1 In some situations, there is a strong argument for separating the roles of DNScache and authoritative server, with dedicated servers for each.

The main reason for this is to maximise security. DNS caches have some inherent

security risk attached to them. Since DNS lookups being cached come from

anywhere, outside the control of your network, placing the cache on separate

servers leaves your authoritative records where there is no risk that DNS cache

poisoning will give a route into them.

This approach is usually seen as particularly important in service provider

deployments, where with wide public access (ie to at least the subscriber base)

to the cache, the risk is heightened.

A secondary reason for separating the roles is load. Where servers see high loadsfor both authoritative and cached lookups, it makes sense to spread the load

over more servers. The split between authoritative and caching is a sensible way

to do this because it also increases security.

2 In other situations, the role of DNS cache is combined with authoritative server ona single slave server. This is a sensible option when the perceived risk from DNSCache-poisoning is not as significant. This clearly applies on a corporate privatenetwork, where the DNS cache is internal facing and access to it can be limitedto a known set of relatively trusted – or at least controllable - IP addresses.


12/142



DHCP and Dynamic DNS

When a DHCP server issues a lease, it can add corresponding DNS host records to the

master DNS server, using the Dynamic DNS (DDNS) protocol (standardised and

documented in RFC 2136). This maps a client host name to the leased IP address.

In a DNSBOX deployment, DNSBOX300 and your DHCP servers (either the on-box DHCPD

and/or remote DHCP servers in your network) combine to deliver DDNS. The reasons forusing this feature are:

Traceability: By registering each DHCP client in the DNS database, you can seewhich hostnames and which IP addresses are in use. This information is presentedin the DNS management pages of the NameSurfer web interface.

Reverse DNS records: Many network services, such as email or SSH, require thatclient IP addresses have a corresponding reverse DNS record (a PTR record).These can be created and deleted dynamically by the DHCP server as it issuesand revokes leases.

Human-readable hostnames: It is usually much more convenient to connect to a

network device using its hostname, which is more memorable than its IP address.Your DHCP servers can be configured to dynamically add host (A) records to theDNSBOX300 DNS server as DHCP leases are issued and released.

High Availability Slaves

In some scenarios, the conventional DNS approach to redundancy, designed into BIND,

does not deliver the performance you will need.

Some real time mission-critical applications time out if a DNS query is not resolvedfast enough

The standard#] approach – with alternate DNS servers on different IP addressesand hosts configured to switch between them – can be too slow to beat thetimeout.

So a single IP address must deliver

100% uptime. This demands high

availability and rapid cutover in the

event of a DNS server becoming

unavailable.

A proprietary DNSBOX slave clustering

facility provides this with DNSBOX100

slaves, controlled from DNSBOX300.

This combines both failover and load-

balancing functionality. It will help you

to set up a highly available DNS

service that is both cost effective and

extremely robust. It allows you to run

multiple active DNS slaves with less

need for additional units to provide

failover.


13/142



DNS Views

DNS Views are a way of managing multiple copies of the same zone for presentation to

different client networks.

A common example is when a company needs different internal- and external-facing

records. mail.example.com might resolve to 10.10.10.2 when queried from a client on an

internal/private network, but when queried from the Internet it might be seen as 192.0.2.27.This functionality is sometimes also known as ‘split DNS’.

In some scenarios, DNS Best Practice advocates separating DNS servers serving different

client populations to maximise security. For example, presenting internal and external

DNS views on separate

slaves could give extra

protection to your internal

DNS.

DNSBOX300 supports this

approach. With it, you

can create multiple DNSViews on the master, for

copying to slaves. Each

slave is configured to

serve one and only one

view – you deploy

separate slaves for

internal and external DNS.

In other cases, you may not wish to deploy separate slave servers for each view, but

instead to serve multiple views to different clients from the same server. This could be

simply a pragmatic balancing of the extra costs of having separate servers, or based ona judgement in a particular scenario that there is not extra risk to be guarded against

from one of the client

networks.

DNSBOX300 supports this

approach as well. With it,

you again create multiple

DNS Views on the master,

for copying to slaves.

Each slave is configured

to serve multiple views.

Where you have 2 views,internal and external for

example, both are served

from each slave. Each

view is only seen by the

client network for which it

is defined.


14/142



Failover Master

DNSBOX300 can be deployed with a failover unit. This is deployed in a standby mode

and configured to synchronize data on a periodic basis from the active master. In the

event of the active machine failing, the failover is

restarted in active mode and starts to respond tozone transfer requests and name queries.

When the original active machine becomes

available again, it is placed in standby mode until

the data has been fully synchronized back. Both

machines are then restarted and their modes

reversed. To ensure reliable zone transfers, it is usual

to set up slaves to know of both the active and the

failover master. This way they automatically query

the failover machine when necessary without

needing reconfiguration.

The standby master is not automatically restarted in active mode, as by definition the

standby master cannot be sure that the active master has failed - it could be a case of

network partitioning rather than the active master's failure.


15/142



Enterprise Deployment – External DNS

DNSBOX300 and DNSBOX100 can be used to manage and serve your external DNS

domains. This is the simplest DNSBOX deployment.

You will contact your domain registrar and ask them to list the domain names ofyour DNSBOX100s in the NS records for your external domain and optionally atertiary DNS server (hosted by your ISP).

Normally there will not be a high load on your authoritative DNS servers.Authoritative queries will be balanced between the two DNSBOXs based on theround trip time between the recursive resolver and your authoritative DNSBOX100.Furthermore, most resolvers will cache the resulting response.

The example below is quite advanced, with several layers of redundancy built in:

- Master-slave architecture with at least two slaves

- Failover master

- Multiple data centres

- Tertiary DNS with ISP

Two DNSBOX300s are deployed in separate data centres.

- They are only connected to a private network. For maximum security of

your original authoritative data, DNSBOX masters should not be exposed

to the Internet

- Deployed as a failover pair, critical DNS data is synchronized between the

two masters. This introduces redundancy and ensures minimal interruptionto your network in the unlikely event that one server fails

Two DNSBOX100s are also deployed one in each of the two data centres.

- These provide internet-facing authoritative DNS

- Using two DNSBOX100s provides redundancy as well as round-robin load

balancing

Additional redundancy could be achieved by allowing zone transfers to anauthoritative DNS server located at your ISP.


16/142



Enterprise Deployment – Mixed BIND/Windows DNS

In a complex deployment dealing with all aspects of a large organisation’s network,

DNSBOX300 can be utilised to manage public external domains and private internal

domains. The example architecture described below builds upon the external DNS

deployment above to deliver a resilient solution.

In addition to the Internet facing DNSBOX100s, multiple DNSBOX100s are deployed

internally to handle recursive DNS requests

Additionally, the DNSBOX300 may be configured to serve internal DHCP via theDNSBOX100, which acts as a DHCP relay

Internal DNSBOX100s provide local authoritative and recursive DNS

DNSBOX100s relay tagged DHCP requests to the DNSBOX300

Head office houses a large number of staff and therefore deploys a clusteredpair of DNSBOX100s with a virtual cluster IP address for recursive resolution. Thecluster provides load balancing of expensive recursive queries

Single DNSBOX100s are also located in each of your branch offices. Managers atbranch offices are able to log in to the DNSBOX300 web interface and from theremanage their own internal DNS zone

In the event of a network failure between branch office and the primary datacentre, the DNSBOX100s continue to provide recursive and internal DNS services –automatically transferring zones from the DNSBOX300 in the secondary datacentre


17/142



ISP Deployment

Deployment in a service provider environment, managing DNS for external clients,

typically varies a little from a corporate deployment. It can though be equally complex,

with DNSBOX300 managing a highly redundant external DNS service – while possibly used

at the same time via DNS Views to manage internal DNS and internal DHCP. A typical

ISP deployment is described here.

DNS and DHCP Management Two DNSBOX300s are deployed in failover mode at two geographically separate

data centres. They are connected to a private ‘admin’ network – accessibleonly by Network Operations Centre staff

You use the DNSBOX300 to manage your organisation’s DNS zones (eg

example.com) and the reverse DNS records associated with your public IP networks

Authoritative DNS

Two internet-facingDNSBOX100s provide your authoritative DNS service

Additional redundancy could be achieved by allowing zone transfers to an

authoritative DNS server located at another ISP


18/142



Internal DNS and DHCP

Two pairs of DNSBOX100s, located in each data centre, provide local

authoritative and recursive DNS

Subscribers use the clustering feature for recursive DNS resolution. Expensiverecursive queries are distributed among all the members of the cluster In the

unlikely event of a hardware failure, the other boxes in the cluster continue toanswer DNS requests on the virtual cluster IP address


19/142


PLANNING DEPLOYMENT - DNSBOX300 Overview I 17

DNSBOX300 Overview

DNSBOX300 is a master appliance for integrated DNS and DHCP management. It is a

central server for controlling unlimited remote DNS servers and enabling integrated

administration by a team of any size, distributed anywhere.

DNSBOX300 integrates particularly closely with the ApplianSys DNSBOX100 slave. It is also

compatible with any other RFC-compliant DNS server and can be used to manage DNS

in most networks.

Being an appliance, DNSBOX300 is engineered to make using it much easier for network

administrators than the alternative of installing BIND on a general purpose server. It is a

device designed for the specific task of DNS/DHCP management, with fully integrated

components:

SOFTWARE

ProprietaryHiddenPrimary

Appliance

Layers

HARDWARE

Operating System

Server Management

Application Layer: NameSurfer

BIND To Slave

Application Extensions

SOFTWARE

ProprietaryHiddenPrimary

Appliance

Layers

HARDWARE

Operating System

Server Management

Application Layer: NameSurfer

BIND To SlaveTo Slave

Application Extensions

Embedded, pre-installed DNS management application software

- NameSurfer is a powerful application which allows integrated editing of

authoritative DNS records, configuring and controlling of remote DNS

slaves and an on-box central DHCP server- NameSurfer holds its DNS data in a proprietary database. This in turn is

copied to an on-box BIND server, leaving the original data hidden

- Software extensions engineered by ApplianSys allow seamless integration

of a failover DNSBOX300 and multiple DNS Views to be pushed to a single

slave

Server appliance software layers

- Management features to make it easy to deploy and manage the device

- An operating system customised for security, reliability and ease of use

Bespoke hardware, with a design optimised for a DNS master server


20/142


18 I PLANNING DEPLOYMENT - DNSBOX300 Overview

User InterfacesIn the DNSBOX300 appliance, NameSurfer application layer software is embedded within

the appliance layer software, to form a fully integrated seamless application. The main

user interface for this application is a web browser-based GUI.

Administration on DNSBOX300 using the web GUI is naturally divided into two roles,

corresponding to the two software layers:

‘DNS Administration’

- Using the application layer functionality to carry out the core task of the

appliance - administration (editing) of DNS and DHCP data to control

those services within your network

‘Server Administration’

- Using the appliance layer functionality to deploy, manage and maintain

the server within your network

DNSBOX300 is designed for use by multiple users with the ability to control what each cando. In many organisations, this would typically involve some who use it for DNS

Administration and some for Server Administration, as well as some for both roles.

The GUI is therefore divided into two parts for these different roles, carried out in

separate browser windows/tabs. For clarity, we refer to each of these as an ‘Interface’:

The NameSurfer Interface is for ‘DNS Administration’

The Appliance Interface is for ‘Server Administration’


21/142



The NameSurfer Interface can be opened from the Appliance Interface, or opened

directly.

Each of these interfaces has its own user authentication system. Individual users can be

limited to one role or the other by being authenticated for that interface only.

You may normally refer to the people who will use DNSBOX300 as ‘administrators’ or

‘admins’ – maybe ‘network administrators’ or ‘server administrators’ or ‘DNS

administrators’ or similar.

On the DNSBOX300 interface and in this guide, administrators in this general sense are

referred to as “Users”.

Here, “Administrators” indicates Users with full user rights - in either the Appliance

Interface or the NameSurfer Interface. (You might normally refer to these as ‘superadministrators’ or ‘super users’).

In the Appliance Interface, multiple Administrators can log in at the same time using the

‘admin’ username or other accounts with the same full rights when RADIUS is being used

for user authentication.

The NameSurfer Interface is designed for controlled delegation of DNS administration.

Unlimited Users with individual usernames can be created. Different specificrights to edit and view data can be defined for any user

Multiple Administrators in overall charge - with full rights - can be created

Users administering DNS records are advised as normal practice to log in directly to the

NameSurfer Interface eg https://dnsbox.example.com, or the IP address of your DNSBOX300

eg https://192.168.1.1

Other interfaces are used occasionally. Basic initial configuration of the appliance is via

a console interface, while users have access to a command line interface to carry outbulk or non-standard configuration tasks.


22/142



DNS Management ApplicationThe application layer of the DNSBOX300 appliance comprises NameSurfer plus

application extensions - additional DNS management software and enhancements

engineered by ApplianSys.NameSurfer is an industrial-grade application for managing DNS and DHCP. It is

“industrial-grade” in that:

First versions were developed for large ISPs in the 1990s. It was designed from thebeginning to be able to support carrier-class requirements

The functionality offered by the software is suitable for large and complexdeployments

NameSurfer is scalable, able to support large numbers of name entries and zones

In high level terms, NameSurfer allows you to perform four tasks:

Manage authoritative DNS data

Configure and control multiple remote DNS slaves

Configure a central DHCP server

Share the tasks above among multiple administrator users in a controlled way

Key features of NameSurfer for carrying out these tasks are explained below.

Managing DNS Data

NameSurfer makes editing authoritative DNS data on a BIND master much easier than

editing BIND files directly.

Tasks which take many steps in BIND are automated in NameSurfer so saving timeand reducing the chance of errors

It is easy to make errors in BIND - even simple syntax errors. NameSurfer validatesdata entries to dramatically reduce the risk of entering incorrect DNS data

Automation and validation features include:

Automated error and consistency check of data input

If the data threatens the stability or usability of the DNS, an error-message is

generated which you cannot ignore and the data will not be allowed.

For data which can’t be automatically verified, but doesn't threaten the stability

or usability of the DNS, you get a warning message which you can override.

Automated zone serial numbering

Zone serial numbers are in effect a ‘version number’ for the data in the zone.

With BIND you have to remember to update the number each time you changedata in the zone. It is easy to forget to do this, which would mean slaves do not

update. Automation of this in NameSurfer avoids this problem and saves time.


23/142



Automated creation of reverse entries

Creating reverse zones in BIND is highly inefficient and prone to error, with several

time-consuming steps. When you add or delete hosts in your forward zones,

NameSurfer will automatically try to add or delete a PTR record for the

corresponding reverse map name. Prior to automatically creating the reversezone, it checks that the reverse zone is available.

Zone template functionality enabling pre-defined entries when adding hosts

The creation of many zones with similar data (eg when multiple domains share

the same resource records) is made much quicker by templates, where you can

save the common data shared among these zones and avoid re-entering it for

each one.

Batch creation of multiple host entries

Lets you conveniently add a whole series of similar hosts. You enter the name forthe first host. Subsequent host names will get a numerical suffix (or an existing

suffix will be incremented). The hosts will automatically be assigned successive IP

numbers, starting with the specified one.

Bulk changes

The bulk changes operation allows you to make mass changes in the zone, such

as replacing resource record contents or deleting hosts matching a pattern

Other important DNS management features are:

Support for DNS Views

Views is a BIND feature for presenting multiple versions of a zone to different

clients, typically resolving some names to different IP addresses according to the

requesting IP address. NameSurfer allows multiple views to be created quickly

Command line interface

NameSurfer has a command line tool which allows you to script large or complex

tasks. It provides an API to interface with external systems (eg for automated

provisioning of DNS data).


24/142



Managing other DNS / DHCP Servers

Configure and control multiple DNSBOX100s as DNS slaves

Copying zone data from a master to slaves in BIND is hard work, with multiple

steps, configuring one server at a time. This is automated in NameSurfer, saving

much time and reducing the chance of making mistakes. The slaves are

controlled from DNSBOX300 via the single NameSurfer interface.

Configure a central DHCP server

NameSurfer allows you to configure a central ISC DHCPD server on DNSBOX300. It

can also integrate with unlimited distributed DHCP servers in your network, via the

standard mechanism of DDNS, although these servers are not configured from

the DNSBOX300

Microsoft Active Directory (AD) integration

You can integrate DNSBOX300 with an AD server in two ways:

- Delegate the AD DNS domain from the DNSBOX300 to the AD server

- Import all the DNS data to DNSBOX300 and serve it from your DNSBOX100s

Controlling multiple users

A big advantage of NameSurfer over simple editing of BIND files is that it is designed as a

multi-user application. This means the task of administering DNS for a network can be

shared among multiple users, wherever they are, in a controlled way (‘distributed

administration’). The main specific features for this are:

Built-in user authentication

The first stage in controlling multiple users is authentication for user login using a

NameSurfer on-box authentication system.

Transaction log with audit trail (who, what, when); unlimited undo and redo

NameSurfer has a complete audit trail, logging all transactions made using the

system. The log file contains information about what, who and when and can be

used to undo/redo all changes. Unlimited undo/redo means that you can undo

any particular changes in the audit trail without having to roll back all changes in

sequence to that point. NameSurfer checks afresh that the changes you nowwish to make are still valid and that you have permission.

Administrators can see all changes made by all delegated users and can roll

back or forwards any changes as required.

User Groups

Different rights to view and edit data can be defined for each user. The

Administrator(s) in overall charge can create User Groups, with a profile of editing

and viewing rights attached to each. They then assign each individual user to

one or more User Groups.


25/142



Templates

These are helpful in a multi-user situation. Templates can be assigned to

individual users for hosts and zones. They define which options should be

available to the user when entering new data. Templates can be pre-populated

with useful information to aid less-experienced users.

Appliance ManagementAfter initial set-up, using serial connection or monitor and keyboard, all administration of

your DNSBOX300 appliance can be done using a secure web interface. It allows

configuration to be performed from any computer with a web browser, anywhere in the

world, without the need for additional software to be installed.

The Appliance Interface provides easy access to server administration features. These

include:

Shared management support

Multiple Administrators can log in to the interface at one time, from different

locations. This can be controlled with authentication via a RADIUS server or via

on-box authentication.

Reporting Tools

You can access information for monitoring the status of the services running on

the appliance.

Logging Support

Standard syslog records are generated on DNSBOX300. These are normally

directed to a syslog server elsewhere on your network. This allows logs to be

analysed or retained to meet data retention laws and assist in investigations.

Recent data can be viewed directly from the Appliance Interface.

Backup and Restore

Configuration parameters can be backed up with a single click, then archived or

sent to your vendor’s technical support to aid in troubleshooting. Restoration of

previous back-ups can be performed with similar ease.

Upgrades

Upgrades provided by ApplianSys (adding features, responding to newly

discovered security flaws in BIND, etc) can be applied via the web interface.

Simple Network Management (SNMP) Support

Performance statistics may be accessed remotely in real-time by external

management applications


26/142



Operating SystemThe Linux-based operating system used by DNSBOX300 is a custom-built ‘appliance

distribution’ developed by ApplianSys to optimise its appliance products. It is designed

to maximise security, reliability and ease of use.

All programs, services and files found on a standard Linux distribution that are not

required for a DNS server are not included, making DNSBOX300 faster and more securethan a standard Linux server.

The appliance is protected by an on-box firewall. Ports are only opened in the firewall as

needed when services are enabled. All other traffic is dropped.

DNSBOX300 uses a read-only compressed file system. This is best practice for appliances,

being extremely solid and reliable. Core operating system files are maintained read-

only, adding an extra security layer.

If you have a DNSBOX support contract, your support package includes ‘upgrade

protection’. New software versions will be made available to you as they are released.

These will include upgrades to the latest stable Linux kernels and BIND releases. You canapply them easily from the Appliance Interface.

HardwareDNSBOX300 uses specially selected hardware to ensure both reliability and high

performance without unnecessary cost.

CompactFlash cards are used for the operating system and settings. This has several

advantages over traditional hard disks:

Hard disks have moving parts and are the primary cause of hardware failure. So

being diskless, DNSBOX300 is much more reliable

It means faster boot times and gives more resilience to hardware failure. If yousuffer an unexpected power outage, the risk of configuration data andapplication corruption is minimised

Cards can be ejected from each unit, allowing them to be moved to a spare ornew appliance in the unlikely event of failure, retaining all settings and licenseinformation and data. The replacement unit instantly continues from where thefailed unit left off, without the need to reinstall software or recover data

There are two CompactFlash cards used in the system:

The Program card is bootable and contains the operating system andapplications. It is mounted read-only at all times (other than when receivingupgrades). Licence data also resides on this card

The Data card contains all your configuration settings and DNS data

In-depth information about these and other features is discussed later, in the

Deployment and Configuration sections.


27/142



Hardware ModelsDNSBOX masters are available in 4 models:

DNSBOX050 DNS/DHCP master – small form factor (SFF) model

DNSBOX310 DNS/DHCP master – 1U light duty

DNSBOX320 DNS/DHCP master – 1U standard duty

DNSBOX330 DNS/DHCP master – 1U heavy duty

All models use identical software but differ in terms of hardware and performance.

Where this guide refers to DNSBOX300, it applies equally to all 4 models unless explicitly

stated otherwise.

DNSBOX320/330

Front:

Rear (subject to change):


28/142


29/142


USING DNSBOX300 I 27

SECTION 2:USING DNSBOX300

IN THIS SECTIONDetailed ‘how-to’ instructions for the mainappliance administration tasks you will typicallyhave with DNSBOX300

Install and start the appliance. Configurebasic information to:

- access the admin interface

- allow DNSBOX300 to communicate

with other DNS/DHCP servers in your

deployment

Complete your system setup: configurethe appliance and other linked servers forone (or more) of the main deploymentscenarios. These tasks you would typically

only carry out in initial deployment orwhen changing your system architecture

Carry out key appliance administrationtasks that you will usually carry out on anongoing basis

Getting Started 28

Physical Setup 28

Network Requirements 29

Initial Appliance Configuration 29

Set up DNS records for your DNS servers 33

Online Help and Documentation 37

Deployment Guide 38

Set up relationship with DNSBOX100 slaves 38

Set up Failover Master 42

Configure DHCP for Dynamic DNS updates 47

DNS Views 49

Take control of your own public zones 50

Configuration Scenarios and Options 56

Delegated administration 56

Network security 59

System Log 61

SNMP Logging and Alerting 61

Administration over SSH 61

Remote Administration of BIND 62

Web Browser Certificate Warning 62

Static Routes 62

Configuration Restore and Backup 62

Password 62

Current status 63

Query DNS Server 63

Upgrades 63

Power Control 63


30/142


28 I USING DNSBOX300 - Getting Started

Getting Started

These step-by-step instructions will help you to start using your appliance as quickly as

possible. If at any time you need further assistance, contact your vendor (ApplianSys

Support Partner or ApplianSys).

ApplianSys Support: Email Support:

+44 (0) 8707 707 789 [email protected]

For initial deployment you will need:

Either a PS/2 keyboard and a VGA monitor, or a serial connection

A CAT 5 network cable

Your network addressing information.

Physical Setup

Step 1

Unpack your server, check that all items listed on your delivery note are present and

then check for transit damage.

DNSBOX300 is supplied with a power cable with a suitable plug for the country towhich it is originally supplied. Check you have the right cable.

Please contact your vendor immediately if anything is missing or damaged.

Step 2

You can place DNSBOX050 on a desk or a shelf within a rack. It is slightly more than 1U

high. Ventilation is from the bottom of the unit. Do not attempt to remove the feet on

the underside or overheating could occur. If placed in a rack without fan units (e.g. a

wall-mounted communications cabinet) the power brick should be placed outside the

rack and the cable looped through to reduce the heat generated within the cabinet.

DNSBOX310 should be secured in a rack. It is 1U in height. No shelf is required – the lugs

can support the weight. Ventilation is from the front to the back of the unit. If placed in

a rack without fan units (i.e. a wall mounted communications cabinet) the power brick

should be placed outside the rack and the cable looped through to reduce the heat

generated within the cabinet

DNSBOX320/330 should be secured in a rack. It is 1U in height. A shelf (or other securely

fixed surface below) is required – no rails are provided and the whole weight of each

unit should not be placed on the lugs. Ventilation in each unit is from side to side.

Your appliance should be positioned so that adequate airflow can be achieved

Choose a suitable place to house your DNSBOX300 and connect it to a 240V or 110V AC

mains supply as appropriate (the appliance is auto-switching).


31/142


USING DNSBOX300 - Getting Started I 29

Network RequirementsFor DNSBOX300 to operate correctly with other devices, it may be necessary to configure

firewalls. The following table details all port and protocol usage of the DNSBOX300. Use

this information to aid configuration of the appliance attached to your network.

80/TCP Appliance web interface1000/TCP Appliance web interface443/TCP NameSurfer web interface22/TCP SSH53/TCP DNS53/UDP DNS161/UDP SNMP500/UDP IPsec key exchange daemon* 514/UDP SysLogProtocol 50 (ESP) *

*When you connect DNSBOX appliances (or compatible slaves) via an IPsec secureconnection, port 500/UDP and a GRE connection are the only ports needed for DNS

data and this is the only time they are used. Ports 53/TCP and 53/UDP are not needed

and can be blocked in your firewall if you choose

The firewall must be configured to allow traffic between the DNSBOX300 and the

DNSBOX100 using protocol type 50 (GRE) for the IPsec tunnel to function. If this is not

allowed, then the connection may appear to be functioning but the tunnel will not exist

Initial Appliance ConfigurationFor DNSBOX300 to operate on your network, it first needs some basic network settings.

Console configuration takes only a few minutes and will prompt for a reboot upon

completion. For this you will need:

IP address/netmask for the DNSBOX300 to use

IP address of the default gateway

IP addresses of DNS servers for the DNSBOX300 to resolve network addresses

Step 1

Connect the appliance. Attach:

VGA monitor and PS/2 keyboard, or

Serial cable. The communication settings required for a serial connection are38400 bps, 8 data bits, no parity, 1 stop bit (8N1).

Do not attach the network cable at this time.


32/142



Step 2

Power the appliance on:

DNSBOX050 has its power button on the front (black)

DNSBOX310 has a rocker switch located behind the front panel. Rock and

release to toggle between on and off

DNSBOX320/330 appliances have a green indicator on the front which is also thepower button

Step 3

Once booted a login page will be shown. Login using the username “admin” and the

password - also “admin”

Step 4

On the following screen hit [RETURN] to enter Network Configuration settings. The

following screen will be displayed:

Hit [RETURN] to select an item and the cursor keys to move between fields

Do not use the [ESCAPE] key unless you wish to cancel changes. Unlike computer BIOSs,

this key cannot be used to go back to the previous screen whilst retaining changes.

The key required information is:

the hostname you wish to assign to the appliance

the network address and netmask

the default gateway

The DNS servers that the DNSBOX300 can use to resolve network addresses. Youshould set this initially to 127.0.0.1 (the internal BIND resolver for the DNSBOX300)

Step 6

Upon completion select Exit


33/142



Step 7

You will be prompted to reboot, which you should allow

Step 8

You may now remove the monitor and keyboard, and plug in the network cables

Step 9

Once connected to the network and rebooted the secure web interface can be

accessed.

Open a browser (it is recommended that you use Mozilla Firefox, Google Chrome or

IE7+) at a machine that has network access to the DNSBOX300.

Type the address of the DNSBOX300 into the address bar: eg http://192.168.1.149. This will

redirect automatically to the HTTPS interface.

Your browser must support Javascript. If there is a pop-up blocker integrated into yourbrowser (i.e. Internet Explorer in Windows XP SP2, or Firefox / Mozilla) you will need to

either disable it, or add the IP address of the DNSBOX300 to its exceptions list.

Step 10

Many browsers will complain that the SSL certificate is not valid. This is because it is self

signed and not registered with a certifying body for the IP address that it is on. The

warning can therefore be ignored.


34/142



Step 11

Enter the username ‘admin’ and the password chosen during the initial configuration

and click LOGIN. You will see the ’ABOUT’ screen.

Step 12

Remaining configuration is from a web browser and can be completed remotely. A key

task is to configure timeserver information, to ensure your DNS servers are synchronised.

The system clocks on all related DNSBOX100s and DNSBOX300s must be synchronised, in

order to set up IPsec secure network links and TSIG authentication for secure zone

transfers. You are advised to configure all your DNSBOXs to use a local NTP time server.

Go to ‘Configure’ > ‘Config Network’. You should enter the Timeserver(s) you wishto use to provide accurate time for DNSBOX and select your Timezone.


35/142



You should click OK at this point. If you move to another screen before this, your

changes will be lost. This behaviour is consistent across all the forms in the system

Set up DNS records for your DNS serversIn this section you will learn how to set up an initial DNS zone and hostnames for each of

your DNSBOXs. You will also create reverse DNS zones containing PTR records for each

of your DNSBOXs.

This important step, will allow you to refer to your DNSBOXs by name rather than by IP

address, which in turn will allow you to easily change the IP addresses of boxes should

you need to.

In the following examples we will refer to a domain example.com and a network of four

DNSBOXs. In these examples, mns stands for Master Name Server and sns stands for

Slave Name Server.

2 x DNSBOX300 (mns1 and mns2)

2 x DNSBOX100 (sns1 and sns2)

All the boxes will be deployed on a private class C network 192.168.4.0/24.


36/142



Add the reverse zone

1 Log into the NameSurfer web interface and navigate to‘View Zones’ > ‘Reverse’ > ‘Create zone’ > ‘Empty zone’ and fill in the basicinformation required

2 You will create hostnames

ns1 and

ns2 for the

DNSBOX100s later so enter theminto the Authoritative name servers fields and ignore the warning by clicking the

button labelled ADD ANYWAY.


37/142



Add the Main Zone

Navigate to ‘View Zones’ > ‘Forward > ‘Create zone’ > ‘Empty zone’. Enter the zone

name example.net and the same basic zone information that you entered for the

reverse zone above. Again, ignore the warning about non-existent records.

Add host records for all your DNSBOXs

We will add example hostnames listed in the table below.

mns1.example.com 192.168.4.10

mns2.example.com 192.168.4.20

sns1.example.com 192.168.4.11

Private hostnames

sns2.example.com 192.168.4.12

ns1.example.com 192.0.2.18Public hostnames

ns2.example.com 192.0.2.19


38/142


39/142


USING DNSBOX300 - Online Help and Documentation I 37

Online Help and Documentation

In addition to this manual DNSBOX300 also has online help.

Appliance Interface Online Help

You can access online help by pressing HELP on the bottom right hand corner of your

screen. This open a popup window containing context sensitive help.

NameSurfer Interface Online Help

You can access online help from the web interface by choosing HELP from the list of

options on the left of your screen. This will open a page containing a list of help options.

Press the BACK button on your browser to return to the previous page.


40/142


38 I USING DNSBOX300 - Deployment Guide

Deployment Guide

Set up relationship with DNSBOX100 slaves

DNSBOX300 is normally deployed in an orthodox master-slave architecture. If you are

deploying it with DNSBOX100 slaves, you should configure your appliances to takeadvantage of key DNSBOX features:

Secure IPsec tunnels between master and slave to keep configurations and zonetransfers secure

Automatic push of DNS data from the master to the slaves.

The standard BIND process for copying zone data from a master to a slave

involves several steps on both the master and the slave. Data on slaves only gets

updated when a zone expires, with the slave pulling data from the master.

DNSBOX‘s REMSEC feature automatically updates slaves immediately. Whenever

DNS data is modified on DNSBOX

300, relevant updates are automatically pushedimmediately to the DNSBOX100s. When you add a new zone (using the

NameSurfer Interface) the new zone will be published to all the DNSBOX100s that

you define in the REMSEC fields for that zone.

REMSEC is a proprietary feature which only works between DNSBOX300 masters and

DNSBOX100 slaves

First you must have… Installed and connected your DNSBOX100s on the network, so that they are

accessible from the DNSBOX300

Completed the steps outlined in ‘Getting Started’ section ‘Set up DNS records foryour DNS servers’ so that the DNSBOX100s can be contacted using their DNS

names rather than by IP address.

If you are deploying a failover DNSBOX300, it is a good idea to set up the failover

relationship first, because configuring the master-slave relationships will be a little quicker

for you.

Generally, there is not a critical order to the steps in implementing your DNSBOX300 /

DNSBOX100 architecture. But the order you do things can save you time: while

configuring relationships between appliances, you will want to copy information such as

public keys from one device to another; you will want to test relationships are working,

which requires devices to be online and accessible to each other on your network.


41/142


USING DNSBOX300 - Deployment Guide I 39

Configuration

The steps detailed below to integrate your DNSBOX300 and DNSBOX100 devices are:

Set up secure IPsec links between the master and each slave

- Configure secure link on master and enable automatic configuration

- Configure secure link on each slave

Edit DNS data on the DNSBOX300 to specify slaves to push zone data to

Configure IPsec VPN Connection

For each slave, configure a secure link on the master, and then on the slave.

1 In the DNSBOX300 Appliance Interface, go to ‘system > ‘add secure server’

2 For each DNSBOX100 slave you are linking to, complete the page

a. Put a name for the server link in Description. A simple approach is to use

the hostname you have already created in the DNS.

b. Set Enabled to Yes to create the IPsec link and enter the IP address of

the slave

c. Set VPN enabled to Yes and paste the slave’s public key into public key.

You can copy this from the DNSBOX100‘s Appliance Interface at

’system’ > ‘my public key’.

d.

Set Auto configure to Yes to enable REMSEC and click OK to submit

3 Go to ’system’ > ‘my public key’ and copy the DNSBOX100‘s public key


42/142



4 Log in to the Appliance Interface of the DNSBOX100. Go to ‘system > ‘add secure

server’ and repeat similar steps, entering the details of the master.

5 Repeat these steps for each of your DNSBOX100s.

The DNSBOX300 will set up a secure connection to each DNSBOX100. This may take up to

thirty seconds. The ’secure servers’ screen should now show the link you have created.

Initially the status ‘traffic light’ will be red, but if you refresh after a few seconds, the VPN

connection should have now been established and the traffic light will turn green.

In the DNSBOX100 interface, you should also see the link displayed.


43/142



Specify automatic zone updates

You now have to specify in the DNS data which zone data is to be automatically pushed

to which slaves. You do this by filling in the names of all associated slaves in the REMSEC

fields when using NameSurfer to create (or edit) a zone. After the action is approved,

the DNSBOX300 will contact all specified DNSBOX100 slaves and instruct them to add thenew zone.

When a zone is removed or REMSEC records removed, the process is reversed. Where

REMSEC slaves are listed, the zones are automatically removed from the slave.

DNSBOX100 slaves that you wish to update with REMSEC must be connected to the

DNSBOX300 via an IPsec tunnel. This is to ensure the update messages are secure and

authenticated.


44/142



Set up Failover MasterIf the network connection fails between your DNSBOX300 and its associated DNSBOX100s,

the DNSBOX100s will continue to answer DNS requests and issue DHCP leases. However,

unless it can communicate with its master, the DNS zones on the DNSBOX100 will

eventually become stale and the box will stop responding to authoritative requests.To avoid this, you can set up two DNSBOX300s as a failover pair. The active box is known

as the failover master. The box on standby is the failover mirror. In this mode, the mirror

copies the DNS data from the master at regular intervals. You can configure replication

to happen as often as every five minutes. DNS and DHCP services on the standby

DNSBOX300 are paused while data is copied – this usually takes less than a second.

If the link between active master and its DNSBOX100s fails (or in the unlikely event of a

DNSBOX300 hardware failure), the DNSBOX100s will automatically attempt to use the

standby master for DNS zone transfers.

First you must have… Installed and connected your DNSBOX300s on the network

Installed and connected your DNSBOX100s on the network, so that they areaccessible from the DNSBOX300s

Completed the steps outlined in ‘Getting Started’ section ‘Set up DNS records foryour DNS servers’ so that the DNSBOX100s can be contacted using their DNSnames rather than by IP address.

Configuration

There are two stages - detailed below - to linking your active and standby DNSBOX300s:

Set up secure server link between them. This ensures that data transfers betweenthem are secure and authenticated.

Configure the failover relationship between them

You then need to make sure your slaves link to both DNSBOX300s.

If you haven’t already done so, you link them to the failover master exactly as described

in the previous section Set up relationship with DNSBOX100 slaves:

Set up secure IPsec links to each slave

-

Configure secure link on master, enabling REMSEC by setting Autoconfigure to Yes on the master

- Configure secure link on each slave

Edit DNS data on the DNSBOX300 to specify slaves to push zone data to

To integrate the slaves with the failover mirror, you simply need to:

Create a secure server link between the failover mirror and each DNSBOX100.Configuration steps are almost identical to linking to the failover master, with justone field entered differently, as detailed below.

The IP address of the failover mirror is now added automatically to all of your slave zonesand if the DNSBOX100 can’t reach the failover master, it will instead transfer zone data

from the failover mirror.


45/142



Configure IPsec secure link between DNSBOX300s

You need to define the secure server link at both ends – on each of the DNSBOX300s.

You will need to move between both Appliance Interfaces, so log in to both. Let’s say

we configure the active failover master mns1 first

1 On the standby failover mirror mns2, go to ’system’ > ‘my public key’ and copyPublic key

2 Go to the active mns1 Appliance Interface and to ‘system > ‘add secure server’

3 Complete the page

a. Put a name for the server link in Description. The obvious approach is to

use the hostname of the other master mns2.example.com.

b. Set Enabled to Yes to create the IPsec link and enter the IP address of the

other master

c. Set VPN enabled toYes

and paste the public key for mns2 into public key.

d. Click OK to submit

4 Go to ’system’ > ‘my public key’ and copy Public key.

5 Now go to the standby mns2 Appliance Interface ‘system’ > ‘add secure server’

6 Repeat step 3 entering the information for mns1.example.com

After you have submitted this data, you should see the secure servers screen ineach interface, with the link you have just created. Initially the status ‘traffic light’will be red, but if you refresh after a few seconds, the VPN connection shouldhave now been established and the traffic light will turn green.


46/142



Set up DNSBOX300 failover pair

1 Log into the web interface of the failover master and navigate to‘configure’ > ‘config advanced’

a. Change failover mode to failover master

b.

Enter a failover password c. Leave failover master and refresh interval at their defaults – they have no

effect on the failover master

2 Reboot when prompted

3 Log into the web interface of the failover mirror and navigate to‘configure’ > ‘config advanced’

a. Change failover mode to failover mirror (copy)

b. Enter the same failover password that you chose on the master.

c. Choose the failover master from the drop down list

d. Choose a refresh interval (five minutes is recommended)


47/142



4 Click OK and reboot when prompted

After five minutes (or whatever refresh interval you chose) the log into the

NameSurfer web interface on the failover mirror. You should find that the zones

have been copied from the failover master.

Configure IPsec Connection between DNSBOX100s and Failover Mirror

You now need to make sure your slaves link to both DNSBOX300s.

If you haven’t already done so, you link them to the failover master exactly as described

in the previous section Set up relationship with DNSBOX100 slaves.

In ‘System’ > ‘Secure Servers’ on the DNSBOX100, you would now see:

You then need to configure your DNSBOX100s to point them at the failover mirror as well.

This enables zone data to be transferred from the failover mirror, if the failover master is

offline for some reason.

This is done simply as you create a secure link between each slave and the mirror. For

each of your DNSBOX100s:

1 In the DNSBOX300 Appliance Interface for the mirror, go to ‘system’ > ‘add secureserver’ – complete the page in exactly the same way as for failover master (see

Configure IPsec VPN Connection on p.39) 2 In the Appliance Interface of the DNSBOX100, go to ‘system’ > ‘add secure server’

and repeat similar steps, entering the details of the master.

The one difference is that you enter the IP address of the failover master into the

failover master field at the bottom of the page


48/142



3 In ‘System’ > ‘Secure Servers’, you should now see the second link to the failovermirror mns2.example.com added

4 The IP address of the failover mirror is now added automatically to all of yourslave zones. You can check this by viewing one of your slave zones. Navigate to‘DNS’ > ‘Slave domains’. Click on one of your zones and look at themaster ip address field. It should contain the IP addresses of both DNSBOX300s.

Now, if it can’t reach the failover master, the DNSBOX100 will instead transfer zone

data from the failover mirror.


49/142



Configure DHCP for Dynamic DNS updatesWhen a DHCP server issues a lease, it can add corresponding DNS host records to the

NameSurfer DNS database, using the Dynamic DNS (DDNS) protocol (standardised and

documented in RFC 2136). These map a client host name to the leased IP address. The

reasons for doing this are: Traceability: By registering each DHCP client in the DNSBOX300 DNS database,

you will be able to see which hostnames are in use, and which IP addresses are inuse. This information is presented in the DNS management pages of theNameSurfer web interface.

Reverse DNS records: Many network services such as email or SSH require thatclient IP addresses have a corresponding reverse DNS record (a PTR record).These can be created and deleted dynamically by the DHCP server as it issuesand revokes leases.

Human readable hostnames: It is usually much more convenient to connect to a

network device using its hostname, which is more memorable than its IP address.The DNSBOX100 DHCP server can be configured to dynamically add host (A)records to the DNSBOX300 DNS database as DHCP leases are issued andreleased.

DNSBOX300 supports dynamic DNS updates, from either its own onboard DHCP server, or

from a 3rd party server. By default, dynamic updates are denied.

To make a zone dynamically updatable you must add a special host (A) record called

allow-dynamic-updates. Any IP addresses that you add to this record will be takenas those permitted to issue updates. E.g.

$ORIGIN test.

test. 86400 IN SOA . hostmaster.test. (

2005032117 28800 7200 604800 86400 )

NS slave

;- REMSEC slave

allow-dynamic-updates A 192.168.1.26

mail A 192.168.1.1

master A 192.168.1.26

slave A 192.168.1.27


50/142



You can also dynamically update reverse zones but in this case you use PTR records:

1 In the reverse zone, create a PTR record named allow-dynamic-updates, itcan point to anything (e.g. the name of the DNSBOX300).

$ORIGIN 192.in-addr.arpa.

192.in-addr.arpa. 86400 IN SOA . hostmaster.test. (

2005012115 28800 7200 604800 86400 )

NS me.

allow-dynamic-updates PTR master.test.

2 Click on the PTR record that was just created and click the “Add RR” menuoption on the left. Then select OK on the default record type of “A”.

3 In the IP address field, enter the address of the first server to be allowed to issuedynamic updates.

$ORIGIN 192.in-addr.arpa.

192.in-addr.arpa. 86400 IN SOA . hostmaster.test. (

2005012116 28800 7200 604800 86400 )

NS me.

allow-dynamic-updates A 192.168.1.26

PTR master.test.

4 If there are more addresses to be added to enable multiple servers to issue DDNSupdates, simply click on the PTR record you created again and an additional “A”record input box will be available to you.


51/142



DNS ViewsA DNS view allows you to configure your DNS server so that DNS clients will be served

different DNS records based on their source IP address.

A simple example is an organisation with an internal email server. Users who make DNS

requests to mail.example.com from the internal office network (eg 192.168.1.0/24) will be servedan internal email server IP address. Users on the Internet will be sent the IP address of an

external email server. This functionality is sometimes also known as ‘split DNS’.

NameSurfer allows you to set up multiple DNS views containing multiple zones. Each

view can be configured to allow requests from multiple ranges of IP addresses.

The IP ranges specified for different views must never overlap. If they did, the server

would not know which view to provide.

With NameSurfer, it is easy to manage the DNS data in each view.

You should generally create a prototype zone in the default view and then usethe "copy zone" feature to copy the zone into one or more views.

You can then modify the DNS data for each view and also the REMSEC recordsfor each zone in each view. If you have enough DNSBOX100s, this allows you tototally separate your public DNS data from you private internal DNS data.

The default View in NameSurfer operates differently from the standard BIND approach.

Normally, a DNS client would only be able to request DNS data from zones whichare defined explicitly in their view.

If it is not defined in their view, DNSBOX will serve the data from the default view if

it exists there. This saves you having to duplicate all zones to all views.

With DNSBOX300 deployed in a master-slave architecture with DNSBOX100 slaves, you

can set up multiple views on a single slave or deploy a separate slave to serve each

view. You do this simply by defining which slave each view is copied to.

Configuration

Set up a simple, single DNS view as follows. Repeat as required for more views:

1 In the NameSurfer interface, select ‘Views’ > ‘New view’ from the menu on the left

2 Enter a name for the new view (e.g. internal or external). A single word is

recommended, as spaces and other invalid DNS characters will be convertedinto ASCII codes for compatibility

3 You can enter a HTXT or HTML comment but this is not required. These will only bevisible in the views menu and are for documentation purposes only. The HTXT willonly display a limited number of characters in the main views screen, whereas afull HTML comment will be shown.

4 Enter an IP address range to limit which hosts will be able to access this view. Ifthis is only a single address (not a range), leave the second input box blank.


52/142



5 Create a new zone and select the newly created view in ‘select view’

Ensure the NS records for the zone are set to name servers that have access to this view

6 On the DNSBOX100 check the “Status” of the zone - in particular that time of lastupdate is listed, as well as the serial number. When the DNSBOX100 has verifiedthe zone, a blue tick will appear in the status field.

Only DNSBOX100 slaves that have auto configure set on will receive the new zone.

IP address ranges for a View can be modified on the DNSBOX300 and the slaves will be

immediately informed of the new address ranges.

For more information on DNS views please see the NameSurfer reference guide. The

details found here relate specifically to the DNSBOX300 appliance.

Take control of your own public zonesOnce you have migrated your public zones to the DNSBOX300, and have verified that all

the DNS data is up to date you will need to arrange for your domain registrar or ISP to

delegate control of the forward zone to your DNS servers.

You may also control your own public IPv4 subnets and it is then your responsibility tomaintain a reverse DNS zone for each of these subnets. These will also need to be

delegated to you.

This section shows you how to approach your ISP or domain registrar in order to take

control of your forward and reverse DNS zones.

First you must have…

Imported or set up all your public forward and reverse zones on the DNSBOX300.

Published these zones to your public DNSBOX100s

Configuration

The steps detailed below are:

Register your public subnet

Arrange delegation of forward zones

Arrange delegation of public reverse zones


53/142



Register your public subnet

The public subnet on which your DNSBOXs are deployed must be registered. You may

be using a portion of a subnet belonging to your ISP or you may control your own

subnet. In either case the subnet must be registered.

1 First check the status of your network using the web based tools provided by the

major regional Internet registries (RIRs). Choose the registry that is responsible foryour region:

- https://ws.arin.net/whois/ (North America and Canada)

- http://www.db.ripe.net/whois (Europe, the Middle East and parts of Central Asia)

- http://www.afrinic.net/cgi-bin/whois (Africa)

- http://wq.apnic.net/apnic-bin/whois.pl (Asia Pacific and Oceania)

- http://www.lacnic.net/cgi-bin/lacnic/whois (Latin American and Caribbean)

If you’re unsure which registry to use, check the interactive map at

https://www.arin.net/knowledge/rirs/APNICcountries.html.

2 If a query for your IP address returns a positive result, it means that that IP belongsto a registered network.

3 It is quite likely that your subnet is already registered. But if it is not, you shouldapproach your ISP (or Internet registrar directly) for information about registering.

Arrange delegation of your forward zones

This section assumes that you have already purchased one or more public domain

names from a registrar.

The registrar will probably have provided you with access to a web interface through

which you can set the authoritative nameservers for your domain.

1 Enter the public IP addresses (or hostnames – as long as they are not within thisdomain) of your public facing DNSBOX100s.

2 The screenshot below illustrates the nameserver configuration from one popularregistrar in the UK:


54/142



3 After submitting this form, your domain registrar will send an update tomaintainers of the parent domain (.com in this case) – and they in turn will updatetheir NS records for the example.com subdomain. This can take a few days to takeeffect.

4 Test the state of the NS records using the dig command from the command lineinterface of the DNSBOX300. In the following example we use bbc.co.uk as anillustration.

First, look up the nameserver authoritative for the parent domain (co.uk )

admin@d400a:~$ dig co.uk. NS

...

;; ANSWER SECTION:

co.uk. 172800 IN NS nsb.nic.uk.

co.uk. 172800 IN NS nsd.nic.uk.

co.uk. 172800 IN NS ns3.nic.uk.

co.uk. 172800 IN NS nsa.nic.uk.

co.uk. 172800 IN NS ns1.nic.uk.

...

;; ADDITIONAL SECTION:

ns1.nic.uk. 172367 IN A 195.66.240.130

5 Next query that nameserver for the NS records associated with your publicdomain (bbc.co.uk )

admin@d400a:~$ dig @195.66.240.130 bbc.co.uk NS

...

;; AUTHORITY SECTION:

bbc.co.uk. 172800 IN NS ns1.bbc.co.uk.

...

;; ADDITIONAL SECTION:ns1.bbc.co.uk. 172800 IN A 132.185.132.21

...

You should see the IP address or hostname of your DNSBOX100s listed under the

“authority section”

You may also see an “additional section” which lists the IP addresses

corresponding to your public DNSBOX100 hostnames. These are known as ‘glue

records’ and are necessary to bootstrap the lookup process when a nameserver

hostname is within the domain for which it is authoritative.


55/142



Arrange delegation of your public reverse zones

Each IP subnet should have a corresponding reverse zone. The parent domain for all

reverse zones is in-addr.arpa

Given a network 192.168.1.0/24 you should aim to be in control of the reverse zone

1.168.192.in-addr.arpa and each device on that network should have a forward hostname

(A) record and a reverse (PTR) record, such as:

Ns1.example.com IN A 192.168.1.11

11.1.168.192.in-addr.arpa IN PTR ns1.example.com

1 Check that you have setup reverse zones for each of your public subnets in theNameSurfer web interface.

2 Verify that the public facing DNSBOX100s respond correctly to requests for PTRrecords within your reverse zone.

admin@d400a:~$ dig @192.168.1.11 -x 10.0.0.99

...;; QUESTION SECTION:

;10.1.168.192.in-addr.arpa. IN PTR

;; ANSWER SECTION:

10.1.168.192.in-addr.arpa. 86400 IN PTR mns1.example.com.

...

3 Once you have sanity checked the data in your reverse zone, you can approachyour ISP or the Internet registrar which is responsible for the parent zone.

For example, given a class C network (10.0.0.0/24), ask your registrar to add NS

records for each of your authoritative nameservers to the zone 0.0.10.in-addr.arpa,

and send them the IP addresses of your public facing DNSBOX100s.


56/142



4 Check the reverse zones have been correctly delegated. Look up the name-server authoritative for the parent zone (eg for bbc.co.uk IP address 132.185.240.21…)

admin@d400a:~$ dig 132.in-addr.arpa. NS

...

;; ANSWER SECTION:

132.in-addr.arpa. 86118 IN NS z.arin.net.

...

;; ADDITIONAL SECTION:

...

z.arin.net. 2824 IN A 199.212.0.63

5 Query that nameserver for an IP address within the public network. The answer

shows 185.132.in-addr.arpa. has been delegated to the bbc.co.uk nameservers.

admin@d400a:~$ dig @199.212.0.63 185.132.in-addr.arpa. -x

132.185.240.21

...

;; AUTHORITY SECTION:

185.132.in-addr.arpa. 86400 IN NS ns1.thny.bbc.co.uk.

185.132.in-addr.arpa. 86400 IN NS ns1.thdo.bbc.co.uk.

185.132.in-addr.arpa. 86400 IN NS ns1.thls.bbc.co.uk.

185.132.in-addr.arpa. 86400 IN NS ns.ripe.net.

185.132.in-addr.arpa. 86400 IN NS ns.bbc.co.uk.

...

If you have a classless IPv4 network, you may have seen references to “classless reverse

zones” and RFC 2317. These are supported by NameSurfer but have a number of

drawbacks and are not usually necessary.

If you have a ‘classless’ subnet, your Internet registrar will need to delegate domain

records individually.If you are delegating a classless reverse zone, you need to add the the PTR records on

the DNSBOX300 for all the addresses in the subnet that you are delegating. Say for

example you want to delegate reverse records for the subnet 192.0.2.0/25 to a customer

that uses this address space:

6 Click the reverse zone 2.0.192.in-addr.arpa


57/142



7 Select ’Delegation’ on the left and fill in Name and Authoritative name servers

8 Once you have delegated the zone to the proper name servers, you will need toadd the CNAME records as described in RFC 2317. Select ‘Alias’ on the left andfill in the fields. Repeat this step for each address. In this example you will needto create 128 records.

userguide dnsbox300.pdf

Documents