May the source be with you, but remember the KISS principle ;-)
Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Solaris DNS Client (resolver)

News See Also Recommended Links Name Service Cache Daemon (nscd) nsswitch file getent utility Man pages
DNS Tools Configuring DNS clients DNS Security

Solaris DNS Tutorial, part 1/3

 Random Findings Humor Etc

The client piece of the DNS architecture is known as a "resolver", and the server piece is known as a “name server”.  Resolvers retrieve information associated with a domain name, and domain name servers store various information about the domain space and return information to the resolvers upon request. The resolver is a set of routines that are built into the operating system. The Solaris client resolver code is controlled by the following two files:

DNS clients (resolvers) resolve requests from its memory-based (cached) or disk-based database (/etc/hosts). The order client access various name resolution sources is defined in /etc/nsswitch.conf. The client always first access this file to determine the order and list of possible name service sources to search.

Usually the switch file instructs the client to search the local host file first. If there is no such information , the client’s name service switch file redirects the search to an appropriate service, for example DNS server, if the second entry is DNS.  If name server got the request it searches its database and tries to locates the information. in case of success the name server returns the information to its requesting client.


The /etc/resolv.conf file contains configuration directives for the DNS resolver. The following resolv.conf example shows two name servers  and three search suffixes:



The following sequence of steps is typically used by a DNS client to resolve name to address (let' assume that the client wants to access 

  1. The client system consults the /etc/nsswitch.conf file to determine name resolution order. In this example, the presumed order is local file first, DNS server second.

  2. The client system consults the local /etc/inet/host file and does not find an entry.

  3. The client system consults the /etc/resolv.conf file to determine the name resolution search list and the address of the local DNS server.

  4. The client system resolver routines send a recursive DNS query regarding the return address for to the local DNS server. (A recursive query says "I'll wait for the answer, you do all the work.") At this point, the client will wait until the local server has completed name resolution. Resolver does not maintain any cache. If case of Solaris if nscd is running its cache will be consulted before sending the query to the local DNS server. Let's assume that the name was not cached.

  5. The local DNS server consults the contents of its cached information in case this query has been tried recently. If the answer is in local cache, it is returned to the client as a non-authoritative answer.

  6. The local DNS server contacts the appropriate DNS server for the domain, if known, or a root server and sends an iterative query. (An iterative query means "Send me the best answer you have, I'll do the rest.").  Let's assume that the answer is not cached on the local DNS server. In this case the root server for org domain needs to  be contacted.

  7. The root server returns the best information it has. In this case, the only information you can be guaranteed that the root server will have is the names and addresses of all the org. DNS servers. The root server returns these names and addresses along with a time-to-live value specifying how long the local name server can cache this information.

  8. The local DNS server contacts one of the org. servers returned from the previous query, and transmits the same iterative query sent to the root servers earlier.

  9. The org. server contacted returns the best information it has, which is the names and addresses of the DNS servers along with a time-to-live value.

  10. The local DNS server contacts one of the DNS servers and makes the same query.

  11. The DNS servers return the address(es) of the along with a time-to-live value.

  12. The local DNS server returns the requested address to the client system and the WWW browser request to read a page can proceed.

Caching Daemon (nscd)

The nscd daemon is a process that implements a cache for the most common name service requests. It's not limited to DNS.

The nscd daemon starts during multiuser boot. The /etc/nscd.conf configuration file controls the behavior of the nscd daemon. The nscd daemon provides caching for the passwd, group, hosts, ipnodes, exec_attr, prof_attr, and user_attr databases.

Solaris system calls automatically reference the nscd cache if the nscd cache holds the type of data needed. Standardized calls retrieve the cached data. The names of the calls are structured as getXbyY, where X is the name of object to get and Y is the index to be used. For example gethostbyname, gethostbyaddr, and so on.

Cached data has time-to-live. It is affected by operations of local files. For example, proper modification of the /etc/hosts causes expiration of the corresponding name service cache (upon the next call to the nscd daemon.).

Configuring the nscd Daemon

The /etc/nscd.conf file contains the configuration information for the nscd daemon. Each line specifies either an attribute and a value, or an attribute, a cache name, and a value. An example of an attribute and a value is: enable-cache hosts no

An example of /etc/nscd.conf

... ... ...
# Currently supported cache names: passwd, group, hosts, ipnodes
# exec_attr, prof_attr, user_attr
# logfile /var/adm/nscd.log
# enable-cache hosts no
debug-level 0
positive-time-to-live passwd 600
negative-time-to-live passwd 5
suggested-size passwd 211
keep-hot-count passwd 20
old-data-ok passwd no
check-files passwd yes
positive-time-to-live group 3600
negative-time-to-live group 5
suggested-size group 211
keep-hot-count group 20
old-data-ok group no
check-files group yes
positive-time-to-live hosts 600
negative-time-to-live hosts 5
suggested-size hosts 211
keep-hot-count hosts 20
old-data-ok hosts no
check-files hosts yes
positive-time-to-live ipnodes 3600
negative-time-to-live ipnodes 5
suggested-size ipnodes 211
keep-hot-count ipnodes 20
old-data-ok ipnodes no
check-files ipnodes yes
positive-time-to-live exec_attr 3600
negative-time-to-live exec_attr 300
suggested-size exec_attr 211
keep-hot-count exec_attr 20
old-data-ok exec_attr no
check-files exec_attr yes
positive-time-to-live prof_attr 3600
negative-time-to-live prof_attr 5
suggested-size prof_attr 211
keep-hot-count prof_attr 20
old-data-ok prof_attr no
check-files prof_attr yes
positive-time-to-live user_attr 3600
negative-time-to-live user_attr 5
suggested-size user_attr 211
keep-hot-count user_attr 20
old-data-ok user_attr no
check-files user_attr yes

Stopping and Starting the nscd Daemon

Proper updates to the name service databases notify the nscd daemon to update its cache, as needed. However, the nscd daemon's cache might become out of date due to various abnormal circumstances or due to hand-editing files. A common way to force the nscd daemon to update its cache is to stop and start the daemon.

The preferred method for stopping and starting the nscd daemon is by using the /etc/init.d/nscd script.

Trobleshooting Name Service Information

Each name service provides tool for acquiring information stored within it. The problem is that it displays only information pertinent to a particular name service without understanding of the influence of /etc/nsswitch.conf on the real behavior of the system. To solve this problem Selecting the correct In Solaris the getent utility provides a generic retrieval interface to search several name service databases in the order in which they are specified in /etc/nsswitch.conf.

Usage of the getent utility instead of service specific utilities like nslookup, dig, ypmatch, etc can reduce troubleshooting time when isolating name service malfunctions.

Dr. Nikolai Bezroukov

Top Visited
Past week
Past month


Old News ;-) Solaris 10 What's New

