|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Skepticism and critical thinking is not panacea, but can help to understand the world better
|News||See Also||Recommended Links||Name Service Cache Daemon (nscd)||nsswitch file||getent utility||Man pages|
|DNS Tools||Configuring DNS clients||DNS Security||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:
- /etc/resolv.conf should contains the list of up to three nameservers and search directive to specify the scope of a DNS query
- /etc/nsswitch.conf Should contains the reference to DNS along with the hosts entry
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:
domain nj.bigcorporation.com nameserver 192.168.10.11 nameserver 192.168.20.88 search london.bigcorporation.com, ny.bigcoporation.com, toronto.bigcorporation.com
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 www.softpanorama.org):
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.
The client system consults the local /etc/inet/host file and does not find an entry.
The client system consults the /etc/resolv.conf file to determine the name resolution search list and the address of the local DNS server.
The client system resolver routines send a recursive DNS query regarding the return address for www.softpanorama.org 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 www.softpanorama.org was not cached.
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.
The local DNS server contacts the appropriate DNS server for the softpanorama.org. 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.
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.
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.
The org. server contacted returns the best information it has, which is the names and addresses of the softpanorama.org. DNS servers along with a time-to-live value.
The local DNS server contacts one of the softpanorama.org. DNS servers and makes the same query.
The softpanorama.org. DNS servers return the address(es) of the www.softpanorama.org. along with a time-to-live value.
The local DNS server returns the requested address to the client system and the WWW browser request to read a page can proceed.
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.).
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
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
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.
You can also manually stop the
daemon as follows: /etc/init.d/nscd
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
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 http://www.isc.org. For information about IPv6 support, see the System Administration Guide: IP Services.
Google matched content
http://www.securecomputing.com/index.cfm?skey=430 -- list of DNS tutorials
Configuring TCP/IP on Solaris - Network Configuration Procedures
Linux Network Administrator's Guide, 2nd Edition Chapter 6 Name Service and Resolver Configuration
docs.sun.com man pages section 1M System Administration Commands
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.
System Administration Guide Resource Management and Network Services
docs.sun.com- Naming Services Transition Kit 1.2 Administrator's
docs.sun.com- System Administration Guide- Solaris Containers
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. 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 softpanorama.org is down you can use the at softpanorama.info|
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: March 12, 2019