1. Home
  2. Support
  3. MultiNet
  4. FAQ
  5. DNS

MultiNet FAQ: DNS

 

I would like to change the amount of time it takes for DNS name lookups to fail. Can this be done?

Yes. This is controlled in any version of MultiNet by the NAMESERVER-RETRANSMISSION setting in MULTINET CONFIGURE. This controls the time between requests and the number of name server requests made before the system stops sending requests to a nonresponding server. The first argument is the time in seconds; the optional second argument is the number of tries to make.

You can change the value of NAMESERVER-RETRANSMISSION without rebooting by also defining or redefining the system-wide logical name MULTINET_NAMESERVER_RETRANS and restarting the MULTINET_SERVER (@MULTINET:START_SERVER) and SMTP_SYMBIONT (@MULTINET_START_SMTP) processes.

Can zone transfers be allowed from certain hosts only?

Access to the server can be restricted based on the IP address of the requesting system. This is done by using an address_match_list. The following can be address match lists:

  • An IP address (in dotted-decimal notation)
  • Another address match list
  • An IP prefix (in /- notation)
  • An address match list defined with the acl statement
  • A key ID, as defined by the key statement

The following Access Control Lists (ACLs) are predefined and are not case-sensitive:

  • any
  • none
  • localhost
  • localnets

Place the ! character in front of elements you want to negate.

Remember that address match lists follow the standard named.conf syntax and require a semi-colon (;) after each element. For example: 

allow-update { !192.168.0.1; 192.168.0.0/16; };

When an IP address or prefix is compared to an address match list, the list is examined and the first match (regardless of its negated state) is used. The interpretation of a match depends on the conditions defined in the following table.

When a list is being used... A non-negated match... A negated match...
as an access control list allows access. denies access.
with the listen-on option causes the DNS server to listen on matching interfaces. causes the DNS server to NOT listen on matching interfaces.
with the topology clause returns a distance based on its position on the list; the closer the match to the start of the list, the shorter the distance between it and the server. is assigned the maximum distance from the server. Note! If there is no match, the address gets a distance that is further than any non-negated list element, and closer than any negated element.

Since the address match list uses a first-match algorithm, care must be taken when using negation. In general, if an element is a subset of another element, the subset should be present in the list before the broader element.

For example, 10.0.0/24; !10.0.0.1 will never negate to the 10.0.0.1 address because a 10.0.0.1 address will match with the 10.0.0/24 element and not traverse any farther. So the 10.0.0.1 address will be accepted in the match list.

Using !10.0.0.1; 10.0.0/24 will elicit the desired effect. The 10.0.0.1 will be matched against the first, negated, element. All other 10.0.0.* addresses will pass by the 10.0.0.1 element and be matched against the 10.0.0/24 subnet element.

After upgrading MultiNet, NAMED no longer performs zone transfers from the primary server.

The following OPCOM messages are produced. What do the status codes mean and how can I correct them? 

%%%%%%%%%%% OPCOM 23-AUG-1999 11:18:03.08 %%%%%%%%%%% 
Message from user SYSTEM on XXXX named: can't exec NAMED_XFER: status = 1c 

%%%%%%%%%%% OPCOM 23-AUG-1999 11:18:03.14 %%%%%%%%%%% 
Message from user SYSTEM on XXXX named: can't exec NAMED_XFER: status = 1c

The error status in both messages is 1c. To find out what this means, enter the following: 

$ EXIT %X1c
%SYSTEM-F-EXQUOTA, process quota exceeded

It is most likely the subprocess quota that have been exceeded, which you can increase by entering the following commands: 

$ MULTINET CONFIGURE/SERVER
SERVER-CONFIG> sel domain
[The Selected SERVER entry is now DOMAINNAME]
SERVER-CONFIG> set pql-prclm 20
[PQL PRCLM of DOMAINNAME set to 20]

After you increase the quota, restart the MultiNet_Server process and the namedserver process. Enter the following commands: 

$ @MULTINET:START_SERVER
$ MU NETC DOMAIN RESTART

Can I restrict what hosts can do a zone transfer from my DNS server?

Yes. You can use the allow-transfer option in the NAMED.CONF either in the global options or the options for a specific zone to restrict zone transfers to just those IP addresses specified. In the following example the allow-transfer option in the global options restricts access to just systems in the 192.168.1.0 subnet while the allow-transfer in the zone statement for the company.com zone restricts transfers for that zone to just the 192.168.2.1 IP address. 

