TCPIP Names


TCP/IP Names

The address space for IP addresses is a hierarchical one that allows computers to be grouped into networks and sub-networks. The flat address spaces created by MAC addresses don't allow for any kind of grouping because they only provide an address for the host physical adapter and do not provide any sort of organization that can be used outside a LAN. In a small LAN, it doesn't matter that MAC addresses are not ordered. Each node can recognize a packet that's destined for it by examining the MAC address for every packet that passes on the LAN. This concept would not work on a larger network because every packet would have to be forwarded to every node for examination. Imagine having every packet on the Internet sent to every node! It's also possible to create a hierarchical namespace for nodes on a TCP/IP network by concatenating the hostname with a domain name. For example, the host computer named zira in the domain named nirvana.com is zira.nirvana.com as a fully qualified name.

Names are more convenient for humans than the numerical address format implemented in the TCP/IP suite. Just as the numerical address space is a hierarchical one, so is the namespace. However, it's important to understand that the two do not have to be directly related on a one-to-one basis. For example, suppose that a computer named printserver.ono.com has an address of 193.220.113.10. This is a class C IP address, so the network portion of the address is 193.220.113. You might be inclined to think, then, that a computer with a name of fileserver.ono.com is also located in the same network and has an address that begins with 193.220.113. However, there is no direct relation between the two.

Not that there can't be. It might be very convenient to set up a small network with a few subnets and create host computer names that all match up to a particular network address or subnet. In practical terms, however, this is hard to maintain as the network grows and changes.

Instead, use the TCP/IP namespace to create a logical arrangement of computers that matches some kind of business layout or other type of function. It makes sense to use names such as the following:

susan.accounting.zira.com heather.accounting.zira.com holly.shipping.zira.com penny.research.zira.com foster.research.zira.com 


It's clear from these names that the company or organization is called Zira and that there are computers in the accounting, shipping, and research departments. In this case, however, it might be that Susan works out of the company's office located in the heart of downtown, whereas Heather works in a suburban office. Their TCP/IP hostnames reflect the business organizational unit in which they work. However, their IP addresses can be on completely different subnets or networks, depending on the physical location or other factors.

The rules for creating a hostname are not as carefree as those used for NetBIOS names. You cannot use spaces in a TCP/IP name, for example. The following rules must be followed when creating a hostname:

  • You can use alphabetical characters (az) or numeric characters (09), and the first character of the name must be a letter or a digit.

  • You can use the minus sign (dash), but this cannot be the last character in the name.

  • Periods are allowed, but are used to separate hostnames from domain or subdomain portions of the name. This is covered in RFC 921, "Domain Name System Implementation Schedule." Because the period is used to separate components, it cannot be the last character in the name either.

  • Names are not case sensitive. An uppercase A is the same as a lowercase a.

  • The host portion of the name should not be longer than 24 characters. In practice, you can exceed this limit most of the time, but doing so is not a good idea if you're connected to the Internet where there are other computers and devices that do stick to the strict limit.

Note

These restrictions apply to names you enter in the HOSTS file. When using a DNS server, the restrictions are a little different, as is explained in the following sections.


Although you can use names in the TCP/IP networking environment to conveniently organize your host computers, there must again be a mechanism for resolving these names to the actual IP addresses that are associated with the computer. TCP/IP provides the HOSTS file, which was originally a central file maintained by a central authority and periodically distributed to nodes throughout the Internet. You can probably guess that this methodas with the LMHOSTS file used on NetBIOS networkshas been outgrown by the rapid growth of the Internet, and is now used only on small networks or for special cases.

The Domain Name System is now the primary means for resolving IP addresses to hostnames on the Internet. In some Unix shops, the Network Information System (NIS) is used. NIS was originally called Yellow Pages, but had to change its name due to a trademark infringement.

The HOSTS File

On Unix systems, the HOSTS file is usually found in the /etc or /etc/inet directory. Like the LMHOSTS file, it has no filename extension. It is a text file that contains IP addresses followed by the hostname or names associated with the address. The # character is used to denote comments. Each line should have only one IP address, followed by a space or tab character, and then the hostname. You can place more than one name on the line (each separated by a space or tab character) to provide multiple names for a host (sometimes called nicknames). For example:

#This is the HOSTS file # 127.0.0.1      localhost 10.1.22.13     pkd.ubik.com            # Server at Atlanta office. 10.1.22.46     psi.ubik.ocm            # Joe's workstation. 192.208.46.158 www.compaq.com          # Compaq's homepage. 


Note that the first entry in the file is the loop-back address for the local adapter. You will find this in many HOSTS files, but it isn't a requirement.

The HOSTS file has the same limitations as the LMHOSTS file. Mainly, it doesn't scale very well. Each time a change is made in the network, you need to update the file on each machine to reflect the change. This makes it easy to get different copies out-of-sync on a larger network.

In a very small TCP/IP network that doesn't change very often and doesn't use NetBIOS names, using the HOSTS file might be preferable to using DNS. You can get a decent DNS server from everyone from Microsoft to Novell to any Unix/Linux server. But if it means that you have to purchase a server operating system to provide for a small number of clients, you might be better off using a simple LAN without a DNS server. For a growing network or one in a fast-paced business environment where employees are always on the move, DNS or NIS should be used.

However, even in a SOHO office, there should be little need to keep using this legacy HOSTS file. If you're connected to the Internet, network names can be translated using a DNS server provided by your Internet provider. Names on the local LAN can be resolved using NetBEUI.

Domain Name System

When TCP/IP became the standard protocol used on ARPAnet (which evolved into the Internet), the HOSTS file was maintained by SRI-NIC at a central location. Changes were periodically made to the file as administrators emailed requests to SRI-NIC. The updated HOSTS file then had to be distributed to every node, making the maintenance of this file a major administrative chore. For a few thousand computers in the beginning, this was a difficult enough task. But just imagine trying to coordinate the distribution of text files containing IP to name translation files in today's Internet environment, where there are many millions of users all over the world.

In 1984, the Domain Name System (DNS) was adopted for the Internet. DNS is not only a hierarchical database, but also a distributed one. WINS servers use replication with partners to keep a full copy of the WINS database on each WINS server. On the Internet, each registered domain (for example, zira.com or microsoft.com) has a DNS server, which is responsible for managing the database of hostnames within that domain or subdomains. This distribution of the database makes it easier to scale to a larger size than with the WINS model. Administration can also be delegated so that no central management of the entire database is needed.

Tip

One of the first implementations of DNS was developed at Berkeley for its BSD Unix (version 4.3) operating system. Therefore, you'll often see the term BIND (Berkeley Internet Name Domain) used in place of DNS on many Unix and Linux systems.


The topmost entry in the DNS hierarchy is called the root domain and is represented by the period character (.). Underneath this root domain are the top-level directories that fall into two groups: geographical and organizational. Geographical domains are used to specify specific countries. For example, .au for Australia and .uk for the United Kingdom. Under each of the geographical domains, you might find organizational domains. Organizational domains include

  • com Used for commercial organizations

  • edu Used for educational institutions

  • gov Used for U.S. government entities

  • mil Used for U.S. military organizations

  • int Used for international organizations

  • net Used for network organizations such as Internet service providers

  • org Used for nonprofit organizations

  • arpa Used for inverse address lookups

The structure of the Domain Name System is similar to an inverted tree. In Figure 29.10, you can see that at the top is the root domain with the com through arpa domains underneath. Under the com domain are individual business organizations that each have their own domain. Under any particular domain there can be subdomains.

Figure 29.10. The Domain Name System is a distributed hierarchical structure.


At each level, a fully qualified domain name (FQDN) is created by concatenating the local name with the names of the entities above it in the hierarchy. Thus, msdn.microsoft.com is used to name the msdn subdomain in the microsoft.com domain that falls under the com domain. By using the FQDN, it's possible for a hostname to be used multiple times, as long as it produces a unique FQDN. For example, fileserver.twoinc.com names a host called fileserver. This host cannot become confused with another host of the same name that resides in a different domain such as fileserver.acme.com.

There are a number of restrictions to the names you can use in the DNS system:

  • The maximum length of a domain name or a host label is 63 characters.

  • The maximum length for the FQDN is 255 characters.

  • There can be up to 127 subdomains.

  • Text is not case sensitive.

New Top-Level Domains

