Skip to main content

Prior to 17.1 STCP would resolve host names by first querying any configured DNS and only if there was no response or a negative response from the name servers would it search the local hosts file.

Starting in 17.1 you now have the option of searching the local hosts file first but there are some conditions. First, your application has to be built under POSIX rules on a 17.1 system. The standard set of commands in >system>stcp>command_library are all built this way but you cannot just install 17.1 without rebuilding your applications and expect to use this feature. Second you must install the Name Service Switch, nsswitch.conf, configuration file in the >system>stcp directory. A default version of the file can be found in the >system>stcp>templates directory.

As you can see from figure 1 the nsswitch.conf file appears to control all sorts of things. However, only the “hosts” and “networks” entries have any effect on system behavior. The order of the key words “dns” and “files” control the search order. If “files” comes first the hosts or networks file will be searched before querying the DNS. If “dns” comes first then the DNS will be queried before searching the files. If the “hosts” or “networks” entry includes only one of the key words then only the search corresponding to that keyword will be performed.

The major reason for using the hosts file instead of just querying the DNS is speed/disaster recovery and control. As example 1 shows when one of the name servers is not answering the name resolution time goes from 20 milliseconds to almost 2 seconds. If none of your name servers are answering, name resolution time can be very long (example 2). By placing critical names in the hosts file and searching the hosts file first you don’t have to worry about the time it takes to resolve names (example 3).

Another reason for searching the hosts file first is local control. When using a DNS you give up control of the name resolution process. Under most condition this works without problems but sometimes local control is required. For example, if it becomes necessary to temporarily or permanently block access to a host you can do it at the firewall or by redirecting requests to a problem host to a different address by changing the DNS database or hosts file.  It may not be possible to change the DNS database and changes to the firewall may take too long but you can change your own hosts file. Example 4 shows that access to www.google.com is redirected to local host.

The down side of the hosts file is that the mapping between host names and IP addresses is static. As example 5 shows name servers can be configured to provide different IP addresses to spread the load among multiple application servers. If you add an entry in the hosts file that entry is static and you lose the benefit of any load balancing that the DNS might provide. In addition you must manually maintain the hosts file if/when host IP addresses are changed.

So how should you configure the nsswitch.conf file. The comments in the file (figure 1) suggest that you do not install the file into the >system>stcp directory until all your applications have been rebuilt to use it. This will prevent possible divergent results where the old application uses DNS getting one address while new applications use the hosts file getting a different address (example 4).  In addition since the DNS has always been queried first it is quite possible that there are entries in an existing hosts file that are no longer correct. An alternative strategy is to install the file with the hosts entry set to “files dns” but make sure that the only entry in the hosts file is localhost (example 6). You can then add host /IP addresses to the hosts file as necessary with a minimum of editing, keeping in mind that any old application will not see the host file address.

OK, what about networks? It’s always been possible to give a network a name by placing it in the >system>stcp>networks file. Personally, I’ve never seen the need but you could use a name when adding a route. Interestingly, the name is not displayed when you print routes (example 7). You can also use a name when using the -network argument in the arp command. The default nsswitch.conf file for networks searches the networks file first and then queries the DNS. Unless you actually have your DNS configured to return network name information my suggestion is to remove the dns key word from the networks entry.

One final point. I’ve included two example programs. The first resolve.c uses the old name resolution function gethostbyname; the second, new_resolve.c uses the new function getaddrinfo. The gethostbyname function has been replaced by the POSIX standard function getaddrinfo. Because it is the POSIX standard you will not find any documentation about getaddrinfo in Stratadoc; however there is a great deal of documentation on the web, just google getaddrinfo.

Examples:

In the following examples the resolve_17.0 and resolve programs are based on the same source code. The only difference is that resolve_17.0 was compiled on a VOS 17.0 system while resolve was compiled on a 17.1 system. Name servers 1.1.1.1, 1.1.1.2, and 1.1.1.3 are fictions and are used to simulate a name server that is not responding. I’ve also X’ed out the host numbers of hosts that are not on a public network.

d >system>stcp>resolv.conf -match nameserver

%phx_vos#m16_mas>system>stcp>resolv.conf  11-05-24 08:07:13 mst

nameserver      164.152.XXX.XXX
nameserver      134.111.XXX.XXX

ready  08:07:13

resolve_17.0 ftp.stratus.com
ftp.stratus.com resolved to 192.52.248.14 in 20.615 ms
ready  08:07:20

d >system>stcp>resolv.conf -match nameserver

%phx_vos#m16_mas>system>stcp>resolv.conf  11-05-24 08:07:30 mst