/*
* NAMED.CONF - bind configuration file
*/

options {
      allow-transfer { 192.168.1.0/24; };
};

zone "company.com" in {
     type master;
     allow-transfer { 192.168.2.1; };
     file "company.hosts";
};

/*
* END NAMED.CONF - bind configuration file
*/

What is the difference between DNS load balancing and cluster aliasing?

DNS load balancing is a MultiNet feature that allows you to direct a request for a given service to the least busy node. It is primarily used for TCP based services (e.g., Telnet, FTP). DNS load balancing is configured through DNS and with the CLUSTER-SERVICE-NAMES parameter as discussed in the Host Tables and DNS chapter of the Administrator's Guide. When a client wants to connect (TELNET, for example) to your cluster, they issue the command against the CLUSTER-SERVICE-NAMES hostname (e.g., TELNET CLUSTER.PROCESS.COM). Before the client can connect, it must resolve CLUSTER.PROCESS.COM into an IP address. When the client asks the MultiNet nameserver for this resolution, the results (i.e., the IP addresses for your cluster nodes) are ordered from least busy to most busy.

Cluster aliasing is a functionality of MultiNet that allows failover in the event a cluster member becomes unavailable. It is primarily intended for use with UDP based services (e.g., NFS). To use this feature, choose one or more IP addresses that are NOT IN USE on your network and assign them to the MULTINET_IP_CLUSTER_ALIASES logical as described in the Establishing IP Connectivity section of the Administrator's Guide. This parameter must be assigned the same value on all cluster members that will participate. The cluster members will negotiate amongst themselves to determine who initially binds to the cluster alias(es). If the node that has bound to the address fails, another node in the cluster will assume the responsibility of handling the connectionless (UDP) services for the cluster alias address.

Why are underscores not allowed in DNS host names?

The BIND RFC states that underscores in host names are illegal. MultiNet did not enforce this rule until v4.0B. If you upgrade from v4.0A or prior and have a zone file that contains underscores or try to do a zone transfer from a zone with underscores you will get OPCOM errors and these zones will not be loaded correctly. It is recommended that all underscores be removed from host names. There is, however, a workaround. Underscores ARE allowed on CNAME records so you can change the original A record from an underscore to a hyphen, then create a CNAME record with the underscore in it and point it to the A record.

For example, if you have the following A record: 

MARS_ALPHA.PROCESS.COM IN A 10.1.1.9

You could make the following entries instead: 

MARS-ALPHA.PROCESS.COM IN A 10.1.1.9
MARS_ALPHA. PROCESS.COM IN CNAME MARS-ALPHA. PROCESS.COM

Why do I get OPCOM error messages when I start the MultiNet nameserver as a secondary to a Windows server?

The primary DNS server for our zone runs on a Windows machine. For redundancy purposes, I would like to make one or more of my MultiNet nodes act as secondary DNS servers. I read Chapter 14 of the Administrator's Guide and feel that I've configured MultiNet properly to act as a secondary, but when I start the MultiNet nameserver, I get messages from OPCOM like: 

Multinet Server: ns: print_output: short answer (35, 68), zone test. process.com
Multinet Server: ns: zoneref: Masters for secondary zone "test.process. com" unreachable

You need to tell Windows that there are secondary nameservers on the network which are not running Windows. The easiest way to do this is to:

  1. log in as an administrator on the Windows machine
  2. Locate the registry key \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters
  3. Add a parameter BindSecondaries (type DWORD) and make its value 0 if you are running MultiNet v4.0 or later

What does the named: default: warning: check_hints: error mean?

I get the following warning on the console: 

named: default: warning: check_hints: 
A records for J.ROOT-SERVERS.NET class 1 do not match hint records

What does this mean and what can I do to correct it?

This message indicates that your current root hint file is out of date and should be updated. You can download the new version of the root hints file from ftp://ftp.rs.internic.net/domain/named.root

You will want to replace your current root hint file with the named.root referenced above. By default the root hint file is MULTINET:DOMAIN-NAME-SERVICE.CACHE.

On recent versions of VMS and FTP access from your MultiNet system you can use the following commands to copy the new version of the hint file and restart the named server: 