Since ICANN took over responsibilities for handling names and numbers used on the Internet, several new top-level domains have been created. Over the next few years, you can expect to see additional top-level domains added to this list. The most recent additions were made in 2000. These are

  • aero Intended for use by the air-transport industry

  • biz For use by businesses

  • coop For use by cooperatives

  • info Anything you want

  • museum Guess?

  • name For registration of individual names

  • pro Accountants, lawyers, and physicians

Note

In 2003, NeuStar, Inc. was asked by the U.S. congress to set up a new domain name called .kids.us. All content on any Web site registered for a domain name in .kids.us will be screened to ensure that it contains no adult or other information that might be harmful to kids.


Of these domains, some are unsponsored (biz, info, name, and pro), which means that they will be governed by the global Internet community through ICANN, whereas the others (aero, coop, and museum) are sponsored domains. That means they'll be governed by specific entities. For example, the coop domain is sponsored by the National Cooperative Business Association.

Note

You might have noticed recently that there are other domains that appear to be new, such as the popular tv domain. However, note that the .tv domain is not a new top-level domain. Instead, tv is the country code domain for the country of Tuvalu (a small island in the Pacific Ocean), which has allowed an enterprising company to use its country-style domain name for a fee. The company can market the tv domain to register domains that are associated with, of course, television. However, remember that this is just a country code domain. It isn't one of the new top-level domains that ICANN has authorized. There is nothing that requires a particular country to use its own domain designation for just its use. Whoever thought up this method for establishing what appears to be a new domain should be named Capitalist of the Year!


To stay up-to-date on what the current top-level domains are, visit the ICANN Web site at www.icann.org. You'll also find a lot of other valuable information at this site if you administer a network that makes heavy use of the Internet. If you want to use the Internet to increase your business, it's important that the networking staff understand who is responsible for the network numbers, protocols, and so forth on the Internet. Therefore, as many others mentioned in this book, the previous URL should be something you put in your bookmarks or favorites folder.

Primary, Secondary, and Caching-Only Name Servers

For each domain on the Internet, there must be a primary server and a secondary server. The primary DNS server for the domain contains a collection of resource records that contain the address mappings for hostnames in the domain. The primary DNS server is the final authority for these mappings. The secondary DNS server contains a copy of the database maintained by the primary server and can continue to resolve names when the primary server is offline. It's important to note that the primary DNS server is where changes are made to the database. Through the use of the zone transfer mechanism, the data is copied to secondary servers.

In many cases, a DNS server answers name queries for domains for which it isn't the authority. In that case, the DNS server contacts a DNS server further up the hierarchy until one is found that can resolve the name or that can point to another DNS server that is the authority for the name. The DNS server maintains a cache of names that have been resolved by this method so that it doesn't have to continually poll other servers for names that are frequently queried.

A third type of DNS server is a caching-only server. This type of server does not maintain a database for a particular zone. To put it in other terms, a caching-only server isn't authoritative for any zone or domain and does not use the zone transfer mechanism to keep a current copy of the entire database. Instead, a caching-only name server has to contact another DNS server to initially resolve a name, but like the other servers it maintains a cache of names it has resolved so that it doesn't have to keep forwarding the query to another server. This type of server is normally used on a network segment that's connected to the rest of the network by a slower link (or a more expensive one) and is used to reduce network traffic.

Zones

In many cases, it isn't efficient to have a single server maintain the database for an entire domain. Instead, a primary DNS server can be authoritative for only a zone in the domain. A zone is a partition of the domain into subdomains. For example, one DNS server might be the authority for the zone zira.twoinc.com, whereas another might serve as the authority for the zone research.twoinc.com. Both subdomains exist within the same domain: twoinc.com. However, by dividing the domain into subdomains, it becomes easier to manage not only the DNS servers but also the individual business or organizational units that the domain services.

A zone transfer occurs when a secondary DNS server contacts a server that is primary for the zone and finds that it needs to obtain changes to the database. This is accomplished by using serial numbers contained in the database. If the secondary server has a lower serial number, a new copy of the database is copied to it.

Standard DNS Database Files

