UserGuide DNSbox300 PDF

DNSBOX050/300
DNS and DHCP

Management Appliance
USER GUIDE
Published By:
ApplianSys Limited
University of Warwick Science Park
Business Innovation Centre
Binley Business Park
Coventry, 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
www.appliansys.com/company/copyright.doc
V6.23 - 14 Dec 2010
products
included
in
DNSBOX050/030
are
available
online
at
DNSBOX050/300 User Guide
Contents
Using This Guide
SECTION 1: PLANNING DEPLOYMENT

Introduction to DNS and DHCP
DNSBOX300 Overview
5
6
17
SECTION 2: USING DNSBOX300

Getting Started
Online Help and Documentation
Deployment Guide
Configuration Scenarios and Options
27
28
37
38
56
SECTION 3: CONFIGURATION REFERENCE

DNS Menu
SYSTEM Menu
CONFIGURE Menu
65
66
93
94
SECTION 4: FREQUENTLY ASKED QUESTIONS

Appliance Management
Troubleshooting
Hardware
97
98
99
100
APPENDICES
Appendix A: Resource Records Types
Appendix B: Advanced DHCP Configuration
Appendix C: Using the Command Line Interface
101
101
109
128
Using This Guide

Products Covered
This 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 Organised

This guide has been organised into sections to fit the different ways you will need
information at different times:
PLANNING DEPLOYMENT understand in advance key principles about how to

work with DNSBOX300, to make sure your deployment follows a sensible
approach:
-
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 will
typically 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 out
on an ongoing basis
The remaining sections are for you to refer to whenever you need a specific
piece of information:
Using This Guide
CONFIGURATION REFERENCE - describes in detail each of the screens

you can find in your appliances 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
Who This Guide Is For

DNSBOX300 is typically used by different administrators with different roles:
If you are involved in planning or carrying out deployment, Sections 1 and 2 are
particularly relevant to you
If you are a network administrator tasked with ongoing management of the

DNSBOX300 device in your network, you are likely to use most of the guide
regularly, with particular emphasis on Configuration Scenarios and Options in
Section 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 main
reference 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 Guide

The following formats have been used to help you use this guide:
[KEYSTROKE]
Something you have to type or select from a drop down or radio

button 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
Using This Guide
SECTION 1:
PLANNING DEPLOYMENT
Make sure you can start to use DNSBOX300 with
confidence. Understand in advance key
principles about how to work with it. Make sure
your deployment follows a sensible approach
Understand different deployment

scenarios for integrating 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.
IN THIS SECTION
Key DNS Concepts
Deployment Options and Scenarios
Authoritative DNS: Master-Slave

Recursive DNS and Caching
DHCP and Dynamic DNS
High Availability Slaves
DNS Views
Failover Master
Enterprise Deployment External DNS
Enterprise Deployment Mixed
BIND/Windows DNS
ISP Deployment
DNSBOX300 Overview
8
9
10
10
11
12
13
14
15
17
User Interfaces
18
DNS Management Application
20
Managing DNS Data

Managing other DNS / DHCP Servers
Controlling multiple users
20
22
22
23
Operating System
24
Hardware
24
Hardware Models
25
PLANNING DEPLOYMENT

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 has
a 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 Unix
systems. 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 Concepts

The 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 the
authoritative data is held and edited.
A Slave (secondary) holds a copy of the authoritative data. It obtains the zone
data by doing zone transfers from a master. It periodically queries the master to
see if the zones 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.
PLANNING DEPLOYMENT - Introduction to DNS and DHCP
For example, finding the IP address of

queries:
www.example.com
may require a series of three DNS
To a root name server, which will point to a server authoritative for .com
To the server authoritative for .com, which will point to a server authoritative for
.example.com
To the server authoritative for .example.com, which will supply the IP address for
www.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 Scenarios

Overall 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:
DNS Views
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

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 is

used to edit DNS records. It holds the original
authoritative records, but does not resolve DNS
queries
A minimum of two slaves serve queries, for

redundancy. Each slave only carries a copy of
zone data, with the original held securely on the
master. Data on the slave is not propagated to
any other device. If a slave somehow became
compromised, any amended DNS data could not
infect the entire installation. Any damaging results
would be more temporary and more contained
than if compromises were made to the master
authoritative 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-server
architecture 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.

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 DNS
cache 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 loads
for 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.
In other situations, the role of DNS cache is combined with authoritative server on
a single slave server. This is a sensible option when the perceived risk from DNS
Cache-poisoning is not as significant. This clearly applies on a corporate private
network, where the DNS cache is internal facing and access to it can be limited
to a known set of relatively trusted or at least controllable - IP addresses.

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 for
using this feature are:
Traceability: By registering each DHCP client in the DNS database, you can see
which hostnames and which IP addresses are in use. This information is presented
in the DNS management pages of the NameSurfer web interface.
Reverse DNS records: Many network services, such as email or SSH, require that
client IP addresses have a corresponding reverse DNS record (a PTR record).
These can be created and deleted dynamically by the DHCP server as it issues
and 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 the
DNSBOX300 DNS server as DHCP leases are issued and released.

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 resolved
fast enough
The standard#] approach with alternate DNS servers on different IP addresses

and hosts configured to switch between them can be too slow to beat the
timeout.
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 loadbalancing 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.
10
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 DNS
Views 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 on
a 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.
11
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 to
zone 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.
12
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 of
your DNSBOX100s in the NS records for your external domain and optionally a
tertiary 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 the
round 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 interruption
to 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 an

authoritative DNS server located at your ISP.
13
Enterprise Deployment Mixed BIND/Windows DNS

In a complex deployment dealing with all aspects of a large organisations 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.
14
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 the
DNSBOX100, 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 clustered
pair of DNSBOX100s with a virtual cluster IP address for recursive resolution. The
cluster provides load balancing of expensive recursive queries
Single DNSBOX100s are also located in each of your branch offices. Managers at
branch offices are able to log in to the DNSBOX300 web interface and from there
manage their own internal DNS zone
In the event of a network failure between branch office and the primary data
centre, the DNSBOX100s continue to provide recursive and internal DNS services
automatically transferring zones from the DNSBOX300 in the secondary data
centre
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 accessible
only by Network Operations Centre staff
You use the DNSBOX300 to manage your organisations DNS zones (eg
example.com) and the reverse DNS records associated with your public IP networks
Authoritative DNS
Two internet-facing DNSBOX100s provide your authoritative DNS service
Additional redundancy could be achieved by allowing zone transfers to an

authoritative DNS server located at another ISP
15
Internal DNS and DHCP
16
Two pairs of DNSBOX100s, located in each data centre, provide local

authoritative and recursive DNS
Subscribers use the clustering feature for recursive DNS resolution. Expensive
recursive 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 to
answer DNS requests on the virtual cluster IP address
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:
HARDWARE
SOFTWARE
Application Layer: NameSurfer
Proprietary
Hidden
Primary
BIND
To Slave
Application Extensions
Appliance
Layers
Server Management
Operating System
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
PLANNING DEPLOYMENT - DNSBOX300 Overview
17
User Interfaces
In 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 can
do. 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:
18
The NameSurfer Interface is for DNS Administration
The Appliance Interface is for Server Administration
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 super
administrators 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 specific

rights 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 out
bulk or non-standard configuration tasks.
19
DNS Management Application

The 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.
industrial-grade in that:
It is
First versions were developed for large ISPs in the 1990s. It was designed from the
beginning to be able to support carrier-class requirements
The functionality offered by the software is suitable for large and complex
deployments
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 time
and reducing the chance of errors
It is easy to make errors in BIND - even simple syntax errors. NameSurfer validates
data 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 cant 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 change
data 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.
20
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 reverse
zone, 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 for
the 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).
21
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 now
wish 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.
22
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.
After 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 vendors 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
23
Operating System
The 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 secure
than 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 readonly, 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 can
apply them easily from the Appliance Interface.
Hardware
DNSBOX300 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 you
suffer an unexpected power outage, the risk of configuration data and
application corruption is minimised
Cards can be ejected from each unit, allowing them to be moved to a spare or
new appliance in the unlikely event of failure, retaining all settings and license
information and data. The replacement unit instantly continues from where the
failed 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 and
applications. It is mounted read-only at all times (other than when receiving
upgrades). 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.
24
Hardware Models
DNSBOX 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):
25
DNSBOX310
Front:
DNSBOX050
Front:
26
SECTION 2:
USING DNSBOX300
Detailed how-to instructions for the main
appliance administration tasks you will typically
have with DNSBOX300
Install and start the appliance. Configure

basic information to:
-
access the admin interface
allow DNSBOX300 to communicate

with other DNS/DHCP servers in your
deployment
Complete your system setup: configure

the appliance and other linked servers for
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
Carry out key appliance administration
tasks that you will usually carry out on an
ongoing basis
IN THIS SECTION
Getting Started
28
Physical Setup
28
Network Requirements
29
Initial Appliance Configuration
29
Set up DNS records for your DNS servers
33
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

Delegated administration
56
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
USING DNSBOX300
27
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
support@appliansys.com
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 to
which 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).
28
USING DNSBOX300 - Getting Started
Network Requirements
For 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
1000/TCP
443/TCP
22/TCP
53/TCP
53/UDP
161/UDP
500/UDP
514/UDP
Protocol 50 (ESP)
Appliance web interface

NameSurfer web interface
SSH
DNS
DNS
SNMP
IPsec key exchange daemon*
SysLog
*
*When
you connect DNSBOX appliances (or compatible slaves) via an IPsec secure
connection, 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 Configuration

For 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 are
38400 bps, 8 data bits, no parity, 1 stop bit (8N1).
Do not attach the network cable at this time.
29
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 the
power 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.
following screen will be displayed:
The
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. You
should set this initially to 127.0.0.1 (the internal BIND resolver for the DNSBOX300)
Step 6
Upon completion select Exit
30
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
redirect automatically to the HTTPS interface.
http://192.168.1.149.
This will
Your browser must support Javascript. If there is a pop-up blocker integrated into your
browser (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.
31
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.
32
Go to Configure > Config Network. You should enter the Timeserver(s) you wish
to use to provide accurate time for DNSBOX and select your Timezone.
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 servers

In 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.
33
Add the reverse zone
34
Log into the NameSurfer web interface and navigate to

View Zones > Reverse > Create zone > Empty zone and fill in the basic
information required
You will create hostnames ns1 and ns2 for the DNSBOX100s later so enter them
into the Authoritative name servers fields and ignore the warning by clicking the
button labelled ADD ANYWAY.
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.
Private hostnames
Public hostnames
mns1.example.com
mns2.example.com
sns1.example.com
sns2.example.com
ns1.example.com
ns2.example.com
192.168.4.10
192.168.4.20
192.168.4.11
192.168.4.12
192.0.2.18
192.0.2.19
35
Use the Add host link in the left hand menu and add host records for each DNSBOX.
Note that the reverse zone has been automatically populated with PTR records for each
of the DNSBOX IP addresses.
NameSurfer will leave the IP address field blank unless the user account has a limited
range of IP addresses, or if reverse mapping information is not available.
Otherwise, when adding a new host, NameSurfer can search for the next available IP
address (chosen from the users "Allocate IP addresses from range(s)" configuration)
automatically, and put it in the IP address field as a default.
Next Steps
The basic configuration of your appliance is now complete. You are now ready to carry
out configuration tasks specific to your deployment.
36
Update the hostname of each DNSBOX (with its fully qualified domain name) via
the network configuration page of the Appliance Interface
Set up IPsec connections between the DNSBOX300s and the DNSBOX100s (see Set
up relationship with DNSBOX100 slaves in the Deployment Guide section)
Set up a failover link (including IPsec connection) between two DNSBOX300s (see
Set up DNSBOX300 failover in the Deployment Guide section)

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.
USING DNSBOX300 - Online Help and Documentation
37
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 take
advantage of key DNSBOX features:
Secure IPsec tunnels between master and slave to keep configurations and zone
transfers 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.
DNSBOXs REMSEC feature automatically updates slaves immediately. Whenever
DNS data is modified on DNSBOX300, relevant updates are automatically pushed
immediately 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 for
your 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.
38
USING DNSBOX300 - Deployment Guide
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
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 slaves public key into public key.
You can copy this from the DNSBOX100s Appliance Interface at
system > my public key.
d. Set Auto configure to Yes to enable REMSEC and click OK to submit
Go to system > my public key and copy the DNSBOX100s public key
39
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.
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.
40
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 the
new 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.
41
Set up Failover Master

If 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 are
accessible from the DNSBOX300s
Completed the steps outlined in Getting Started section Set up DNS records for
your DNS servers so that the DNSBOX100s can be contacted using their DNS
names 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 between
them are secure and authenticated.
Configure the failover relationship between them
You then need to make sure your slaves link to both DNSBOX300s.
If you havent 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 Auto

configure 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 just
one field entered differently, as detailed below.
The IP address of the failover mirror is now added automatically to all of your slave zones
and if the DNSBOX100 cant reach the failover master, it will instead transfer zone data
from the failover mirror.
42
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. Lets say
we configure the active failover master mns1 first
1
On the standby failover mirror mns2, go to system > my public key and copy
Public key
Go to the active mns1 Appliance Interface and to system > add secure server
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 to Yes and paste the public key for mns2 into public key.
d. Click OK to submit
Go to system > my public key and copy Public key.
Now go to the standby mns2 Appliance Interface system > add secure server
Repeat step 3 entering the information for mns1.example.com

After you have submitted this data, you should see the secure servers screen in
each 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 should
have now been established and the traffic light will turn green.
43
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
Reboot when prompted
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)
44
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 havent 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 secure
server complete the page in exactly the same way as for failover master (see
Configure IPsec VPN Connection on p.39)
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
45
In System > Secure Servers, you should now see the second link to the failover
mirror mns2.example.com added
The IP address of the failover mirror is now added automatically to all of your
slave 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 the
master ip address field. It should contain the IP addresses of both DNSBOX300s.
Now, if it cant reach the failover master, the DNSBOX100 will instead transfer zone
data from the failover mirror.
46
Configure DHCP for Dynamic DNS updates

When 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 in
use. This information is presented in the DNS management pages of the
NameSurfer web interface.
Reverse DNS records: Many network services such as email or SSH require that
client IP addresses have a corresponding reverse DNS record (a PTR record).
These can be created and deleted dynamically by the DHCP server as it issues
and 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 and
released.
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 taken
as those permitted to issue updates. E.g.
$ORIGIN test.
test. 86400 IN
SOA
. hostmaster.test. (
2005032117 28800 7200 604800 86400 )
NS
slave
;-
REMSEC
allow-dynamic-updates
192.168.1.26
mail
192.168.1.1
master
192.168.1.26
slave
slave
192.168.1.27
47
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, it

can point to anything (e.g. the name of the DNSBOX300).
$ORIGIN 192.in-addr.arpa.
192.in-addr.arpa.
86400 IN
SOA
2005012115 28800 7200 604800 86400 )
NS
me.
PTR
master.test.
Click on the PTR record that was just created and click the Add RR menu
option on the left. Then select OK on the default record type of A.
In the IP address field, enter the address of the first server to be allowed to issue
dynamic updates.
$ORIGIN 192.in-addr.arpa.
192.in-addr.arpa. 86400 IN
SOA
2005012116 28800 7200 604800 86400 )
48
NS
me.
192.168.1.26
PTR
master.test.
If there are more addresses to be added to enable multiple servers to issue DDNS
updates, simply click on the PTR record you created again and an additional A
record input box will be available to you.
DNS Views
A 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 served
an 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 use
the "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 records
for each zone in each view. If you have enough DNSBOX100s, this allows you to
totally 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 which
are 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
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 converted
into ASCII codes for compatibility
You can enter a HTXT or HTML comment but this is not required. These will only be
visible in the views menu and are for documentation purposes only. The HTXT will
only display a limited number of characters in the main views screen, whereas a
full HTML comment will be shown.
Enter an IP address range to limit which hosts will be able to access this view. If
this is only a single address (not a range), leave the second input box blank.
49
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 last
update is listed, as well as the serial number. When the DNSBOX100 has verified
the 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 zones