$ copy/ftp/log ftp.internic.net::"/domain/named.root" - multinet:domain-name-service.cache
$ multinet netcontrol domain restart

Name Server Configuration File

The standard name server software is called BIND (Berkeley Internet Name Daemon). On MultiNet systems, the service is called DOMAINNAME. The default configuration file is as follows: 

/*
**  MULTINET:NAMED.CONF
**  Sample configuration file for a caching-only name server.
**
**  NOTE: Do not edit NAMED_CONF.DEFAULT. Copy this to NAMED.CONF first.
**  NAMED_CONF.DEFAULT is replaced when MultiNet is re-installed.
*/

options {
  /* The following are defaults, but shown for examples */
  fake-iquery no;
  check-names master fail;
  check-names slave warn;
  check-names response ignore;

  /* get bind4-like behavior of listing local nets first */
  sortlist {
    { localhost; localnets; };
    { localnets; };
  };

  /* round-robin A,NS,MX records only */
  rrset-order {
    class IN type A  name "*" order cyclic;
    class IN type NS name "*" order cyclic;
    class IN type MX name "*" order cyclic;
    order fixed;
  };

};

/* disable the default control socket */
controls {
  inet 127.0.0.1 port 101 allow { none; };
};

zone "." in {
  type hint;
  file "MULTINET:DOMAIN-NAME-SERVICE.CACHE";
};

zone "0.0.127.in-addr.arpa" in {
  type master;
  file "MULTINET:DOMAIN-NAME-SERVICE.LOCAL";
};

/*
**  Uncomment the following lines if you have problems resolving
**  LOCALHOST as a domain name.
*/

//zone "localhost" in {
//  type master;
//  file "MULTINET:DOMAIN-NAME-SERVICE.LOCALHOST";
//};

The options section controls global server configuation options and sets defaults for other statements.

Each of the zone sections specifies a domain and how the server show treat that domain. Zone statements are used to make a server a master (previously refered to as a primary) or slave (previously refered to as a secondary) for a domain. The zone type hint loads the file that contains the address of the root name servers – the name servers that know all about .com, .edu, .mil, and so on. This file should be kept reasonably up to date. The current version can be downloaded using anonymous FTP from rs.internic.net in /domain/named.root.

Simple DNS Configuration Example

Most sites require only a simple DNS configuration. Following is an example of the MultiNet out-of-the-box configuration:

Set your domain name server to be 127.0.0.1 (your loopback address) with: 

$ MULTINET CONFIGURE
NET-CONFIG> SET DOMAIN-NAMESERVERS 127.0.0.1
NET-CONFIG> EXIT
$ DEFINE/SYSTEM/EXECUTIVE MULTINET_NAMESERVERS "127.0.0.1"
$ DEFINE/SYSTEM/EXEC/NOLOG UCX$BIND_SERVER000 "127.0.0.1"
$ DEFINE/SYSTEM/EXEC/NOLOG TCPIP$BIND_SERVER000 "127.0.0.1"

Edit the file MULTINET:NAMED.CONF to look like the following example: 

/*
**  MULTINET:NAMED.CONF
**  Sample configuration file for a caching-only name server.
**
**  NOTE: Do not edit NAMED_CONF.DEFAULT. Copy this to NAMED.CONF first.
**  NAMED_CONF.DEFAULT is replaced when MultiNet is re-installed.
*/

options {

  /* The following are defaults, but shown for examples */
  fake-iquery no;
  check-names master fail;
  check-names slave warn;
  check-names response ignore;

  /* get bind4-like behavior of listing local nets first */
  sortlist {
    { localhost; localnets; };
    { localnets; };
  };

  /* round-robin A,NS,MX records only */
  rrset-order {
    class IN type A  name "*" order cyclic;
    class IN type NS name "*" order cyclic;
    class IN type MX name "*" order cyclic;
    order fixed;
  };

};

/* disable the default control socket */
controls {
  inet 127.0.0.1 port 101 allow { none; };
};

zone "." in {
  type hint;
  file "MULTINET:DOMAIN-NAME-SERVICE.CACHE";
};

zone "0.0.127.in-addr.arpa" in {
  type master;
  file "MULTINET:DOMAIN-NAME-SERVICE.LOCAL";
};

/*
**  Uncomment the following lines if you have problems resolving
**  LOCALHOST as a domain name.
*/

