NIS allows the site to split the namespace into organizational unit service “domains”
NIS allows for multiple servers
Master server – authoratative for a domain
Slave server – a backup server for a domain
Each sub-domain may have master and slave servers which are authoritative for their own sub-domains.
NIS is a LOCAL name service.
You must still run DNS to be on the Internet!
Alternate: You can have your ISP run DNS for you.
NIS is not secure (No Information Security)
DNS is a distributed database which holds information about hosts IP addresses, mail routing information, and hostnames.
DNS is typically implemented via the Berkeley Internet Name Domain system (bind).
Other name service packages are available: Cisco Network Registrar is one example.
DNS uses a hierarchical tree of name servers to minimize impact on any one nameserver.
At the top of the hierarchy is the root domain.
The root domain has no name server.
DNS specifications set aside certain top-level domain names.
These domains reside under the root domain.
Each of these top level domains has one (or more) master name servers.
Unfortunately, these are referred to as the root name servers.
These top-level domains are different in the US than in other countries.
In the US, the top level domains are:
.com - commercial companies
.edu - educational institutions
.gov - government agencies
.mil - military agencies
.net - network providers
.org - non-profit organizations
.int - international organizations
.arpa - a dead elephant (historical)
Each of these domains has (at least) one authoritative name server.
In other countries, the ISO country codes are used as top level domain names:
au - Australia
ca - Canada
dk - Denmark
fi - Finland
fr - France
jp - Japan
se - Sweden
hk - Hong Kong
ch - Switzerland
Within each top-level domain there are several second level domains.
Each second level domain can have an authoritative name server.
nd.edu is a second level domain.
bind.cc.nd.edu is the name server for the nd.edu domain.
Under each second level domain you might find many subdomains.
cse.nd.edu, math.nd.edu, lsc.nd.edu and cselab.nd.edu are all subdomains of nd.edu.
These domains may or may not have their own nameservers.
If not, they rely upon the second level server for address resolution.
If so, they generally rely upon the higher level name servers for information on hosts outside of the subdomain.
music.cselab.nd.edu (18.104.22.168) is our lab nameserver. The cselab domain is a 3 rd level domain.
Music refers requests to bind.nd.edu for hosts outside of the lab domain.
There are three components to the name service system:
A daemon ( named ) that answers queries
Library routines that programs call in order to contact the server when they need to resolve hostnames/addresses.
Command line interfaces to the DNS database ( nslookup, dig, host )
Named is the process that answers queries about hostnames and IP addresses.
If named knows the answer, it replies.
If not, it queries a nameserver at a higher level to get the information required
named is also responsible for transferring the database from high level servers to the lower level servers ( zone transfers ).
Named operates in one of three modes:
master - one per domain - keeps the master copy of the DNS database for this domain.
slave - copies it’s data from the primary server via a zone transfer. Multiple secondary servers allowed within a domain.
caching - loads a few important addresses into it’s database, and gathers information on other hosts through normal operation.
Nameservers come in two flavors:
recursive nameservers - stick with a query until they get a resolution for the client machine.
The cache management becomes very resource intensive.
non-recursive - are lazy.
If they don’t know the answer, they return a “go ask him” response to the client.
Their cache of information is not very resource intensive.
Low level servers are usually recursive, while higher level servers are usually non-recursive.
A user on a system called darwin.cc.nd.edu wants to finger a user on a system called foyt.central.sun.com
Darwin looks in the /etc/hosts file to see if it knows who foyt.central.sun.com is and how to get there.
If we find an entry in the hosts file, skip to host-resolved.
If darwin does not find foyt.central.sun.com in it’s hosts file, it checks /etc/resolv.conf, finds the name of it’s nameserver.
Darwin creates a DNS query packet, and sends it to the nameserver.
The nameserver receives the DNS query packet and examines it:
“ Hi, I’m darwin, I live at 22.214.171.124, my MAC address is 08:00:20:00:4e:3f. Who is foyt.central.sun.com and how do I get there?”
The nameserver (bind.cc.nd.edu) looks in its database to see if it knows who foyt.central.sun.com is and how to get there.
If the nameserver has an entry for the foyt.central.sun.com machine skip to DNS-resolved .
If the nameserver does not have an address for the foyt machine, it sends out an DNS request to it’s master nameserver (.edu) saying “Hi, I’m bind.cc.nd.edu, I live at 126.96.36.199, my MAC address is 08:00:20:ff:ee:dd. Who is foyt.central.sun.com and how do I get there?”
This starts an iterative process of nameservice lookups...
The master .edu nameserver is lazy (non-recursive). It tells bind to go ask the nameserver for .com. The reply packet tells bind the address of a .com name server.
The master .com nameserver is lazy (non-recursive). It tells bind to go ask the nameserver at Sun.com. The reply packet dives bind the address of the Sun.com name server.
Bind queries the Sun.com nameserver.
If Sun.com is recursive, it will go ask Central.sun.com.
If Sun.com is non-recursive, it will tell bind to ask central.sun.com.
If no nameserver knows who foyt.central.sun.com is, then the user gets the always helpful “host unknown” message on their console. Skip to DONE.
If a nameserver finds the foyt.central.sun.com machine in it’s database, then it will reply back through the chain that “foyt.central.sun.com is at 188.8.131.52”.
Some of the name server(s) which are contacted add bind.cc.nd.edu, and foyt.central.sun.com to their named cache.
Bind.cc.nd.edu adds foyt to it’s named cache, and forwards the information about foyt.central.sun.com (from the master nameserver) on to darwin.
Darwin receives the address information from bind, and thanks bind.
Darwin adds the bind.cc.nd.edu information to it’s named cache.
GO TO ARP
Darwin looks to see if it has the hardware address of foyt.
If not , GO TO ARP
Darwin sends a hardware broadcast packet that says:
Hi, I’m Darwin, my IP address is 184.108.40.206, my MAC address is 08:00:20:00:4e:3f. Who is Foyt, and what is his MAC address?
If Foyt is on the same network, it replies with it’s MAC address.
Otherwise the router replies with it’s MAC address.
Darwin sends an IP packet to foyt.central.sun.com at IP address 220.127.116.11 saying “Hi, I’m darwin.cc.nd.edu, I live at 18.104.22.168 and my MAC address is 08:00:20:00:4e:3f. I’d like to contact your finger server (port 79) with the information contained in the data segment of this packet”
Foyt.central.sun.com receives the packet, decodes the protocol information and determines that it is for the /usr/etc/in.fingerd program.
Foyt forwards the packet to it’s finger daemon on port 79.
Foyt adds the darwin machine to it’s named cache.
The finger server on foyt looks up the information requested by the user on Darwin, and sends a packet out on the net saying “Hi there darwin.cc.nd.edu, I am foyt.central.sun.com. I live at 22.214.171.124, my MAC address is 11:22:33:44:55:66, here is the information you requested.
Darwin receives the information from foyt, thanks the foyt machine, and sends the data to the user’s terminal.
Darwin adds the Foyt machine to it’s named cache.
The user finds out their friend wasn’t logged in, goes home and drinks beer (or whatever users do when not logged in to a system).
Now it is time to look at the contents of the DNS database(s), and see what information is there, what it does, and how it is used.
Client-side database files
The /etc/resolv.conf file is the simplest DNS database file.
This file contains the IP address(es) of the nameserver(s), a search list, and the domain information for this host.
All hosts in the domain need a copy of the /etc/resolv.conf file so their name/address resolver knows where to go for information.
# cat /etc/resolv.conf domain cse.nd.edu ; search cse and nd
The named.conf file defines the zones and files to use.
The files referenced in the named.conf file contain resource records that govern the information provided by the name service.
The format of a DNS resource record is:
[name] [ttl] [class] type data
name - is the name of the domain object this record refers to. This can be a hostname, or an entire domain. Name is relative to the current domain unless it ends in a “ . ” (dot). If the name is blank, this record applies to the domain object from the last name command.
ttl - Time-to-live defines the length of time (in seconds) that the resource record should be kept in cache. Usually blank so the default (in an SOA record) is used.
class - defines this to be an Internet DNS record. Other record types are possible but not used by DNS.
type - identifies what type of record this is:
SOA - Start Of Authority - Marks the beginning of a zone’s data and defines global (zone) parameters.
NS - Name Server - Identifies a domain’s name server.
A - Address - Converts a hostname to an IP address.
PTR - Pointer - Converts an IP address to a hostname.
MX - Mail eXchange - Identifies where to deliver mail for a given domain name.
CNAME - Canonical Name - Defines an alias host name.
HINFO - Host Information - Describes host hardware/OS.
WKS - Well Known Services - advertises network services.
RP - Responsible Person - who is in charge of this server.
data - the data specific to this record (IP address for a host).
The database files are
root.hint – used to locate the root name servers.
d.zonename – used to define the forward lookup records for the zone.
d-reverse-ip – used to define the reverse lookup records for the zone.
; Root.hint Data file for initial cache data for root domain servers.
. 6D IN NS G.ROOT-SERVERS.NET.
. 6D IN NS J.ROOT-SERVERS.NET.
. 6D IN NS K.ROOT-SERVERS.NET.
. 6D IN NS L.ROOT-SERVERS.NET.
. 6D IN NS M.ROOT-SERVERS.NET.
. 6D IN NS A.ROOT-SERVERS.NET.
. 6D IN NS H.ROOT-SERVERS.NET.
. 6D IN NS B.ROOT-SERVERS.NET.
. 6D IN NS C.ROOT-SERVERS.NET.
. 6D IN NS D.ROOT-SERVERS.NET.
. 6D IN NS E.ROOT-SERVERS.NET.
. 6D IN NS I.ROOT-SERVERS.NET.
. 6D IN NS F.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 5w6d16h IN A 126.96.36.199
J.ROOT-SERVERS.NET. 5w6d16h IN A 188.8.131.52
K.ROOT-SERVERS.NET. 5w6d16h IN A 184.108.40.206
L.ROOT-SERVERS.NET. 5w6d16h IN A 220.127.116.11
M.ROOT-SERVERS.NET. 5w6d16h IN A 18.104.22.168
A.ROOT-SERVERS.NET. 5w6d16h IN A 22.214.171.124
H.ROOT-SERVERS.NET. 5w6d16h IN A 126.96.36.199
B.ROOT-SERVERS.NET. 5w6d16h IN A 188.8.131.52
C.ROOT-SERVERS.NET. 5w6d16h IN A 184.108.40.206
D.ROOT-SERVERS.NET. 5w6d16h IN A 220.127.116.11
E.ROOT-SERVERS.NET. 5w6d16h IN A 18.104.22.168
I.ROOT-SERVERS.NET. 5w6d16h IN A 22.214.171.124
F.ROOT-SERVERS.NET. 5w6d16h IN A 126.96.36.199
Localhost zone files
# cat localhost.zone
; Forward lookup for 127.0.0. zone
@ 1D IN SOA @ root (
42 ; serial (d. adams)
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
1D IN NS @
1D IN A 127.0.0.1
Localhost zone files
# cat 127.0.0.zone
; Reverse information file for 127.0.0 zone
@ 1D IN SOA localhost. root.localhost. (
42 ; serial (d. adams)
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
1D IN NS localhost.
1 1D IN PTR localhost.
# more d.cselab.nd.edu
; Lab Start of Authority Record
cselab 86400 IN SOA music.cselab.nd.edu. root.music.cselab.nd.edu. (
261 86400 21600 604800 86400 )
86400 IN NS music.cselab.nd.edu.
music.cselab 86400 IN A 188.8.131.52
; Now define the lab hosts
localhost 86400 IN A 127.0.0.1
loghost 86400 IN A 127.0.0.1
stu-gw 86400 IN A 184.108.40.206
86400 IN HINFO "Cisco 4500" "IOS"
stu-switch 86400 IN A 220.127.116.11
86400 IN HINFO "Cisco 4500" "IOS"
dilbert 86400 IN A 18.104.22.168
86400 IN HINFO "Generic PC" "Linux/BSD"
# cat d.70.74.129.in-addr.arpa
70 86400 IN SOA bind.nd.edu. root.music.cselab.nd.edu. (
241 86400 21600 604800 86400 )
86400 IN NS bind.nd.edu.
66 86400 IN PTR cselab-gw.cselab.nd.edu.
67 86400 IN PTR noise.cselab.nd.edu.
69 86400 IN PTR acapella.cselab.nd.edu.
70 86400 IN PTR latin.cselab.nd.edu.
71 86400 IN PTR swing.cselab.nd.edu.
72 86400 IN PTR spiritual.cselab.nd.edu.
73 86400 IN PTR march.cselab.nd.edu.
74 86400 IN PTR country.cselab.nd.edu.
75 86400 IN PTR salsa.cselab.nd.edu.
76 86400 IN PTR blues.cselab.nd.edu.
77 86400 IN PTR music.cselab.nd.edu.
78 86400 IN PTR pop.cselab.nd.edu.
Once all of the databases are set up you need to start the named daemon.
The startup is usually handled by the /etc/rc* files.
To manually start the named process, login as root, and type:
# /path/to/ named
After named is started, it is a good idea to query the DNS database to see how things look.
There are two common commands used to query the database: nslookup , and dig .
Query the database
nslookup is a standard part of BIND. It allows you to query the BIND database files to determine information about a host.
nslookup allows interactive, or command line queries.
In the simple form, the syntax is nslookup hostname
grumpy% nslookup wizard
Querying the DNS database
We have dig online (in the lab), in /usr/site/bin/dig.
The user interface for dig is nicer than the nslookup command.
dig is generally easier to use than nslookup.
Nslookup will go away soon, replaced by dig
You can ping/telnet/... a host by address, but not by hostname.
This tells you that some things are right, and something is wrong:
Right: The network card is operable, and the wiring is all correct.
Wrong: The name service software is not properly configured.
By using the IP address of the remote host, you bypass the name service.
When you use the hostname of the remote host, the name service software needs to resolve the IP address. This step is failing...
It is possible, and even common to use multiple name services concurrently.
This configuration is controlled via the nsswitch.conf file.
# cat /etc/nsswitch.conf
hosts: files dns
printers: user files
Name Services are an essential component of the network.
Local name services provide the capability of distributing several types of information.
Many of these pieces of information should not be distributed globally.
Global name services (DNS) are required for sites on the Internet.
Management and security of DNS is a time consuming task.