The Dynamic Name System

DNS

good urls:

http://www.dns.net/dnsrd/- DNS resources

http://www.isoc.org/briefings/016/ - a tutorial about DNS for non-specialist bby the chief scientist of RIPE

ftp://ftp.rs.internic.net/domain/named.root - for the latest named.root file.

http://www.iana.org/gtld/gtld.htm– listing of top level domains and sponsoring organizations.

http://www.iana.org/cctld/cctld-whois.htm – listing of country domains.

http://www.networksolutions.com/en_US/whois/index.jhtml - domain lookup service

http://www.traceroute.org/ - allows you to trace the route from your ccomputer to selected routing points

The book to get: DNS and BIND by Albitz and Liu (O'Reilly and Assoc.)

The Domain Name System is an Internet wide system that allows systems on one network to send packets or email to a system on another network without knowing its IP address. DNS is an IP Address to Name resolution service. It works automatically to provide IP addresses to packets, but can also be queried directly using the command nslookup. DNS can also associate names with IP addresses.

DNS domains: DNS is based on a hierarchical system of domains, each of which has a server that provides DNS name resolution for the systems on its network. Above the entire DNS namespace (all systems served by the DNS system) is the root domain . (dot). The root domain is served by 13 servers called the root servers. Each is named in alphabetical order: A.ROOT.SERVERS.NET to M.ROOT.SERVERS.NET, and they are distributed across the world to provide (relatively) local name resolution for the second level servers. Each has the same information; multiple servers are needed because the traffic is too great for any single one. Below the root domains, the top level domains (.com, .edu, .gov, .mil, .uk, .jp etc) also have multiple servers associated with each, including some of the root servers, which thereby provide service to both the root and top level domains. ICANN nominally has control of these domains, which it has assumed from the InterNIC. Within the top level domains, the second level domain servers generally provide name resolution for a single routing domain, and must be registered with the root servers. For the most part, these servers exist to serve a corporation or educational or governmental institution. They may have names like sun.com, mit.edu or nasa.gov. Second level domains may be subdivided into smaller domains, or not, as the owner of the domain chooses for their own organizational purposes. The levels of domain subdivision cannot exceed 127 and the total characters in the name cannot exceed 255. Thus Sun.com is subdivided into ebay.sun.com, sfbay.sun.com, east.sun.com, central.sun.com etc. Each subdomain may also be further subdivided. The name of a system or network is written from the lowest level subdivision to the top level, which is . (dot). Thus, a system called maui on the subdomain ebay in sun.com would have the name maui.ebay.sun.com. . This is its fully qualified domain name (FQDN) which includes the entire name from lowest to highest level including the root domain, dot. The FQDN is required for some DNS files, but is otherwise rarely used. Instead, a relative domain name (RDN) may be used. The relative domain name, like a relative file name, assumes a starting point. For a relative file name, the current working directory is that starting point. For a relative domain name, the domain of the current system is that starting point. Thus, if I want to send email to jon.smith at maui.ebay.sun.com from kauai.ebay.sun.com, I need only use the address: jon.smith@maui . The absence of the . indicates that this email address does not contain a a fully qualified domain name, so the domain of the current system, ebay.sun.com. is assumed.

DNS Servers: ICANN requires every second level domain to have at least two servers with its name information registered with the DNS root servers. That second level domain server may serve multiple domains, as do primary servers maintained by ISPs. The total of all systems in a server's domains are referred to as its "zone of authority." A primary server is a server on which is kept all the most up-to-date information about systems in the domain. If there is a mistake in the primary server's files, that mistake will prevent lookups for the system that has the error. Secondary domain servers, or "slave" servers are added to a network as needed. The slave servers get configuration files directly from the primary server on a periodic basis, and store this information on disk. Caching-only servers may also exist and are used to reduce network traffic. These do not store anything on disk; they merely query an authoritative server and cache the reply to reduce network traffic. All servers cache information and look at that cache before they go to disk, caching-only servers, as their name suggests, have no information on disk. Forwarding servers are types of primary or secondary servers. They are the systems that handle all DNS lookups that have to go out to the root servers. Since they then cache the information that comes back, they can often provide information from that cache, and thus reduce traffic on the network, and load on the root servers. The forwarder system is designated in the file /etc/named.conf on the non-forwarder systems.

Reverse lookups: While DNS is mainly used to lookup IP addresses, it can also take an IP address and look up a hostname to go with it. Such lookups are called "reverse" lookups, and are done via the in-addr.arpa. domain. A system in this domain is represented by its IP address, typed backwards, and with the in-addr.arpa. appended. Thus 128.50.2.1 is represented as 1.2.50.128.in-addr.arpa.. There are two final domains (arpa and in-addr) for historical reasons, and the root name servers serve both.

Name resolution with DNS: DNS clients and servers begin the process of name resolution with the file /etc/nsswitch.conf. This is the file used for all name resolution, including NIS and NIS+. DNS only provides name resolution for hosts, so only the hosts line is affected. The administrator must edit this file on DNS client systems and server systems to provide whatever sequence of name resolution is desired. Ideally the "hosts" entry is some variation on "files <name service, such as nis or nisplus> dns" "files dns" or "<name service> dns", since it makes no sense to go to DNS for information that is locally available. Once the client or server has exhausted local resources in its effort to get an IP address for a hostname, it then goes to DNS, by checking the file /etc/resolv.conf. This file contains two important entries: the name of the client's domain, and the name of the server it should use. This may be any type of a server, primary, secondary or caching-only, so the administrator can balance the load on the local servers using entries in this file.

The client then contacts the server with its request. The server checks its cache and disk, and if it doesn't find the information, contacts the domain nameserver, if it has that information in its cache, or if it doesn't, the root nameserver. The root nameserver provides the address of the next server to check, which provides the address of any further servers that may need to be queried.

When information about name resolution comes off a disk, it is said to be authoritative. When it comes from a cache, it is non-authoritative. All types of servers may therefore provide non-authoritative information, but caching-only servers provide only non-authoritative information.

As an example: for a reverse lookup (assuming nothing is cached): if we are looking for the hostname of the system with IP address 24.33.90.111, starting with the system host1.tampabay.rr.com:

1. host1.tampabay.rr.com. sends a request to the name server for a reverse lookup for 24.33.90.111
2. ns1.tampabay.rr.com queries a root server.
3. The root server returns an ip address for the nameserver 24.in-addr.arpa since it serves both the in-addr and the arpa domains.

4. ns1.tampabay.rr.com queries 24.in-addr.arpa
5. 24.in-addr.arpa returns an ip address for the nameserver 33.24.in-addr.arpa
6. ns1.tampabay.rr.com queries 33.24.in-addr.arpa
7. 33.24.in-addr.arpa returns an ip address for the nameserver 90.33.24.in-addr.arpa
8. ns1.tampabay.rr.com queries 90.33.24.in-addr.arpa
9. 90.33.24.in-addr.arpa returns a FQDN for 24.33.90.111
10. ns1.tampabay.rr.com returns a FQDN for 24.33.90.111 to host1.tampabay.rr.com

Server setup: /etc/named.conf

DNS servers run the daemon in.named which looks to the file /etc/named.conf for its configuration information. in.named starts at boot time by /etc/rc2.d/S72inetsvc if /etc/named.conf exists. /etc/named.conf tells the server 1. over which domains it has authority (its "zones of authority") 2. the file with the location of the root servers (/var/named/named.root) 3. name resolution information for inverse lookups from IP address to name 4. The names and IP addresses of servers which are a level below the current server. 5. Information about security, forwarding etc. 6. What type of server it is: primary, secondary, etc. 7. logging. This file must therefore first be set up. It is much easier to copy an existing /etc/named.conf file and then to customize it than to set it up from scratch. /etc/named.conf has numerous formatting details; leaving out a semi-colon will prevent DNS from working. Any time this or any other configuration file is altered, you must stop and start in.named.

The file /etc/named.conf cites the file named.root, usually placed in the directory /var/named. This file contains the lookup information for the root servers, and must be downloaded from the InterNIC (see url above) and installed in the appropriate directory. No other configuration is required for this file on a DNS server.

Zone files: /etc/named.conf lists a set of "zone files" which contain detailed information for the domains defined in /etc/named.conf. These zone files have a standard format which differs from that of /etc/named.conf. Three zone files per domain must be set up by the administrator: the domain-info file, /var/named/<domain file name from /etc/named.conf>, the inverse-domain-info file, /var/named/<inverse domain file name from /etc/named.conf>, and and the loopback-domain-info file, /var/named/<loopback file name from /etc/named.conf>. One additional file, /var/named/named.root, is downloaded from InterNIC, and no matter how many domains served by a DNS server, only one copy of this file is required. It is also possible to use the same loopback-domain-info file for all domains served. Except for the file /var/named/named.root, the names of these files are up to the administrator. Since DNS can be confusing, they should be kept simple. Examples of reasonable names for zone files, for the zone zoo.edu might be: /var/named/zoo.edu.zone (domain-info file), /var/named/zoo.edu.rzone (inverse-domain-info file), and /var/named/loopback.domain.info (loopback-domain-info file).

The file /var/named/<domain-info> contains actual mapping information for host names and IP addresses, and will be used by in.named to set up the zone files specified in /etc/named.conf. It has the standard zone file type format, including an SOA record, but also defines name servers, glue records and name to address mappings for individual hosts. The name server records contain the following:

IN NS server_name

for each server serving this domain. It is not necessary to specify if a server is master or slave. If any of the name servers are in another domain than the current, their IP addresses must be defined in what is called a "glue" record. These records look like:

Each host in the domain must then have a name to address mapping in the format:

The loopback address must also be defined here with:

localhost IN A 127.0.0.1

This last line does not vary. Aliases such as those for web servers must also be defined here using the CNAME keyword. (Such an alias has the same effect as a virtual interface: it associates a name with an interface on the network). If the second entry is left out of a line, "IN" is assumed.

The file /var/named/<inverse-domain-info> is similar to the domain-info file, except that the address to name mappings for individual hosts take the form:

/var/named/<loopback-domain-info> also has an SOA record identical to those in inverse-domain-info and domain-info,but its name server is limited to the current host. It also contains the line:

1.0.0 IN PTR localhost.zoo.edu

Client setup:

Configure these two files:

/etc/nsswitch.conf - contains the line

hosts: files [nis|nisplus] dns

Files MUST be first, or name resolution cannot occur during boot.

/etc/resolv.conf contains:

search <domain_name/s> # domain names to append to requested names that are not FQDN. The first is the client's current domain. Thus if you type # mail root@fish

the domain names in the list will be resolved in order, until fish is found in one.

nameserver <IP_address> #nameservers for the domain. May have up to 3, each on a line. This line must use an IP address, not a hostname.

nslookup: The command "nslookup" can be used to query DNS directly for either IP addresses or hostnames. If you type the command with a hostname, you will get the IP address, if you type it with an IP address (nslookup 192.68.2.1) you will get a domain name. If you type nslookup and hit return, you get an interactive session. You can then set the server you want to query, change the type of record you query (default is type A), list your DNS servers etc. You may also just type in a hostname, and you will get back an IP address.

Acronyms:

BIND – Berkeley Internet Name Domain – the most frequently used implementation of DNS; used in Solaris 8.

DIG – Domain Information Groper – DNS debugging tool.

DNS – Domain Name Service/Domain Name System

FQDN – Fully Qualified Domain Name – a name which includes all domains, in order from lowest level to top level, followed by . Example: ebay.sun.com.

ICANN – Internet Corporation for Assigned Names and Numbers – the organization which has now assumed responsibility for the registration of domain names. This used to be the responsibility of InterNIC.

RDN – Relative Domain Name – a domain name which may be relative to a location below the top level, and is not followed by the . Example: ebay

SOA – Start Of Authority – a record denoting what server is responsible for a domain and time info.

Definitions:

authoritative answer – a DNS lookup response which is

1. From a disk, not a cache 2. As correct as humanly possible.

non-authoritative answer – a DNS lookup response which is

1. From a cache. 2. If an update is made to the authoritative server which supplied the information in the cache, it may be wrong.

DNS namespace – all the hierarchical domains on the Internet plugged into DNS.

domain – a collection of systems, routers, interfaces and networks under the control of an administrative entity, and which has a name.

forwarding server – looks at next server up, as well as in own info/cache. Does not go directly to .

h2n – Perl script to automate DNS file generation. There is a man page for h2n located at http://www.crihan.fr/system/linux/maint/bind/old/h2n-man.html.

in-addr.arpa. – domain that is used to turn an IP address into a name. Addresses in this domain are written backwards from IP addresses. For example, 128.50.1.2 becomes 2.1.50.128.in-addr.arpa.

in.named – DNS server daemon started by inetsvc at run level 2. It must be stopped and restarted every time a change is made to the /etc/named.conf or zone files.

single component lookup – one component of name is looked up at a time – first root, then net, then internic etc.

slave server – a server which has copies of the resource files from the server.

stub server – a slave server that only copies NS information. It is specified with the entry "type stub" in the zone file.

zone – a subdomain.

Zone of Authority – a domain for which a DNS server is authoritative. One server may have more than one zone of authority.

zone transfer – transfer of data to secondary server from primary server.

Commands:

nslookup <system-name|IP address> – query DNS servers for host names or IP

addresses.

with no options – start interactive nslookup session. In such a session, you can list

servers, nameservers, reverse servers, secondary (alternate) servers. You can

also choose a server to query.

Commands for interactive sessions:

> ls <domain name> - lists the contents of a doman

>set q=ns - sets the default query to name servers from names. Then:

> <domain name> will list all the systems in a domain.

>set q-ptr - sets the default query to reverse lookups. Then when you type

an IP address, the name is returned.

> server <new server name> - sets a new server to query.

pkill -INT in.named - causes in.named daemon to write its cache to /var/named/named-dump.db. This can be used to see if there was a problem.

pkill -USR1 in.named - increase in.named daemon debug level by 1 (0-10 possible.) Each time you repeat THIS command, the debug level increases again. Output is sent to /var/named/named.run.

pkill –USR2 in.named - turn off in.named debug output.

pkill –HUP in.named - restart in.named. This command forces in.named to reread /etc/named.conf. It must be run every time a change is made to the DNS configuration files.

pkill -ABRT in.named – forces statistics on process usage to be written to /var/named/named.stats.

named –bootconf – translates /etc/named.boot (< Solaris 2.6) to /etc/named.conf format.

Example: named-bootconf -i /etc/named.boot -o /etc/named.conf

/usr/sbin/in.named - start the DNS server daemon in.named.

ndc - name daemon control program, controls the operation of a name server. It runs in interactive mode with the prompt ndc> as soon as it is invoked. All commands that can be entered at the prompt can also follow ndc at the command line.

ndc> /h - provides an abbreviated help menu - same as ndc /h

ndc> help - provides a detailed help menu - same as ndc help

ndc> restart - restarts in.named. Same as pkill -HUP in.named and ndc restart

ndc> status - report on DNS status. Same as ndc status.

ndc> dumpdb - dumps in.named's cache. Same as pkill -INT in.named and ndc dumpdb.

ncd> /e - exit. Same as ndc /e

Files:

/etc/named.conf – in.named configuration file, read by daemon at start up.(this file was called /etc/named.boot prior to Solaris 2.6)

Entries in /etc/named.conf (this file is not case-sensitive, nor does it use FQDNs); all undefined text entries should be surrounded by quotes (that is, any text entry which is not a keyword defined for use in the file. Terms such as forwarders or options are defined, so do not require quotes. Zone names such as "marketing.com" are not defined, so require quotes…if in doubt, use quotes); each entry is followed by a semi-colon and surrounded by curly brackets.

#comments – begin with #, or //, or are surrounded by /* */ as in /* comment */

options {

#a list of options which apply to all zones for which the server is authoritative directory "/var/named"; #sets the default directory for all files subsequently

# mentioned in this file unless they have absolute

# pathnames.Optional (default: .) master/slave

forwarders { # sets the forwarding servers. Optional (default: no forwarding)

128.50.1.3; # master/slave.

};

forward only; # outside lookups are done by the forwarders only.

}; # Optional (default: first – try forwarders first, then server

# tries for itself. master/slave.

include "absolute_filename" # include the contents of this file at this location. Optional

zone "." in { # definition of the root domain . Required "in" means

# "internet" type network, which is the default. master/slave.

type hint; # queries for this information will return a list of servers to contact.

file "named.root"; # try the servers in this file until one responds with a list of servers.

# Then try those in order. You can call this file whatever you want.

};

zone "zoo.edu" in { # definition of the domain "zoo.edu" Required for each

# zone for which the server is authoritative. master only.

type master; # this server is the master server for the domain

file "zoo.edu.zone"; # the name of the zone file containing resource records

}; # for this domain. Choice of name is up to you.

zone "veggie.edu" in { # definition of the domain "veggie.edu"

type slave; # this server is a slave server for the domain

file "broccoli"; # the name of the zone file containing resource records.

masters { # The file name is not required, but if not present the slave

# must contact the server every time it does a lookup.

128.50.1.3; # IP address(es) of master servers for veggie.edu.

}; # Required for slave only.

};

zone "2.50.128.in-addr.arpa" in { # definition of the inverse lookup zone.

type slave; # this server is a slave server for the inverse domain

file "junk"; # the name of the zone file containing resource records.

masters { # The slave must have a reverse entry for each forward entry.

128.50.1.3; # IP address(es) of master servers for veggie.edu.

}; # Required for slave only.

};

zone "1.50.128.in-addr.arpa" in { # definition of the inverse lookup zone. Required

type master; # this server is the master server for the domain.

file "zoo.edu.rzone"; # the name of the file containing resource records.

}; # You need one of these definitions for every

# network for which the server is authoritative. master only

zone "127.in-addr.arpa" in { # definition of the loopback address lookup zone. Required

type master; # this server is the master for the domain.

file "loopback-domain-info"; # the name of the file with resource records. master/slave

};

Security options for /etc/named.conf: prevent unauthorized systems from querying a server, or unauthorized slave servers from transferring files.

options { # add the following line to the options section:

allow-query {!128.50.1.2; 128.50.1/24;};

};

[Only the systems (specified by system name or IP address) or networks (specified by network name or network number in slash format) listed can query this server for DNS name resolution. Names of systems or networks or the term "none" may also be used. You may also deny access to one system by prefixing its address with "!," but if it is a subset of another item in the access list, it must come before that item, as shown above, where all systems on 128.50.1.0 are allowed to query the server, except 128.50.1.2. Access control lists may also be set up with the "acl" keyword, and the list so defined can subsequently be used in an allow-query or allow-transfer statement. An allow-query or allow-transfer statement as part of an options list applies to all zones specified in the file and is therefore "global."]

zone "x.y" { # add the following line to the appropriate zone.

. …various statements…

allow-query {128.50.1.2; "zoo.edu";};

};

[Only the system and the network specified can query this server about the zone x.y. An allow-query or allow-transfer statement for a particular zone overrides a global allow-query or allow-transfer statement.]

options { # add the following line to the options section:

allow-transfer {128.50.1.3;};

};

[ Restricts transfers globally to the slave server or servers listed, or to slaver servers on the network listed. Transfers may also be restricted on a per-zone basis by including an allow-transfer statement in the zone definition statements.]

zone "x.y" in {

type master;

file "one.zone"

allow-update { 127.0.0.1; 192.168.1.1;};

};

[Allows dynamic DNS updates to come from DHCP clients. The issue is that DHCP clients change their IP addresses every time they come on. If the client needs DNS name resolution for its name, that's a problem. Dynamic DNS means that the server updates its cache with the IP address and name reported from a client. It doesn't want to do that for just ANY client, so it will specify a list of IP addresses for which it will accept dynamic updates. These follow the keyword "allow-update." You must have this keyword for both the forward and reverse listings in the /etc/named.conf file.

Contents of zone files: ( in example above: /var/named/zoo.edu.zone, /var/named/zoo.edu.rzone etc). These files are not case sensitive, and they do require the use of fully qualified domain names. Any domain which is not fully qualified (ends with a .) will have the domain specified by @ or $ORIGIN appended to it. These files do not require quotes around non-defined text. Comments are preceded by the semi-colon.

Entries in zone files have the format:

Where:

<name of resource> is the domain name (zoo.edu, 1.50.128.in-addr.arpa, 127.in-addr.arpa etc., including aliases by which the domain may be known, like www.zoo.edu). This field may be replaced by the symbol @ to specify the domain cited in /etc/named.conf (in the line citing the particular zone file, in the second field, after the word "zone"), or omitted, and thus assumed to be @. Any domain name not terminated by . will have the domain indicated by @ appended to it. Thus, if the domain is fish.net, and you list a system as grunion.fish.net that system will become grunion.fish.net.fish.net!

<time to live> is the amount of time in seconds this record should be cached before it is discarded as being too old to be authoritative. This entry is optional, and will default to the value given in the SOA entry.

<class> is the type of network.

IN - internet. This is the only supported format, so IN is the default. It may be left out.

<type> is the kind of entry which may be:

A – maps host names to IP addresses.

PTR – Used only in reverse name resolution – maps IP addresses to host names.

NS – name service – this entry maps a domain name to a server name. Each subdomain that has its own nameserver must have one of these entries in the top server.

MX – mail server for this domain. The data entry has 2 parts for MX, the preference of the server, and the server name itself. The lower the value next to the server name, the higher its preference as a mail server, so multiple mail servers may be listed. Format:

IN MX 10 mailhost.mydomain.com

IN MX 5 mailhost2.mydomain.com

CNAME – canonical name – this is an alias for the real name of the domain. It maps the alias to the actual domain name. Format (where www is the alias, and webserver is the actual name of the system):

www IN CNAME webserver

SOA – start of authority – lists the person who is responsible for administration of this domain as well as variable settings. SOA records have a different format than others in the zone files. They look like:

<domain name> IN SOA <primary master for domain> root.<server name> ( ; the contact person is root@servername. @ is replaced by "."

<value> ;serial number - an arbitrary number assigned by the admin. This number

; should be incremented each time the master is updated. The slaves will

; only download zone files if the serial number is larger than it was.

<value(secs)> ; refresh - how long a slave server waits between zone file updates.

<value(secs)> ; retry - if refresh is unsuccessful, how long to wait before trying again.

<value(secs)> ; expire – when to stop offering name resolution if there is no refresh.

<value(secs)> ; ttl – how long to keep negative entries. These are entries indicating that

; no entry exists for a lookup.

)

<data> - the actual IP addresses associated with the domain name (a data type).

Additional entries in this file:

$INCLUDE <absolute filename> - include the contents of the specified file into this file at this point.

$TTL - set the default time to live, which is the length of time a cached entry from this file should be retained if no specific time to live is set on the entry itself. This is the only way to set a default time to live for all entries in a file.

@ appends the domain name specified in /etc/named.conf to all domain names not ending in . (dot).

$ORIGIN <domain name> - Replaces the domain set with @.

/var/named/named.root – zone file which contains name to address resolution for root servers, and therefore must be obtained from the InterNIC. It has the same format given above for other zone files. Once a server is contacted, it returns THE list of root servers to use, which is cached. It gives the IP address and name server for roots:

Format

domain name time to live internet type Name service

(seconds)

. 3600000 IN NS A.ROOT.SERVERS.NET

; The above line designates the hostname of the server for the domain .

A.ROOT.SERVERS.NET 360000 IN A 191.04.40.4

; The above line maps the domain server for . to an IP address.

/var/named/domain-info - maps names to IP addresses for all systems in this server's domain, along with SOA and NS. All slave servers in different domains also have entries in this file.

/etc/nsswitch.conf - contains the line

hosts: files [nis|nisplus] dns

Files MUST be first, or name resolution cannot occur during boot.

/var/named/inverse-domain-info – maps address to names. Contains SAP, "glue" addresses and arpa addreseses.

/var/named/named.stats – name of file which contains statistics output by ABRT signal.

/var/named/named_dump.db – name of dump file for debug dump of in.named.

/var/named/loopback-domain-info

/etc/nsswitch.conf – name service file. To use DNS, the keyword dns must be appended to the list of sources for "host" on all clients and servers.

/etc/resolv.conf contains:

search <domain_name/s> # domain names to append to requested names that are not FQDN. The first is the client's current domain. Thus if you type # mail root@fish

the domain names in the list will be resolved in order, until fish is found in one.

nameserver <IP_address> #nameservers for the domain. May have up to 3, each on a line. This line must use an IP address, not a hostname.

Misc.:

Domain name rules for FQDN:

1. 255 characters maximum including .

2. 63 characters maximum per domain.

3. 127 levels maximum depth.

4. alphas, numerics, - are the only allowed characters. ., _ are not allowed.

Server types:

1. root servers – have data on top level zones (.org, .com, .mil etc). They are run by various organizations under contract with the U.S. Government.

Root servers table

Name IP address Agency, Location.

A.ROOT-SERVERS.NET 198.41.0.4 VeriSign Global Registry Services, Dulles, VA

B.ROOT-SERVERS.NET 192.228.79.201 Information Sciences Institute, Marina del Rey, CA

C.ROOT-SERVERS.NET 192.33.4.12 Cogent Communications, Herndon, VA, Los Angeles; New York City; Chicago

D.ROOT-SERVERS.NET 128.8.10.90 University of Maryland College Park, MD

E.ROOT-SERVERS.NET 192.203.230.10 NASA Ames Research Center Moffett Field, CA

F.ROOT-SERVERS.NET 192.5.5.241 Internet Software Consortium Ottawa; Palo Alto; San Jose CA;
New York City; San Francisco;Madrid; Hong Kong; Los Angeles;Rome; Auckland; Sao Paulo; Beijing; Seoul; Moscow; Taipei; Dubai; Paris; Singapore; Brisbane

G.ROOT-SERVERS.NET 192.112.36.4 DOD Network Information Center Vienna, VA

H.ROOT-SERVERS.NET 128.63.2.53 Army Research Laboratory Aberdeen Proving Ground, MD

I.ROOT-SERVERS.NET 192.36.148.17 NORDU Stockholm; Helsinki; Milan; London

J.ROOT-SERVERS.NET 198.41.0.10 VeriSign Global Registry Services Herndon, VA Dulles VA; Mountain View CA; Sterling VA (2 locations);Seattle WA; Amsterdam;Atlanta GA; Los Angeles CA; Miami; Stockholm; London

K.ROOT-SERVERS.NET 193.0.14.129 European Regional Internet Registry/RIPE NCC London; Amsterdam; Frankfurt

L.ROOT-SERVERS.NET 198.32.64.12 ICANN Los Angeles, CA

M.ROOT-SERVERS.NET 202.12.27.33 WIDE Project Fujisawa Japan

2. Primary (Master) servers: DNS servers for lower domains. As a rule there is one per domain. Changes to systems in domain are recorded here, and they are authoritative for their domain. They update the secondary servers, and can delegate authority for subdomains.

3. Secondary (slave) servers: Backup servers for second level domains. There is usually more than 1, and they have copies of all information on the primary server, and are also authoritative for their domain.

4. Caching-only servers: Servers which only have cached DNS name information and are never authoritative. They provide local access without having to configure a primary or secondary server.

5. forwarding servers: a server that is a central jump point for off-site queries.

Top level domains:

Original:

.com .gov (US only) .mil (US only) .edu (4 year institutions, US only)

Also:

.org .net .int (only for international organizations established by treaty)

As of November 2000:

.aero .museum .biz .info .coop .name .pro

Various 2 letter country codes – see http://www.iana.org/cctld/cctld-whois.htm

Name resolution process: If the required information is not found at one level, continue to the next.

1. local lookups

2a: check /etc/resolv.conf for local DNS server 2b: query the server found in /etc/resolv.conf 2c: the server checks its cache or files.

3. Contact the next level server or the root server for server information, then query that server. Continue.

Client and Server configuration:

1.Add "dns" to hosts line of /etc/nsswitch.conf BEFORE any [NOTFOUND = return]

2.Create /etc/resolv.conf and enter the following:

search <domainname>

nameserver <IP addresses of DNS servers to query>

Additional Server configuration:

1.Set up /etc/named.conf

2. Configuration done at boot by in.named from /etc/named.conf which specifies zones of authority and related files: /var/named/named.root, /var/named/domain-info, /var/named/inverse-domain-info, /var/named/loopback-domain-info.

3. /var/named/domain-info must contain a NS entry for any slave servers.

Secondary Server configuration:

Same as primary server configuration except:

In /etc/named.conf, domain zone and reverse file type is "slave", and line citing master servers is added.

Versions of BIND in Solaris

Solaris 8 BIND 8.1.2

Solaris 7 BIND 8.1.2

Solaris 2.6 BIND 4.9.4_P1

Solaris 2.5.1 BIND 4.9.3

Solaris 2.5 BIND 4.9.3

Uses:

Problems associated with early naming protocols:

1. Size of hosts.txt file – network wide /etc/hosts download file got too large.

2. Each name in hosts.txt had to be unique.

3. Overload on server (sri-nic) from which hosts.txt was downloaded.

Uses of /etc/named.conf

1. Establishes the type of server: primary, secondary or cache-only.

2. Specifies the zones of authority that the host serves, and type and file association

3. Security.

Format for naming of subdomains in the file /etc/named.conf on the server for the parent domain:

Example: on the server veggie.edu to call out sub1.veggie.edu and sub2.veggie.edu

veggiesrv.veggie.edu. in a 10.1.1.1
sub1.veggie.edu. in ns subserver1.<some_domain>
sub2.veggie.edu. in ns subserver2.<some_domain>
veggiesrv.veggie.edu. in ns 10.1.1.1
subserver1.<some_domain>. in a 192.9.200.1
subserver2.<some_domain>. in a 128.50.1.1

Reverse:

REVERSE LOOKUP EXAMPLE:

1.1.10.in-addr.arpa. in ns veggiesrv.veggie.edu.
200.9.192.in-addr.arpa. in ns subserver1.<some_domain>.
1.50.128.in-addr.arpa. in ns subserver2.<some_domain>.
1.1.1.10.in-addr.arpa. in ptr veggiesrv.veggie.edu.
1.200.9.192.in-addr.arpa. in ptr subserver1.<some_domain>.
1.1.50.128.in-addr.arpa. in ptr subserver2.<some_domain>.

CHeck out "whois" which should show the primary or zone authority and secondary servers.