//zone "localhost" in {
//  type master;
//  file "MULTINET:DOMAIN-NAME-SERVICE.LOCALHOST";
//};

If your system is connected to the Internet, your name server automatically finds the authoritative name servers for any domain and caches the results of all queries for later use. As long as your host can talk to the root name servers, there is no need to have a forwarders option. A server configured as described is called a caching-only name server.

If you are not connected to the Internet, then the simple out-of-the-box caching-only configuration will not work, as you will be unable to contact the Internet root name servers. Instead, configure your system to have a forwarder and use the forward-only option, by editing the NAMED.CONF file and adding the following to the options section: 

    forwarders { 10.1.1.1; };
    forward only;

Note: The forwarders line is a list of IP addresses of other name servers in your DNS on which your server will rely. Only one forwarders line is permitted. To specify multiple servers, separate their addresses with colons. Add the forward only line to protect your server from trying to directly contact other name servers.

Sample DNS Name Server Configuration

This section contains a sample name server configuration. The examples given will be for a VMS system running MultiNet; differences under Unix are noted where appropriate.

The example demonstrates how a subdomain of arizona.edu can configure and run its own name server.

In the example, you have subdomain called philosophy.arizona.edu. There is also a subnet, 128.196.23.0, and three hosts in the subdomain: the department's hub machine, socrates.philosophy.arizona.edu, and two workstations, wittgenstein.philosophy.arizona.edu (also known as ludwig) and hegel.philosophy.arizona.edu. socrates will act as the name server for the subdomain, as well as the mail exchanger for the workstations. For the sake of elegance, you want socrates also to be known as just philosophy.arizona.edu.

On socrates, edit the BIND config file MULTINET:NAMED.CONF to look like the following example. 

Options {
  /* The following are defaults, but shown for examples */
  fake-iquery no;
  check-names master fail;
  check-names slave warn;
  check-names response ignore;

  /* get bind4-like behavior of listing local nets first */
  sortlist {
    { localhost; localnets; };
    { localnets; };
  };

  /* round-robin A,NS,MX records only */
  rrset-order {
    class IN type A  name "*" order cyclic;
    class IN type NS name "*" order cyclic;
    class IN type MX name "*" order cyclic;
    order fixed;
  };

};

/* disable the default control socket */
controls {
  inet 127.0.0.1 port 101 allow { none; };
};

zone "." in {
  type hint;
  file "MULTINET:DOMAIN-NAME-SERVICE.CACHE";
};

zone "0.0.127.in-addr.arpa" in {
  type master;
  file "MULTINET:DOMAIN-NAME-SERVICE.LOCAL";
};

zone "philosophy.arizona.edu" in {
  type master;
  file "MULTINET:PHILOSOPHY.HOSTS";
};

zone "23.196.128.IN-ADDR.ARPA" in {
  type master;
  file "MULTINET:PHILOSOPHY-NET.REVERSE";
};

zone "arizona.edu" in {
  type slave;
  masters { 128.196.128.234; };
  file "MULTINET:ARIZONA.DUMP";
};

zone "196.128.IN-ADDR.ARPA" in {
  type slave;
  masters { 128.196.128.234; };
  file "MULTINET:ARIZ-REVERSE.DUMP";
};

The file PHILOSOPHY.HOSTS looks like this: 

; Authoritative data for the Philosophy.Arizona.EDU zone
@ IN SOA Socrates.Philosophy.Arizona.EDU. System.Philosophy.Arizona.EDU. (
         1       ; serial
         43200   ;   refresh - 12 hrs
         21600   ;   retry - 6 hours
         604800  ;   expire - 1 week
         86400 ) ;   minimum - 1 day
  IN NS  Socrates.Philosophy.Arizona.EDU.
  IN NS  Arizona.EDU.    ; assume Arizona.EDU is secondary for us
;
  IN A      128.196.23.5    ; Socrates' IP address
  IN MX     10      Philosophy.Arizona.EDU.
  IN HINFO  "VAX 9000/430" "VMS+MultiNet"
;
  IN TXT    "site manager: Joe Beets <beets@philosophy.arizona.edu>"
  IN TXT    "              Phone: 1 602 621 6700 / Fax : 621 5555"
;
Socrates IN   A       128.196.23.5
       IN     MX      10      Philosophy.Arizona.EDU.
       IN     HINFO   "VAX 9000/430" "VMS+MultiNet"