BIND 9 is new in the Solaris Express 8/04 release. In the Solaris 10 3/05 release, the BIND version was upgraded to BIND version 9.2.4.

BIND is an open source implementation of DNS. BIND is developed by the Internet Systems Consortium (ISC). BIND allows DNS clients and applications to query DNS servers for the IPv4 and IPv6 networks. BIND includes two main components: a stub resolver API, resolver(3resolv), and the DNS name server with various DNS tools.

BIND enables DNS clients to connect to IPv6 DNS servers by using IPv6 transport. BIND provides a complete DNS client-server solution for IPv6 networks.

BIND 9.2.4 is a redesign of the DNS name server and tools by the Internet Systems Consortium (ISC). The BIND version 9.2.4 nameserver and tools are available in the Solaris 10 OS.

BIND 8.x-to-BIND 9 migration information is available in the System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP). Additional information and documentation about BIND 9 is also available on the ISC web site at For information about IPv6 support, see the System Administration Guide: IP Services.

Configuring DNS client

Configuring TCP/IP on Solaris - Network Configuration Procedures

Linux Network Administrator's Guide, 2nd Edition Chapter 6 Name Service and Resolver Configuration

Man Pages man pages section 1M System Administration Commands


FAQ document for the newsgroup by Chris Peckham. Here is a local copy of the most recently posted text version. You could also try a DNS book, DNSRD tips or Ask Mr. DNS.
How to set up DNS on Linux, by Nicolai Langfeldt. There are some small problems with this document, but it has some useful tips.
Simple DNS Configuration Example (RIPE-192)
Probably the quickest way to get going, if you are using BIND 8 on Unix. Just cut and paste the examples and make a few changes for a working setup.
FAQ for microsoft.public.windowsnt.dns
FAQ document for the Microsoft newsgroup microsoft.public.windowsnt.dns.


Name Service and Resolver Configuration discusses named and bind configuration. From The Network Administrators' Guide by Olaf Kirch/Andrew Anderson.

Network Databases and nsswitch.conf File

The network databases are files that provide information needed to configure the network. The network databases are: As part of the configuration process, you edit the hosts database and the netmasks database, if your network is subnetted. Two network databases, bootparams and ethers, are used to configure machines as network clients. The remaining databases are used by the operating system and seldom require editing.

Although it is not a network database, the nsswitch.conf file needs to be configured along with the relevant network databases. nsswitch.conf specifies which name service to use for a particular machine: NIS, NIS+, DNS, or local files.

Random Findings

System Administration Guide Resource Management and Network Services Naming Services Transition Kit 1.2 Administrator's System Administration Guide- Solaris Containers


FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  


Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least

Copyright © 1996-2016 by Dr. Nikolai Bezroukov. was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case is down you can use the at


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: September 12, 2017