There are three basic types of files used by DNS servers. In most DNS implementations, you need to use a text editor to make changes to these files. Most newer DNS servers, such as Microsoft's DNS server, provide a graphical interface that can be used for adding or changing information in the DNS files. The basic files are

  • Database File This is the file that stores the resource records for the zones for which the DNS server is responsible. The first record in this file is the Start of Authority (SOA) record.

  • Cache File This file contains information for other name servers that can be used to resolve queries that are outside the zone or domain for which the server is responsible.

  • Reverse Lookup File This file is used to provide a hostname when the client only knows the IP address. This can be useful for security purposes. For example, a Web server that receives a request from a client can query the DNS with the name of the client to find out whether the hostname associated with the IP address is correct.

Resource Records

Until recently, most DNS databases were usually composed of ASCII text files containing records that could be used to translate a name to an IP address. Several types of records can be used in the database, with each representing a specific type of resource, such as a computer hostname or a mailserver name. Today, many fast DNS servers maintain a database with far greater capabilities than those that used a flat-file format. Therefore, newer DNS servers also contain many newer capabilities, such as dynamic updates.

When representing a domain name in DNS, a specific syntax is used. The term label is used in RFC 1035, "Domain NamesImplementation and Specification," when describing this syntax. A label is a one-byte length field followed by a data field. The length field indicates the number of characters in the data field. A domain name is represented by a series of labels and the entire domain name string is terminated with a length field of zero. For example, Figure 29.11 shows the layout of a series of labels that would be used to define the domain name zira.twoinc.com.

Figure 29.11. The domain name is represented by a series of labels in DNS.


Tip

You can find other RFCs, both standards and proposed standards, by entering DNS as a keyword in the search capability offered on the Web's own archive for RFCs: http://www.rfc-editor.org.


Although the string is only 13 bytes long, excluding the periods, it takes 17 bytes to represent it in the database because of the length fields and the terminator field. To avoid repetition for domain names that are used a lot in the database, a pointer record can be used.

The general format used for a resource record contains the following fields:

  • Name The owner name. This is the name of the domain to which this record belongs.

  • Type A 2-byte field that specifies the resource record type code.

  • Class A 2-byte field that specifies the resource record class code.

  • TTL A 32-bit signed integer that specifies the time-to-live value. The TTL value specifies the amount of time a record can be cached before its value needs to be refreshed from the authoritative source. 0 indicates that the record cannot be cached.

  • RDLENGTH An unsigned 16-bit integer that indicates the length of the data field that follows.

  • RDATA The data field. This part of the record describes the resource. The contents depend on the values of the type and class fields.

The Type field indicates the type of resource record. Table 29.1 contains a list of the standard record types used in most DNS implementations, along with a description of their use.

Table 29.1. DNS Resource Records

Record Type

Description

A

Host IP address

AAAA

Host IP address (Ipv6)

NS

Name server record

PTR

Pointer to another domain name record

SOA

Start of a zone of authority

WKS

Well-known service

HINFO

Host information

MX

"Mail exchanger" for the domain

MINFO

Mailbox or mail list information

TXT

Text entry for miscellaneous information

CNAME

Canonical name for an alias


In earlier implementations of DNS, other record types were also used. For instance, MD and MF were used to specify mail destination and mail forwarder records. RFC 1035 made obsolete three other RFCs: 882, 883, and 973. Four other record types that are considered experimental are

  • MB Mailbox domain name

  • MG Mail group member

  • MR Mail rename domain name

  • NULL Null resource record

In addition, RFC 2782, "A DNS RR for Specifying the Location of Services (DNS SRV)," added a new record type that figures heavily into a Windows 2000/.NET network: the SRV or service record. This type of record is used to store records in a DNS database that clients can use to look up services. For example, Windows servers use this type of record to enable clients to use DNS to locate domain controllers and other services. We'll get into more details about that in the next chapter.

The Start of Authority (SOA) record is used at the beginning of the database and is used to describe the database. It's used mostly by secondary DNS servers to get zone information. The fields in this record are

  • Domain name Name of the domain for which this database is the authority.

  • IN The class type of Internet.

  • SOA The Start of Authority record type indicator.

  • Primary server The FQDN of the primary DNS server for this domain.

  • Email address The email address of a person who is responsible for this domain.

  • Serial number A 32-bit value that shows the revision number of the database file. It is incremented each time a change is made to the database so that secondary servers can detect the change.

  • Refresh rate A 32-bit value used by secondary servers. After this interval has elapsed, the data for a record needs to be checked again in the primary server database.

  • Retry rate A 32-bit value indicating the amount of time to wait before retrying to refresh data after a failed attempt.

  • Expire rate A 32-bit value indicating the maximum amount of time a secondary server is to try to refresh data before it stops processing DNS data for this zone.

  • Minimum TTL The minimum amount of time for a resource record's TTL. This value can be overridden by the TTL value specified in the record itself.