;
Wittgenstein IN A       128.196.23.6
; Wittgenstein can handle its own mail, so give it an MX record in
; preference to the hub machine.
       IN     MX       5      Wittgenstein.Philosopy.Arizona.EDU.
; If Wittgenstein is not reachable, then Socrates will accept mail
; for it.
       IN     MX      10      Philosophy.Arizona.EDU.
       IN     HINFO   "VAXstation 3100/76" "VMS+MultiNet"
; "Ludwig.Philosophy.Arizona.EDU" is an alias for
; "Wittgenstein.Philosophy.Arizona.EDU".
Ludwig IN     CNAME   Wittgenstein
;
Hegel  IN     A       128.196.23.7
; Hegel can't handle its own mail, so don't give it an MX record
; pointing to itself.
       IN     MX      10      Philosophy.Arizona.EDU.
       IN     HINFO   "PC clone"      "MS-DOS"

Note that the suffix .philosophy.arizona.edu is assumed for all host names in this file, unless the name has a trailing dot (.). You can change the default suffix with the $ORIGIN directive.

The at sign (@) signifies "this domain," that is, "philosophy.arizona.edu".

Note also that you can have multiple resource records per hostname without repeating the hostname on each line. The reverse domain file PHILOSOPHY-NET.REVERSE has SOA (Start of Authority) and NS (Name Service) records identical to those in the forward file. From there it looks like this: 

  5       IN      PTR     socrates.philosophy.arizona.edu.
  6       IN      PTR     wittgenstein.philosophy.arizona.edu.
  7       IN      PTR     hegel.philosophy.arizona.edu.

And that does it!

Now restart the name server, and socrates becomes the authoritative name server for philosophy.arizona.edu and for 23.196.128.IN-ADDR.ARPA.

Note: In practice, you would need to coordinate with the name server (in this example, arizona.edu) to ensure delegation of authority and secondary name service backup is handled correctly.

Domain Delegation

This document contains an example of what to do in the BIND config file and the zone file to cause domains to be delegated.

The example uses the arizona.edu delegating nameservice for philosophy.arizona.edu and 23.196.128.IN-ADDR.ARPA to socrates.philosophy.arizona.edu (128.196.23.5).

It is not necessary to change the BIND config file on the rootward name server when it delegates a subdomain. A sound standard procedure, however, would be to have the primary (main) name server (arizona.edu in this example) act as a secondary for all of its subdomains. To do this, you would add lines like the following to the BIND config file: 

secondary philosophy.arizona.edu 128.196.23.5 Philosophy.Dump
secondary 23.196.128.IN-ADDR.ARPA 128.196.23.5 Philosophy-Subnet.Dump

zone "philosophy.arizona.edu" in {
 type slave;
 masters { 128.196.23.5; };
 file "MULTINET:Philosophy.Dump";
};

zone "23.196.128.IN-ADDR.ARPA" in {
 type slave;
 masters { 128.196.23.5; };
 file "MULTINET:Philosophy-Subnet.Dump";
};

The important part of the domain delegation is for the superior zone file to have the proper NS record pointing to the primary name server for the subdomain.

The zone file for arizona.edu (MULTINET_DNS:ARIZONA.HOSTS on arizona.edu) contains: 

 $ORIGIN philosophy.arizona.edu.
 @ IN NS socrates.philosophy.arizona.edu.
 IN NS arizona.edu. ; include ourselves too
 socrates IN A 128.196.23.5 ; "glue" record

The zone file for 196.128.IN-ADDR.ARPA (MULTINET_DNS:UNIV-ARIZ.REV on arizona.edu) contains: 

 $ORIGIN 23.196.128.IN-ADDR.ARPA.
 @ IN NS socrates.philosophy.arizona.edu.
 IN NS arizona.edu.
 ; no "glue" needed.

Restart the name server, and the change is complete.

Note: The subdomain's name server should set up its zone files and set up itself as primary, and test this configuration, beforethe rootward name server makes the delegation.

Creating a DNS Root Name Server for an Off-Internet Site ("Fake Root")

This document describes how to create a DNS root name server, sometimes known as a "fake root." Read this if the following conditions apply:

  • You want to create a DNS root name server for use with load balancing.
  • Your site is not on the Internet (may be behind a firewall, for example).
  • You use MultiNet for VMS (any version).

