Go to main content

man pages section 4: File Formats

Exit Print View

Updated: July 2017



resolv.conf - resolver configuration file




The resolver is a set of routines that provide access to the Internet Domain Name System. See resolver(3RESOLV).

resolv.conf is a configuration file that contains the information that is read by the resolver routines the first time they are invoked by a process. The file is designed to be human readable and contains a list of keywords with values that provide various types of resolver information.

The configuration used by the resolver is managed by SMF in the svc:/network/dns/client service.

For the purposes of backwards compatibility, the resolv.conf file is regenerated from the SMF properties.

The following properties are supported and contained in the config property group of the svc:/network/dns/client service.

The following properties are single-valued or multi-valued:


Specifies the IPv4 or IPv6 Internet address of a name server that the resolver is to query. Up to MAXNS name servers may be listed, one per keyword. See resolv.h. If there are multiple servers, the resolver library queries them in the order listed. If no name server entries are present, the resolver library queries the name server on the local machine. The resolver library follows the algorithm to try a name server until the query times out. It then tries the name servers that follow, until each query times out. It repeats all the name servers until a maximum number of retries are made.


Specifies the local domain name. Most queries for names within this domain can use short names relative to the local domain. If no domain entry is present, the domain is determined from sysinfo(2) or from gethostname(3C). (Everything after the first `.' is presumed to be the domain name.) If the host name does not contain a domain part, the root domain is assumed. You can use the LOCALDOMAIN environment variable to override the domain name.


The search list for host name lookup. The search list is normally determined from the local domain name. By default, it contains only the local domain name. You can change the default behavior by listing the desired domain search path following the search keyword, with spaces or tabs separating the names. Most resolver queries will be attempted using each component of the search path in turn until a match is found. This process may be slow and will generate a lot of network traffic if the servers for the listed domains are not local. Queries will time out if no server is available for one of the domains.

The search list is currently limited to six domains and a total of 256 characters.


Allows addresses returned by the libresolv-internal gethostbyname() to be sorted. A sortlist is specified by IP address netmask pairs. The netmask is optional and defaults to the natural netmask of the net. The IP address and optional network pairs are separated by slashes. Up to 10 pairs may be specified. For example:


Allows certain internal resolver variables to be modified. The syntax is

options option ... 

where option is one of the following:


Sets RES_DEBUG in the _res.options field.


Sets a threshold floor for the number of dots which must appear in a name given to res_query() before an initial absolute (as-is) query is performed. See resolver(3RESOLV). The default value for n is 1, which means that if there are any dots in a name, the name is tried first as an absolute name before any search list elements are appended to it.


Sets the amount of time the resolver will wait for a response from a remote name server before retrying the query by means of a different name server. Measured in seconds, the default is RES_TIMEOUT. See <resolv.h>. The timeout and retrans values are the starting point for an exponential back off procedure where the timeout is doubled for every retransmit attempt.


Sets the number of times the resolver will send a query to its name servers before giving up and returning an error to the calling application. The default is RES_DFLRETRY. See <resolv.h>.


Sets RES_ROTATE in _res.options. The name servers are queried round-robin from among those listed. The query load is spread among all listed servers, rather than having all clients try the first listed server first every time.


Sets RES_NOCHECKNAME in _res.options. This disables the modern BIND checking of incoming host names and mail names for invalid characters such as underscore (_), non-ASCII, or control characters.


Sets RES_USE_INET6 in _res.options. In the Solaris BIND port, this has no effect on gethostbyname(3NSL). To retrieve IPv6 addresses or IPv4 addresses, use getaddrinfo(3SOCKET) instead of setting inet6.

The domain and search keywords are mutually exclusive. If more than one instance of these keywords is present, the last instance takes precedence.

You can override the search keyword of the system resolv.conf file on a per-process basis by setting the environment variable LOCALDOMAIN to a space-separated list of search domains.

You can amend the options keyword of the system resolv.conf file on a per-process basis by setting the environment variable RES_OPTIONS to a space-separated list of resolver options.

The keyword and value must appear on a single line. Start the line with the keyword, for example, nameserver, followed by the value, separated by white space.

The LOCALDOMAIN environment variable is only supported when an application is compiled to directly call APIs from the resolver(3RESOLV) library.

The HOSTALIAS environment variable is only supported when an application is compiled to directly call APIs from the resolver(3RESOLV) library.

Interaction with Location Profiles

DNS configuration data is sometimes managed in Location profiles (refer to netcfg(1M) for more information about location profiles). When profiles are fixed, the network configuration is being managed in the traditional way, as discussed above. When profiles are reactive, meaning the network configuration is being managed automatically, reactions to changes in the network environment occur according to policy rules specified in the location profiles.

When a fixed location (there can currently be only one, the DefaultFixed location) is active, changes made to the SMF repository will be applied to the location when it is disabled, and thus will be restored if that location is later re-enabled.

When a reactive location is active, changes should not be applied directly to the SMF repository; these changes will not be preserved in the location profile, and will thus be lost if the location is disabled, or if the system's network configuration, as managed by svc:/network/physical:default and svc:/network/location:default, is refreshed or restarted. Changes should instead be applied to the location itself, using the netcfg(1M) command; this will save the change to the location profile repository, and will also apply it to the SMF repository (if the change is made to the currently active location).

When a reactive location is active, DNS configuration data is stored in the following location profile properties:



Example 1 Listing Available Configuration Parameters for svc:/network/dns/client

Use the following command to list the available configuration parameters for svc:/network/dns/client:

$ svccfg -s network/dns/client describe -tv config
Example 2 Configuring a Client in Sub Domain to Use DNS Servers and Try givenname and Make Two Attempts To Contact Each Server

Use the following commands to configure a client in sub domain us.example.com to use two DNS servers, to try a givenname as-is if it has two or more dots, and to only make two attempts to contact each server:

$ svccfg -s svc:/network/dns/client setprop config/nameserver = \ 
net_address: ( 
$ svccfg -s svc:/network/dns/client \ 
setprop config/search = astring: (us.example.com example.com) 
$ svccfg -s svc:/network/dns/client \ 
setprop config/options = astring: "ndots:2 attempts:2" 
$ svcadm refresh svc:/network/dns/client

    Few points to note while executing this example:

  • attempts is overridden by retries option in nsswitch.conf(4) when standard application interfaces such as gethostbyname() and getipnodebyname() are used.

  • config/search and config/nameserver take a multiple values, not a space separated list.

  • config/options is a space separated list of options.

  • refresh is necessary for the requested changes to take effect.


See attributes(5) for descriptions of the following attributes:

Interface Stability
BIND 8.3.3

See Also

domainname(1M), netcfg(1M), svcadm(1M), svccfg(1M), sysinfo(2), gethostbyname(3NSL), getnameinfo(3SOCKET), getipnodebyname(3SOCKET), gethostname(3C), resolver(3RESOLV), attributes(5)

Working With Oracle Solaris 11.3 Directory and Naming Services: DNS and NIS

Working With Oracle Solaris 11.3 Directory and Naming Services: LDAP

Vixie, Paul, Dunlap, Keven J., Karels, Michael J. Name Server Operations Guide for BIND. Internet Software Consortium, 1996.