Chapter 20 - Name Services
Download
Report
Transcript Chapter 20 - Name Services
Name Services
Chapter 20
Chapter Goals
•
•
•
•
•
Understand Local vs. global name services.
Understand basic use of NIS.
Understand how DNS works.
Understand DNS configuration files.
Understand how to make multiple name
services work together.
Network Configuration
• Review
– In order to install a network connection on a UNIX box, you have to
do the following:
• Set up the nameservice files:
– /etc/nsswitch.conf
» set the hosts entry to use the appropriate name service
(this step to be discussed later)
» If you are using NIS, you have to set up files in /var/yp.
– /etc/resolv.conf
nameserver 129.74.70.77
domain cselab.nd.edu
search cselab.nd.edu cse.nd.edu helios.nd.edu cc.nd.edu nd.edu
Name Service
• There are several name services available.
– For UNIX, the most common are:
• Network Information Services (NIS)(NIS+)
• /etc/hosts file (static mappings)
• Network Information Service (Federated Name Services FNS)
• Domain Name Service
– For WINDOWS, the most common are:
• lmhosts file
• Wins
• DNS
Name Services
• The Network Information Service (NIS) (and it’s
successor NIS+) are local information servers.
– NIS/NIS+ provides hostname to IP address lookups,
password lookups, and other local information lookups.
– NIS/NIS+ are not global services.
• It does not make sense to make some of the NIS
services global (passwords, email aliases, ...).
• Must run DNS for Internet name lookups.
Name Services
– NIS/NIS+ Strong Points:
• Centralized Administration (all local information in one
database).
• Several versions of Unix include NIS/NIS+
– Integral part of Solaris.
• Easy to understand file formats
• Configurable
– NIS Shortcomings:
•
•
•
•
The database does not scale well.
NIS requires/facilitates centralized administration.
NIS/NIS+ are not available on all platforms.
NIS/NIS+ open the site up to security problems.
Name Services
• 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 Summary
• 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)
Name Services
• 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.
Name Services
• 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.
Name Services
• 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.
Name Services
• 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
Name Services
– 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.
Name Services
– 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 (129.74.70.77) is our lab
nameserver. The cselab domain is a 3rd level domain.
» Music refers requests to bind.nd.edu for hosts outside of
the lab domain.
Name Services
– 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).
Name Services
– 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.
Name Services
– 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.
Name Services
– START
• 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 hostresolved.
• 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 129.74.250.114, my MAC address
is 08:00:20:00:4e:3f. Who is foyt.central.sun.com and
how do I get there?”
Name Services
• 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 129.74.250.100, 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...
Name Services
• 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.
Name Services
• 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 123.45.67.89”.
• Some of the name server(s) which are
contacted add bind.cc.nd.edu, and
foyt.central.sun.com to their named cache.
Name Services
– DNS-resolved
• 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
Name Services
– host-resolved
• Darwin looks to see if it has the hardware address of foyt.
– If not, GO TO ARP
• ARP
– Darwin sends a hardware broadcast packet that says:
» Hi, I’m Darwin, my IP address is 129.74.250.114, 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.
Name Services
• Darwin sends an IP packet to foyt.central.sun.com at IP address
123.45.67.89 saying “Hi, I’m darwin.cc.nd.edu, I live at
129.74.250.114 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.
Name Services
• 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
123.45.67.89, 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.
– DONE
• 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).
Name Services
– 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.
Name Service
# cat /etc/resolv.conf
domain cse.nd.edu
; search cse and nd
search cse.nd.edu. nd.edu.
nameserver 129.74.250.100
nameserver 129.74.37.173
nameserver 129.74.4.18
Name Services
– While the resolver only requires one file, the name server
(named) requires several configuration files.
• named.conf - Sets general named parameters and points to
locations (disk files or other servers) which we obtain our
information from.
• root.hint - Points to the root domain servers.
• localhost.zone - Used to resolve the loopback addresses.
• d.zonename - The zone file that maps names to IP addresses.
• d.reverse-ip - the zone file for reverse domain lookups (IP
address to hostname).
– We’ll start by looking at some of the keywords allowed in the
named.conf file.
Name Services
• named.conf - allows several keywords:
directory - Directory for all subsequent file references.
primary - Declares this server as primary for this zone.
secondary - Declares this server as secondary in zone.
cache - Points to the cache file.
forwarders - Lists servers to which we send requests.
slave - Forces the server to forward all requests.
; - Comment (note, that # works, but is not correct!)
(data) - Allow data to span lines
@ - The current domain name
* - Wildcard (name field only) - dangerous!
Name Services
# cat /etc/named.conf
options {
version "Surely you must be joking!";
listen-on { 129.74.70.77; };
directory ".";
statistics-file "named.stats";
dump-file "named_dump.db";
// _PATH_DUMPFILE
pid-file "named.pid";
// _PATH_PIDFILE
notify yes;
auth-nxdomain yes;
interface-interval 60;
// scan for new or deleted
interfaces
allow-transfer { 129.74.250.100; 129.74.4.18; 129.74.25.98; };
forwarders { 129.74.250.100; };
};
Name Services
logging {
category default { default_syslog; default_debug; } ;
channel goobers { file "/var/log/named.log" versions 5 size 32m; } ;
category queries { goobers; };
category lame-servers { null; };
};
zone "." {
type hint;
file "root.hint";
};
Name Services
zone "cselab.nd.edu" {
type master;
file "d.cselab.nd.edu";
allow-update { none; };
allow-transfer { 129.74.250.100; 128.74.4.18; 129.74.25.98; };
allow-query { 129.74.0.0/16; };
};
zone "70.74.129.in-addr.arpa" IN {
type master;
file "d.70.74.129.in-addr.arpa";
allow-transfer { 129.74.250.100; 128.74.4.18; 129.74.25.98; };
allow-update { none; };
allow-query { 129.74.0.0/16; };
};
Name Services
zone "nd.edu" {
type slave;
file "nd.edu.zone";
masters { 129.74.250.100; 129.74.4.18; };
forwarders { 129.74.250.100; 129.74.4.18; };
allow-query { 129.74.0.0/16; };
};
zone "74.129.in-addr.arpa" IN {
type slave;
file "d.74.129.in-addr.arpa";
masters { 129.74.250.100; 129.74.4.18; };
forwarders { 129.74.250.100; };
allow-query { 129.74.0.0/16; };
};
Name Services
zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "127.0.0.zone";
allow-update { none; };
};
Name Services
• 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.
Name Services
– 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.
Name Services
• 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).
Name Services
• 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
.
6D IN NS
.
6D IN NS
.
6D IN NS
.
6D IN NS
.
6D IN NS
.
6D IN NS
.
6D IN NS
.
6D IN NS
.
6D IN NS
.
6D IN NS
.
6D IN NS
.
6D IN NS
G.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.
5w6d16h IN A 192.112.36.4
5w6d16h IN A 198.41.0.10
5w6d16h IN A 193.0.14.129
5w6d16h IN A 198.32.64.12
5w6d16h IN A 202.12.27.33
5w6d16h IN A 198.41.0.4
5w6d16h IN A 128.63.2.53
5w6d16h IN A 128.9.0.107
5w6d16h IN A 192.33.4.12
5w6d16h IN A 128.8.10.90
5w6d16h IN A 192.203.230.10
5w6d16h IN A 192.36.148.17
5w6d16h IN A 192.5.5.241
Name Services
•
Localhost zone files
# cat localhost.zone
; Forward lookup for 127.0.0. zone
$ORIGIN localhost.
@
1D IN SOA
42
3H
15M
1W
1D )
1D IN NS
1D IN A
@ root (
; serial (d. adams)
; refresh
; retry
; expiry
; minimum
@
127.0.0.1
Name Services
•
Localhost zone files
# cat 127.0.0.zone
; Reverse information file for 127.0.0 zone
$ORIGIN 0.0.127.in-addr.arpa.
@
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
$ORIGIN 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
129.74.70.77
; Now define the lab hosts
$ORIGIN cselab.nd.edu.
localhost
86400 IN A
127.0.0.1
loghost
86400 IN A
127.0.0.1
stu-gw
86400 IN A
129.74.46.33
86400 IN HINFO "Cisco 4500" "IOS"
stu-switch 86400 IN A
129.74.46.34
86400 IN HINFO "Cisco 4500" "IOS"
dilbert
86400 IN A
129.74.46.35
86400 IN HINFO "Generic PC" "Linux/BSD"
# cat d.70.74.129.in-addr.arpa
$ORIGIN 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.
$ORIGIN 70.74.129.in-addr.arpa.
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.
Name Services
– 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.
Name Services
– 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
Server: bind.nd.edu
Address: 129.74.250.100
Name: wizard.cse.nd.edu
Address: 129.74.25.101
Name Services
grumpy% nslookup cse.nd.edu
Server: bind.nd.edu
Address: 129.74.250.100
grumpy% nslookup
Default Server: bind.nd.edu
Address: 129.74.250.100
Name: cse.nd.edu
Address: 129.74.18.2
> set type=MX
> cse.nd.edu
Server: bind.nd.edu
Address: 129.74.250.100
grumpy% nslookup wizard
Server: bind.nd.edu
Address: 129.74.250.100
Name: wizard.cse.nd.edu
Address: 129.74.25.101
cse.nd.edu preference = 1, mail exchanger = mail.cse.nd.edu
cse.nd.edu nameserver = bind.nd.edu
cse.nd.edu nameserver = iugate.ucs.indiana.edu
cse.nd.edu nameserver = odin.cc.nd.edu
cse.nd.edu nameserver = thor.cc.nd.edu
mail.cse.nd.edu internet address = 129.74.25.101
mail.cse.nd.edu internet address = 129.74.18.4
bind.nd.edu internet address = 129.74.250.100
iugate.ucs.indiana.edu internet address = 129.79.1.9
odin.cc.nd.eduinternet address = 129.74.4.18
thor.cc.nd.edu internet address = 129.74.37.173
Name Services
>?
Commands:
(identifiers are shown in uppercase, [] means optional)
NAME
- print info about the host/domain NAME using default server
NAME1 NAME2
- as above, but use NAME2 as server
help or ?
- print info on common commands; see nslookup(1) for details
set OPTION
- set an option
all
- print options, current server and host
[no]debug
- print debugging information
[no]d2
- print exhaustive debugging information
[no]defname
- append domain name to each query
[no]recurse
- ask for recursive answer to query
[no]vc
- always use a virtual circuit
domain=NAME - set default domain name to NAME
srchlist=N1[/N2/.../N6] - set domain to N1 and search list to N1,N2, etc.
root=NAME
- set root server to NAME
retry=X
- set number of retries to X
timeout=X
- set initial time-out interval to X seconds
querytype=X
- set query type, e.g., A,ANY,CNAME,HINFO,MX,PX,NS,PTR,SOA,TXT,WKS
type=X
- synonym for querytype
class=X
- set query class to one of IN (Internet), CHAOS, HESIOD or ANY
Name Services
server NAME - set default server to NAME, using current default server
lserver NAME - set default server to NAME, using initial server
finger [USER] - finger the optional USER at the current default host
root
- set current default server to the root
ls [opt] DOMAIN [> FILE] - list addresses in DOMAIN (optional: output to FILE)
-a
- list canonical names and aliases
-h
- list HINFO (CPU type and operating system)
-s
- list well-known services
-d
- list all records
-t TYPE
- list records of the given type (e.g., A,CNAME,MX, etc.)
view FILE
- sort an 'ls' output file and view it with more
exit
- exit the program, ^D also exits
Name Services
• 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
Network Configuration
• Common problem:
– 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...
Name Services
• 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
passwd: files
group:
files
hosts:
files dns
ipnodes: files
networks: files
protocols: files
rpc:
files
ethers: files
netmasks: files
bootparams: files
publickey: files
netgroup: files
automount: files
aliases: files
services: files
sendmailvars: files
printers:
user files
auth_attr: files
prof_attr: files
project: files
Summary
• 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.