Follow these steps:

1. Create a MULTINET:DOMAIN-NAME-SERVICE.ROOT file similar to the following: 

DNS Authoritative data
DNS DOMAIN-NAME-SERVICE.ROOT file
;
; Authoritative data for a fake root zone
;
; This example constructs a fake root name server
; to use DNS when a site is NOT on the Internet.
;
; A. Create an SOA record for the root zone listing 
; XXX.YOUR.COM as the name of the primary name server 
; for the root zone and another domain (such as 
; Fnord in the example) on this machine to act 
; as the primary contact.
;
. IN SOA XXX.YOUR.COM. Fnord.XXX.YOUR.COM. (
 1994040142 ; Serial
 7200 ; refresh every 2 hours
 7200 ; retry every 2 hours
 12096000 ; expire in twenty weeks
 604800 ) ; minimum ttl
;
;
; B. Put NS records in the root zone listing the 
; primary (XXX.YOUR.COM) and any other secondaries 
; (YYY.YOUR.COM) for the root zone:
;
;
. IN NS XXX.TGV.COM.
. IN NS YYY.TGV.COM.
;
; NOTE: BIND requires at least two root name servers.
;
; C. Delegate authority for the zones UNDER the 
; root zone to other name servers. In this example, we 
; delegate authority for YOUR.COM and the inverse-query 
; address database, 0.0.192.IN-ADDR.ARPA
; to the same set of name servers:
;
;
YOUR.COM. IN NS XXX.YOUR.COM.
YOUR.COM. IN NS YYY.YOUR.COM.
0.0.192.IN-ADDR.ARPA. IN NS XXX.YOUR.COM.
0.0.192.IN-ADDR.ARPA. IN NS YYY.YOUR.COM.
;
;
; D. To finish, add "glue A" (host address)
; records to connect the world together. Each machine 
; that is listed by name above must have a copy of 
; its A records here:
;
;
XXX.YOUR.COM. IN A 192.0.0.1
YYY.YOUR.COM. IN A 192.0.0.2
;

2. Edit the NAMED.CONF file to remove the hint zone statement and replace it with a line like: 

zone "." in {
 type master ;
 file "MULTINET:DOMAIN-NAME-SERVICE.ROOT";
};

Note: Use of secondary name servers with a root name server is not recommended.

The MULTINET:DOMAIN-NAME-SERVICE.CACHE file contains the addresses of the Internet root DNS servers. By eliminating the reference to the MULTINET:DOMAIN-NAME-SERVICE.CACHE file, you prevent access to the Internet root name servers.

3. Edit the MULTINET:DOMAIN-NAME-SERVICE.CACHE files on all other machines in your network that are running name servers (even if they are not running MultiNet), so that each machine uses this database. List the addresses of the two machines that are primary for the dot (.) statement.

Using a Caching-only Name Server

A caching-only name server has the simplified function of looking up zone data and caching (storing) what is returned. Then it can return the answers to subsequent queries by using the cached information.

A caching-only server is authoritative only for the local host, but it can automatically send requests to the Internet host handling name lookups for your domain.

In most situations, a caching-only name server sends queries directly to the name server that contains the answer. Because of its simplified nature, a DNS zone file is not created for a caching-only name server.

A caching-only name server is provided with MultiNet for OpenVMS. Once DNS is enabled, a caching-only server can begin processing data for your system without requiring further configuration. For most sites, this type of server is all that is required.

The server you select to use for caching must be reliable.

If you want to specify a name server to answer queries, add a forwarders statement to the NAMED.CONF file. The forwarders statement redirects queries to the specified name server; that name server then queries the name server that contains the answer and caches a copy.

To add a forwarders line, follow these steps.

1. Using a text editor, add a forwarders statement to the options section of the DNS configuration file MULTINET:DOMAIN-NAME-SERVICE.CONFIGURATION that includes the IP address of the DNS server or servers to which name server requests are forwarded.

For example, to add two servers with IP addresses 192.1.1.98 and 192.1.1.99 to your network, the forwarders line would be: 

; 
forwarders { 192.1.1.98; 192.1.1.99; };
;

2. Once the forwarders line is added, restart the master server: 

$ reply/enable=network/temporary
$ multinet netcontrol domain restart

