Before installing FusionLayer NameSurfer , you should be familiar with the general structure of a FusionLayer NameSurfer installation. In particular, you need to understand how FusionLayer NameSurfer fits into the big picture of primary, secondary, and caching name servers. You also need to understand its dual role as a name server and a web server. This document introduces these issues to a site DNS administrator planning to install FusionLayer NameSurfer.

This document is not a Domain Name System tutorial. The reader is assumed to be familiar with the DNS and with its most common implementation, BIND. For a general introduction to the DNS, we recommend the following book:

DNS and BIND (5th Edition)
by Paul Albitz & Cricket Liu
O'Reilly, 2006
ISBN 0-596-10057-4

For detailed technical information about FusionLayer NameSurfer's operation, see the FusionLayer NameSurfer Administrator's Guide.

Name servers and processes

A fully operational FusionLayer NameSurfer installation consists of seven separate server processes running on the same machine: the Apache HTTP server, the NameSurfer primary name server, the NameSurfer Application Programming Interface service, the PostgreSQL server, the confd process for controlling remote secondaries, a Java process for running IPAM and a BIND name server that is configured as a secondary name server.

Additionally, if you run ISC DHCP server on FusionLayer NameSurfer primary, a seventh process will be present.

To allow a primary and a secondary name server to coexist peacefully on the same machine, the FusionLayer NameSurfer primary name server must use an alternate port number (typically port 8054). Since version 8.2, BIND supports syntax for accessing the primary name server on a port other than the standard DNS port (53), but earlier versions need some minor modifications to be able to access the primary.

The FusionLayer NameSurfer primary name server is a "hidden primary", meaning that it does not communicate directly with the outside world. Instead, all communication passes through its secondary BIND servers of which one can be run on the primary server. Please note that this local BIND secondary is automatically installed and running after installation. To disable it, edit namesurfer start script in /etc/init.d directory. When used, the outside world will only talk to the BIND server, as if it were actually the primary name server.

It is also possible to set up alternative configurations, such as running all server processes on different hosts, but such advanced setups are not covered in this document.

For reliability, each domain should have at least two non-hidden authoritative name servers. The FusionLayer NameSurfer primary is hidden, so it does not count, but its local BIND secondary counts as one of the two. This means that you should set up at least one additional secondary name server, preferrably at an off-site location, just as you would with BIND as a primary. These additional secondaries can be configured to get their data from FusionLayer NameSurfer's local BIND secondary. This will technically make them "secondaries to a secondary", but that is perfectly okay. For these additional secondaries, you can use any RFC1035-compliant name server implementation; they do not even have to be UNIX-based.

All Unix-based secondary name servers can be also configured as Remote Secondaries in FusionLayer NameSurfer . This means that their configuration file is stored in FusionLayer NameSurfer database and is edited and uploaded to the secondary ONLY by using the web-based user interface. The process control is also done with WebUI.

If you are upgrading an existing BIND installation to FusionLayer NameSurfer and you are running FusionLayer NameSurfer's BIND secondary on the host that used to be your primary, your existing secondaries will continue to work as before, without any configuration changes. They will simply continue to get their data from the same host as before.

Optionally, you can install FusionLayer NameSurfer companion DHCP server, or control existing DHCP server using FusionLayer NameSurfer's user interface.

The DHCP server should be managed from the web-based user interface. The changes made to the DHCP configuration will take effect only when the server is stopped and restarted. The DHCP server will not reload its configuration automatically when the configuration has been changed; it must be restarted manually.

Please note: The FusionLayer DHCP Server product can be integrated into FusionLayer NameSurfer in two ways, either in integrated mode where the DHCP Server configuration is managed and stored in FusionLayer NameSurfer, or in standalone mode where the configuration is managed locally on the FusionLayer DHCP Server. Standalone servers can be created in FusionLayer NameSurfer to keep track of servers in your environment.

FusionLayer NameSurfer currently ships with the following database:

Open Source: PostgreSQL 9.0
PostgreSQL is a powerful, open source object-relational database system. It has more than 15 years of active development and a proven architecture that has earned it a strong reputation for reliability, data integrity, and correctness. It runs on all major operating systems, including Linux, UNIX (AIX, BSD, HP-UX, SGI IRIX, Mac OS X, Solaris, Tru64), and Windows. It is fully ACID compliant, has full support for foreign keys, joins, views, triggers, and stored procedures (in multiple languages). It includes most SQL:2008 data types, including INTEGER, NUMERIC, BOOLEAN, CHAR, VARCHAR, DATE, INTERVAL, and TIMESTAMP. It also supports storage of binary large objects, including pictures, sounds, or video. It has native programming interfaces for C/C++, Java, .Net, Perl, Python, Ruby, Tcl, ODBC, among others, and exceptional documentation which can be found at http://www.postgresql.org/docs/manuals/.

Please note: NameSurfer versions from 7.0.1 onwards do not use IBM Solid Embedded Engine 4.5. When upgrading into these versions the Solid database is dumped into files, and then imported into the PostgreSQL. In case you would like to upgrade within FusionLayer NameSurfer 6 series, the automated Solid DB conversion is included in version 6.9.1. For further instructions, please contact FusionLayer DDI Helpdesk at support@fusionlayer.com for assistance.

In FusionLayer NameSurfer 5.6.1 a new service was introduced to a suite of FusionLayer NameSurfer components: the NameSurfer Application Programming Interface. It is recommended to use it in a closed environment and not to expose it directly to the outside world.

The Apache HTTP Server

From FusionLayer NameSurfer version 5 onwards, the server of the web-based interface has been substituted by the Apache HTTP server. For details, please see the FusionLayer NameSurfer Administrator's Guide.

The Apache HTTP server receives HTTP requests from the users' web browsers, displays DNS data as HTML, and allows users to change the DNS data by submitting HTML forms.

The Apache HTTP server also provides access to an online, hypertext version of the FusionLayer NameSurfer Reference Manual.