All time values in the SOA record are in seconds.

The NS record type can be used to indicate that another name server is authoritative for this subdomain. For example, the record

zork.twoinc.com     IN     NS     zira.twoinc.com 


indicates that the name server whose FQDN host name is zira.twoinc.com is the authoritative name server from which to get information about the subdomain zork.twoinc.com. To get the address of the name server zira.twoinc.com, an A type record is needed:

zira.twoinc.com     IN     A     216.65.33.219 


The CNAME record is used to specify aliases or nicknames that can be used in addition to a hostname; for example:

ftp.zira.twoinc.com     IN     CNAME     zira.twoinc.com 


Pointer records (PTR class) are used to get the name that's associated with an IP addressa reverse translation. For example

219.33.65.216     IN     PTR     zira.twoinc.com 


can be used to perform a query to get the name of this host when only the IP address is known. However, notice that the IP address has been reversed in this record. It is represented in a pointer record as 219.33.65.216 instead of 216.65.33.219. The reverse format is used to make a key lookup in the database function properly. The special domain IN-ADDR.ARPA contains the data used when a server needs to look up the hostname for an address in the domain.

The Class field is generally IN, which stands for Internet. The numeric value for this code is 1. In addition to this class type, you might see references to CS, which stands for the obsolete CSNET class. The CH class stands for the CHAOS class and the HS class code stands for the Hesiod class.

Configuring a Unix DNS Server

On most Unix systems, configuring a DNS server involves editing ASCII text files and making the appropriate entries. The actual files to edit depend on the brand of Unix you're using. The most common is the Berkeley Internet Name Domain (BIND) implementation. This server uses a daemon called in.named.

In addition to the actual zone database files, you also have to edit

  • /etc/named.boot This file provides information for the in.named daemon when it starts up. The Directory directive specifies the directory that holds the zone database files (usually /var/named). The Cache directive tells the server to load a cache of initial hostnames. The Primary directive tells the server that it will function as the primary DNS server for the zone and the Secondary directive tells the server that it will function as the secondary DNS server for the zone.

  • /var/named/db.cache This is the usual name for the cache file.

To start the BIND service daemon after you've edited all the appropriate files, you only need to enter the command in.named at the system command prompt (or in a startup file). If you've edited the /etc/named/boot file or its equivalent on your Unix/Linux variant, the server automatically starts the next time the system is booted.

The most time-consuming task is the editing of the zone database files and making entries for the hosts in the domain.

Configuring DNS Clients

Unix/Linux clients usually get their information about name servers from the /etc/resolv.conf file. (Note that this might be different for your variant of the "universal" Unix operating system. Check the manual pages.) To configure the client, edit this file. To place comments in this file, you can use the semicolon (;) character. The three directives that you configure in this file are

  • Domain The default domain name. This name is appended to any names that are partially qualified.

  • Search This is a search list of domains used to look up names that are not fully qualified. You can specify up to six domain names with a total of 256 characters for this directive.

  • Nameserver You can specify up to three DNS servers by IP address with this directive. Note that if you don't specify a nameserver address, the default is the local domain.

For example:

;This is the /etc/resolv.conf file for local workstations domain twoinc.com ; Name servers nameserver 199.45.32.38 nameserver 151.197.0.39 nameserver 216.645.33.219 ; search lists search twoinc.com biznesnet.com ; end of file 


A client using this file to try to resolve the name of a host named zira would first search the domain twoinc.com and then the domain biznesnet.com. The first match found is the one that will be used to resolve the name to an IP address.

To configure a Microsoft client to use a DNS server, you only need to enter the IP addresses of the DNS servers when you perform the initial client network setup (or set your DHCP server to provide this information to the client).

Using nslookup