Note: When using a forwarders line, select only a name server over which you or another member of your staff has control. If the name server data becomes corrupted, your caching-only name server then acquires its corrupted data and stays that way until the forwarded name server is fixed.

Adding Forwarders to Your DNS Configuration

A forwarder provides a way to keep off-site DNS traffic to a minimum by allowing you to designate a name server that handles inquiries for other name servers. Off-site queries are sent first to the forwarder, which caches the response information. Then the forwarder attempts to answer future queries from information already in its cache.

When selecting a name server to designate as a forwarder, make sure that you (or your staff) have control over the server. Otherwise, if zone data is corrupted on the host indicated in the forwarders line, you have no way to prevent the other name server from acquiring the same corrupted data. If control of the system is not available, the corrupted data stays that way until the other host is fixed.

To add a forwarder, add a forwarders line to the DNS configuration on all the other servers at your site to direct them to send their queries through the designated forwarder. The DNS configuration on the forwarder itself is not modified.

To add a forwarders line, follow these steps.

1. Using a text editor, add a forwarders statement to the optoins section of the DNS configuration file MULTINET:NAMED.CONF that includes the IP address of the DNS server or servers to which name server requests are forwarded.

For example, to add two servers with IP addresses 192.1.1.98 and 192.1.1.99 as forwarders for your network, the forwarders line would be: 

forwarders { 192.1.1.98; 192.1.1.99; };

2. Once the forwarders line is added, restart the master server: 

$ reply/enable=network/temporary
$ multinet netcontrol domain restart

How often is the DDNS zone information check-pointed to the zone file, and is this configurable?

DDNS zone information is check-pointed to the zone file hourly, which is every time the zone goes into maintenance. It is not configurable. The changes get written to a log file temporarily, and then re-applied if something happens to the server (when it comes up, it looks for the log file, and applies the changes if they are there). The updates are re-applied after loading the zone on startup, providing that the nameserver believes the zone file hasn't been changed since the last time it committed the changes to the file.

When the nameserver is shut down correctly [e.g. MU NETC DOMAIN STOP], the dynamic updates are committed to the file during the shutdown procedures; The logfile is only there for uncontrolled shutdowns [e.g. process/system crashes, killing the nameserver process, etc....]

How do I disable OPCOM Messages from NAMED?

Since I upgraded from a really old version of MultiNet, I get the following OPCOM messages from NAMED. What are they and can I disable them? 

%%%%%%%%%%%  OPCOM  28-JAN-2000 10:05:01.64  %%%%%%%%%%%
Message from user SYSTEM on PSC1
named: NSTATS 949053901 949053895
 
%%%%%%%%%%%  OPCOM  28-JAN-2000 10:05:01.65  %%%%%%%%%%%
Message from user SYSTEM on PSC1
named: XSTATS 949053901 949053895 RR=1 RNXD=0 RFwdR=0 RDupR=0 RFail=0
RFErr=0 RErr=0 RAXFR=0 RLame=0 ROpts=0 SSysQ=1 SAns=0 SFwdQ=0
SDupQ=0 SErr=0 RQ=0 RIQ=0 RFwdQ=0 RDupQ=0 RTCP=0 SFwdR=0 SFail=0 SFErr=0
SNaAns=0 SNXD=0

%%%%%%%%%%%  OPCOM  29-JAN-2000 10:41:20.02  %%%%%%%%%%%
Message from user SYSTEM on PSC1
named: Lame server on 'node1.process.com'  
  (in 'process.com'?):[10.1.0.2].53 'C.ROOT-SERVERS.NET'

These are informational messages from the new BIND v8 namserver and none represents a serious problem. The NSTATS and XSTATS messages (the first two shown) are the statistics for the currently running nameserver. The last message means that the nameserver has found a "lame server". A lame server is a server that supposedly has authority for a particular zone, but is not configured as such.

Using the new configuration options, these and other informational messages can be surpressed easily or even sent to a file rather than to OPCOM. The new nameserver in MultiNet has a truly advanced logging configuration that provides more control than in the previous version.

Add the following logging statement to your NAMED.CONF file to keep all informational messages from going to OPCOM. 

logging {
  channel no_info_opcom {
      syslog daemon;
      severity notice; 
      print-severity yes;
      print-category yes;
    };
  category default { no_info_opcom; default_debug; };
};

The BIND v8 Configuration File Guide has in depth-information on how to configure logging for the BIND server.