This specifies the IP address(es) and port(s) of the TCP/IP name server(s).
If JANUS NAMESERVER is executed without parameters, it displays the current setting for NAMESERVER.
The JANUS NAMESERVER command only has an effect when running in an IBM (
TCPTYPE=IBM) TCP/IP environment.
The following form, invoked without any parameters, displays the current NAMESERVER setting:
The following form specifies the new NAMESERVER setting:
JANUS NAMESERVER ip_address port_number - [AND ip_address port_number]] ... - [TIMEOUT numsec] - [CACHE numcache] - [MAXTTL maxsec] - [RETRIES num]
|The IP address of the host on which the name server resides.
|The port on the name server host that is used to access the name server. If port_number is not specified, it defaults to 53, the standard port for name servers.
In the following example, the name server location is specified as port 53 on the host at IP address 126.96.36.199:
JANUS NAMESERVER 188.8.131.52 53
Under Sirius Mods Version 6.8 and later, the AND clause(s) allow specification of alternative backup name servers. This can be useful to provide redundancy in the unlikely case that there is a failure or shutdown of the primary name server.
Typically, all DNS requests go to the primary (first) name server. If a request times out, it is assumed that that name server is having problems, and the second name server is sent the request. If the second name server sends a response, it becomes the primary name server. That is, all subsequent DNS requests are sent to it. If the second name server fails to respond, the third name server is tried; if it responds, it becomes the primary name server. And so on.
The following command tells Janus Sockets to use the nameserver at IP address 184.108.40.206 as the primary name server, and to use the one at 220.127.116.11 as a backup. No port numbers are specified because the name servers use the default port of 53 (as do almost all name servers):
JANUS NAMESERVER 18.104.22.168 AND 22.214.171.124
Since name servers rarely go down, it is probably quite unnecessary to have more than two name servers, but as many as eight name servers are supported by Janus.
Note: A negative response from a name server, that is, a response that indicates that the name server does not know the requested host name, does not cause a subsequent name server to be tried. If name servers are properly configured, changing name servers should not affect the success of a hostname lookup.
The other JANUS NAMESERVER command parameters available in Sirius Mods Version 6.8 and later are:
|This sets the maximum number of seconds to wait for a name server response. The internet standard for this value, and the value used by Janus Sockets before Sirius Mods Version 6.8, was 10. While this might be a reasonable value if lookups are going against busy name servers on the other side of the world, and the internet is extremely busy, this value is absurdly high for business applications where the name server is local and all host names being sought are local. Even for internet-wide lookups, a ten-second timeout is probably overkill these days. In any case, the cost of a high timeout value is that if there should be a problem with a name server, it would take the timeout number of seconds to notice the problem and correct for it. 10 seconds is a fairly long time for this to happen, so one might want to set this timeout to a lower value.
|This parameter indicates that Janus Sockets is to save hostname-to-IP address mappings in the Online address space. This means that subsequent name server lookups would be extremely fast in-memory lookups, rather than calls to an external name server. This would both save CPU and reduce name lookup latency. numcache is the maximum number of hostnames to cache in the Online. Names are cached in virtual storage, and the amount of virtual storage required for the cache is about 100*numcache. If the number of hostnames ever looked up is relatively small, it would make sense to set numcache to a little more than this number of hostnames. Otherwise, the setting of numcache is a trade-off between CPU savings and latency and virtual storage — cache entries are saved according to a most-recently-used algorithm so that frequently requested hostnames tend to remain in cache. There are several system statistics the can be viewed via SirMon that make it possible to determine how well the name caching is working. These statistics are described below.
|This parameter indicates the maximum amount of time Janus Sockets is to save a hostname to IP address mapping in its local cache before checking it again with the name server. The name MAXTTL stands for MAXimum Time To Live. This parameter might be useful in highly dynamic environments where host addresses might change somewhat frequently. When a name server sends a hostname to IP address mapping response, it also sends a "Time To Live" with that response. This indicates that the requestor should revalidate the name after the indicated time-to-live. Janus Sockets uses the minimum of the time-to-live sent by the name server and the value of MAXTTL for the effective time-to-live of a name server response. Janus Sockets does not cache negative responses. That is, if the name server did not know a particular hostname, and that hostname is requested again, Janus Sockets will again query the name server for that hostname.
|This parameter retries a DNS UDP packet for which no response is received. This means that if Janus does a DNS lookup just when the target nameserver is down for an instant, or if the UDP packet gets lost on the network (IP networks don't have to guarantee delivery of IP packets), the DNS lookup does not fail.
Setting RETRIES to a positive integer value, say 2, instructs Janus to retry as many as two times if no response was received to a DNS lookup. Setting RETRIES to 0, its default, means no retries are attempted.
On a swamped network, it is probably better to set a JANUS NAMESERVER TIMEOUT value of, say, 3 and a RETRIES setting of 2, rather than to set TIMEOUT to 10 with RETRIES at 0. This is so because:
It probably does not make sense to set RETRIES to a value greater than 2: if packets are being dropped so frequently that three consecutive DNS requests are dropped, you have problems much more serious than the failed lookups.
RETRIES is available as of Version 7.8 of the Sirius Mods.
The JANUS NAMESERVER command can be issued at any time, so the name server lookup behavior of Janus Sockets can be dynamically changed for extraordinary situations such as name server crashes, name server reconfigurations, wholesale IP address changes on the local network, and so on.
Resets of CACHE and MAXTTL should "do the right thing." That is, a change of CACHE value should preserve as many as the new CACHE value's number of entries. For example, if CACHE went from 300 to 50, the fifty most recently used entries would be preserved. If it went from 100 to 200, all entries would be preserved, of course. So if one wants to clear the cache, numcache should be set down to 0, then back up to the desired cache size.
The following system statistics can be viewed in SirMon to determine how name server lookups are faring in an Online:
|The number of entries in the name server cache (the CACHE value on the JANUS NAMESERVER command).
|The value of the MAXTTL parameter on the JANUS NAMESERVER command.
|The current "go to" name server, in dotted IP address format with the port number in parentheses. For example:
|Total number of name lookup requests.
|Number of name lookup requests that did not succeed, that is, did not get an IP address.
|Number of name lookup requests that succeeded.
|Number of name lookup requests that found the requested name in the local cache.
|Number of requests to name servers that timed out before they got a response. With multiple name servers, a single request can try several servers and so get several timeouts. But, of course, this is probably rare in practice.
|Total time spent waiting for responses from name servers.