| Add comments here | |
|
|
| |
We know that each computer on the Internet has its own IP
address. Although this is sufficient to identify a computer for
purposes of transmitting packets, it is not particularly
accommodating to people. Also, if a computer were to be
relocated we would like to still identify it by the same name.
|
| |
Hence each computer is given a descriptive textual name. The basic
textual name of a machine is called the
unqualified-hostname31.1 and is usually less than eight characters and
contains only lowercase letters and numbers (and especially no
dots). Groups of computers have a domainname. The full
name of machine is unqualified-hostname.domainname and
is called the fully qualified hostname31.2or the qualified-hostname31.3 For example, my
computer is cericon. The domainname of my company is
obsidian.co.za, and hence the qualified-hostname of my computer
is cericon.obsidian.co.za, although the IP address
might be 160.124.182.1.
|
| |
Often the word domain usally is synonymous with
domainname, and the word hostname on its own
can mean either the qualified or unqualified hostname.
|
| |
This system of naming computers is called the Domain
Name System (DNS)
|
| |
|
| |
Domain's always end in a standard set of things. Here is a
complete list of things that the last bit of a domain can be:
|
| |
.com- A US or international
company proper. In
fact, any organisation might have a .com domain.
.gov- A US
government organisation.
.edu- A US university.
.mil- A US
military department.
.int- An organisation established by international treaties.
.org- A US or non-profit
organisation. In fact, anyone
can have a .org domain.
.net- An Internet service providor. In fact, any bandwidth reseller,
IT company or any company at all might have a
.net
domain.
|
| |
Besides the above, the domain could end in a two letter country
code.
|
| |
The complete list of country codes follows is given in Table 31.1. The .us
domain is rarely used, since in the US .com, .edu,
.org, .mil, .gov, .int, or .net
are mostly used.
|
| |
Table 31.1:
ISO country codes
 |