The nslookup utility is generally employed to find the IP address associated with a name. However, the utility can be used to interrogate the DNS database to find not only IP addresses, but also information stored in other records in the database. The utility can be used either in interactive mode, where the user can continue to issue commands, or in a one-shot, non-interactive mode where a single query is executed. The basic syntax for the command is

nslookup [[-option ...] [hostname to locate]] - [server] 


If you omit the last item in this syntax (- server), the local DNS server is queried. However, when you have multiple servers or if you want to query a server outside your organization, specify it with this parameter.

A simple example of the command is nslookup twoinc.com, which returns the following information:

Name:    twoinc.com Address:  216.65.33.219 


If you want to retrieve more information about the server, you can use options and specify the info records:

nslookup -query=hinfo -timeout=10 www.twoinc.com twoinc.com         primary name server = ns1.tentex.com         responsible mail addr = hostmaster.twoinc.com         serial  = 1342         refresh = 3600 (1 hour)         retry   = 600 (10 mins)         expire  = 86400 (1 day)         default TTL = 3600 (1 hour) 


As you can see, this tool is useful for looking up addresses, but can also be used to query the DNS database and help you debug configuration problems. With this simple query, you can see the serial number of the current database along with other information stored in the SOA record. The syntax for the options of this command varies depending on your operating system.

Dynamic DNS

Earlier in this chapter, I discussed Microsoft's WINS servers. These NetBIOS name servers can be used to dynamically accept information from clients so that the network administrator does not have to make edits to the database each time a node is added to the network or a workstation is moved to a new location. The Dynamic Host Configuration Protocol (DHCP) has eliminated the necessity of manually configuring each computer host with network information. Microsoft's DNS server can be configured to query the WINS server when it needs to resolve a name it cannot find in its own databases.

This solution does not help if you have a multivendor network with workstations running different operating systems. There are several relevant RFCs that address these problems associated with standard DNS implementations, such as

  • RFC 2136, "Dynamic Updates in the Domain Name System (DNS UPDATE)" This RFC describes a method that can be used for dynamic updates to DNS. It provides for an atomic (all-or-nothing) update mechanism that can be used to add, delete, or modify one or more resource records in a zone file. This RFC was updated by a proposed standard, RFC 3007, "Secure Domain Name System (DNS) Dynamic Update," among others.

  • RFC 1995, "Incremental Zone Transfer in DNS" Incremental zone transfer means that only portions of the zone database file that have been modified need to be transferred from primary DNS servers to secondary servers. This process conserves network bandwidth and decreases the latency time for changes to be distributed throughout the Internet.

  • RFC 1996, "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)" The third piece of the solution enables the primary DNS server to notify the secondary servers that changes have been made to the zone database. Currently, zone transfers can occur only after a refresh interval has passed.

Offerings for a DNS server that's truly dynamic and a corresponding DHCP server capable of making updates are becoming more widespread at this time. Portions of the technology are implemented here and there, while some vendors offer both and DNS and DHCP solutions that work well together. For example, The Internet Software Consortium (ISC), which maintains BIND, releasedon March 4, 2003version 9.2.2 of BIND, which supports RFC 2136. You can download documentation or the kit files from the ISC Web site at http://www.isc.org.

At the same site, you will also find a version of DHCP, along with a list of products developed by other developers that are based on or can work with these products.

For network administrators who already have DNS servers running on the network but are concerned about whether these servers can be used in conjunction to the Windows 2000 version of DNS, please note that Windows 2000 DNS server also supports the following RFCs in addition to the dynamic update RFCs listed previously:

  • RFC 1034, "Domain NamesConcepts and Facilities"

  • RFC 1035, "Domain NamesImplementation and Specification"

  • RFC 1123, "Requirements for Internet HostsApplication and Support"

  • RFC 1886, "DNS Extensions to Support IP Version 6"

  • RFC 2181, "Clarifications to the DNS Specification"

  • RFC 2308, "Negative Caching of DNS Queries (DNS NCACHE)

Check the documentation for your BIND or DNS server to see which RFCs it supports. You might be surprised to find that this new and improved DNS server from Microsoft might be as good as, or perhaps better than, your current version.




Upgrading and Repairing Networks
Upgrading and Repairing Networks (5th Edition)
ISBN: 078973530X
EAN: 2147483647
Year: 2006
Pages: 411

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net