Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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
Contents
Using This Guide
5
6
17
27
28
37
38
56
65
66
93
94
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
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.
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
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:
If you are involved in planning or carrying out deployment, Sections 1 and 2 are
particularly relevant to you
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.
[KEYSTROKE]
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
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
IN THIS SECTION
Introduction to DNS and DHCP
DNSBOX300 Overview
8
9
10
10
11
12
13
14
15
17
User Interfaces
18
20
20
22
22
Appliance Management
23
Operating System
24
Hardware
24
Hardware Models
25
PLANNING DEPLOYMENT
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.
www.example.com
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.
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:
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.
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.
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.
Some real time mission-critical applications time out if a DNS query is not resolved
fast enough
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
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:
Failover master
Two DNSBOX100s are also deployed one in each of the two data centres.
-
13
14
Additionally, the DNSBOX300 may be configured to serve internal DHCP via the
DNSBOX100, which acts as a DHCP relay
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.
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
15
16
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
Proprietary
Hidden
Primary
BIND
To Slave
Application Extensions
Appliance
Layers
Server Management
Operating System
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
-
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 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.
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
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
Share the tasks above among multiple administrator users in a controlled way
Key features of NameSurfer for carrying out these tasks are explained below.
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
20
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
21
Import all the DNS data to DNSBOX300 and serve it from your DNSBOX100s
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.
Appliance Management
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:
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.
Upgrades
Upgrades provided by ApplianSys (adding features, responding to newly
discovered security flaws in BIND, etc) can be applied via the web interface.
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
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:
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:
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
IN THIS SECTION
Getting Started
28
Physical Setup
28
Network Requirements
29
29
33
37
Deployment Guide
38
38
42
49
50
56
56
Network security
59
System Log
61
61
61
62
62
Static Routes
62
62
Password
62
Current status
63
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:
support@appliansys.com
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.
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
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)
*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
Step 1
Connect the appliance. Attach:
Serial cable. The communication settings required for a serial connection are
38400 bps, 8 data bits, no parity, 1 stop bit (8N1).
29
Step 2
Power the appliance on:
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 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
33
34
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.
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)
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
REMSEC is a proprietary feature which only works between DNSBOX300 masters and
DNSBOX100 slaves
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
Configuration
The steps detailed below to integrate your DNSBOX300 and DNSBOX100 devices are:
Set up secure IPsec links between the master and each slave
-
Edit DNS data on the DNSBOX300 to specify slaves to push zone data to
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.
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
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
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.
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:
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
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
Now go to the standby mns2 Appliance Interface system > add secure server
43
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
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
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
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.
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
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
86400 IN
SOA
. hostmaster.test. (
allow-dynamic-updates
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
. hostmaster.test. (
allow-dynamic-updates
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.
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.
Imported or set up all your public forward and reverse zones on the DNSBOX300.
Configuration
The steps detailed below are:
50
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
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.
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
...
;; ADDITIONAL SECTION:
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
1.168.192.in-addr.arpa
Ns1.example.com IN A 192.168.1.11
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
...
;; ADDITIONAL SECTION:
...
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:
185.132.in-addr.arpa.
86400 IN
NS
ns1.thny.bbc.co.uk.
185.132.in-addr.arpa.
86400 IN
NS
ns1.thdo.bbc.co.uk.
185.132.in-addr.arpa.
86400 IN
NS
ns1.thls.bbc.co.uk.
185.132.in-addr.arpa.
86400 IN
NS
ns.ripe.net.
185.132.in-addr.arpa.
86400 IN
NS
ns.bbc.co.uk.
...
If you have a classless IPv4 network, you may have seen references to classless reverse
zones and RFC 2317. These are supported by NameSurfer but have a number of
drawbacks and are not usually necessary.
If you have a classless subnet, your Internet registrar will need to delegate domain
records individually.
If you are delegating a classless reverse zone, you need to add the the PTR records on
the DNSBOX300 for all the addresses in the subnet that you are delegating. Say for
example you want to delegate reverse records for the subnet 192.0.2.0/25 to a customer
that uses this address space:
6
54
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
Configuration
The steps for creating a delegated user account are:
56
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
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).
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.
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
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:
Use secure tunnel options on DNSBOX to secure traffic between your DNS servers
-
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.
DNS
DNS
IPsec key exchange daemon*
SysLog
*
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
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.
`
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.
61
Go to configure > Ssl certificate and copy the Certificate Signing Request from
CSR to your certificate authority
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.
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.
Upgrades
Software upgrade patches are made available from time to time by ApplianSys. New
software versions are normally released to:
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
66
Index
66
Zone
68
Reverse zone
72
74
Node
75
DHCP configuration
77
User accounts
79
User
80
Group list
82
Group
83
88
Preferences
89
TTLs
90
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.
66
DHCP
The page is generated from your DHCP server's configuration file and gives you a
representation of your current configuration.
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: Groups
User profiles are defined by joining users to groups with various rights and restrictions.
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.
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: 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.
69
Sorting
By pressing the corresponding headers above the table of zone data, you can view the
data sorted either by name or by address.
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.
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.
72
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.
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.*.
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.
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.
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".
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.
78
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.
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
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
Zone/host information
User information
Group information
DHCP information.
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.
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.
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 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 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.
85
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.
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
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
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:
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.
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 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.
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
System Status
Service Status
My Public Key
Secure Servers
Secure Servers
Description
Enabled
IP Address
VPN Enabled
Compression Enabled
Public Key
Auto Configure
Enter Query
Server Address
Service to Query
Query Type
System Log
System Log
Upgrade
Firmware Upgrade
Shutdown/reboot the
DNSBOX
Add Secure
Server
Query Service
Shutdown
93
CONFIGURE Menu
Menu Item
Options
Description
Summary
Network/Advanced
Host Name
Appliance hostname
Ethernet Mode
IP Address
Netmask
Default Route
Time Zone
Admin Address
DHCP Services
Only Secure
Front Button
SSH Support
Syslog Server
Failover Mode
Failover Password
Failover Master
Refresh Interval
SNMP Community
Config network
Config
advanced
94
Time Server
Menu Item
Options
Description
RADIUS Authentication
RADIUS Server
SSL certificate
SSL keys
Authorized keys
Password
Password
Backup
Backup System
Config auth
Restore
Static routes
Restore System
Description
Subnet
Netmask
Gateway
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
Appliance Management
98
Troubleshooting
99
Hardware
100
97
Appliance Management
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)
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.
98
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 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.
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.
99
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.
Weight: 8kg
Weight: 5kg
100
Weight: 5kg
APPENDICES
APPENDICES
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.
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.
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:
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
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:
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
Records such as
*._udp
SRV
0 0 0 .
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.
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
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.
109
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 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.
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.
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.
110
Time should be the minimum length in seconds that will be assigned to a lease.
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 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.
111
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 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.
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.
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.
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 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 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 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.
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 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 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 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.
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:
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 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
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";
119
];
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
client. The servers should be listed in order of preference.
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
servers should be listed in order of preference.
option log-servers ip-address [, ip-address...
];
The log-server option specifies a list of MIT-LCS UDP log servers available to the
client. The servers should be listed in order of preference.
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 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
];
This option specifies a list of IP addresses indicating NIS servers available to the
client. The servers should be listed in order of preference.
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
client. The servers should be listed in order of preference.
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
];
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
servers should be listed in order of preference.
option resource-location-servers ip-address [, ip-address...];
This option specifies a list of RFC 887 Resource Location servers available to the
client. The servers should be listed in order of preference.
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
servers should be listed in order of preference.
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
];
The StreetTalk server option specifies a list of StreetTalk servers available to the
client. The servers should be listed in order of preference.
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
client. The servers should be listed in order of preference.
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
servers should be listed in order of preference.
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 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
--add @ NS ns1 \
--add @ NS ns2
For example:
129
--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.
For example,
130
--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.
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
Columns to display in zone listings
SHOWCOLSIDX
Columns to display in index listings
SHOWRRS
Entry fields to display for new hosts
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
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.
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("./" .
}
srand time;
while (<>) {
chomp; print crypt($_, salt.salt), "\n";
}
132
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
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.
137
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
138
The command
nsctl view-list
The command
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,
139
Notes
140
Notes