Introduction

Directories and files

NameSurfer is installed in its own directory. The location of this directory is system-dependent. Typical locations are /usr/local/namesurfer and /opt/namesurfer. In this document, we will refer to this directory as $NS.

The directory $NS contains a number of subdirectories for the NameSurfer program and data files. The following sections describe the major data files.

• The primary DNS server configuration file
• The WWW user interface configuration file
• The command line interface configuration file
• The IPAM server configuration file

$NSDIR/logs/namesurfer.log

• All changes to DNS data
• Error and warning messages
• DNS Notify/Zone Transfers from hidden primary

$NS/run/ns.pid

$NS/run/webui.pid

$NS/named/ (binary distributions only)

$NS/run/confd.pid

Network ports

8053/tcp

Incoming HTTP connections.

8054/udp

8054/tcp

Hidden Primary DNS Server listens to this port. Secondary Servers user this port to make zone transfers. NameSurfer will also answer ordinary (non-zone-transfer) DNS queries about its authoritative data on this port, but does not provide recursive lookup services.

8057/tcp

Incoming HTTP connections, NameSurfer API service

8055/tcp

Remote configuration daemon default port, used internally

8056/tcp

Used by PostgreSQL DBMS

8443/tcp

On port 8443, FusionLayer NameSurfer listens for SSL-enabled HTTP traffic. This port number can be changed in httpd.conf.

Starting and killing the NameSurfer server processes

    /etc/init.d/namesurfer restart/stop/start

Configuring NameSurfer's companion BIND

Configuring other BIND secondaries

Configuring BIND secondaries by manually

For BIND 8 and BIND 9, you will have to edit named.conf each time a zone is added or removed with NameSurfer, and restart BIND. For each domain maintained using NameSurfer, the named.conf file of each secondary should contain an entry in the following format:

zone "zone" {
        type slave;
        file "backup-file";
        masters port 53/8054 { primary_ip; };

BIND directories and files

data files

Security issues

This level of security may be sufficient for authenticating local users within an organization's internal network, but it is widely considered unsuitable for use over the public Internet.

When NameSurfer is used by an ISP to let customers administer their own domains, it cannot be protected by a firewall. In this situation, we recommend that all user accounts be configured with the "Allow WWW access only from IP address range(s)", restricting access to the IP addresses of the customer's network. This makes it considerably harder for an outside attacker to make use of a leaked password.

FusionLayer NameSurfer 5 is SSL-enabled by default and we recommend using it whenever possible. The SSL-enabled HTTP server listens at port 8443 by default. The file $NS/db/secrets contains a shared secret used for authentication between the command line interface and the NameSurfer name server process. It should be owned by the UID of the NameSurfer servers, and should not give even read permission to anyone else (that is, it should have mode 0600). Anyone who gains knowledge of its contents is able to make changes to the DNS data, even remotely by TCP or UDP.

In any event, a person who gains unauthorized access to a NameSurfer user account will at worst be able to examine or corrupt the DNS data being maintained by it. The machine running NameSurfer will not be otherwise compromised. Great care has been taken to ensure that NameSurfer will under no circumstances execute arbitrary shell commands or read or write arbitrary files. Even if NameSurfer itself were somehow compromised, the potential for damage would still be limited because NameSurfer runs with an unprivileged UID.

FusionLayer NameSurfer 5.1.2 introduced some new security features. These new features can be enabled by turning on configuration option strict_securitys_checks from config/webui.conf. This parameter enables the following security enhancements:

1. Minimum password length check
2. Strong password check,
3. Password check against dictionary,
4. Locking an account after several failed login attempts.

Recovering from disaster

Recovering a lost NameSurfer password

However, if you forget the password of this privileged account (or all of them, if you have several), you no longer have a means of changing the password you forgot - a chicken-and-egg problem. A similar situation may occur if you inadvertently restrict logins to a range of IP numbers that is outside your own network.

To recover from this situation, you need to use the recoverpw program. First, kill any currently executing NameSurfer process, and then execute $NS/bin/recoverpw from the shell as root. You will be prompted for a new account name and password.

The recoverpw program simply adds a new password to the given account (which may or may not already exist). It does not erase any existing password and it does not remove any other access restrictions defined for the account. Therefore, you should enter a new account name to make sure no existing access restrictions apply to it.

Then restart the server. After you have successfully logged in using the new account, you can use the WWW user interface to fix any problems with the old account, and you can then remove the new one, if desired.

Recovering lost or corrupted data files

Taking a backup copy of FusionLayer NameSurfer files

FusionLayer NameSurfer takes great care to preserve your DNS data in all situations. However, in the event of a system crash or similar malfunction, there is still the possibility of data files becoming lost or corrupted. For this reason it is important to take periodic backups of the FusionLayer NameSurfer database.

There is nothing specific about taking backup copies of most of the FusionLayer NameSurfer files and it can be done with standard tools such as tar or backup. The only exceptions are the PostgreSQL database files. The standard system way to take backup copies is not safe enough to take backup copies of the database file while PostgreSQL DBMS is running. The method for creating backup copies of the database without stopping the SQL server itself is documented at http://www.postgresql.org/docs/manuals/. FusionLayer NameSurfer program namesurferctl backup automates this process: it creates a backup copy of the database in the $NS/backup directory.

Please note: user should run namesurferctl backup command as namesurf, not as root. In a case where the user did run this command as root, he/she should remove file dbdump.bak from /usr/local/namesurfer/backup/ and repeat the process in the correct way.

Please note: executing namesurferctl backup command only starts the backup copy creation process, the process itself might take several minutes depending on the database size. It is better you create a directory for FusionLayer NameSurfer database backups in a different file system or a different physical disk and than "symlink" it to FusionLayer NameSurfer directory with the name backup.

If, for any reason, you should need to recover the database from the backup copy, you have to stop running FusionLayer NameSurfer with namesurferctl stop, and copy all the files from the backup copy to FusionLayer NameSurfer $NS/db directory overwriting the existing files.

Recovering zone information from the secondary server zone files

Another possiblity to recover zone information is to get it from the secondary server zone files. This way is more complicated, requires more manual work, and does not recover all the database contents. For example, ChangeLog and user account information cannot be recovered from the zone files. Recovering the SQL database is a preferable way in any case.

If the zone data has not yet expired from the secondary name servers (as determined by the "Expire" field of the zone's SOA record), you can recover the contents of a lost zone simply by using the "Create zone: [Copy from other name server]" command on the Index page and entering the zone name and the IP address of any one of the zone's secondaries.

Alternatively, you may obtain a backup file (the file listed in the last field of the secondary line in named.boot) from any of the secondaries, and recreate the zone from the backup file by using the "[Create zone from master file]" command on the Index page. In the case of BIND 8, the backup file name can be found by looking up the file statement for the zone in named.conf.

The user accounts must be recreated by removing the corrupted file and running the recoverpw program.