|
| |
Within each country, a domain may have things before it for
better description. Each country may implement a different
structure. Some examples are:
|
| |
.co.za- A South African
company.
(za = Zuid Afrika, for the old Dutch postal codes.)
.org.za- A South African non-profit
organisation.
.ac.za- A South African
academic university.
.edu.au- An
australian tertiary educational institution.
.gov.za- A South African
government organisation.
|
| |
Note that a South African company might choose a .com
domain or a .co.za domain. In our case we use
obsidian.co.za. The same applies everywhere, so there
is no hard and fast rule to locate an organisation from its
domain.
|
| |
|
| |
In practice, a user will type a hostname (say
www.obsidian.co.za) into some application like
a web browser. The
application has to then try find the IP address associated with
that name, in order to send packets to it. This section
describes the query structure used on the Internet so that
everyone can find out anyone else's IP address.
|
| |
An obvious way to do this is to distribute a long table of
hostname vs. IP numbers to every machine on the Internet.
But as soon as you have more than a few thousand machines,
this becomes impossible.
|
| |
Another obvious way to do this is to have one huge computer on
the Internet somewhere who's IP address is known by everyone.
This computer would be responsible for servicing requests for IP
numbers, and the said application running on your local
machine would just query this big machine. Of course with their
being billions of machines out their, this will obviously create far
too much network traffic31.4.
|
| |
The DNS structure on the Internet actually works like this:
|
| |
There are computers that service requests for IP
numbers -- millions of them. They are called name
servers (or DNS servers), and a request is called a DNS
lookup. However, each name server only has
information about a specific part of the Internet, and they
constantly query each other.
|
| |
There are 13 root name servers on the Internet31.5:
5
10
|
a.root-servers.net 198.41.0.4
b.root-servers.net 128.9.0.107
c.root-servers.net 192.33.4.12
d.root-servers.net 128.8.10.90
e.root-servers.net 192.203.230.10
f.root-servers.net 192.5.5.241
g.root-servers.net 192.112.36.4
h.root-servers.net 128.63.2.53
i.root-servers.net 192.36.148.17
j.root-servers.net 198.41.0.10
k.root-servers.net 193.0.14.129
l.root-servers.net 198.32.64.12
m.root-servers.net 202.12.27.33
|
|
| |
Each country also has a name server, and in turn each
organisation has a name server. Each name server only has
information about machines in its own domain, as well as
information about other name servers. The root name servers
only have information on the IP addresses of the name servers
of .com, .edu, .za etc. The .za name
server only has information on the IP addresses of the name
servers of .org.za, .ac.za,
.co.za etc. The .co.za name server only has information
on the name servers of all South African companies, like .obsidian.co.za,
.icon.co.za, .mweb.co.za, etc. The .obsidian.co.za,
name server only has info on the machines at Obsidian Systems,
like www.obsidian.co.za.
|
| |
Your own machine will have a name server defined in its
configuration files that is geographically close to it. The
responsibility of this name server will be to directly answer any
queries about its own domain that it has information about, and
also to answer any other queries by querying as many other
name servers on the Internet as is necessary.
|
| |
Now our application is presented with
www.obsidian.co.za. The following sequence of lookups
take place to resolve this name into an IP address. This procedure
is called hostname resolution and the algorithm that
performs this operation is called the resolver.
|
| |
- The application will check certain special databases
on the local machine. If it can get an answer directly
from these, it proceeds no further.
- The application will look up a geographically close
name server from the local machines configuration file.
Lets say this machine is called
ns.
- The application will query
ns with
``www.obsidian.co.za?''.
ns will decide if that IP has
been recently looked up before. If it has, there is no need to ask
further, since the result would be stored in a local cache.
ns will see if the domain is local. I.e.
if it is a computer that it has direct information about. In this
case this would only be true if the ns were Obsidian's very
own name server.
ns will strip out the TLD (Top Level Domain) .za
It will query a root name server, asking what name server is
responsible for .za The answer will be
ucthpx.uct.ac.za of IP address 137.158.128.1.
ns will strip out the next highest domain co.za
It will query 137.158.128.1, asking what name server is
responsible for co.za The answer will be
secdns1.posix.co.za of IP address 160.124.112.10.
ns will strip out the next highest domain obsidian.co.za
It will query 160.124.112.10, asking what name server is
responsible for obsidian.co.za The answer will be
lava.obsidian.co.za of IP address 196.28.133.1.
ns will query 196.28.133.1 asking
what the IP address is of www.obsidian.co.za The answer
will be 160.124.182.1.
ns will return the result to the application.
ns will store each of these results in a local
cache with an expiry date. To avoid having to look them up a second
time.
|
| |
|
| |
We made reference to ``configuration files'' above. These are
actually the files: /etc/host.conf, /etc/hosts, and
/etc/resolv.conf. These are the three and only files that specify
how applications are going to lookup IP numbers, and have
nothing to do with the configuration files of the nameserver
daemon itself, even thought a nameserver daemon might be
running on the local machine.
|
| |
When an application requires to lookup a hostname it goes through the
following procedure31.6. The
following are equivalent steps 1, 2 and 3 above with the details of the
configuration files filled in. The configuration files that
follow are taken as they my might be on my own personal machine:
|
| |
- The application will check the file
/etc/host.conf.
This file will usually have a line order hosts,bind in it, specifying that
it should first (hosts) check the local database file /etc/hosts, and then
(bind) query the name server specified in /etc/resolv.conf. The file
/etc/hosts contains a text readable list of IP addresses and
names. An example is given below. If it can get an answer directly
from /etc/hosts, it proceeds no further.
- The application will check in the file
/etc/resolv.conf
for a line nameserver <nameserver>. There can actually be
three of these lines, so that if one nameserver fails, the application
can try the next in turn.
- The application will query that name server with the hostname. If the
hostname is unqualified, then it appends the domainname of the local machine
to it before trying the query. If the keyword
search <domain1> <domain2> ... <domainN> appears in the configuration
file, then it tries a query with each of <domain1>, <domain2>
etc. appended in turn until the query successfully returns an IP. This
just saves you having to type in the full hostname for computers within
your own organisation.
- The nameserver will proceed with the hierarchical queries described
from step 4 onward.
|
| |
The /etc/hosts file should look something like this:
|
127.0.0.1 localhost.localdomain localhost
192.168.3.9 cericon.obsidian.co.za cericon
192.168.3.10 aragorn.obsidian.co.za aragorn
192.168.2.1 ra.obsidian.co.za ra
|
|
| |
The hosts aragorn, cericon and ra are the
hosts I am most interested in, and hence are listed here.
cericon is my local machine and must be listed. You can list
any hosts that you want fast lookups too, or hosts that might need to
be known in spite of nameservers being down.
|
| |
The /etc/host.conf might look like this. All of the lines
are optional:
5
|
order hosts, bind, nis
trim some.domain
spoofalert
nospoof
multi on
reorder
|
|
| |
order- The order in which lookups are done. Don't try fiddling
with this value. It never seems to have any effect. You should leave it
as
order hosts,bind (or order hosts,bind,nis if you are
using NIS -- discussed in later (possibly unwritten) chapters). Once again, bind means to then go and check the /etc/resolv.conf
which holds the nameserver query options.
trim- Strip the domain
some.domain from the end
of a hostname before trying a lookup. You will probably never require this
feature.
spoofalert- Try reverse lookups on a hostname after looking up
the IP (i.e. do a query to find the name from the IP.) If this query
does not return the correct result, it could mean that someone is trying
to make it look like they are a machine that they aren't. This is a hackers
trick called spoofing. This warns you of such attempts in your log
file
/var/log/messages.
nospoof- Disallows results that fail this spoof test.
multi on- Return more than one result if there are aliases.
Actually, a host can have several IP numbers and an IP number
can have several hostnames. Consider a computer that might
want more than one name (
ftp.obsidian.co.za and
www.obsidian.co.za are the same machine.) Or a machine that
has several networking cards and an IP address for each.
This should always be turned on. multi off is the alternative.
Most applications use only the first value returned.
reorder- Reorder says that if more than one
IP is returned by a lookup, then that list should be sorted
according to the IP that has the most convenient network route.
|
| |
Despite this array of options, an /etc/host.conf file almost always looks simply like:
|
order hosts, bind
multi on
|
|
| |
The /etc/resolv.conf file could look something like this:
5
|
nameserver 192.168.2.1
nameserver 160.124.182.1
nameserver 196.41.0.131
search obsidian.co.za ct.obsidian.co.za uct.ac.za
sortlist 192.168.3.0/255.255.255.0 192.168.2.0/255.255.255.0
options ndots:1 timeout:30 attempts:2 rotate no-check-names inet6
|
|
| |
nameserver- Specifies a nameserver to query.
No more than three may be listed. The point of having more than one
is to safeguard against a nameserver being down -- the next in
the list will then just be queried.
search- If given a hostname with less than
ndots
dots (i.e. 1 in this case), add each of the domains in turn
to the hostname, trying a lookup with each. This allows you to type in
an unqualified hostname and have application work out what organisation
it is belongs to from the search list. You can have up to six domains,
but then queries would be a time-consuming.
domain- The line ``
domain ct.obsidian.co.za'' is the
same as ``search ct.obsidian.co.za obsidian.co.za co.za''. Always
use search explicitly instead of domain to reduce
the number of queries to a minimum.
sortlist- If more than one host is returned, sort them
according to the following network
/masks.
options- Various additional parameters can be specified in this one line:
ndots- Explained under
search
above. The default is one.
timeout- How long to wait before considering a query
to have failed. The default is 30 seconds.
attempts- Number of attempts to make before failing.
This defaults to 2. This means that a down nameserver will cause
your application to wait 1 full minute before deciding that it
can't resolve the IP.
rotate- Try the nameservers at in round robin fashion.
This distributes load across nameservers.
no-check-names- Don't check for invalid characters in
hostnames.
inet6- The man page for
resolv.conf (resolver5) says:
inet6 sets RES_USE_INET6 in _res.options . This has the ef-
fect of trying a AAAA query before an A query inside
the gethostbyname function, and of mapping IPv4 re-
sponses in IPv6 ``tunnelled form'' if no AAAA records
are found but an A record set exists.
But I don't know what an AAAA query is.
|
| |
Despite this array of options, an /etc/resolv.conf file almost always looks simply like:
|
nameserver 192.168.2.254
search obsidian.co.za
|
|
| |
|
| |
A reverse lookup was mentioned under nospoof above. This is
the determining of the hostname from the IP address. The course of queries is
similar to forward lookups using part of the IP address to find out what
machines are responsible for what ranges of IP address.
|
| |
A forward lookup is an ordinary lookup of the IP address from the
hostname.
|
| |
|
| |
It has been emphasised that name servers only hold information
for their own domains. Any other information they may have
about another domain is cached, temporary data that has an
expiry date attached to it.
|
| |
The domain that a name server has information about is said to
be the domain that a name server is authoritive for.
Alternatively we say: ``a name server is authorative
for the domain''. For instance, the server
ns2.obsidian.co.za is authoritive for the domain
obsidian.co.za. Hence lookups from anywhere on the Internet having the domain
obsidian.co.za ultimately are the responsibility of
ns2.obsidian.co.za, and originate (albeit via a long
series of caches) from the host ns2.obsidian.co.za.
|
| |
|
| |
The command host looks up a hostname or an IP address, by doing
a nameserver query. Try:
for an example of a host with lots of IP address. Keep typing host
over and over. Notice that the order of the hosts keeps changing randomly.
This is to distribute load amidst the many cnn.com servers.
|
| |
Now pick one of the IP addresses and type
This will return the hostname cnn.com.
|
| |
Note that the host command is not available on all UNIX's.
|
| |
The ping command has nothing directly to do with DNS,
but is a quick way of getting an IP address, and checking if a
host is responding at the same time. It is often used as the acid
test for network and DNS connectivity. See Section 28.8.1.
|
| |
Now enter:
|
whois cnn.com@rs.internic.net
|
(Note that original BSD whois worked like whois -h <host> <user>)
You will get a response like:
5
10
15
20
|
[rs.internic.net]
Whois Server Version 1.1
Domain names in the .com, .net, and .org domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.
Domain Name: CNN.COM
Registrar: NETWORK SOLUTIONS, INC.
Whois Server: whois.networksolutions.com
Referral URL: www.networksolutions.com
Name Server: NS-01A.ANS.NET
Name Server: NS-01B.ANS.NET
Name Server: NS-02A.ANS.NET
Name Server: NS-02B.ANS.NET
Updated Date: 22-sep-1999
>>> Last update of whois database: Thu, 20 Jan 00 01:39:07 EST <<<
The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and
Registrars.
|
31.7
|
| |
(Internic happens to have this database of .com, .net, .org
and .edu domains.)
|
| |
|
| |
nslookup is a program to interactively query a nameserver.
If you run
you will get a > prompt where you can type commands.
If you type in a hostname, nslookup will return its
IP address(s) and visa versa. Also typing
any time will return a complete list of commands. By default,
nslookup uses the first nameserver listed in /etc/resolv.conf
for all its queries. However, the command
can be used to explicitly use a particular server.
|
| |
|
| |
The word record is a piece of DNS information.
|
| |
Now enter the command:
This tells nslookup to return the second type of
information that a DNS can deliver: the authoritive name
server for a domain or the NS record of the domain. You
can enter any domain here. For instance, enter
It will return
5
10
|
Non-authoritative answer:
cnn.com nameserver = NS-02B.ANS.NET
cnn.com nameserver = NS-02A.ANS.NET
cnn.com nameserver = NS-01B.ANS.NET
cnn.com nameserver = NS-01A.ANS.NET
Authoritative answers can be found from:
NS-02B.ANS.NET internet address = 207.24.245.178
NS-02A.ANS.NET internet address = 207.24.245.179
NS-01B.ANS.NET internet address = 199.221.47.8
NS-01A.ANS.NET internet address = 199.221.47.7
|
This tells us that their are four name servers authoritive for the
domain cnn.com (one plus three backups). It also tells us
that it did not get this answer from an authoritive source, but via
a cached source. It also tells us what nameservers are
authorative for this very information.
|
| |
Now switch to a nameserver that is authoritive for cnn.com:
|
| |
and run the same query:
The new result is somewhat more emphatic, but no different.
|
| |
There are only a few other kinds of records that you can
get from a nameserver. Try
to get the so-called MX record for that domain. The MX
record is the server responsible for handling mail destined to
that domain. MX records also have a priority (usually
10 or 20). This tells any mail server to try the 20 one should
the 10 one fail, and so on. There are usually only one or two MX records.
Mail is actually the only Internet service handled by
DNS. (For instance there is no such thing as a NEWSX record for
news, nor a WX record for web pages, whatever kind of
information we may like such records to hold.)
|
| |
Also try
5
|
set type=PTR
<ip-address>
set type=A
<hostname>
set type=CNAME
<hostname>
|
So-called PTR records are reverse lookups, or
PoinTeRs to
hostnames. So-called A records are forward lookups
(the default type of lookup when you first invoke
nslookup), or Address lookups.
So-called CNAME records are lookups of
Canonical NAMEes. DNS allows
one to alias a computer to many different names, even though
each has one real name (called the canonical name).
CNAME lookups returns the machine name proper.
|
| |
|
| |
dig stands for domain information groper, and sends
single requests to a DNS server for testing or scripting
purposes (it is very similar to nslookup, but
non-interactive).
|
| |
It is usually used
|
dig @<server> <domain> <query-type>
|
Where <server> is the machine running the DNS daemon
to query, <domain> is the domain of interest and
<query-type> is one of A, ANY, MX,
NS, SOA, HINFO or AXFR, of which the
non-obvious ones you can check about in the man page.
|
| |
Useful is the AXFR record. For instance
|
dig @dns.dial-up.net icon.co.za AXFR
|
lists the entire domain of one of our local ISP's.
|
| |
|