nameserver      1.1.1.1
nameserver      164.152.XXX.XXX
nameserver      134.111.XXX.XXX

ready  08:07:30

resolve_17.0 ftp.stratus.com
ftp.stratus.com resolved to 192.52.248.14 in 1989.395 ms

ready  08:07:38
Example 1 – change in time when a name server (1.1.1.1) does not answer

d >system>stcp>resolv.conf -match nameserver

%phx_vos#m16_mas>system>stcp>resolv.conf  11-05-23 13:11:31 mst

nameserver      1.1.1.1
nameserver      1.1.1.2
nameserver      1.1.1.3

ready  13:11:31

resolve_17.0 ftp.stratus.com
ftp.stratus.com resolved to 192.52.248.14 in 14759.949 ms

ready  13:12:13
Example 2 – time to resolve a name when no name servers answer

 

d >system>stcp>resolv.conf -match nameserver

%phx_vos#m16_mas>system>stcp>resolv.conf  11-05-24 08:18:10 mst

nameserver      1.1.1.1
nameserver      164.152.XXX.XXX
nameserver      134.111.XXX.XXX

ready  08:18:10

d >system>stcp>nsswitch.conf -match hosts:

%phx_vos#m16_mas>system>stcp>nsswitch.conf  11-05-24 08:18:21 mst

hosts: files dns

ready  08:18:21

resolve ftp.stratus.com
ftp.stratus.com resolved to 192.52.248.14 in 13.702 ms

ready  08:18:31

resolve www1.stratus.com
www1.stratus.com resolved to 134.111.1.84 in 227.798 ms

ready  08:18:39
Example 3 – difference in time when searching the hosts file first and finding/not finding an entry

d >system>stcp>resolv.conf -match nameserver

%phx_vos#m16_mas>system>stcp>resolv.conf  11-05-23 13:28:51 mst

nameserver      164.152.XXX.XXX
nameserver      134.111.XXX.XXX

ready  13:28:51

d %phx_vos#m16_mas>system>stcp>hosts -match google

%phx_vos#m16_mas>system>stcp>hosts  11-05-23 13:29:29 mst

127.0.0.1      www.google.com   google.com   google

ready  13:29:29

resolve_17.0 www.google.com
www.google.com resolved to 74.125.226.115 in 180.099 ms
ready  13:29:40

resolve www.google.com
www.google.com resolved to 127.0.0.1 in 13.458 ms

ready  13:30:01
Example 4 – blocking access to www.google.com by changing its address to localhost for new applications

resolve www.yahoo.com
www.yahoo.com resolved to 67.195.160.76 in 21.439 ms
ready  13:35:56
resolve www.yahoo.com
www.yahoo.com resolved to 69.147.125.65 in 21.713 ms
ready  13:35:56
resolve www.yahoo.com
www.yahoo.com resolved to 67.195.160.76 in 30.106 ms
ready  13:35:57
resolve www.yahoo.com
www.yahoo.com resolved to 69.147.125.65 in 29.739 ms
ready  13:35:58
resolve www.yahoo.com
www.yahoo.com resolved to 67.195.160.76 in 23.880 ms
ready  13:35:58
resolve www.yahoo.com
www.yahoo.com resolved to 69.147.125.65 in 22.736 ms
ready  13:35:58
Example 5 – DNS provides multiple IP addresses

d >system>stcp>hosts

%phx_vos#m16_mas>system>stcp>hosts  11-05-24 08:32:51 mst

#
#       Sample hosts file
#
# IP address    name            alias                   # comment(s)
#
127.0.0.1       localhost loopback-host loopback lb     # required

ready  08:32:51
Example 6 – minimum hosts file

route add noahs-test 164.152.XXX.XXX 5.255.255.0
ready  13:52:54 

route print

Default Gateway: 164.152.XXX.XXX

Network Address   Gateway Address   Subnet Mask     Redirect      Life
1.2.3.0           164.152.XXX.XXX   255.255.255.0

ready  13:53:26

d networks -match noahs-test

%phx_vos#m16_mas>system.17.1>stcp>networks  11-05-23 13:53:48 mst

noahs-test          1.2.3.0

ready  13:53:48
Example 7 – adding a network using a name in the networks table

