8.3   The VxWorks Resolver

The VxWorks implementation of the resolver closely follows the 4.4 BSD resolver implementation. However, the VxWorks implementation differs in the way it handles the hostent structure. The 4.4 BSD resolver is a library that links with each process. It uses static structures to exchange data with the process. This is not possible in VxWorks, which uses a single copy of the library that it shares among all the tasks in the system. All applications using the resolver library must provide their own buffers. As a result, under VxWorks, the functions resolvGetHostByName( )and resolvGetHostByAddr( )require two extra parameters (for a detailed description of the interface, see the reference entries for these routines).

Under VxWorks, the resolver library uses UDP to send requests to the configured name servers. The resolver also expects the server to handle any recursion necessary to perform the name resolution. You can configure the resolver at initialization or at run time.1 The resolver can also query multiple servers if you need to add redundancy to name resolution in your system. Additionally, you can configure the resolver library's response to a failed name server query. Either the resolver looks in the static host configuration table immediately after the failed query, or the resolver ignores the static table.2 The default behavior of the resolver is to query only the name server and ignore the static table.

8.3.1   Resolver Integration

The resolver has been fully integrated into VxWorks. Existing applications can benefit from the resolver without needing to make any code changes. This is because the code internal to hostGetByName( ) and hostGetByAddr( ) have been updated to use the resolver.3 Thus, the only thing you need do to take advantage of the resolver is to include it in your VxWorks image.

8.3.2   Resolver Configuration

The resolver library is not included by default in the VxWorks image. Thus, to include the resolver in your VxWorks image, you must modify config.h as follows:

  1. Reconfigure VxWorks with the DNS resolver on. The relevant configuration macro is INCLUDE_DNS_RESOLVER.

  1. Establish the IP address of the Domain Name Server. Change the default value for the constant:

#define RESOLVER_DOMAIN_SERVER "ip_address" 
The IP address of the server needs to be in dotted decimal notation (for example, 90.0.0.3).

  1. Make sure that a route to the Domain Name Server exists before you try to access the resolver library. To do this, you can use routeAdd( ) to add the route to the routing table. However, if you have included a routing protocol such as RIP or OSPF in your VxWorks image, these protocols add the route for you.

  1. Define the domain to which the resolver belongs by changing the default Resolver Domain in the VxWorks configuration (defined by the configuration constant RESOLVER_DOMAIN).

You must change this domain name to the domain name to which your organization belongs. The resolver uses this domain name when it tries to query the domain server for the name of the host machine for its organization.

The resolver library supports a debug option, the DNS Debug Messages parameter: DNS_DEBUG.

Using this parameter causes a log of the resolver queries to be printed to the console. The use of this feature is limited to a single task. If you have multiple tasks running, the output to the console will be garbled.


1:  For initialization, call resolvParamsGet( ) and resolvParamsSet( ). See the reference entries for these routines.

2:  The boot configuration table is maintained by hostLib.

3:  Both hostGetByName( )and hostGetByAddr( ) are hostLib functions.