Once 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 to
maintain 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:
50
Register your public subnet
Arrange delegation of forward zones
Arrange delegation of public reverse zones
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 for
your region:
(North America and Canada)
https://ws.arin.net/whois/
http://www.db.ripe.net/whois
http://www.afrinic.net/cgi-bin/whois
http://wq.apnic.net/apnic-bin/whois.pl
http://www.lacnic.net/cgi-bin/lacnic/whois
(Europe, the Middle East and parts of Central Asia)

(Africa)
(Asia Pacific and Oceania)
(Latin American and Caribbean)
If youre 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 belongs
to a registered network.
It is quite likely that your subnet is already registered. But if it is not, you should
approach 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 this
domain) of your public facing DNSBOX100s.
The screenshot below illustrates the nameserver configuration from one popular
registrar in the UK:
51
After submitting this form, your domain registrar will send an update to
maintainers of the parent domain (.com in this case) and they in turn will update
their NS records for the example.com subdomain. This can take a few days to take
effect.
Test the state of the NS records using the dig command from the command line
interface of the DNSBOX300. In the following example we use bbc.co.uk as an
illustration.
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.
195.66.240.130
...
;; ADDITIONAL SECTION:
ns1.nic.uk.
172367
IN
Next query that nameserver for the NS records associated with your public
domain (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.
IN
...
ns1.bbc.co.uk.
172800
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.
52
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

and each device on that network should have a forward hostname
(A) record and a reverse (PTR) record, such as:
1.168.192.in-addr.arpa
Ns1.example.com IN A 192.168.1.11
11.1.168.192.in-addr.arpa IN PTR ns1.example.com
Check that you have setup reverse zones for each of your public subnets in the
NameSurfer web interface.
Verify that the public facing DNSBOX100s respond correctly to requests for PTR
records 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
86400 IN
PTR
;; ANSWER SECTION:
10.1.168.192.in-addr.arpa.
mns1.example.com.
...
Once you have sanity checked the data in your reverse zone, you can approach
your 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.
53
Check the reverse zones have been correctly delegated. Look up the nameserver 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.
199.212.0.63
...
...
z.arin.net.
2824
IN
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:~$
132.185.240.21
dig
@199.212.0.63
185.132.in-addr.arpa.
-x
...
;; AUTHORITY SECTION:
86400 IN
NS
ns1.thny.bbc.co.uk.
86400 IN
NS
ns1.thdo.bbc.co.uk.
86400 IN
NS
ns1.thls.bbc.co.uk.
86400 IN
NS
ns.ripe.net.
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
54
Click the reverse zone 2.0.192.in-addr.arpa
Select Delegation on the left and fill in Name and Authoritative name servers
Once you have delegated the zone to the proper name servers, you will need to
add the CNAME records as described in RFC 2317. Select Alias on the left and
fill in the fields. Repeat this step for each address. In this example you will need
to create 128 records.
55

Delegated administration
Using the NameSurfer interface, you can enable administration of zones by other
people, letting them manage their own DNS.
For example, in a corporate deployment, you may want to delegate the administration
of a subdomain (coventry.example.com) to the network manager at your Coventry branch
office. They will log in with their username and will only be able to add / delete / modify
hosts within that subdomain.
NameSurfer supports multiple users each with their own password. You can create users
or groups of users who only have permission to edit a subset of DNS data.
To allow delegated users to administer their own zones, they should log directly into the
NameSurfer Interface at https://dnsbox.example.com, or using the IP address of your
DNSBOX300.
First you must have

Created the domain which you want to delegate (eg. coventry.example.com)
Configuration
The steps for creating a delegated user account are:
Create a user group with the appropriate administration rights
Create a user account belonging to that group
Test the delegation is working correctly
Create User Group
56
In the NameSurfer interface, navigate to Configuration > Groups, then

Add > New group
Enter a group Name (you may want to use the delegated domain name as the
group name), tick the box Access to zone/host information: Modify, leave the
other boxes un-ticked
USING DNSBOX300 - Configuration Scenarios and Options
Fill in the delegated zone name in Access to zones and type * in

Access to name patterns
Click OK to save the new group
Create New User

Now create a new user and add it to the group that you created above.
5
Navigate to Configuration > User accounts and Add > New user. Enter a user
Name and Password, select the group that you created above and tick all the
Columns to display in zone listings
57
Testing
Finally, test the new user account, by logging into the NameSurfer interface from
another web browser (or close and restart your current browser).
6
When prompted for a username and password, enter the details that you used
for the user above.
When you log in as that user, the Index page should contain only the zone that
has been delegated to that user (coventry.example.com in this example).
Test that you can add and delete hosts.
Check that changes in the zone changelog are attributed to the newly created
user. Navigate to Change log > View change log and click GO (leave the
date range boxes empty to show all changes made today)
Check that the host you added to the delegated zone appears in the
changelog and that the change was made by the restricted user.
Recovering a lost NameSurfer password

NameSurfer user accounts and passwords are normally managed using the Web user
interface, by logging in to NameSurfer using the admin user account. This password is
synchronised from the Appliance.
If you have forgotten the Appliance administrative password then:
1
Power on the box whilst holding down the [LEFT SHIFT] key on your keyboard. Hold
this key until you see the line "boot:" on the screen
At this point you should press the [TAB] key to confirm exactly how the word
"DNSbox" is presented. You need to ensure that when you type DNSbox it
matches the lower/ upper case exactly as it is displayed on screen after pressing
the [TAB] key
At the boot: prompt type DNSbox single
The DNSBOX will now boot into single user mode and should end up on a '#'
prompt. At this point please type the command below;
/home/product/bin/set_root_passwd <new_password>
/home/product/bin/make_passwd_file
58
Then reboot
Network security
Security features of DNSBOX and good network design will help secure your DNS. In an
ideal setup, you will:
Position each DNS server to maximise protection from network firewalls

-
Put DNSBOX300 on an internal admin network, hidden behind a firewall

from other hosts in your network or on the Internet
Put Internet-facing DNSBOX100s in a DMZ
Use secure tunnel options on DNSBOX to secure traffic between your DNS servers
-
Between DNSBOX300 failover pairs
Between DNSBOX300 and DNSBOX100 slaves
Restrict network access to DNSBOX to administrative Users
The network services on the DNSBOX300 can be classified into two groups.
1
The core DNS service should be accessible to wider networks. For example:
-
Remote third party DNS servers (eg Microsoft DNS servers) may need to be
able to do DNS zone transfers from the DNSBOX300.
Access to administrative services such (eg Appliance Interface, SSH, SNMP)

should generally be restricted to Users (network administrative staff) only.
Ports and protocols used by DNSBOX300 are:

For administrative services
80/TCP
1000/TCP
443/TCP
NameSurfer web interface
22/TCP
SSH
161/UDP
SNMP
For DNS traffic
53/TCP
53/UDP
500/UDP
514/UDP
Protocol 50 (ESP)
DNS
DNS
IPsec key exchange daemon*
SysLog
*
Network firewalls and DNSBOX tunnels

DNSBOX300 should generally be deployed on an internal admin network.
If Internet users require access to the DNS management services (web GUI, SSH)
they can do so via a third party VPN
Or you may prefer to set up port forwarding/NAT rules to allow Internet access to
selected admin services
Internet facing DNSBOX100s should be deployed in a DMZ (demilitarised zone).

You may choose to use the second network interface on the DNSBOX100 and
connect it to an internal admin network. You can then disable all admin services
(Web GUI etc) on the Internet facing network interface.
59
Communications between pairs of DNSBOX300s in failover mode are secured with IPsec.
Any firewalls between the pair must be configured to allow UDP port 500 and ESP
protocol traffic between the boxes.
All traffic between the DNSBOX300 and the DNSBOX100 is via the SSH VPN tunnel.
Your internal firewall only needs to allow TCP port 22 and TCP port 443 traffic
between the DNSBOX300 and DNSBOX100.
DNSBOX firewall options

DNSBOX300 has an on-box firewall which allows you to restrict network access to the
appliance. You can limit access to administrative services to defined IP addresses.
1
Navigate to Configure > config network
`
2
Enter in Admin address the IP address(es) you wish to allow access to the
Appliance Interface. This can be entered as a list of IP addresses and/or subnets
This will restrict access to:
60
Appliance Interface
SSH
SNMP
If you set Protect dns admin to Yes, access to the NameSurfer Interface is also
restricted to the same set of IP addresses.
If you set Only secure to Yes, only peers with an IPsec tunnel to the DNSBOX300
can access TCP/UDP port 53.
System Log
DNSBOX300 holds recent system log messages. You can viewed these by going to
system > system log, which will open a new window displaying lines of syslog output.
This window is refreshed periodically or when you click the REFRESH button. The button
ALL will show all the messages in the log, TOP just the latest messages.
The log can fill quickly, losing older messages, so you are recommended to direct the
system log output to a syslog server on your network. Go to configure > config
advanced and enter the IP address or hostname of a syslog server.
SNMP Logging and Alerting

The DNSBOX300 can provide management information via SNMP. The necessary
configuration parameters are on the configure > config advanced page.
Administration over SSH

DNSBOX300 includes a number of command line tools for power users and these can be
accessed by logging into the DNSBOX300 as root using an SSH client. This is disabled by
default, and is enabled on the configure > config advanced page. Three methods of
authentication are provided.
The administrator may authenticate using his SSH key. This is entered on the configure >
sshkeys page. Alternatively, up to three RADIUS servers can be entered on configure
> config auth page, with the necessary parameters. Finally, the administrator may login
as root using the same password as that used to access the GUI as admin.
A detailed guide to the Command Line Interface is available in Appendix C.
61
Remote Administration of BIND

The BIND server within the DNSBOX300 may be administered using RNDC. The key is
displayed on the system > my public key page.
Web Browser Certificate Warning

The web interface of the DNSBOX300 uses Secure Socket Layers (SSL) to encrypt the
traffic between your web browser and the web server running on the DNSBOX300.
When you first log into the web interface, your web browser will warn you that a trusted
certificate authority has not signed the SSL certificate. This is because the default
certificate on the DNSBOX300 is "self signed"
One way to suppress this warning is to install a signed certificate:
1
Go to configure > Ssl certificate and copy the Certificate Signing Request from
CSR to your certificate authority
It will respond with a signed certificate
Paste the signed certificate text into Ssl certificate on the same page
Your DNSBOX300 will check the content of the certificate that you pasted and, if it is
valid, the new certificate will be installed.
Static Routes
You can configure additional static routes to enable access to devices on networks that
would otherwise be inaccessible. You can add new static routes at configure > static
routes. Existing routes are listed here and you can delete them if you need to.
Configuration Restore and Backup

The entire configuration of the DNSBOX300 may be saved as a single file, which may be
subsequently restored to this or another DNSBOX300. Go to configure > restore or
configure > backup and follow the on-screen instructions.
A restore operation completely overwrites the previous configuration and the
DNSBOX300 reboots.
Configuration backups may not be compatible with future or earlier versions of

DNSBOX300 software. You can only be sure a restore will work if the DNSBOX300 being
restored to is running the same version as that the backup was taken from. Where
versions are different, check with your vendor technical support whether the versions are
compatible.
Password
Clicking on configure > password allows you to change the admin password for the
GUI. This will also update the root password for SSH. This is a different password to that
used by NameSurfer, though they are both set to admin on new DNSBOX300 boxes.
62
Current status
You can view information about the system at system page (or system > system
status'), and about the BIND application at system > service status.
Query DNS Server

The DNSBOX300 includes a DNS diagnostic tool SYSTEM > query service which you can
use to query the local or remote DNS servers for resource records.
Upgrades
Software upgrade patches are made available from time to time by ApplianSys. New
software versions are normally released to:
Upgrade BIND or Linux to fix newly discovered security vulnerabilities
Fix known bugs
Enhance existing features or add new ones
If you have a support contract, you will be contacted when updates are released. You
decide whether you wish to receive the upgrade.
To apply an upgrade, store the patch in a folder you can access. Go to system >
upgrade to open the Upgrade the DNSBOX popup window. Click CHOOSE FILE to
select the patch file to be applied and then click INSTALL UPGRADE.
Your web browser will then upload the file from your PC to your DNSBOX which will check
that the file is a full and complete patch, and that it is appropriate to install on your
version of software.
If these tests are successful then all major system services will be shut down and the
update will be installed. If any users are logged into the system when this happens, they
will lose connection, so it may be better to ensure that the system is not in use before
installing an update.
Depending on the speed of your network connection, installation may take several
minutes. You will receive a confirmation message when the upgrade is complete and
the appliance will reboot automatically.
Power Control
The unit can be restarted or powered-down from system > shutdown. The front panel
power button may be disabled with configure > config network > Front button.
63
SECTION 3:
CONFIGURATION REFERENCE
This section describes each of the screens that
can be found in the Appliance Interface.
IN THIS SECTION
DNS Menu
Note: More detailed help on each section can

be found in the online help system. For help
with NameSurfer, please refer to the online help
within the NameSurfer Interface or refer to the
NameSurfer reference guide.
66
Index
66
Zone
68
Reverse zone
72
Reverse zone data
74
Node
75
DHCP configuration
77
User accounts
79
User
80
Group list
82
Group
83
Uploading DNS data
88
Preferences
89
TTLs
90
Add resource record
90
Change Log
91
SYSTEM Menu
93
CONFIGURE Menu
94
CONFIGURATION REFERENCE
65
DNS Menu
Index
On the index page you can select one of several zones for editing. You can also
perform some other operations that apply to NameSurfer as a whole rather than to a
specific zone.
The index page contains the following functions (some may be missing depending on
user permissions and licensing options):
Search
The search entry field on the index page searches through all the zone names on the
index page.
View zones: Forward

This section lists the zones currently maintained using NameSurfer. Each zone name is a
link to the zone page for that zone. These are the "forward" mappings. The
corresponding reverse mappings are listed separately in the "Reverse zones" section.
View zones: Reverse

This section lists all the IN-ADDR.ARPA zones maintained on this server. These are used for
reverse mappings. The reverse mappings are updated automatically by NameSurfer to
keep them consistent with the corresponding forward mappings, so you do not normally
need to edit them by hand.
66
CONFIGURATION REFERENCE - DNS Menu
DHCP
The page is generated from your DHCP server's configuration file and gives you a
representation of your current configuration.
Create zone: Empty zone

Create a new zone to be maintained using NameSurfer. Displays a node page where
you are asked to fill in the mandatory SOA and NS records for the zone. Otherwise the
zone will be empty. You can then use "Add Host" and related operations on the zone
page to create new names in the zone.
Create zone: Small zone

Like "Create zone: Empty zone", but lets you define several hosts (for example www, mail,
ftp) in this zone with the same form.
Create zone: From text file

Create a new zone to be maintained using NameSurfer by uploading the zone data
from a text file in /etc/hosts or RFC1035 master file format.
Create zone: Copy from other name server

Create a new zone to be maintained using NameSurfer by copying it from another
name server using a zone transfer. This operation is particularly useful when migrating an
existing zone from another name server to NameSurfer.
Configuration: Views
A link to the views page, where you can define and modify the NameSurfer DNS views
configuration. NameSurfer DNS views allow the creation of multiple versions of one zone.
The versions are shown differently to different DNS clients and secondary DNS servers.
Configuration: User accounts

A link to the user accounts page, where you can define the authorized NameSurfer users
and their access rights.
Configuration: Groups
User profiles are defined by joining users to groups with various rights and restrictions.
View change log

View a log of recent changes to the DNS data.
Log in as different user

Force NameSurfer to repeat the initial user authentication procedure so that you can
enter a different username and password.
67
Due to restrictions of the HTTP protocol, your WWW browser will typically open a dialog
box displaying an error message "Authorization failed. Retry? OK/Cancel" before asking
for the username and password. This is normal; you should simply select OK. You will
then be given an opportunity to enter the new username and password.
Another restriction is that re-entering the current user name to return to the current user
account will not work. The authentication will fail repeatedly until you enter a different
user name.
Zone
This page displays a summary of the contents of a DNS zone. It lets you browse the
contents of a zone and select one of its domain names for viewing or editing.
The zone page contains the following functions:
Search
You can search for a specific name using the Search: field on the zone page.
NameSurfer will scan the zone and display all names matching the search string.
You can use the * character as a wildcard matching any number of characters in the
name. Searches are case insensitive.
For example, entering ann* might match the hosts annex.acme.com and Anne.Bella.net.
You can also search for IP addresses on the zone page. You can search for a single IP
address or use the * character as a wildcard matching some part of the address. For
example, you may enter search strings like 10.*, 10.*.10.10 or 10.10.10.*.
68
Add: Host
Displays an empty node page for adding information about a new host, such as its IP
address and mail routing information.
Add: Multiple hosts

Like "Add host", but lets you add a whole series of similar hosts. The name entered will be
used for the 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.
Add: Mail route

Displays a form for defining a new name with a set of MX records. This is useful for
defining the routing of mail addressed to a domain name that does not correspond to a
physical host. By entering the special name "*" it is possible to define a set of wildcard
MX records.
Add: Comment
Displays a form for defining a new name with one or more TXT records.
Add: Alias
Displays a form for creating a new alias (in other words, a new domain name with a
CNAME record).
Add: Delegation
Displays a form for delegating a subdomain of the current zone, to make it separately
maintained with a set of name servers of its own.
Add: Service
Displays a form for a new name with a set of SRV records. This resource record set is
intended to specify location of services with load balancing and priorities.
Import names: Upload

Upload a file containing DNS data in a text-based format from the machine running the
web browser.
Export zone: DNS master file

Lists the current zone in the standard RFC1035 master file format. By using the "save"
function of your web browser, you can save the zone data for further processing by
other DNS software that uses the master file format.
69
Export zone: /etc/host file

Lists the current zone A records in the /etc/hosts format. By using the "save" function of
your web browser, you can save the zone data for further processing by other software
that uses this file format.
Delete: Entire zone

After asking for confirmation, deletes the entire zone and all its contents. If you have not
configured your remote secondaries to be automatically updated, you need to remove
the corresponding "secondary" line from the named.boot files of each BIND 4 secondary by
hand (or ask its administrator to do so). For BIND 8 or BIND 9, you need to remove the
corresponding slave zone statement from the named.conf files by hand.
Delete: Hosts matching pattern

See Search delete in "General Functionality" for more detailed information.
Bulk changes: Copy zone

You can create a copy of the zone contents, a new zone, or a new view of the zone.
Change log: View change log

Define the log period by giving the dates in appropriate formats.
Sorting
By pressing the corresponding headers above the table of zone data, you can view the
data sorted either by name or by address.
The zone data

The bulk of the form consists of a table summarizing the contents of the zone, one line
per name.
Name
The DNS name. The name serves as a hypertext link leading to the node page, which
contains complete information about the name.
Icon
An icon illustrating the type of DNS data stored under the name.
Address
The data shown in this column varies depending on the types of records stored under
the name. If the name is a host, the IP address (or addresses) is shown here. If the name
is an alias, the canonical name is shown, etc.
70
MX
A list of mail exchangers (MX records) of the name, from most preferred to least
preferred.
HINFO
The host information (HINFO) records.
Aliases
Known aliases of this name. Only aliases in the same zone are displayed.
RP
The e-mail field of the RP (Responsible Person) record for this name, if any.
Comments
The contents of the name's TXT records, if any. Due to limited screen space, only the first
few characters of each TXT record are displayed.
Private
The private comment data (HTXT and HTML records) of the name, if any. Due to limited
screen space, only the first few characters of each HTXT record is displayed. HTML
records are displayed in full.
71
Reverse zone
This page displays a summary of the contents of a DNS reverse zone. It lets you browse
the contents of a reverse zone and select its domain names for viewing or editing.
The reverse zone page contains the following functions:
Search
The Search feature works in a similar way to the one on the Zones pages.
Add: Pointer
Displays an empty node page for adding information about a new pointer; that is, a
reverse map name and the domain name the reverse map points to.
Add: Multiple Pointers

Like "Add: Pointer", but lets you add a whole series of pointers. The pointer name
entered will be used for the first pointer. Subsequent pointer names will get a numerical
suffix (or an existing suffix will be incremented). This means that you can, for example,
add nomachine.foo.test for every PTR record not pointing to any existing machine in your
zone.
The pointer name entered will be used for the first pointer.
72
Add: Multiple Delegations

Like "Add: Multiple PTRs", but lets you add a series of subdomain delegations. The
number entered as name will be used for the first delegation, and the subsequent
delegation names will have the first label incremented. This means that you can, for
example, delegate reverse mapping for zones in range 17.0.10.in-addr.arpa - 28.0.10.in-addr.arpa
to another name server, or to the same name server if you wish to maintain these zones
separately from 0.10.in-addr.arpa.
Add: Alias
Displays a form for creating a new alias (in other words, a new domain name with a
CNAME record).
Add: Delegation
Displays a form for delegating a subdomain of the current zone to maintain it separately,
with a set of name servers of its own.
Add: Service
Displays a form for a new name with a set of SRV records. This resource record set is
intended to specify the location of services with load balancing and priorities.
Import names: Upload

Uploads a file containing DNS data in a text-based format from the machine running the
web browser.
Export zone: DNS master file

Lists the current zone in the standard RFC1035 master file format. By using the "save"
function of your web browser, you can save the zone data for further processing by
other DNS software that uses the master file format.
Delete: Entire zone

After asking for confirmation, deletes the entire zone and all its contents. If you have not
configured your remote secondaries to be automatically updated, you need to remove
the corresponding "secondary" line from the named.boot files of each BIND 4 secondary by
hand (or ask its administrator to do so). For BIND 8 and BIND 9, you need to remove the
corresponding slave zone statement from the named.conf files by hand.
Search Delete (Delete: Hosts matching pattern)

You can search for a specific name to be deleted using the Hosts matching pattern field
from the menu on the zone page. NameSurfer will scan the zone and display all names
matching the search string. You may choose the entries you want to delete from the list
displayed by checking the checkboxes for these entries, and delete them in a single
transaction.
73
You can use the * character as a wildcard matching any number of characters in the
name. Searches are case insensitive.
For example, entering ann* might match the hosts annex.acme.com and Anne.Bella.net.
You can also search for IP addresses on the zone page. You can search for a single IP
address or use the * character as a wildcard matching some part of the address. For
example, you may enter search strings like 10.*, 10.*.10.10 or 10.10.10.*.
View change log

Enables you to view a log of recent changes to the DNS data.
Reverse zone data

The bulk of the form consists of a table summarizing the contents of the zone, one line
per name.
The table may contain some or all of the following columns, depending on the
preferences settings.
Reverse map name

The name of the zone in its reverse mapping form. The name serves as a hypertext link
leading to the node page which contains complete information about the name.
Icon
This is an icon illustrating the type of DNS data stored under the name.
mouse cursor over the icon opens a tooltip with more information.
Holding your
Name
The DNS name.
IP Address
The reverse map domain name contains the IP address of the domain name it points to
in reverse order. The IP address field contains the IP address the reverse map is
corresponding to.
74
Node
The node page displays all the DNS data belonging to a domain name, and lets you
make changes to the data. It is also used for entering initial data when creating a new
name.
The page title

The page title changes with the type of data stored under the name. For example, a
name that has an IP address associated with it is considered a "Host", while a name with
only an MX record is called a "Mail route".
The name entry field

The domain name whose data is being displayed or entered is shown in an editable text
entry field. If you are creating a new name, the field is empty and you need to fill it in
with a new domain name. The name may be given either in relative or fully qualified
form (for example, fred or fred.namesurfer.com).
When editing an existing entity, this field can be edited to rename the entity.
Data fields
Following the name entry field, you will find a number of entry fields displaying the
current DNS data for the name, or allowing the entry of new data. Usually, there is one
field for each resource record attached to the name.
If the title preceding the entry field is a hypertext link, it leads to additional online help
explaining the resource record you are looking at.
75
Most of the resource record types are displayed as text entry fields. To remove a record,
simply clear the field (for example, by selecting the whole text using the mouse and
pressing the delete key), and then submit the form using the OK button.
Submit buttons:
At the bottom of the form, there is a set of submit buttons.
OK - Accepts the current contents of the form and makes any changes permanent. In
some cases, you may be prompted for additional information. Exits the form.
Cancel - Exits the form without making any changes.
Remove - Deletes the domain name completely, together with all of its data. (Note: The
first address of each zone is the root, which cannot be removed.)
76
DHCP configuration
On this page you can see a representation of your current configuration, read from your
DHCP server's configuration file.
You can navigate through the configuration file by clicking on the links that represent
different subnets, groups, hosts, etc. At the top of the page your current location is
displayed.
If you belong to a group which has modification rights to dhcp, next to each parameter
there is a button labelled REMOVE that you can use to remove that particular
parameter. To remove containers, first click on the container name, then press the
REMOVE button.
The View current leases link in the Options section will take you to a page where the
leases already assigned by the DHCP server are displayed. Only the dynamically
allocated addresses are listed here.
The Undo changes link in the Administration section lets you view the changelog, and
undo some of the changes administrators have made to the configuration file.
To add more declarations to the configuration file, use one of the links on the left, under
the heading Add. After the addition of a new declaration the program requests the
DHCP server to check the new configuration file. If there are no problems, the file is
changed. Otherwise, the program asks for confirmation. However, the server will not be
restarted automatically.
Whenever you want the changes you made to be in effect, the dhcpd server must be
restarted manually. To do this, go to the Process administration' page by selecting
Process administration from under the Dhcp Daemon heading and click the last item
of the command links.
77
Process Administration
With this page you can start or stop the DHCP server.
If the server doesn't start up, that is, the message at the bottom of the page still reads
"not running", you have to check the messages from the server for errors.
If the server starts up, it will still display some messages, but the link at the bottom of the
page will change to "stop".
Selecting a new declaration

To make the building of the configuration file easier, NameSurfer gives you all the
declarations the DHCP server accepts. They are grouped in three categories.
We suggest that you choose options from the first, basic group only. The declarations in
the advanced category are usually used only in very special network setups.
Clicking the question mark next to a declaration name will show a description of that
declaration, taken from the manual of the DHCP server.
Clicking the name of the declaration will show the arguments that particular declaration
needs. Filling these in and pressing OK will take you back to the main page, provided
that the dhcp server accepted the updated configuration.
The input fields for the arguments of the declaration are arranged in a table, one
argument in each row. If there are multiple columns in a row, don't forget to check the
box next to the input field you filled in.
Configuration file errors

The new declaration you have just created did not pass the test of the DHCP server. It's
now safe to click "Keep" towards the end of the page, and then try to add the correct
declaration.
If the offending is displayed as a link, you may try to click it. It should take you to a page
where you can change the arguments of the declaration. It is also safe to use the
browser's Back button for that purpose.
If you know that the new declaration is correct you can ignore the message, and
update the file anyway. This is needed when you add a new empty "shared-network"
declaration.
78
The dhcpd leases file

The Internet Software Consortium DHCP Server keeps a persisten database of leases that
it has assigned. Every time a lease is acquired, renewed or released, its new value is
recorded at the end of the lease file. Thus if more than one declarations appear for a
given lease, the last one in the file is the current one.
The leases are sorted by default by the IP address. To change the order, you can click
on the header of each column.
A warning from ISC:

There is a window of vulnerability where if the dhcpd process is killed or the system
crashes after the old lease database has been renamed but before the new one has
been moved into place, there will be no dhcpd.leases file. In this case, dhcpd will refuse
to start, and will require manual intervention. DO NOT simply create a new lease file
when this happens - if you do, you will lose all your old bindings, and chaos will ensue.
Instead, rename dhcpd.leases~ to dhcpd.leases, restoring the old, valid lease file, and
then start dhcpd. This guarantees that a valid lease file will be restored.
See Appendix B for more advanced DHCP configuration.
User accounts
The user accounts page displays the currently defined NameSurfer user accounts.
NameSurfer supports simultaneous access by multiple users. Each user can be assigned
a separate set of qualities which make up his / her profile.
Apart from the "admin" user, these accounts are unique to the NameSurfer interface. A
NameSurfer user account gives the user permission to examine and possibly change the
DNS data maintained using NameSurfer. The NameSurfer user account does not give
the user any other kind of access to the DNSBOX.
Each account name is a link to the user page for that user.
To add a new user account, select New user. This will bring up a form for creating a
new user.
79
User
On the user page, you can add, delete, or change a NameSurfer user account.
Each user account has the following attributes:
Name
The account name, for example, "john".
Password
The password to be used when logging into the NameSurfer interface using a web
browser. The password should be chosen with care similar to that of a UNIX account.
The password will be echoed as a string of asterisks "*". Users can change their own
passwords at any time by editing this field.
Groups
The Groups section displays all the user groups currently existing in NameSurfer. A tick in
a box adds the user account to a group.
80

Ticks in the fields have the following effects:
Address: shows the zone IP address on the zone page.
Aliases: shows the CNAME records on the zone page.
HINFO: shows the HINFO column on the zone page.
MX: shows the MX column on the zone page.
Comments: shows the Comments column on the zone page.
RP: shows the RP column on the zone page.
SRV: shows the SRV column on the zone page.
Private: shows the Private column on the zone page.
Columns to display in index listings

Ticks in the fields have the following effects:
Comments: shows the Comments column on the zone page.
Private: shows the Private column on the zone page.
Entry fields to display for new hosts

Defines the fields to be shown on the Define new host page.
Additional fields to display when listing hosts in DHCP and

Additional fields to display when listing groups in DHCP
It is possible to see some of the contents of hosts and groups when they are displayed in
DHCP configuration listings. Select the additional fields you want to see.
Submit buttons
After entering new data for a user account, press the OK button to perform the change.
If you wish to exit the form without making any changes, press CANCEL. If you wish to
remove a user, press REMOVE.
81
Group list
The group list page displays the currently defined NameSurfer user - both end user and
superuser (or administrator) - groups.
Each group can be assigned different privileges and restrictions. A user gets these
privileges and restrictions (or rights, for short) when the administrator adds the user to one
or several groups.
By default, a user only has the right to
change his/her password
define the columns to be displayed in the zone listing
define the columns to be displayed in the index listing
define the entry fields to be displayed for new hosts.
The group can have access to the following types of information:

Zone/host information
User information
Group information
DHCP information.
NameSurfer supports simultaneous access by multiple groups. For further information

about the rights, please study a group in detail.
Each group name is a link to the group page for that group.
To create a new group, click New group. This will bring up an empty group page to fill
in.
82
Group
Introduction
In NameSurfer all access permissions are given to specific user groups and users
permissions are set according to the group they belong to.
For example,
Group 1 have access to zone a.x
Group 2 have access to zone b.x
User 1 is a member of both Group 1 and Group 2 and thus he/she has access to a.x and
b.x.
Setting up groups
The DNSBOX comes with the admin user in a default group "admingroup" and one user
in this group. This default user is capable of creating new groups and users, and we
recommend that a personal user account is created for each administrator even if they
all belong to the "admingroup".
When access restrictions are needed, an administrator must create a group and assign
proper access restrictions for this group. After that, users can be assigned to this group
(on the User account page) for new restrictions to take effect.
How the Group page works

On the Group page, you can add or delete a NameSurfer user group, or change its
attributes. A group consists of a specified set of rights, as described below:
83
Attributes
Name
The name of the group, for example, admingroup. No white spaces are allowed in the
names.
Description
Space for a description of the group.
Allow WWW access only from IP address range(s):

For additional security the DNSBOX uses a local proxy to encrypt access to the
NameSurfer interface, this field should therefore not be used.
Using this field will result in a loss of access to the DNS interface.
Access to various information types

A group can have access to the information types listed below:
Zone/host information: Gives the right to create, modify and delete zones and hosts
(Modify), or just to view them.
User information: Gives the right either to create, modify and delete user accounts
(Modify), or just to view them. See also Group information below.
Group information: Gives the right either to create, modify and delete groups (Modify),
or just to view them.
Giving group members modification rights to Group information gives them Superuser
rights in this aspect, since with these rights, they can include themselves in the group of
Administrators. Meanwhile, if group members do not have modification rights to Group
information, they can join users to only those groups of which they are members
themselves.
DHCP information: Checking the Modify or View box here produces the DHCP link on the
Index page. A checked Modify box gives the group member the right to modify DHCP
information and displays an OK button on the DHCP pages. If only the View box is
checked, the group member has no modification rights and no OK button on the DHCP
pages, but has access to the DHCP pages through the link.
84
Access to specific record type(s)

When a group is created, by default its members have rights to modify all record types.
This is indicated by ticks in all boxes. If access needs to be restricted, remove ticks in
appropriate boxes.
Access to zone(s):
Definition of the zones to which the group members have access, if the access to
zone/host information has been given. Fill in the appropriate zone names or name
patterns to define the zones to which the group members have access. Asterisk (*) can
be used as wildcard. If the field is empty, the group members have access to no zones.
A sole asterisk in the field gives access to all zones.
In addition to the views available to the user, the values given here also limit the names
the user may give to new zones: they need to comply with the given pattern.
Access to reverse zone(s):

Gives the group members rights to one or several reverse zones. Fill in the appropriate
reverse zone names or name patterns to define the reverse zones to which the group
members have access. Asterisk (*) can be used as wildcard. If the field is empty, the
group members have access to no reverse zones. A sole asterisk in the field gives access
to all reverse zones.
Access to name(s)
Gives the group members the right to names containing the given name pattern in a
zone or a DNS view, and restricts the naming of new nodes by that same name pattern.
Fill in the appropriate name pattern. Asterisk (*) can be used as wildcard. If the field is
empty, the group members have access to no names. A sole asterisk in the field gives
access to all names.
Access to IP address range(s)

This field may be used to give access to the set of IP addresses whose reverse mappings
are updated automatically when the user adds or removes hosts.
Reverse mappings are updated automatically whenever A records are added or
deleted to forward zones, provided that the A records fall within the given address
range (or one of the ranges).
Multiple address ranges may be entered by pressing the OK button after entering the
first one. If the fields are left blank, any reverse mapping under the authority of
NameSurfer may be updated automatically as a result of editing done by this user.
If the user is permitted to access and modify reverse zones as well as forward zones,
these restrictions apply to the changes the user is allowed to make.
85
Access to IPv6 address range(s)

The same as Access to IP address ranges above but concerning IPv6 (AAAA) addresses.
Allow A6 prefix
The use of A6 prefixes can be allowed by entering the relevant prefix(es) in this field. If
the field is empty, no A6 prefixes are allowed. A sole asterisk in the field allows the use of
all A6 prefixes.
Access to DHCP subnet in IP address range

With this function, it is possible to give a DHCP administrator access to DHCP subnets. If
these fields contain IP addresses, the DHCP administrator will be able to edit subnets
where the network address falls in this IP address range. If the fields are empty, no
access is given.
Host template
The name of a host to use as a template when creating new hosts. New hosts will be
given default initial data similar to that of the given template host. This is particularly
useful as a way of giving each new host a standard set of MX records.
Any existing host can be used as a template, but it is a good idea to create one or more
dedicated "template hosts" that do not correspond to any physical machine. The
template hosts can be created in any zone maintained from the NameSurfer interface.
A large site may even want to create a separate zone just for templates.
Any A records of the template host are ignored. Instead, the IP address of the new host
is determined by the usual IP address allocation mechanism.
If the host template setting is not used, or the template host does not exist, new hosts
have no default data.
Zone template
The name of a zone to use as a template when creating new zones. New zones will be
given default initial data similar to that of the given template zone. This is particularly
useful as a way of giving each new zone a standard set of MX records and NS records.
Any existing zone can be used as a template, but you can also create one or more
dedicated "template zones".
If the zone template setting is not used, or the template zone does not exist, new zones
have no default data.
86
Allocate IP addresses from range(s)

Defines a range of IP addresses for automatic allocation. When displaying the form for
adding a new host to the DNS, NameSurfer will automatically search this range (or these
ranges) for unused addresses. The first unused address will be offered as a default for
the host address field. If the fields are left blank, no automatic address allocation will
take place.
Submit buttons
After entering new data for a group, press the OK button to perform the change. If you
wish to exit the form without making any changes, press CANCEL. If you wish to remove
a group, press REMOVE.
87
Uploading DNS data

The upload form lets you upload DNS data in a text-based file format into NameSurfer.
The file to upload must reside on the machine where you are running your web browser.
Uploading a new zone

When the upload function is entered through the Create zone: From text file menu
option on the index page, it will attempt to create a new zone from the uploaded data.
The data must be in the DNS master file format (as defined in RFC1035) and must form a
complete zone. In particular, it must contain an SOA record.
Uploading into an existing zone

When the upload function is entered through the Import names: Upload link on the
zone page, it will add the uploaded data to the current zone.
Both the UNIX /etc/hosts format and the standard RFC1035 master file format are
supported.
All the resource records in the file must belong to the current zone. Each resource
record in the file will be added to the current zone. No data is removed, so careless use
may lead to duplicate records.
This function is intended for amending an existing zone with some new records from a
partial master file. Note that when uploading a DNS master file, the file may not contain
an SOA record, because adding a SOA to an existing zone would cause it to have two
SOA records - an illegal situation.
88
Preferences
The preference page is visible for users who have no modification rights to user accounts
other than their own. On the preference page, you can set certain site-wide
preferences:

Determines the format of the zone page display. The default is to display the address
and MX columns only. Sites that use HINFO, TXT, or RP records may want to enable those
columns also.

Determines the format of the index page display. The default is to display zone names
only. You can also choose to display TXT record and private records (HTXT and HTML
records) on the index page.

When a new host is created, the user is asked to enter a host name and some initial DNS
data on the node page. This setting determines which kinds of records the user will be
prompted for. It should be set to include those record types that are generally used at
your site. The default is to ask for A and MX records only.
89
TTLs
The TTL page displays the TTL (time-to-live) values for the various kinds of records
attached to a domain name.
By editing the values, you can change the TTLs of one or more record types.
Usually there is no need to change the TTL of your resource records.
reasonable default value in the SOA, and it will be used for all new records.
Just set a
One situation where you may want to change the TTL is when you know in advance that
there will be a change to DNS data; for example, that the IP address of a machine will
change. In this case, it is useful to decrease the TTL of that machine's A record well in
advance so that the old data will expire more quickly from caching name servers when
the change actually takes place. Remember to restore the original TTL value after the
change.
Add resource record

The Add RR (resource record) form lets you add any kind of resource record to the
current DNS name.
Select a Record Type using the selector, and press OK. You will then be directed to a
node page containing all the existing records of the name, as well as a new, empty
entry field (or other means of data entry) for the new record.
A list of supported resource record types appears in the table of contents.
It is not possible to add a CNAME record to a name with other records, or vice versa.
90
Change Log
NameSurfer keeps a log of all changes made to your DNS data. Using the change log :
View change log, you can list the changes made to the DNS data on any given date or
range of dates.
The change log shows information on actions taken by running a command on the
index page, and thus, for example, additions and deletions of zones are shown. The
change log for an individual zone shows the changes made to that particular zone.
The dates can be entered in a variety of formats. If you leave a date entry field empty,
it is interpreted as "today". The range is inclusive.
When you press the GO button, NameSurfer searches its log files for the changes made
during the given date interval, and displays them. If the interval is large, this can take a
substantial length of time and generate a long page.
On the resulting form, the changes are grouped into "transactions" consisting of changes
that were originally made as a single operation. Automatic updates to reverse
mappings appear as transactions of their own, immediately after the transaction that
affected the corresponding forward mapping.
For each transaction, NameSurfer shows:
The name of the zone that was updated
The account name of the user requesting the change. If the change was made
using the command line interface, the word "command-line" will appear in place
of the account name. For automatic updates to reverse mappings, the word
"auto-reverse" will appear in place of the account name.
The time at which the update took place
A list of resource records added or deleted, in a format similar to RFC1035 master

file syntax.
An "Undo" check button.
You can undo one or more transactions by checking their Undo check buttons and
pressing the UNDO SELECTED CHANGES button. The undo operation can fail if the
change has already been undone, or if there have been subsequent changes to the
same records.
91
Automatic updates to reverse mappings cannot be undone separately, but they will be
undone automatically as part of undoing the corresponding forward mapping update.
The changes that are made to the DNS data as a result of an undo operation are
logged just like any other change. This makes it possible to redo a change that has
been undone.
It may not be possible to retrieve very old log information because NameSurfer
automatically discards old change log data after 90 days. However this you can
change this to be a shorter or longer period of time.
92
SYSTEM Menu
Menu Item
Options
Description
DNS Server Stats
Overview of incoming and outgoing queries and

requests. Refreshes every 30 seconds
Server's VPN Key
Public key for use on other linked servers in secure

IPsec connections
Server's RNDC Key
RNDC key used to control your named service
System Status
Service Status
My Public Key
Secure Servers
Secure Servers
Lists servers linked to this DNSBOX
Description
Name to help identify server link
Enabled
Toggle for enabling or disabling the connection
IP Address
IP address of server connecting to
VPN Enabled
Activates the VPN connection
Compression Enabled
Compress data transmitted over the connection
Public Key
Public key of other server in the connection
Auto Configure
Enable REMSEC automatic zone configuration of

linked slave
Enter Query
Name of the resource record to look up
Server Address
Name or IP address of DNS server to query
Service to Query
Choose whether to query BIND or NameSurfer
Query Type
Indicates the type of query you can perform
System Log
System Log
Lists events on the appliance
Upgrade
Firmware Upgrade
Shutdown/reboot the
DNSBOX
Select firmware upgrade file and install it
Add Secure
Server
Query Service
Shutdown
Shut down the DNSBOX or restart it
CONFIGURATION REFERENCE - SYSTEM Menu
93
CONFIGURE Menu
Menu Item
Options
Description
Summary
Network/Advanced
Display of network settings
Host Name
Appliance hostname
Ethernet Mode
Set to auto-negotiate or 100BaseT
IP Address
IP address of this appliance
Netmask
The subnet mask of this server
Default Route
Time Zone
Router providing Internet access

Network Time Protocol server used to keep the
appliance clock accurate
The time zone in which the appliance is used
Admin Address
Restrict network access to appliance admin
Protect DNS Admin
Restrict network access to DNS administration
DHCP Services
Enable on-box DHCP server
Only Secure
Allows only servers with secure link to connect
Front Button
Option to disable power button on front panel
SSH Support
Allow root users SSH access to console UI
Syslog Server
Point syslog output to external syslog server
Failover Mode
Set unit as failover master or mirror, or standalone
Failover Password
Password for authenticating with failover service
Failover Master
Identify failover master if this server is failover mirror
Refresh Interval
Interval for copying data to mirror
SNMP Community
Name of community to route SNMP output to
SNMP System Name
Identify DNSBOX to SNMP
SNMP System Location
The location of DNSBOX reported to SNMP
SNMP System Contact
Details of person responsible for the DNSBOX
Config network
Config
advanced
94
Time Server
CONFIGURATION REFERENCE - CONFIGURE Menu
Menu Item
Options
Description
RADIUS Authentication
Authenticate users against RADIUS server(s)
Listed RADIUS Users
Space separated list of allowed RADIUS users
RADIUS Server
Hostname/ip of server for user authentication
RADIUS Server Secret
Key for encryption of RADIUS password
SSL certificate
Custom SSL certificate
SSL certificate for this appliance
SSL keys
Authorized keys
SSH public key for authenticating SSH
Password
Password
Reset the administrators password
Backup
Backup System
Create a backup file of the system configuration
Config auth
Restore
Static routes
Restore System
Restore system configuration backup
Description
Identify static route
Subnet
IP address of the subnet for this static route
Netmask
IP address of the netmask for this static route
Gateway
IP address of the router connecting to the subnet
CONFIGURATION REFERENCE - CONFIGURE Menu
95
SECTION 4:
FREQUENTLY ASKED QUESTIONS
This section helps you find answers to the most
common questions asked about DNSBOX as
well as advice for potential problems.
IN THIS SECTION
98
Troubleshooting
99
Hardware
100
FREQUENTLY ASKED QUESTIONS
97
How do I log in to the administration systems?
For the ApplianSys Interface, enter the following into your browser address bar, where
dnsbox300.example.com is the hostname or IP address you have assigned the appliance:
http://dnsbox300.example.com (redirects
to secure admin)
To go straight to the NameSurfer Interface you should go to:

https://dnsbox300.example.com/
The NameSurfer Interface initially has the default username admin and default
password (admin).
The admin passwords for the Appliance Interface and the NameSurfer Interface are
both maintained from the Appliance interface.
Can I connect to the appliance using a serial cable to perform local

administration?
Yes, as mentioned in the Quick Start Guide, a serial connection can be established by
connecting a suitable 9-pin null-modem cable to COM1 on the back of the appliance.
Terminal software (minicom or cu in *nix, or Tera Term in Windows are all ideal) should
be set to 38400 bps with 8 data bits, no parity and 1 stop bit (8N1).
Is there an SSH server on the appliance for remote administration?

Yes, but it is disabled by default. To enable it, change the SSH support option in the
CONFIGURE > Config advanced menu to Yes. No reboot is necessary for this change
to take effect.
98
FREQUENTLY ASKED QUESTIONS - Appliance Management
Troubleshooting
I cant connect to the DNSBOX Appliance Interface
Check the basic network configuration by attaching a monitor and keyboard, or by
using a serial connection and terminal program, to the DNSBOX and logging into the
console interface and running console_ui. The most important settings to check are
the DNSBOXs IP address, subnet mask and default gateway; with these items correctly
configured you should be able to access the Appliance Interface.
I have changed the administrator password in the Appliance Interface, but

now I cant access the NameSurfer Interface
The user list for the NameSurfer Interface is kept separately from the user list for the
Appliance Interface. This is to allow for multiple administrators to be defined in
NameSurfer. Changing the password for the admin user on one Interface will not
change it on the other.
I have created a zone but cannot see it on the DNSBOX100

You may have forgotten to enable auto configure on the secure server for that slave.
After enabling auto configure you will need to wait up to five minutes for any changes to
be synchronised. If you are still have problems look in your system log for messages
labelled ZoneCast or REMSEC.
I have configured an IPsec connection, but the traffic light indicator still shows
red and the connection doesnt work
Ensure both appliances are either on the same network, are on public addresses, or are
in some other configuration that does not involve NAT (network address translation)
between the hosts. If NAT is involved, then the secure server link will fail due to packets
being modified as part of the NAT procedure.
My DHCP configuration wont start, whats wrong?

A valid DHCP configuration must at the very least have a valid DDNS update style
definition, and a valid subnet definition (matching the interface on the appliance).
Once these conditions are met, the DHCP server will start.
Syslog is being flooded by DHCP messages saying the service cant start
If CONFIGURE > Config network > DHCP services is enabled, the software watchdog in
the DNSBOX300 will regularly check the DHCP server daemon, and attempt to start it if it is
down.
If you have enabled DHCP services but failed to configure DHCP correctly, the server will
fail to start. It will report this to Syslog until corrected or disabled.
FREQUENTLY ASKED QUESTIONS - Troubleshooting
99
How can I see the logs?

The easiest way to view recent log output is through the System > system log option
on the Appliance Interface.
Ideally you should redirect syslog to a syslog server. Enter the IP address of your syslog
server on the system log page. No reboot should be necessary before output
commences.
If you dont have a syslog server available to capture output, its extremely easy to set
one up on your workstation to capture the messages. There are many free syslog servers
available, for most operating systems.
A free and simple Windows syslog server is 3csyslog, by 3Com Corporation. It is available
from www.3com.com.
Hardware
What is the power consumption and input voltage?
The maximum draw is 220W for DNSBOX330/320 models and 80W for DNSBOX310/050. The
exact draw will depend on exact usage and specification of components used. 150W is
typical for DNSBOX300 and 50W on DNSBOX050.
DNSBOX works with 110-240 volts.
What type of power cord does DNSBOX use?

DNSBOX330/320 uses an IEC C13 (Kettle) cord, which is standard for most computer
power supplies.
DNSBOX310 and DNSBOX050 may be supplied with an IEC C13 (Kettle), IEC C5 (Clover
Leaf) or figure-of-8 cord, depending on the model of power supply in use at the time.
What are the weight and dimensions of DNSBOX330/320?

Unit: 19in (482.6mm) x 1.75in (44.45mm) x 17in (432mm)
Packaging: 23.5in (600mm) x 23.5in (600mm) x 6in (150mm)
Weight: 8kg
What are the weight and dimensions of DNSBOX310?

Unit: 19in (482.6mm) x 1.75in (44.45mm) x 10in (254mm)
Packaging: 22.4in (570mm) x 14.2in (360mm) x 5.5in (140mm)
Weight: 5kg
What are the weight and dimensions of DNSBOX050?
100
Unit: 12in (305mm) x 2.1in (54mm) x 11in (279mm)
Packaging: 6in (152mm) x 16in (406mm) x 14in (355mm)
Weight: 5kg
FREQUENTLY ASKED QUESTIONS - Hardware
APPENDICES
APPENDICES

Standard DNS Records
A records
A (Address) records define the IP addresses of hosts and other network devices.
The IP addresses are entered in the usual dotted quad notation, for example,
192.168.1.2.
Most hosts have a single IP address and therefore a single A record.
Routers (or hosts acting as routers) have multiple IP addresses, and are commonly given
more than one A record. Alternatively, each interface of the router can be given a
name of its own, each with one A record.
NameSurfer can be set up to allocate IP addresses automatically when new hosts are
added to the DNS.
By default, whenever an A record is added or deleted, NameSurfer will automatically
attempt to add or delete the corresponding reverse mapping. You can choose not to
create the reverse map automatically by unchecking the checkbox controlling
automatic reverse map creation.
AAAA records
AAAA (IPv6 address) records define the IPv6 addresses of hosts and other network
devices that use the IPv6 protocol.
The addresses may be entered in any of the formats defined in RFC1884. For example,
1080:0:0:0:8:800:200C:417A is a valid IPv6 address.
Unlike the case of IPv4 A records and IPv6 A6 records, NameSurfer does not allocate IPv6
addresses automatically, nor does it automatically update their reverse mappings.
A6 records
A6 (IPv6 Address with aggregation and renumbering support) records define the IP
addresses part of hosts and other network devices.
The IPv6 addresses are entered in the form prefix_len suffix prefix_name, where
prefix_len is prefix length - decimal number between 0 and 128 inclusive, suffix is
address suffix in RFC 2373 form, prefix_name is a prefix name if prefix length is not zero.
For example 28 0:0001:CA00:: C.ISP.NET.. Most hosts have a single IPv6 address
and therefore a single A6 record.
Routers (or hosts acting as routers) have multiple IPv6 addresses, and are commonly
given more than one A6 record. Alternatively, each interface of the router can be given
a name of its own, each with one A6 record.
By default, whenever an A record is added or deleted, NameSurfer will automatically
attempt to add or delete the corresponding reverse mapping. You can choose not to
create the reverse map automatically by unchecking the checkbox controlling
automatic reverse map creation.
101
CNAME records
A domain name with a CNAME (Canonical Name) record acts as an alias to another
domain name, the canonical name.
Because the canonical name and its alias can belong to different zones, the CNAME
record must always be entered as a fully qualified domain name. NameSurfer checks
that the canonical name really is an existing domain name, and issues a warning if the
name does not exist.
CNAME records are useful for setting up logical names for network services so that they
can be easily relocated to a different physical host. For example, it is common to define
www.company.com as an alias for the machine running the company's web server.
The DNS protocol places a number of restrictions on the use of CNAME records:
A name with a CNAME record may not have any other records
Other records that "point" to domain names, such as NS, MX and PTR records,
may not point to an alias. Instead, they should point directly to the canonical
name
DNAME records
A domain name with a DNAME (Non-Terminal DNS Name Redirection) record acts as an
alias to the entire DNS subtree (as opposed to CNAME alias which acts like single host
alias).
Because the domain name and DNS subtree it refers to can belong to different zones,
the DNAME record must always be entered as a fully qualified domain name.
NameSurfer checks that the subtree really is an existing domain name, and issues a
warning if the name does not exist.
DNAME records are useful in conjunction with IPv6 A6 resource record and binary labels.
It is assumed that all the delegations made for IPv6 reverse maps are made using
DNAMEs. For example if ISP A.NET delegates part of its reverse map to the client
X.EXAMPLE it does it like \[x11/8].IP6.A.NET DNAME IP6.X.EXAMPLE. The DNS
protocol places a number of restrictions on the use of DNAME records:
A name with a DNAME record may have other records (but CNAME or other
DNAME)
There should be no other records in the same zone which are name descendants
NameSurfer checks these restrictions and does not allow you to create resource records
which break this rule.
HINFO records
The HINFO (Host INFOrmation) record can be used to identify the CPU type and
operating system of a host.
MX records
MX (Mail eXchanger) records define where e-mail addressed to a given domain name
gets delivered.
MX records make it possible to deliver e-mail addressed to hosts that do not themselves
run mail software, to hosts that are not connected to the network (and therefore lack A
102
records), or even to mail addresses that do not correspond to any physical machine at
all.
The MX records of a host should list one or more "mail exchanger" (MX) hosts that are
willing to receive mail on behalf of that host.
If there are no predefined MX alternatives, MX records are entered using a set of text
entry fields. Each field should contain the name of one mail exchanger, in order from
most preferred to least preferred. If there are more entry fields than mail exchanger
hosts, the leftover fields should be left blank.
The first (most preferred) mail exchanger host should be the one where the final delivery
of mail will take place (in other words, the server machine containing the users'
mailboxes). The other MXs will be used only as backups in the case when the most
preferred MX is not responding. Typically, these "fallback MXs" will simply store the mail
temporarily and re-send it to the most preferred MX when it comes back to life.
Each mail exchanger is accompanied by a preference value. This preference value
should be a positive integer and indicates the mail exchanger's priority. The most
preferred mail exchanger should have the lowest preference value.
It is recommended that you define MX records for all your hosts. If you do this, you
should also make sure that the mail server listed in your first MX record is correctly
configured to accept mail addressed to other machines.
NameSurfer checks that the mail exchange really is an existing domain name, and
issues a warning if the name does not exist.
NS records
NS (Name Server) records are used to define a set of authoritative name servers for a
zone. These are the servers that will be consulted by "outside" resolvers and nonauthoritative name servers that want to look up information inside the zone.
There are two copies of the NS records for each zone: one in the root node of the zone
itself, and another at the point of delegation in the parent zone. These two copies must
be kept synchronized manually. Whenever changes are made to the NS records of a
zone, the administrator of the parent domain should be notified so that he can make
the corresponding changes at the delegation point, too.
PTR records
A PTR (Pointer) record serves as a pointer to a different place in the DNS namespace.
PTR records are used in the IN-ADDR.ARPA domain to define reverse mappings. They are
not commonly used in other domains.
Because a PTR record points to a different zone from the one it resides in, it must be
entered as a fully qualified domain name.
103
RP records
The RP (Responsible Person) record can be used to identify the person responsible for a
given name in the DNS. For example, it may be used to identify the person responsible
for the operation of a given host, or the administrator of a subdomain.
The use of RP records is optional.
The RP record consists of two fields. The first field contains the e-mail address of the
responsible person. NameSurfer displays this address in the usual Internet user@dom.ain
format.
The second field may optionally be used to specify the location of additional, freeformat textual information about the responsible person. If used, it should contain a
domain name under which the additional information is stored in the form of one or
more TXT records. This domain name and its TXT records must to be created separately
(using the Add: Comment link on the zone page). If there is no need for additional
information, the field should contain the root domain ".". This is given as the default.
In places where the space available for display of RP data is limited, such as the zone
page, NameSurfer displays only the first (e-mail) field.
The RP record itself is entered on the node page of the domain name whose responsible
person is being defined.
The SOA record

The SOA (Start Of Authority) record marks the top node of a zone. Each zone has
exactly one SOA record.
The SOA record contains various administrative information which applies to the zone as
a whole. It consists of the following fields (the names in parentheses are the standard
field names as defined in RFC1035):
Master NS (MNAME)
The full domain name of the name server where the master copy of the zone data is
maintained. For internal zones requiring DDNS updates from a DHCP server this field
should contain the name of the DNSBOX300
For external zones any of the DNSBOX100 slaves may be used.
Admin e-mail (RNAME)

The e-mail address of the administrator responsible for this zone. This must be an Internetstyle e-mail address (user@dom.ain).
Serial # (SERIAL)
The current serial number for the zone. The serial number is used by secondary name
servers to determine whether there have been recent changes to the zone data. The
serial number is updated automatically by NameSurfer, so there should be no need to
change it by hand.
Refresh (REFRESH)
This field determines how often the secondary name servers will check the zone for
changes. The default value is 8 hours, as recommended in RFC1537.
104
Retry (RETRY)
If a secondary name server fails to contact its primary, it will try again after this interval.
The interval is typically a small fraction of the Refresh time, but it should be at least an
hour. The default value is 2 hours, as recommended in RFC1537.
Expire (EXPIRE)
If a secondary name server is unable to contact its primary, it may still continue to
answer queries using the last data it was able to obtain. When it has been unable to
contact the primary the length of time given by the Expire value, the data will expire,
and the secondary name server will no longer answer queries. The default value is 7
days, as recommended in RFC1537.
Minimum TTL (MINIMUM)
This is the minimum time-to-live (TTL) value for all the DNS data in the zone. It also serves
as a default TTL value when new records are added. The initial default value is 1 day, as
recommended in RFC1537.
TXT records
TXT records can be used to attach arbitrary text strings to domain names. They can be
used for site-specific purposes, such as free-format comments for documenting the
location of a host, or the postal address of the organization the domain belongs to.
There are other record types (such as for HINFO and RP records) that may be used for
similar purposes and which may be more appropriate than TXT records when the
information to be documented is more structured than a free-format comment.
NameSurfer displays TXT records as a multi-line text area. Each line corresponds to a
separate TXT record. Because the DNS does not preserve the order of records, you
should not rely on the lines being displayed in a particular order.
105
WKS records
The WKS (Well Known Services) resource record type can be used to list the services
provided by a host.
It is entered as a list of whitespace-separated words:
The host's IP address
An IP protocol type, typically TCP or UDP
A list of port numbers or mnemonics for the services provided. The mnemonics
are defined in RFC1010.
For example, a host with the IP address 10.0.0.1, providing Telnet and SSH services over
TCP, might have the WKS record 10.0.0.1 TCP TELNET 22 (where 22 is the port
number of the SSH protocol).
The WKS record is widely considered to be obsolete. Although the WKS record type itself
is not officially deprecated, RFC1123 states that applications "should not" rely on its
existence.
There is not much point in maintaining a record that should not be used, so unless you
have a specific need to maintain WKS records in your domain, we recommend you
simply remove any WKS records you have by erasing the WKS text field and pressing the
OK button.
106
Extended Resource Records

LOC records
LOC records can be used to attach geographical location to domain names. Location
is specified in terms of latitude, longitude, altitude, size and precision.
NameSurfer displays LOC records as a single-line text representation as specified in
RFC1876. Example of this text presentation: LOC 42 20 32 N 71 05 19 W 10m 1000m.
SRV records
The SRV (Location of Service) resource record type can be used to to specify the
location of the servers for a specific protocol and domain name.
The name specifies the protocol and is of the form _Service._Proto, where Service is a
name, for example http and Proto is protocol name, for example tcp or udp.
Resource record contents are specified as a list of words separated by white spaces:
Priority is an unsigned integer in a range 0-65535. Smaller number means higher

priority. The client will always be directed to the server with the smallest available
priority
Weight is an unsigned integer in a range 0-65535. This number specifies the

probability of being selected for this service. If you only have one server for this
service it is recommended to specify 0 as weight. Otherwise the probability for a
particular server of being selected is proportional to the weight, which means
that a server with low weight will be selected rarely and a zero-weight server has
a very small chance of being selected
Port number is a target port number of this service
Target is the domain name of the services host. "." as target name indicates that
the service is not available at the domain concerned
For example, one can specify two web servers for a domain. In this case, the RR name
could be _http._tcp and the resource records could be:
0 1 80 old-slow-machine.example.com
0 3 80 new-fast-machine.example.com
1 0 80 backup-machine.example.com
If old-slow-machine or new-fast-machine is available, web clients will access these

machines and the faster of them is supposed to be loaded three times more heavily
than the old one. If both are down, clients are directed to the backup machine.
Records such as
*._udp
SRV
0 0 0 .
specify that no UDP based services are available.
107
The functionality of this DNS feature depends very much on the clients software. If the
client does not support SRV records, this priority and load balancing mechanism will not
function.
HTML records
HTML records are similar to HTXT records, with the difference that when the text strings
they contain are displayed on the zone page, they are displayed as HTML instead of raw
ASCII text. Like HTXT records, they cannot be retrieved by outsiders using DNS queries or
zone transfers.
HTML records can be used for site-specific customization, such as embedding hypertext
links (using A HREF tags) or icons (using IMG SRC tags) in the zone listing.
Make sure that the contents of each HTML record are syntactically correct HTML,
suitable for embedding in a HTML table cell; otherwise, the zone listing may be displayed
incorrectly.
HTXT records
HTXT (Hidden TXT) records are similar to TXT records, except that HTXT records are purely
internal to NameSurfer and are never included in answers to DNS queries or zone
transfers. This makes them more suitable than ordinary TXT records for storing confidential
information.
REMSEC records (Automatic remote secondary update)

Normally when a zone is added or deleted in NameSurfer, the secondaries for the zone
need to be reconfigured. Remote Secondary name server (REMSEC) records are used to
define the DNSbox100s that are set up to be configured automatically (the local BIND
instance is always updated). This record should contain the full domain name for
theDNSbox100. Usually, these will be the same servers that are defined in the
Authoritative Name Servers (NS) records.
ALSO_NOTIFY records
ALSO_NOTIFY records are used to define a set of name servers for a zone which for some
reason should be notified if the zone is changed. This feature is useful for the servers
which should have up to date information about the zone, but are not supposed to be
know as authoritative name servers for the zone. For instance if you have backup DNS
server in your organization which is intentionally not accessible form the external network
and for this reason should not be specified as authoritative.
ALSO_NOTIFY record is only meaningful if it has the same name as zone SOA record.
ALSO_NOTIFY record contains the name of server which should be notified when the
zone is changed.
HTML, HTXT, REMSEC and ALSO_NOTIFY records are NameSurfer extensions. They are not
part of the DNS standards and cannot be retrieved by outsiders using DNS queries or
zone transfers.
108

Statements
The authoritative statement
authoritative;
not authoritative;
The DHCP server will normally assume that the configuration information about a given
network segment is not known to be correct and is not authoritative. The purpose of this
is that if a naive user installs a DHCP server not fully understanding how to configure it, it
does not send false DHCPNAK messages to clients that have obtained addresses from a
legitimate DHCP server on the network.
Network administrators setting up authoritative DHCP servers for their networks should
always write authoritative; at the top of their configuration file to indicate that the
DHCP server should send DHCPNAK messages to mis-configured clients. If this is not
done, clients will be unable to get a correct IP address after changing subnets until their
old lease has expired, which could take quite a long time.
Usually, writing authoritative; at the top level of the file should be sufficient. However,
if a DHCP server is to be set up so that it is aware of some networks for which it is
authoritative and some networks for which it is not, it may be more appropriate to
declare authority on a per-network-segment basis.
Note that the most specific scope for which the concept of authority makes any sense is
the physical network segment - either a shared-network statement or a subnet
statement that is not contained within a shared-network statement. It is not meaningful
to specify that the server is authoritative for some subnets within a shared network, but
not authoritative for others, nor is it meaningful to specify that the server is authoritative
for some host declarations and not others.
The default-lease-time statement

default-lease-time time;
Time should be the length of time in seconds that will be assigned to a lease if the client
requesting the lease does not ask for a specific expiration time.
109
The filename statement

filename "filename";
The filename statement can be used to specify the name of the initial boot file which is
to be loaded by a client. The filename should be a filename recognizable to whatever
file transfer protocol the client can be expected to use to load the file.
The fixed-address statement

fixed-address address [, address ...
];
The fixed-address statement is used to assign one or more fixed IP addresses to a client.
It should only appear in a host declaration. If more than one addresses are supplied,
and the client boots, it will be assigned the address which corresponds to the network on
which it is booting. If none of the addresses in the fixed-address statement are on the
network on which the client is booting, that client will not match the host declaration
containing that fixed-address statement. Each address should be either an IP address or
a domain name which resolves to one or more IP addresses.
The hardware statement

hardware hardware-type hardware-address;
In order for a BOOTP client to be recognized, its network hardware address must be
declared using a hardware clause in the host statement. hardware-type must be the
name of a physical hardware interface type. Currently, only the ethernet and token-ring
types are recognized, although support for a fddi hardware type (and others) would also
be desirable. The hardware-address should be a set of hexadecimal octets (numbers
from 0 through ff) separated by colons. The hardware statement may also be used for
DHCP clients.
The max-lease-time statement

max-lease-time time;
Time should be the maximum length in seconds that will be assigned to a lease. The only
exception to this is that Dynamic BOOTP lease lengths, which are not specified by the
client, are not limited by this maximum.
The min-lease-time statement

min-lease-time time;
110
Time should be the minimum length in seconds that will be assigned to a lease.
The range statement

range [ dynamic-bootp ] low-address [ high-address];
For any subnet on which addresses will be assigned dynamically, there must be at least
one range statement. The range statement gives the lowest and highest IP addresses in
a range. All IP addresses in the range should belong to the subnet in which the range
statement is declared. The dynamic-bootp flag may be specified if addresses in the
specified range may be dynamically assigned to BOOTP clients as well as DHCP clients.
When specifying a single address, high-address can be omitted.
The server-name statement

server-name "name";
The server-name statement can be used to inform the client of the name of the server
from which it is booting. Name should be the name that will be provided to the client.
Allow and deny

The allow and deny statements can be used to control the response of the DHCP server
to various sorts of requests. The allow and deny keywords actually have different
meanings depending on the context. In a pool context, these keywords can be used to
set up access lists for address allocation pools. In other contexts, the keywords simply
control general server behavior with respect to clients based on scope. In a non-pool
context, the ignore keyword can be used in place of the deny keyword to prevent
logging of denied requests.
Allow, deny and ignore in scope

The following usages of allow and deny will work in any scope, although it is not
recommended that they be used in pool declarations.
The unknown-clients keyword

allow unknown-clients;
deny unknown-clients;
ignore unknown-clients;
The unknown-clients flag is used to tell dhcpd whether or not to dynamically assign
addresses to unknown clients. Dynamic address assignment to unknown clients is
allowed by default.
111
The bootp keyword

allow bootp;
deny bootp;
ignore bootp;
The bootp flag is used to tell dhcpd whether or not to respond to bootp queries. Bootp
queries are allowed by default.
The booting keyword

allow booting;
deny booting;
ignore booting;
The booting flag is used to tell dhcpd whether or not to respond to queries from a
particular client. This keyword only has meaning when it appears in a host declaration.
By default, booting is allowed, but if it is disabled for a particular client, then that client
will not be able to get and address from the DHCP server.
The duplicates keyword

allow duplicates;
deny duplicates;
Host declarations can match client messages based on the DHCP Client Identifier option
or based on the client's network hardware type and MAC address. If the MAC address is
used, the host declaration will match any client with that MAC address - even clients
with different client identifiers. This doesn't normally happen, but is possible when one
computer has more than one operating system installed on it - for example, Microsoft
Windows and NetBSD or Linux.
The duplicates flag tells the DHCP server that if a request is received from a client that
matches the MAC address of a host declaration, any other leases matching that MAC
address should be discarded by the server, even if the UID is not the same. This is a
violation of the DHCP protocol, but can prevent clients whose client identifiers change
regularly from holding many leases at the same time. By default, duplicates are
allowed.
The declines keyword
allow declines;
deny declines;
ignore declines;
The DHCPDECLINE message is used by DHCP clients to indicate that the lease the server
has offered is not valid. When the server receives a DHCPDECLINE for a particular
address, it normally abandons that address, assuming that some unauthorized system is
using it. Unfortunately, a malicious or buggy client can, using DHCPDECLINE messages,
completely exhaust the DHCP server's allocation pool. The server will reclaim these
112
leases, but while the client is running through the pool, it may cause serious thrashing in
the DNS, and it will also cause the DHCP server to forget old DHCP client address
allocations.
The declines flag tells the DHCP server whether or not to honour DHCPDECLINE messages.
If it is set to deny or ignore in a particular scope, the DHCP server will not respond to
DHCPDECLINE messages.
The always-broadcast statement

always-broadcast flag;
The DHCP and BOOTP protocols both require DHCP and BOOTP clients to set the
broadcast bit in the flags field of the BOOTP message header. Unfortunately, some
DHCP and BOOTP clients do not do this, and therefore may not receive responses from
the DHCP server. The DHCP server can be made to always broadcast its responses to
clients by setting this flag to 'on' for the relevant scope. To avoid creating excess
broadcast traffic on your network, we recommend that you restrict the use of this option
to as few clients as possible. For example, the Microsoft DHCP client is known not to
have this problem, as are the OpenTransport and ISC DHCP clients.
The always-reply-rfc1048 statement

always-reply-rfc1048 flag;
Some BOOTP clients expect RFC1048-style responses, but do not follow RFC1048 when
sending their requests. You can tell that a client is having this problem if it is not getting
the options you have configured for it and if you see in the server log the message "(nonrfc1048)" printed with each BOOTREQUEST that is logged.
If you want to send RFC1048 options to such a client, you can set the always-replyrfc1048 option in that client's host declaration, and the DHCP server will respond with an
RFC-1048-style vendor options field. This flag can be set in any scope, and will affect all
clients covered by that scope.
The ddns-update-style statement

ddns-update-style flag | number;
This parameter is compulsory in dhcpd.conf. DHCP server does not do DNS updates by
default. Updates can be enabled using this option. Values for this option are: none, adhoc and interim. Recommended value is interim.
The ddns-updates statement
113
ddns-updates flag;
The ddns-updates parameter controls whether or not the server will attempt to perform a
ddns update when a lease is confirmed. Set this to off if the server should not attempt to
perform updates within a certain scope. By default the ddns-updates parameter is on.
The server-identifier statement

server-identifier hostname;
The server-identifier statement can be used to define the value that is sent in the DHCP
Server Identifier option for a given scope. The value specified must be an IP address for
the DHCP server, and it must be reachable by all clients served by a particular scope.
The use of the server-identifier statement is not recommended - the only reason to use it
is to force a value other than the default value to be sent on occasions where the
default value would be incorrect. The default value is the first IP address associated with
the physical network interface on which the request arrived.
The usual case where the server-identifier statement needs to be sent is when a physical
interface has more than one IP address, and the one being sent by default isn't
appropriate for some or all clients served by that interface. Another common case is
when an alias is defined for the purpose of having a consistent IP address for the DHCP
server, and it is desired that the clients use this IP address when contacting the server.
Supplying a value for the dhcp-server-identifier option is equivalent to using the serveridentifier statement.
The shared-network statement

shared-network name {
[ parameters ]
[ declarations ]
}
The shared-network statement is used to inform the DHCP server that some IP subnets
actually share the same physical network. Any subnets in a shared network should be
declared within a shared-network statement. Parameters specified in the sharednetwork statement will be used when booting clients on those subnets unless parameters
provided at the subnet or host level override them. If any subnet in a shared network
has addresses available for dynamic allocation, those addresses are collected into a
common pool for that shared network and assigned to clients as needed. There is no
way to distinguish on which subnet of a shared network a client should boot.
Name should be the name of the shared network. This name is used when printing
debugging messages, so it should be descriptive of the shared network. The name may
have the syntax of a valid domain name (although it will never be used as such), or it
may be any arbitrary name, enclosed in quotes.
114
The subnet statement

subnet subnet-number netmask netmask {
[ parameters ]
[ declarations ]
}
The subnet statement is used to provide dhcpd with enough information to tell whether
or not an IP address is on that subnet. It may also be used to provide subnet-specific
parameters and to specify what addresses may be dynamically allocated to clients
booting on that subnet. Such addresses are specified using the range declaration.
The subnet-number should be an IP address or domain name which resolves to the
subnet number of the subnet being described. The netmask should be an IP address or
domain name which resolves to the subnet mask of the subnet being described. The
subnet number, together with the netmask, are sufficient to determine whether any
given IP address is on the specified subnet.
Although a netmask must be given with every subnet declaration, it is recommended
that if there is any variance in subnet masks at a site, a subnet-mask option statement be
used in each subnet declaration to set the desired subnet mask, since any subnet-mask
option statement will override the subnet mask declared in the subnet statement.
The use-host-decl-names statement

use-host-decl-names flag;
If the use-host-decl-names parameter is true in a given scope, then for every host
declaration within that scope, the name provided for the host declaration will be
supplied to the client as its hostname. So, for example,
group {
use-host-decl-names on;
host joe {
hardware ethernet 08:00:2b:4c:29:32;
fixed-address joe.fugue.com;
}
}
115
is equivalent to
host joe {
hardware ethernet 08:00:2b:4c:29:32;
fixed-address joe.fugue.com;
option host-name "joe";
}
An option host-name statement within a host declaration will override the use of the
name in the host declaration.
The use-lease-addr-for-default-route statement

use-lease-addr-for-default-route flag;
If the use-lease-addr-for-default-route parameter is true in a given scope, then instead of

sending the value specified in the routers option (or sending no value at all), the IP
address of the lease being assigned is sent to the client. This supposedly causes Win95
machines to ARP for all IP addresses, which can be helpful if your router is configured for
proxy ARP.
The dynamic-bootp-lease-cutoff statement

dynamic-bootp-lease-cutoff date;
The dynamic-bootp-lease-cutoff statement sets the ending time for all leases assigned
dynamically to BOOTP clients. Because BOOTP clients do not have any way of renewing
leases, and don't know that their leases could expire, by default dhcpd assigns infinite
leases to all BOOTP clients. However, it may make sense in some situations to set a cutoff
date for all BOOTP leases - for example, the end of a school term, or the time at night
when a facility is closed and all machines are required to be powered off.
Date should be the date on which all assigned BOOTP leases will end. The date is
specified in the form:
W YYYY/MM/DD HH:MM:SS
W is the day of the week expressed as a number from zero (Sunday) to six (Saturday).
YYYY is the year, including the century. MM is the month expressed as a number from 1
to 12. DD is the day of the month, counting from 1. HH is the hour, from zero to 23. MM
is the minute and SS is the second. The time is always in Coordinated Universal Time
(UTC), not local time.
116
The dynamic-bootp-lease-length statement

dynamic-bootp-lease-length length;
The dynamic-bootp-lease-length statement is used to set the length of leases

dynamically assigned to BOOTP clients. At some sites, it may be possible to assume that
a lease is no longer in use if its holder has not used BOOTP or DHCP to get its address
within a certain time period. The period is specified in length as a number of seconds. If
a client reboots using BOOTP during the timeout period, the lease duration is reset to
length, so a BOOTP client that boots frequently enough will never lose its lease. Needless
to say, this parameter should be adjusted with extreme caution.
The get-lease-hostnames statement

get-lease-hostnames flag;
The get-lease-hostnames statement is used to tell dhcpd whether or not to look up the
domain name corresponding to the IP address of each address in the lease pool and
use that address for the DHCP hostname option. If flag is true, then this lookup is done
for all the addresses in the current scope. By default, or if the flag is false, no lookups are
done.
The group statement

group {
[ parameters ]
[ declarations ]
}
The group statement is used simply to apply one or more parameters to a group of
declarations. It can be used to group hosts, shared networks, subnets, or even other
groups.
The host statement

host hostname {
[ parameters ]
[ declarations ]
}
117
There must be at least one host statement for every BOOTP client to be served. host
statements may also be specified for DHCP clients, although this is not required unless
booting is only enabled for known hosts.
If it is desirable to be able to boot a DHCP or BOOTP client on more than one subnet with
fixed addresses, more than one address may be specified in the fixed-address
parameter, or more than one host statement may be specified.
If client-specific boot parameters must change based on the network to which the client
is attached, then multiple host statements should be used.
If a client is to be booted using a fixed address if it's possible, but should be allocated a
dynamic address otherwise, then a host statement must be specified without a fixedaddress clause. hostname should be a name identifying the host. If a hostname option
is not specified for the host, hostname is used.
Host declarations are matched to actual DHCP or BOOTP clients in two ways:
by matching the dhcp-client-identifier option specified in the host declaration to

the one supplied by the client, or,
if the host declaration or the client does not provide a dhcp-client-identifier

option, by matching the hardware parameter in the host declaration to the
network hardware address supplied by the client.
BOOTP clients do not normally provide a dhcp-client-identifier, so the hardware address

must be used for all clients that may boot using the BOOTP protocol.
The min-secs statement

min-secs seconds;
Seconds should be the minimum number of seconds since a client began trying to
acquire a new lease before the DHCP server will respond to its request. The number of
seconds is based on what the client reports, and the maximum value that the client can
report is 255 seconds. Generally, setting min-secs to one will result in the DHCP server
not responding to the client's first request, but always responding to its second request.
This can be used to set up a secondary DHCP server which never offers an address to a
client until the primary server has been given a chance to do so. If the primary server is
down, the client will bind to the secondary server, but otherwise clients should always
bind to the primary. Note that this does not, by itself, permit a primary server and a
secondary server to share a pool of dynamically allocatable addresses.
The next-server statement

next-server server-name;
The next-server statement is used to specify the host address of the server from which the
initial boot file (specified in the filename statement) is to be loaded. Server-name should
be a numeric IP address or a domain name. If no next-server parameter applies to a
given client, the DHCP server's IP address is used.
118
The one-lease-per-client statement

one-lease-per-client flag;
If this flag is enabled, whenever a client sends a DHCPREQUEST for a particular lease, the
server will automatically free any other leases the client holds. This presumes that when
the client sends a DHCPREQUEST, it has forgotten any lease not mentioned in the
DHCPREQUEST - that is, the client has only a single network interface and it does not
remember leases it's holding on networks to which it is not currently attached. Neither of
these assumptions are guaranteed or provable, so we urge caution in the use of this
statement.
DHCP options
The Dynamic Host Configuration Protocol allows the client to receive options from the
DHCP server describing the network configuration and various services that are
available on the network. The syntax for declaring options, and the names and formats
of the options that can be declared, are documented here.
Option statements
The structure is always the following: DHCP option statements always start with the option
keyword, followed by an option name, followed by option data. The option names and
data formats are described below. It is not necessary to exhaustively specify all DHCP
options - only those options which are needed by clients must be specified.
Option data comes in a variety of formats, as defined below:
The ip-address data type can be entered either as an explicit IP address (eg,
239.254.197.10) or as a domain name (eg, haagen.isc.org). When entering a
domain name, be sure that that domain name resolves to a single IP address.
The int data type specifies an integer.
The quote data type specifies an NVT ASCII string, which must be enclosed in double
quotes - for example, to specify a domain-name option, the syntax would be:
option domain-name "isc.org";
However, the quoting is done automatically by NameSurfer.

The flag data type specifies a Boolean value. Booleans can be either true or false (or
on or off).
The string data type specifies either an NVT ASCII string enclosed in double quotes, or
a series of octets specified in hexadecimal, separated by colons. For example:
option dhcp-client-identifier "CLIENT-FOO";

or
option dhcp-client-identifier 43:4c:49:45:54:2d:46:4f:4f;
119
option all-subnets-local flag;

This option specifies whether or not the client may assume that all subnets of the
IP network to which the client is connected use the same MTU as the subnet of
that network to which the client is directly connected. The value true indicates
that all subnets share the same MTU. The value false means that the client should
assume that some subnets of the directly connected network may have smaller
MTUs.
option arp-cache-timeout uint32;
This option specifies the timeout in seconds for ARP cache entries.
option boot-size uint16;
This option specifies the length of the default boot image for the client in 512octet blocks .
option bootfile-name text;
This option is used to identify a bootstrap file. If supported by the client, it should
have the same effect as the filename declaration. BOOTP clients are unlikely to
support this option. Some DHCP clients will support it, and others actually require
it.
option broadcast-address ip-address;
This option specifies the broadcast address in use on the client's subnet. Legal
values for broadcast addresses are specified in section 3.2.1.3 of STD 3 (RFC1122).
option cookie-servers ip-address [, ip-address...
];
The cookie server option specifies a list of RFC 865 cookie servers available to the
client. The servers should be listed in order of preference.
option default-ip-ttl uint8;
This option specifies the default time-to-live that the client should use on outgoing
datagrams.
option default-tcp-ttl uint8;
This option specifies the default TTL that the client should use when sending TCP
segments. The minimum value is 1.
option dhcp-client-identifier string;
This option can be used to specify a DHCP client identifier in a host declaration,
so that dhcpd can find the host record by matching it against the client identifier.
option dhcp-max-message-size uint16;
This option, when sent by the client, specifies the maximum size of any response
that the server sends to the client. When specified on the server, if the client has
not sent a dhcp-max-message-size option, the size specified on the server is used.
This works for BOOTP as well as DHCP responses.
option dhcp-parameter-request-list uint16;
This option, when sent by the client, specifies which options the client wishes the
server to return. Normally, in the ISC DHCP client, this is done using the request
statement. If this option is not specified by the client, the DHCP server will
120
normally return every option that is valid in scope and that fits into the reply.
When this option is specified on the server, the server returns the specified options.
This can be used to force a client to take options that it has not requested, and it
can also be used to tailor the response of the DHCP server for clients that may
need a more limited set of options than those the server would normally return.
option domain-name-servers ip-address [, ip-address...
];
The domain-name-servers option specifies a list of Domain Name System (STD 13,
RFC 1035) name servers available to the client. The servers should be listed in
order of preference.
option domain-name text;
This option specifies the domain name that the client should use when resolving
hostnames via the Domain Name System.
option extensions-path-name text;
This option specifies the name of a file containing additional options. These
options are to be interpreted according to the DHCP option format as specified
in RFC2132.
option finger-server ip-address [, ip-address...
];
The Finger server option specifies a list of Finger servers available to the client. The
servers should be listed in order of preference.
option font-servers ip-address [, ip-address...
];
This option specifies a list of X Window System Font servers available to the client.
The servers should be listed in order of preference.
option host-name string;
This option specifies the name of the client. The name may or may not be
qualified with the local domain name (it is preferable to use the domain-name
option to specify the domain name). See RFC 1035 for character set restrictions.
option ieee802-3-encapsulation flag;
This option specifies whether or not the client should use Ethernet Version 2 (RFC
894) or IEEE 802.3 (RFC 1042) encapsulation if the interface is an Ethernet. The
value false indicates that the client should use RFC 894 encapsulation. The value
true means that the client should use RFC 1042 encapsulation.
option ien116-name-servers ip-address [, ip-address...
];
The ien116-name-servers option specifies a list of IEN 116 name servers available
to the client. The servers should be listed in order of preference.
option impress-servers ip-address [, ip-address...
];
The impress-server option specifies a list of Imagen Impress servers available to the
option interface-mtu uint16;
This option specifies the MTU to use on the interface in question. The minimum
legal value for the MTU is 68.
option ip-forwarding flag;
121
This option specifies whether the client should configure its IP layer for packet
forwarding. The value false stands for "disable IP forwarding", and the value true
stands for "enable IP forwarding".
option irc-server ip-address [, ip-address...
];
The IRC server option specifies a list of IRC servers available to the client. The
option log-servers ip-address [, ip-address...
];
The log-server option specifies a list of MIT-LCS UDP log servers available to the
option lpr-servers ip-address [, ip-address...
];
The LPR server option specifies a list of line printer servers, complying with RFC
1179, available to the client. The servers should be listed in order of preference.
option mask-supplier flag;
This option specifies whether or not the client should respond to subnet mask
requests using ICMP. The value false indicates that the client should not respond.
The value true indicates that the client should respond.
option max-dgram-reassembly uint16;
This option specifies the maximum size of a datagram that the client should be
prepared to reassemble. The minimum legal value is 576.
option merit-dump text;
This option specifies the path-name of a file to which the client's core image
should be dumped in the event the client crashes. The path is formatted as a
character string consisting of characters of the NVT ASCII character set.
option mobile-ip-home-agent ip-address [, ip-address...
];
This option specifies a list of IP addresses indicating some mobile IP home agents
available to the client. The agents should be listed in order of preference,
although normally there will be only one such agent.
option nds-context string;
The nds-context option specifies the name of the initial Netware Directory Service
for an NDS client.
option nds-servers ip-address [, ip-address...
];
The nds-servers option specifies a list of IP addresses of NDS servers.

option nds-tree-name string;
The nds-context option specifies the NDS tree name that the NDS client should
use.
option netbios-dd-server ip-address [, ip-address...
];
The NetBIOS datagram distribution server (NBDD) option specifies a list of RFC
1001/1002 compliant NBDD servers listed in order of preference.
option netbios-name-servers ip-address [, ip-address...];
The NetBIOS name server (NBNS) option specifies a list of RFC 1001/1002
compliant NBNS name servers listed in order of preference. NetBIOS Name
122
Service is currently more commonly referred to as WINS. WINS servers can be

specified using the netbios-name-servers option.
option netbios-node-type uint8;
The NetBIOS node type option allows NetBIOS over TCP/IP clients which are
configurable to be configured as described in RFC 1001/1002. The value is
specified as a single octet which identifies the client type.
Possible node types are:
1
B-node: Broadcast - no WINS
2
P-node: Peer - WINS only.
4
M-node: Mixed - broadcast, then WINS
8
H-node: Hybrid - WINS, then broadcast
option netbios-scope string;
The NetBIOS scope option specifies the NetBIOS over TCP/IP scope parameter for
the client as specified in RFC 1001/1002. For character-set restrictions see
RFC1001, RFC1002, and RFC1035.
option nis-domain text;
This option specifies the name of the client's NIS (Sun Network Information
Services) domain. The domain is formatted as a character string consisting of
characters from the NVT ASCII character set.
option nis-servers ip-address [, ip-address...
];
This option specifies a list of IP addresses indicating NIS servers available to the
option nisplus-domain text;
This option specifies the name of the client's NIS+ domain. The domain is
formatted as a character string consisting of characters from the NVT ASCII
character set.
option nisplus-servers ip-address [, ip-address...
];
This option specifies a list of IP addresses indicating NIS+ servers available to the
option nntp-server ip-address [, ip-address...
];
The NNTP server option specifies a list of NNTP available to the client. The servers
should be listed in order of preference.
option non-local-source-routing flag;
This option specifies whether the client should configure its IP layer to allow
forwarding of datagrams with non-local source routes. The value 0 means
disallow forwarding of such datagrams, and the value true means allow
forwarding.
123
option ntp-servers ip-address [, ip-address...
];
This option specifies a list of IP addresses indicating NTP (RFC 1035) servers
available to the client. The servers should be listed in order of preference.
option nwip-domain string;
The name of the NetWare/IP domain that a NetWare/IP client should use.
option nwip-suboptions string;
A sequence of suboptions for NetWare/IP clients - see RFC2242 for details.
Normally this option is set by specifying specific NetWare/IP suboptions.
option path-mtu-aging-timeout uint32;
This option specifies the timeout (in seconds) to use when aging Path MTU values
discovered by the mechanism defined in RFC 1191.
option path-mtu-plateau-table uint16 [, uint16...
];
This option specifies a table of MTU sizes to use when performing Path MTU
Discovery as defined in RFC 1191. The table is formatted as a list of 16-bit
unsigned integers, ordered from smallest to largest. The minimum MTU value
cannot be smaller than 68.
option perform-mask-discovery flag;
This option specifies whether or not the client should perform subnet mask
discovery using ICMP. The value false indicates that the client should not perform
mask discovery. The value true means that the client should perform mask
discovery.
option policy-filter ip-address ip-address [, ip-address ip-address...];
This option specifies policy filters for non-local source routing. The filters consist of
a list of IP addresses and masks which specify destination/mask pairs with which
to filter incoming source routes.
Any source routed datagram whose next-hop address does not match one of
the filters should be discarded by the client.
See STD 3 (RFC1122) for further information.
option pop-server ip-address [, ip-address...
];
The POP3 server option specifies a list of POP3 servers available to the client. The
option resource-location-servers ip-address [, ip-address...];
This option specifies a list of RFC 887 Resource Location servers available to the
option root-path text;
This option specifies the path-name that contains the client's root disk. The path is
formatted as a character string consisting of characters from the NVT ASCII
character set.
option router-discovery flag;
This option specifies whether or not the client should solicit routers using the Router
Discovery mechanism defined in RFC 1256. The value false indicates that the
124
client should not perform router discovery. The value true means that the client
should perform router discovery.
option router-solicitation-address ip-address;
This option specifies the address to which the client should transmit router
solicitation requests.
option routers ip-address [, ip-address...
];
The routers option specifies a list of IP addresses for routers on the client's subnet.
Routers should be listed in order of preference.
option slp-directory-agent boolean ip-address [, ip-address...
];
This option specifies two things: the IP addresses of one or more Service Location
Protocol Directory Agents, and whether the use of these addresses is mandatory.
If the initial Boolean value is true, the SLP agent should just use the IP addresses
given. If the value is false, the SLP agent may additionally perform active or
passive multicast discovery of SLP agents (see RFC2165 for details).
Please note that in this option and in the slp-service-scope option, the term "SLP
Agent" is being used to refer to a Service Location Protocol agent running on a
machine that is being configured using the DHCP protocol.
option slp-service-scope boolean text;
The Service Location Protocol Service Scope Option specifies two things: a list of
service scopes for SLP, and whether the use of this list is mandatory. If the initial
Boolean value is true, the SLP agent should only use the list of scopes provided in
this option; otherwise, it may use its own static configuration in preference to the
list provided in this option.
The text string should be a comma-separated list of scopes that the SLP agent
should use. It may be omitted, in which case the SLP Agent will use the
aggregated list of scopes of all directory agents known to the SLP agent.
option smtp-server ip-address [, ip-address...
];
The SMTP server option specifies a list of SMTP servers available to the client. The
option static-routes ip-address ip-address [, ip-address ip-address...];
This option specifies a list of static routes that the client should install in its routing
cache. If multiple routes to the same destination are specified, they are listed in
descending order of priority.
The routes consist of a list of IP address pairs. The first address is the destination
address, and the second address is the router for the destination.
The default route (0.0.0.0) is an illegal destination for a static route. To specify the
default route, use the routers option. Also, please note that this option is not
intended for classless IP routing - it does not include a subnet mask. Since
classless IP routing is now the most widely deployed routing standard, this option is
virtually useless, and is not implemented by any of the popular DHCP clients, for
example the Microsoft DHCP client.
option streettalk-directory-assistance-server ip-address [, ip-address...];
The StreetTalk Directory Assistance (STDA) server option specifies a list of STDA
servers available to the client. Servers should be listed in order of preference.
125
option streettalk-server ip-address [, ip-address...
];
The StreetTalk server option specifies a list of StreetTalk servers available to the
option subnet-mask ip-address;
The subnet mask option specifies the client's subnet mask as per RFC 950. If no
subnet mask option is provided anywhere in scope, as a last resort dhcpd will use
the subnet mask from the subnet declaration for the network on which an
address is being assigned. However, any subnet-mask option declaration that is
in scope for the address being assigned will override the subnet mask specified in
the subnet declaration.
option swap-server ip-address;
This specifies the IP address of the client's swap server.
option tcp-keepalive-garbage flag;
This option specifies whether or not the client should send TCP keepalive
messages with an octet of garbage for compatibility with older implementations.
The value false indicates that a garbage octet should not be sent. The value true
indicates that a garbage octet should be sent.
option tcp-keepalive-interval uint32;
This option specifies the interval (in seconds) that the client TCP should wait
before sending a keepalive message on a TCP connection. The time is specified
as a 32-bit unsigned integer. The value zero indicates that the client should not
generate keepalive messages on connections unless specifically requested by an
application.
option tftp-server-name text;
This option is used to identify a TFTP server and, if supported by the client, should
have the same effect as the server-name declaration. BOOTP clients are unlikely
to support this option. Some DHCP clients will support it, and others actually
require it.
option time-offset int32;
The time-offset option specifies the offset of the client's subnet in seconds from
Coordinated Universal Time (UTC).
option time-servers ip-address [, ip-address...
];
The time-server option specifies a list of RFC 868 time servers available to the
option trailer-encapsulation flag;
This option specifies whether or not the client should negotiate the use of trailers
(RFC 893 [14]) when using the ARP protocol. The value 0 indicates that the client
should not attempt to use trailers. The value true means that the client should
attempt to use trailers.
option uap-servers text;
This option specifies a list of URLs, each pointing to a user authentication service
that is capable of processing authentication requests encapsulated in the User
Authentication Protocol (UAP). UAP servers can accept either HTTP 1.1 or SSLv3
connections. If the list includes a URL that does not contain a port component,
126
the normal default port is assumed (i.e., port 80 for HTTP and port 443 for HTTPS). If
the list includes a URL that does not contain a path component, the path /uap is
assumed. If more than one URL is specified in this list, the URLs are separated by
spaces.
option vendor-class-identifier string;
This option is used by some DHCP clients to identify the vendor type and possibly
the configuration of a DHCP client. The information is a string of bytes whose
contents are specific to the vendor and are not specified in a standard. To see
what vendor class identifier clients are sending, you can write the following in
your DHCP server configuration file:
set vendor-class option vendor-class-identifier;
This will result in all entries in the DHCP server lease database file for clients that
sent vendor-class-identifier options having a set statement that looks something
like this:
set vendor-class "SUNW.Ultra-5_10";
The vendor-class-identifier option is normally used by the DHCP server to
determine the options that are returned in the vendor-encapsulated-options
option.
option vendor-encapsulated-options string;
The vendor-encapsulated-options option can contain either a single vendorspecific value or one or more vendor-specific suboptions. This option is not
normally specified in the DHCP server configuration file - instead, a vendor class is
defined for each vendor, vendor class sub options are defined, values for those
sub options are defined, and the DHCP server makes up a response on that basis.
Some default behaviours for well-known DHCP client vendors (currently, the
Microsoft Windows 2000 DHCP client) are configured automatically, but otherwise
this option must be configured manually.
option www-server ip-address [, ip-address...
];
The WWW server option specifies a list of WWW servers available to the client. The
option x-display-manager ip-address [, ip-address...
];
This option specifies a list of systems that are running the X Window System Display
Manager and are available to the client. Addresses should be listed in order of
preference.
127

The NameSurfer command line interface consists of a program called nsctl.
Adding and deleting resource records

The most common use of the CLI is to incrementally update the DNS data for one or
several names by adding and/or deleting some resource records.
This is accomplished by the nsctl update command. Here are some examples of
nsctl update commands:
nsctl update --zone demo.net.
--add banana A 10.0.0.1
--delete apple A 10.0.0.2
--add orange MX 10 mailhub \

--add orange MX 20 mail.isp.net.
The nsctl update command is followed by options beginning with a double dash --):
--zone zonename
The name of the DNS zone to update. This option is mandatory. All the records that are
added or deleted in a single invocation of nsctl update must belong to the same zone.
--class class
The name or decimal number of the DNS class. The default is IN (the Internet class).
After the options, the actual additions and deletions of resource records are specified as
groups of argument words beginning with --add or --delete. The words following the -add or --delete are interpreted as a name and a resource record, using a syntax similar
to that of a single entry in an RFC1035 master file. That is, they can take either of the
following forms:
<domain-name> [<TTL>] [<class>] <type> <RDATA>
<domain-name> [<class>] [<TTL>] <type> <RDATA>
Domain names with no trailing period are interpreted relative to the zone root given with
the --zone option. Note that this way of interpreting a domain name that has no periods
is similar to that of BIND, but different from that of the WWW user interface.
If the TTL is omitted, the SOA MINIMUM value is used.
128
Creating a new zone from scratch

A new zone can be created from scratch using the nsctl addzone command. Initial
zone data is given using --add arguments just as with the nsctl update command. You
must give an SOA record in this way; giving other initial data is optional. In the following
example, a SOA record and two NS records are given as initial data for the new zone.
nsctl addzone --zone demo.net.
--add @ SOA ns1 hostmaster 96041720 10800 3600 1814400 86400
--add @ NS ns1 \
--add @ NS ns2
Loading an entire zone by zone transfer

An entire zone can be loaded into NameSurfer from another name server by using the
nsctl xfer command. This command fetches the zone data by doing a zone transfer
from a given name server, and creates an identical zone in NameSurfer.
For example:
nsctl xfer --zone demo.net --ns 10.0.1.2
The nsctl xfer command accepts the following options:

--zone zonename
The name of the zone to transfer. This option is mandatory.
--class class
The name or decimal number of the DNS class. The default is IN (the Internet
class).
--ns server
The IP address of the name server to transfer the zone from. A domain name can
also be used if the local host has a working resolver.
129
Loading an entire zone from a master file

An entire zone can be loaded into NameSurfer from a RFC1035 master file by using the
nsctl mf-load command. For example:
nsctl mf-load --zone demo.net --file /etc/namedb/demo.net.db
The nsctl mf-load command accepts the following options:
--zone zonename
The name of the zone to transfer. This option is mandatory.
--class class
The name or decimal number of the DNS class. The default is IN (the Internet
class).
--file filename
The name of the master file to load.
Deleting an entire zone

An entire zone can be deleted from NameSurfer by using the nsctl delzone command.
For example:
nsctl delzone --zone demo.net.
Updating reverse mappings automatically

The nsctl program does not update reverse mappings by default. If you want automatic
reverse updates similar to the ones performed by the WWW user interface, add the
global option, --auto-reverse immediately following the nsctl command. This feature
can be used with any command that causes changes to DNS data, such as update,
xfer, or mf-load.
For example,
nsctl --auto-reverse update --zone demo.net.
--add pear A 10.0.0.3
nsctl --auto-reverse xfer --zone demo.net --ns 10.0.1.2
130
Manipulating remote secondary servers

NameSurfer uses non-standard Resource Record called REMSEC to keep the information
about remote secondary servers. You can manipulate these resource records using the
NameSurfer interface or command-line interface.
For example,

ns2.demo.net.
--add demo.net.
REMSEC
adds ns2.demo.net to the list of remote secondary severs list for zone demo.net. Note
the usage of dots in this example: they should be present; otherwise an incorrect
REMSEC Resource record will be created and the remote secondary server will not be
updated.
Manipulating user accounts

NameSurfer keeps track of its user accounts by means of a special, internal DNS zone.
All such internal zones in NameSurfer use the class number 8053 (NSURF), to keep them
separate from the normal DNS data in class 1 (IN).
The zone of user accounts is rooted at the domain name users. For example, the
information about a user account called einar would be stored under the domain name
einar.users.
Several different kinds of records can be stored under each account name to define
different kinds of permissions and restrictions. The PASSWORD record is mandatory for all
user accounts; all other records are optional. For detailed information about the
semantics of each record, see the online help for the corresponding field on the
NameSurfer "user page".
PASSWORD
The encrypted password, as a 13-character string. The encryption method is identical to
that traditionally used for encrypting passwords in /etc/passwd on UNIX systems.
SHOWCOLS
SHOWCOLSIDX
SHOWRRS
SHOWHOSTAF
Additional fields to display when listing hosts in DHCP
GROUPS
All the user groups currently existing in NameSurfer
131
SHOWGROUPAF
Additional fields to display when listing groups in DHCP
The creation of a new user account

Here is a complete example of how to create a user account called einar, with the
password SalaSana. The user is added to a group called 'usergroup'.
nsctl update --class NSURF --zone users.
--add einar PASSWORD QXFgctg6SGSZQ \

--add einar GROUPS usergroup
As another example, here's how to create a new superuser account called odin. Odin is
called superuser, because the user account is added to a group called 'admingroup',
which gives access without restrictions to everything.
nsctl update --class NSURF --zone users.
--add odin PASSWORD QXFgctg6SGSZQ \

--add odin GROUPS admingroup
The encrypted passwords may be produced using existing software, such as the
htpasswd program used with many WWW servers. If you don't have an existing in-house
procedure for password encryption, the following short Perl script may be useful. It will
read plaintext passwords from standard input, encrypt them, and print the encrypted
passwords on standard output.
#!/usr/local/bin/perl5
sub salt {
substr("./" .
join("", "0".."9","A".."Z","a".."z"), int rand 64)
}
srand time;
while (<>) {
chomp; print crypt($_, salt.salt), "\n";
}
132
Manipulating user groups

All access restrictions are given to specific user groups and users get their access
restrictions according to the group they belong to.
For example,
Group 1 have access to zone a.x
Group 2 have access to zone b.x
User 1 is a member of both Group 1 and Group 2 and thus he/she has access to a.x and
b.x.
Several different kinds of records can be stored under each account name to define
different kinds of permissions and restrictions. All these records are optional.
HTTP_NET
Like the Allow WWW access only from IP address range field on the user page.
MY_NAMES
Like the Restrict editing to name pattern(s) field on the user page. Each pattern
is stored as a separate record.
MY_NET
Like the Restrict editing to IP address range(s) field on the user page. Each
allowed range is stored as a separate record.
MY_ZONE
Like the Restrict editing to zone(s) field on the user page. Each allowed zone is
stored as a separate record.
ALLOC_NET
Like the Allocate IP addresses from range(s) field on the user page.
allocation range is stored as a separate record.
Each
DESCRIPTION
A space for a description of the group.
HTTP_NET
133
These entry fields may be used to permit the user to log in to NameSurfer only
from Web browsers running on a specific network or host, by defining a range of
allowed IP numbers. There are two entry fields, defining the lower and inclusive
upper end of the range, respectively. For example, entering 192.168.23.0 and
192.168.23.255 will allow access only from the class C network 192.168.23.
Entering the same IP number in both fields will restrict the user to logging in from a
single host. If the field is left blank, the user may log in from any host.
ZONE
Gives the right to create, modify and delete zones and hosts (Modify), or just to
view them.
USER
Gives the right to create, modify and delete user accounts (Modify), or just to
view them. See also Group information below.
GROUP
Gives the right to create, modify and delete groups (Modify), or just to view them.
NOTE: Giving group members modification rights to Group information gives them
Superuser rights in this aspect, since with these rights, they can include themselves
in the group of Administrators. Meanwhile, if group members do not have
modification rights to Group information, they can join users to only those groups
of which they are members themselves.
DHCP
Checking the Modify or View box here produces the DHCP link on the Index
page. A checked Modify box gives the group member the right to modify DHCP
information and displays an OK button on the DHCP pages. If only the View box
is checked, the group member has no modification rights and no OK button on
the DHCP pages, but has access to the DHCP pages through the link.
RESTRICTIONS
When a group is created, by default its members have rights to modify all record
types. This is indicated by ticks in all boxes. If access needs to be restricted,
remove ticks in appropriate boxes.
MY_ZONES
Definition of the zones to which the group members have access, if the access to
zone/host information has been given (above). Fill in the appropriate zone
names or name patterns to define the zones to which the group members have
access. Asterisk (*) can be used as wildcard. If the field is empty, the group
members have access to no zones. A sole asterisk in the field gives access to all
zones.
134
In addition to the views available to the user, the values given here also limit the
names the user may give to new zones: they need to comply with the given
pattern.
MY_REVZONES
Gives the group members rights to one or several reverse zones. Fill in the
appropriate reverse zone names or name patterns to define the reverse zones to
which the group members have access. Asterisk (*) can be used as wildcard. If
the field is empty, the group members have access to no reverse zones. A sole
asterisk in the field gives access to all reverse zones.
MY_NAMES
Gives the group members the right to names containing the given name pattern
in a zone or a DNS view, and restricts the naming of new nodes by that same
name pattern. Fill in the appropriate name pattern. Asterisk (*) can be used as
wildcard. If the field is empty, the group members have access to no names. A
sole asterisk in the field gives access to all names.
MY_NET
This field may be used to give access to the set of IP addresses whose reverse
mappings are updated automatically when the user adds or removes hosts.
Reverse mappings are updated automatically whenever A records are added or
deleted to forward zones, provided that the A records fall within the given
address range (or one of the ranges).
Multiple address ranges may be entered by pressing the "OK" button after
entering the first one. If the fields are left blank, any reverse mapping under the
authority of this NameSurfer may be updated automatically as a result of editing
done by this user.
If the user is permitted to access and modify reverse zones as well as forward
zones, these restrictions apply to the changes the user is allowed to make.
MY_NET6
The same as Access to IP address ranges (above) but concerning IPv6 (AAAA)
addresses.
MY_PREFIX
The use of A6 prefixes can be allowed by entering the relevant prefix(es) in this
field. If the field is empty, no A6 prefixes are allowed. A sole asterisk in the field
allows the use of all A6 prefixes.
DHCP_RESTRICT
135
With this function, it is possible to give a DHCP administrator access to DHCP

subnets. If these fields contain IP addresses, the DHCP administrator will be able
to edit subnets where the network address falls in this IP address range. If the
fields are empty, no access is given.
HOST_TEMPLATE
The name of a host to use as a template when creating new hosts. New hosts will
be given default initial data similar to that of the given template host. This is
particularly useful as a way of giving each new host a standard set of MX records.
Any existing host can be used as a template, but it is a good idea to create one
or more dedicated "template hosts" that do not correspond to any physical
machine. The template hosts can be created in any zone maintained in the
same NameSurfer. A large site may even want to create a separate zone just for
templates.
Any A records of the template host are ignored. Instead, the IP address of the
new host is determined by the usual IP address allocation mechanism.
If the host template setting is not used, or the template host does not exist, new
hosts have no default data.
ZONE_TEMPLATE
The name of a zone to use as a template when creating new zones. New zones
will be given default initial data similar to that of the given template zone. This is
particularly useful as a way of giving each new zone a standard set of MX records
and NS records.
Any existing zone can be used as a template, but you can also create one or
more dedicated "template zones".
If the zone template setting is not used, or the template zone does not exist, new
zones have no default data.
ALLOC_NET
Defines a range of IP addresses for automatic allocation. When displaying the
form for adding a new host to the DNS, NameSurfer will automatically search this
range (or these ranges) for unused addresses. The first unused address will be
offered as a default for the host address field. If the fields are left blank, no
automatic address allocation will take place.
136
Setting up groups
The installation script creates the default group "admingroup" and one user in this group - the username and password are asked during installation. This default user is capable
of creating new groups and users, and we recommend that a personal user account is
created for each administrator even if they all belong to the "admin" group.
When access restrictions are needed, an administrator must create a group and assign
proper access restrictions for this group. After that, users can be assigned to this group
and new restrictions take effect.
Note: No white spaces are allowed in group names.
The creation of a new admingroup

An admingroup has unlimited rights.
nsctl update --class NSURF --zone groups.

\
--add admingroup MY_ZONE *.
--add admingroup GROUPDESC Admingroup with all privileges \

--add admingroup ZONE 0 \
--add admingroup USER 0 \
--add admingroup GROUP 0 \
--add admingroup DHCP 0 \
--add admingroup MY_REVZONE *.
--add admingroup MY_NAMES \* \

--add admingroup MY_NET 0.0.0.0 255.255.255.255 \
--add admingroup MY_NET6 0:0:0:0:0:0:0:0
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF \
--add admingroup MY_PREFIX *.
--add admingroup DHCP_RESTRICT 0.0.0.0 255.255.255.255
137
The creation of a new usergroup

Example: The group is restricted to the zone valhalla.com and the IP addresses
10.0.0.0 - 10.0.0.255. IP addresses for new hosts will be allocated from the range
10.0.0.128 - 10.0.0.255, and the group has modifying rights to those zones. No
other privileges.
nsctl update --class NSURF --zone groups.
--add usergroup GROUPDESC Usergroup with restrictions \

--add usergroup ZONE 0 \
--add usergroup USER 0 \
--add usergroup MY_ZONE *valhalla.com.
--add usergroup MY_REVZONE *0.0.10.
--add usergroup MY_NAMES \* \

--add usergroup MY_NET 10.0.0.0 10.0.0.255 \
--add usergroup ALLOC_NET 10.0.0.128 10.0.0.255
User and zone listings

The command line interface includes functionality for listing the NameSurfer users and all
of the zones managed by NameSurfer.
You can generate a list of all the NameSurfer users with the command:
nsctl user-list
The user list is divided into two parts: one showing the NameSurfer superuser accounts,
and one showing the normal user accounts.
The command
nsctl zone-list
generates a list of all the zones managed by NameSurfer.
138
The command
nsctl view-list
generates a list of all the views managed by NameSurfer.
The command
nsctl zone-transfer --zone demo.net
transfers zone from the NameSurfer primary server and prints it in the zone file format.
Unlike BINDs named-xfer utility this command also transfers NameSurfer-specific resource
records and prints these resource records commented with ';-'. The resulting zone file is
understood by BIND. The zone file could be transferred back to NameSurfer using the
mf-load command even if non-standard resource records are uncommented.
This command also allows transferring non-standard zones used by NameSurfer for user
databse (users), preferences (settings) and zone list (zones). These internal zones have
the non-standard class nsusrf. For example,
nsctl zone-transfer --zone users --class nsurf
transfers the user database and prints it in a readable form.
139
Notes
140
Notes

UserGuide DNSbox300 PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UserGuide DNSbox300 PDF

Uploaded by

Copyright:

Available Formats

DNSBOX050/300

DNS and DHCP

DNSBOX050/300 User Guide

SECTION 1: PLANNING DEPLOYMENT

SECTION 2: USING DNSBOX300

SECTION 3: CONFIGURATION REFERENCE

SECTION 4: FREQUENTLY ASKED QUESTIONS

DNSBOX050/300 User Guide

Using This Guide

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

How This Guide is Organised

PLANNING DEPLOYMENT understand in advance key principles about how to

Understand different deployment scenarios for DNS and DHCP in your

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

Using This Guide

CONFIGURATION REFERENCE - describes in detail each of the screens

FREQUENTLY ASKED QUESTIONS on deployment, support, managing the

APPENDICES further information you might need in specific scenarios

DNSBOX050/300 User Guide

Who This Guide Is For

If you are a network administrator tasked with ongoing management of the

Conventions Used in This Guide

Something you have to type or select from a drop down or radio

DNSBOX commands (fixed width font)[console display]

Using This Guide

DNSBOX050/300 User Guide

Understand different deployment

Key DNS Concepts

Deployment Options and Scenarios

Authoritative DNS: Master-Slave

DNS Management Application

Managing DNS Data

DNSBOX050/300 User Guide

Introduction to DNS and DHCP

Key DNS Concepts

PLANNING DEPLOYMENT - Introduction to DNS and DHCP

DNSBOX050/300 User Guide

For example, finding the IP address of

may require a series of three DNS

Deployment Options and Scenarios

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

Authoritative DNS: Master-Slave

Recursive DNS and Caching

DHCP and Dynamic DNS

High Availability Slaves

Enterprise deployment - external DNS

Enterprise deployment mixed BIND/ Windows DNS

Service provider deployment

PLANNING DEPLOYMENT - Introduction to DNS and DHCP

DNSBOX050/300 User Guide

Authoritative DNS: Master-Slave

The master is hidden securely behind a firewall. It is

A minimum of two slaves serve queries, for

PLANNING DEPLOYMENT - Introduction to DNS and DHCP

DNSBOX050/300 User Guide