#
# Sample nsswitch.conf(5) - name service switch configuration file
#
# This configuration file is only used by programs that have been built
# under POSIX rules in release 17.1 or later.  If this configuration
# file is not present, host name lookups will be compatible with the
# older versions of the DNS software.  To avoid confusion, we
# recommend you defer using this configuration file until all
# applications have been rebuilt using POSIX.
#
# The non-POSIX DNS software (and all the DNS software prior to release
# 17.1) resolved hosts by first using DNS and then using the
# >system>stcp>hosts file.  This has a couple of minor problems:
#
#    1.  If there is a bad entry in the hosts file, it won't get
#        detected until something causes DNS to go away.  This
#        could result in confusion exactly when one doesn't want it.
#
#    2.  There is no way to over-ride a bad host coming back from DNS.
#
#    3.  Most other implementations search the hosts file first.
#
# None of these are compelling enough to make an incompatible change
# to the default behavior; however, you can switch the search order
# using this file to avoid the above issues.  To search the hosts file
# first, you want:
#
#              hosts: files dns
#
# to do DNS first and remain 100% compatible with the behavior of
# previous releases of VOS, you want:
#
#              hosts: dns files
#
# Also, note that the non-POSIX and pre 17.1 software never used dns for
# looking up networks.  The new software does.  By default, it does this
# after looking in the >system>stcp>networks file.  One can configure
# this behavior, too.  There usually isn't much useful information that
# comes back from DNS for networks.  If you want to turn off DNS lookups
# for networks, do this:
#
#              networks: files
#
group: compat
group_compat: nis
hosts: files dns
networks: files dns
passwd: compat
passwd_compat: nis
shells: files
services: compat
services_compat: nis
protocols: files
rpc: files
Figure 1 – default nsswitch.conf file found in >system>stcp>templates

#define _POSIX_C_SOURCE 200112L

#include <netdb.h>
#include <arpa/inet.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>

int main (argc, argv)
int    argc;
char   *argv [];
{
 struct hostent      *hInfo;         /* used to hold host information
 including IP address after
 resolving hostname */

 long long           jJiffy1;        /* starting jiffy time */
 long long           jJiffy2;        /* ending jiffy time */
 extern void s$read_jiffy_clock(long long *);
 double              milliseconds;   /* ms between jJiffy2 & jJiffy1 */

/* process arguments. If we don't have exactly the right number of
   arguments print out a usage message, a version message and exit */

 if (argc != 2)
 {
 printf ("Usage:ntresolve hostnamen");
 exit (0);
 }

/* Take a timestamp, resolve the name and take another timestamp */

 s$read_jiffy_clock (&jJiffy1);
 hInfo = gethostbyname (argv [1]);
 s$read_jiffy_clock (&jJiffy2);

 milliseconds = (jJiffy2 - jJiffy1) / 65.536;

 if (hInfo == NULL)
 printf ("nCould not resolve the address of %s - %3.3f msn",
 argv [1], milliseconds);
 else
 {
 printf ("%s resolved to %s in %3.3f msn", argv [1],
 inet_ntoa (*(struct in_addr *)(hInfo -> h_addr_list [0])),
 milliseconds);
 }

 endhostent ();
}
Figure 2 – resolve.c uses the old gethostbyname function

#define _POSIX_C_SOURCE 200112L

#include <netdb.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#include <stdlib.h>
#include <stdio.h>

int main (argc, argv)
int    argc;
char   *argv [];
{
struct addrinfo     *addressInfo;   /* used to hold host information */
struct sockaddr_in  *sin;           /* template to extract addr info */
int                 error;
long long           jJiffy1;        /* starting jiffy time */
long long           jJiffy2;        /* ending jiffy time */
extern void s$read_jiffy_clock(long long *);
double              milliseconds;   /* ms between jJiffy2 & jJiffy1 */
char                szIP [16];      /* holds printable IP address */ 

/* process arguments. If we don't have exactly the right number of
   arguments print out a usage message, a version message and exit */

if (argc != 2)
{
printf ("Usage:ntresolve hostnamen");
exit (0);
}

/* Take a timestamp, resolve the name and take another timestamp */

s$read_jiffy_clock (&jJiffy1);
error = getaddrinfo (argv [1], NULL, NULL, &addressInfo);
s$read_jiffy_clock (&jJiffy2);

milliseconds = (jJiffy2 - jJiffy1) / 65.536;

if (error != 0)
printf ("nCould not resolve the address of %s - %3.3f msn",
argv [1], milliseconds);
else
{
if (inet_ntop (AF_INET,
&(((struct sockaddr_in *)(addressInfo->ai_addr))->
sin_addr.S_un.S_addr), szIP, 16) == NULL)
printf ("Could not convert address %xn",
(((struct sockaddr_in *)(addressInfo->ai_addr))->
sin_addr.S_un.S_addr));
else
printf ("%s resolved to %s in %3.3f msn",
argv [1], szIP, milliseconds);
}

freeaddrinfo (addressInfo);
}
Figure 3 – new_resolve.c uses the new POSIX standard getaddrinfo function

 

© 2024 Stratus Technologies.