|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
|May the source be with you, but remember the KISS principle ;-)|
|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
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 quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard 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 DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting 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
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How 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. 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: September 12, 2017