Zone File Records

Two types of entries are used to construct a zone file: directives that simplify constructing the file, and standard resource records that define the domain data contained in the zone file. While there are many types of standard resource records, there are only four directives. These are:

• $INCLUDE filename
• Identifies a file that contains data to be included in the zone file. The data in the included file must be valid directives or standard resource records. $INCLUDE allows a large zone file to be divided into smaller, more manageable units.

  The filename specified on the command line is relative to the directory named on the directory option in the named.conf file. For example, if the named.conf file for crab points to /etc with the directory option, and a zone file on crab contains an $INCLUDE events.hosts statement, then the file /etc/events.hosts would be included in that zone file. If you don't want the filename to be relative to that directory, specify a fully qualified name, such as /usr/dns/events.hosts.

• $ORIGIN domainname
• Changes the default domain name used by subsequent records in the zone file. Use this command to put more than one domain in a zone file. For example, an $ORIGIN events statement in the wrotethetutorial.com zone file sets the domain name to events.wrotethetutorial.com. All subsequent resource records would be relative to this new domain.

  The named software uses $ORIGIN statements to organize its own information. Dumping the named database, with ndc dumpdb, produces a single file containing all the information that the server knows. This file, named_dump.db, contains many $ORIGIN entries to place all of the domains that named knows about into a single file.

• $TTL time-to-live
• Defines the default TTL value used on resource records that do not include a specific TTL. Each zone file should start with a $TTL directive to ensure that all resource records have a valid TTL. A purely numeric time-to-live field defines the TTL in seconds. An alphanumeric time-to-live format can also be used. For example, w sets the TTL to one week. The possible values for the alphanumeric format are:
  • w for week
  • d for day
  • h for hour
  • m for minute
  • s for second
• $GENERATE range template
• Generates resource records for a range of values using a specific resource record template. range is a numeric range of values written in the form low_value-high_value. $GENERATE creates a resource record for each value in range. Thus a range of -9 would create nine distinct records. The type of records created is determined by the template. The template is composed of literal values that are written to the resource record exactly as shown in the template, and the symbol $ that is replaced by the current range value before the resource record is written. Therefore, if the current range value is 7 and the template is $ CNAME $.first64, the resource record generated is CNAME 7.first64.

These directives are helpful for organizing and controlling the data in a zone file, but all of the actual database information comes from standard resource records. All of the files pointed to by named.conf contribute to the DNS database, so all of these files are constructed from standard resource records.

Standard Resource Records

The format of standard resource records, sometimes called RRs, is defined in RFC 1033, the Domain Administrators Operations Guide. The format is:

[name] [ttl] class type data

The individual fields in the standard resource record are:

• name
• This is the name of the object affected by this resource record. The named object can be as specific as an individual host, or as general as an entire domain. The string entered for name is relative to the current domain unless a fully qualified domain name is used.[160]

  [160]The FQDN must be specified all the way to the root; i.e., it must end with a dot.

  Certain name values have special meaning. These are:

  • A blank name field denotes the current named object. The current name stays in force until a new name value is encountered in the name field. This permits multiple RRs to be applied to a single object without having to repeat the object's name for each record.
  • Two dots in the name field refer to the root domain. However, a single dot (the actual name of the root) also refers to the root domain, and is more commonly used.
  • @
  • A single at-sign (@) in the name field refers to the current origin. The origin is a domain name derived by the system from the current domain name, or explicitly set by the system administrator using the $ORIGIN command.
  • *
  • An asterisk in the name field is a wildcard character. It stands for a name composed of any string. It can be combined with a domain name or used alone. Used alone, an asterisk in the named field means that the resource record applies to objects with names composed of any string of characters plus the name of the current domain. Used with a domain name, the asterisk is relative to that domain. For example, *.uucp. in the name field means any string plus the string uucp.
• ttl
• Time-to-live defines the length of time that the information in this resource record should be kept in the cache. When ttl is specified as a purely numeric value, it defines the length of time in seconds. ttl can also use the alphanumeric format described for the $TTL directive. If no value is set for ttl, it defaults to the value defined for the entire zone file by the $TTL directive.
• class
• This field defines the address class of the resource record. The Internet address class is IN. All resource records used by Internet DNS have IN in this field, but it is possible for a zone file to hold non-Internet information. For example, information used by the Hesiod server, a name server developed at MIT, is identified by HS in the class field, and chaosnet information is identified by a CH in the class field. All resource records used in this tutorial have an address class of IN.
• type
• This field indicates the type of data this record provides. For example, the A type RR provides the address of the host identified in the name field. The most common standard resource record types are discussed in the following sections.
• data
• This field contains the information specific to the resource record. The format and content of the data field vary according to the resource record type. The data field is the meat of the RR. For example, in an A record, the data field contains the IP address.

In addition to the special characters that have meaning in the name field, zone file records use these other special characters:

• ;
• The semicolon is the comment character. Use the semicolon to indicate that the remaining data on the line is a comment.
• ( )
• Parentheses are the continuation characters. Use parentheses to continue data beyond a single line. After an opening parenthesis, all data on subsequent lines is considered part of the current line until a closing parenthesis.
• x
• The backslash is an escape character. A non-numeric character following a backslash (\) is taken literally, and any special meaning that the character may ordinarily have is ignored. For example, ; means a semicolon -- not a comment.
• ddd
• The backslash can also be followed by three decimal numbers. When the escape character is used in this manner, the decimal numbers are interpreted as an absolute byte value. For example, means the byte value 11111111.

The same general resource record format is used for each of the resource records in a zone file. The most commonly used resource records are described below.[161]

[161]There are more than 40 RRs, most of which are not used. For a description of all of them, see Linux DNS Administration by Craig Hunt (Sybex).

Start of Authority record

The Start of Authority (SOA) record marks the beginning of a zone, and is usually the first record in a zone file. All of the records that follow are part of the zone declared by the SOA. Each zone has only one SOA record; the next SOA record encountered marks the beginning of another zone. Because a zone file is normally associated with a single zone, it normally contains only one SOA record.

The format of the SOA record is:

[zone] [ttl] IN SOA origin contact  ( serial refresh retry expire  negative_cache_ttl )

The components of the SOA record are:

• zone
• This is the name of the zone. Usually the SOA name field contains an at-sign (@). When used in an SOA record, the at-sign refers back to the domain name declared in the named.conf zone statement that points to this zone file.
• ttl
• Time-to-live is left blank on the SOA record.
• IN
• The address class is IN for all Internet RRs.
• SOA
• SOA is the resource record type. All the information that follows this is part of the data field and is specific to the SOA record.
• origin
• This is the hostname of the master server for this domain. It is normally written as a fully qualified domain name. For example, crab is the master server for wrotethetutorial.com, so this field contains crab.wrotethetutorial.com. in the SOA record for wrotethetutorial.com.
• contact
• The email address of the person responsible for this domain is entered in this field. The address is modified slightly. The at-sign (@) that usually appears in an Internet email address is replaced by a dot. Therefore, if david@crab.wrotethetutorial.com is the mailing address of the administrator of the wrotethetutorial.com domain, the wrotethetutorial.com SOA record contains david.crab.wrotethetutorial.com. in the contact field.
• serial
• This is the version number of the zone file. It is a ten-digit numeric field usually entered as a simple number, e.g., 117. However, the composition of the number is up to the administrator. Some choose a format that shows the date the zone was updated, e.g., 2001061800. Regardless of the format, the important thing is that the serial number must increase every time the data in the zone file is modified.

  The serial field is extremely important. It is used by the slave servers to determine if the zone file has been updated. To make this determination, a slave server requests the SOA record from the master server and compares the serial number of the data it has stored to the serial number received from the master server. If the serial number has increased, the slave server requests a full zone transfer. Otherwise it assumes that it has the most current zone data. You must increment the serial number each time you update the zone data. If you don't, the new data may not be disseminated to the slave servers.

• refresh
• This specifies the length of time that the slave server should wait before checking with the master server to see if the zone has been updated. Every refresh seconds, the slave server checks the SOA serial number to see if the zone file needs to be reloaded. Slave servers check the serial numbers of their zones whenever they restart. But it is important to keep the slave server's database current with the master server, so named does not rely on these unpredictable events. The refresh interval provides a predictable cycle for reloading the zone that is controlled by the domain administrator.

  The value used in refresh is a number, up to eight digits long, that is the maximum number of seconds that the master and slave servers' databases can be out of sync. A low refresh value keeps the data on the servers closely synchronized, but a very low refresh value is not usually required. A value set lower than needed places an unnecessary burden on the network and the slave servers. The value used in refresh should reflect the reality of how often your DNS database is updated.

  Most sites' DNS databases are very stable. Systems are added periodically, but not generally on an hourly basis. When you are adding a new system, you can assign the hostname and address of that system before the system is operational. You can then install this information in the name server database before it is actually needed, ensuring that it is disseminated to the slave servers long before it has to be used.

  If extensive changes are planned, the refresh time can be temporarily reduced while the changes are underway. Therefore, you can normally set refresh time high, reducing load on the network and servers. Two (43200 seconds) to four (21600 seconds) times a day for refresh is adequate for many sites.

  The process of retrieving the SOA record, evaluating the serial number, and, if necessary, downloading the zone file is called a zone refresh. Thus the name refresh is used for this value.

• retry
• This defines how long slave servers should wait before trying again if the master server fails to respond to a request for a zone refresh. retry is specified in seconds and can be up to eight digits long.

  You should not set the retry value too low. If a master server fails to respond, the server or the network could be down. Quickly retrying a down system gains nothing and costs network resources. A slave server that backs up a large number of zones can have problems when retry values are short. If the slave server cannot reach the master servers for several of its zones, it can become stuck in a retry loop.[162] Avoid problems; use an hour (3600) or a half hour (1800) for the retry value.

  [162]The server may alternate between periods when it fails to respond and when it resolves queries, or it may display the error "too many open files."

• expire
• This defines how long the zone's data should be retained by the slave servers without receiving a zone refresh. The value is specified in seconds and is up to eight digits long. If after expire seconds the slave server has been unable to refresh this zone, it should discard all of the data.

  expire is normally a very large value. 604800 seconds (about one week) is commonly used. This says that if there has been no answer from the master server to refresh requests repeated every retry seconds for the last 7 days, discard the data. Seven days is a good value, but much longer values are not unusual.

• negative_cache_ttl
• The negative_cache_ttl field of the SOA record is the default time-to-live for negative information about this domain that is cached by remote servers. All servers cache answers and use those answers to respond to subsequent queries. Most of the answers cached by a server are standard resource records. Yet a name server can learn from an authoritative server that a specific resource record does not exist. This is also valuable information that should be cached.

  The server keeps cached records as long as they are valid, and the TTL defines how long that is. Each resource record has a TTL, either a TTL defined specifically for that record or the default TTL defined by the $TTL directive. However, there is no resource record for negative information and thus no explicit TTL. It is the negative_cache_ttl that tells remote servers how long to cache negative information.

  The negative_cache_ttl value is usually set to between 5 and 15 minutes. This is long enough to prevent repeated queries for nonexistent information from causing your server any trouble, but short enough for repeated queries caused by a remote user who knows that a system with a certain name will soon come online.

Most of the fields in the SOA record provide values used to keep the slave servers synchronized with the master server. These values are used to guarantee that the slave will periodically pull a copy of the zone from the master server. In addition to this, and completely independent of the settings on the SOA record, the master notifies the slaves when the zone is updated in order to push a copy of the zone down to the slave. Combining the master-initiated zone push and the slave-initiated zone pull ensures that the zone files on the master and its slaves stay tightly synchronized.

A sample SOA record for the wrotethetutorial.com domain is:

@ IN SOA crab.wrotethetutorial.com. david.crab.wrotethetutorial.com. ( 2001061801 ; serial 21600 ; refresh four times a day 1800 ; retry every half hour 604800 ; expire after 1 week 900 ; negative cache ttl is 15 minutes )

Notice the serial number in this SOA. The serial number is in the format yyyymmddvv, where yyyy is the year, mm is the month, dd is the day, and vv is the version written that day. This type of serial number allows the administrator to track what day the zone was updated. Adding the version number allows for multiple updates in a single day. This zone file was created June 18, 2001, and it is the first update that day.

This SOA record also says that crab is the master server for this zone and that the person responsible for this zone can be reached at the email address david@crab.wrotethetutorial.com. The SOA tells the slave servers to check the zone for changes four times a day and to retry every half hour if they don't get an answer. If they retry for an entire week and never get an answer, they should discard the data for this zone. Finally, if an RR does not exist in this zone and the remote server decides to cache that information, it should cache that information for 15 minutes.

Name Server record

Name Server (NS) resource records identify the authoritative servers for a zone. These records are the pointers that link the domain hierarchy together. NS records in the top-level domains point to the servers for the second-level domains, which in turn contain NS records that point to the servers for their subdomains. Name server records pointing to the servers for subordinate domains are required for these domains to be accessible. Without NS records, the servers for a domain would be unknown.

The format of the NS RR is:

[domain] [ttl] IN NS server

• domain
• The name of the domain for which the host specified in the server field is an authoritative name server.
• ttl
• Time-to-live is usually blank.
• IN
• The address class is IN.
• NS
• The name server resource record type is NS.
• server
• The hostname of a computer that provides authoritative name service for this domain.

  Usually domains have at least one server that is located outside the local domain. The server name cannot be specified relative to the local domain; it must be specified as a fully qualified domain name. To be consistent, many administrators use fully qualified names for all servers, even though it is not necessary for servers within the local domain.

Address record

The majority of the resource records in a forward-mapping zone file[163] are address records. Address records are used to convert hostnames to IP addresses, which is the most common use of the DNS database.

[163]"Configuring DNS" describes the various named configuration files.

The address RR contains the following:

[host] [ttl] IN A address 

• host
• The name of the host whose address is provided in the data field of this record. Most often the hostname is written relative to the current domain.
• ttl
• Time-to-live is usually blank.
• IN
• The address class is IN.
• A
• The address resource record type is A.
• address
• The IP address of the host is written here in dotted decimal form, e.g., 172.16.12.2.

A glue record is a special type of address record. Most address records refer to hosts within the zone, but sometimes an address record needs to refer to a host in another zone. This is done to provide the address of a name server for a subordinate domain. Recall that the NS record for a subdomain server identifies the server by name. An address is needed to communicate with that server, so an A record must also be provided. The address record, combined with the name server record, links the domains together -- thus the term "glue record."

Mail Exchanger record

The Mail Exchanger (MX) record redirects mail to a mail server. It can redirect mail for an individual computer or an entire domain. MX records are extremely useful for domains that contain some systems that don't run SMTP server software. Mail addressed to those systems can be redirected to computers that do run server software. MX records are also used to simplify mail addressing by redirecting mail to servers that understand the simplified addresses.

The format of the MX RR is:

[name] [ttl] IN MX preference host

• name
• The name of a host or domain to which the mail is addressed. Think of this as the value that occurs after the @ in a mailing address. Mail addressed to this name is sent to the mail server specified by the MX record's host field.
• ttl
• Time-to-live is usually blank.
• IN
• The address class is IN.
• MX
• The mail exchanger resource record type is MX.
• preference
• A host or domain may have more than one MX record associated with it. The preference field specifies the order in which the mail servers are tried. Servers with low preference numbers are tried first, so the most preferred server has a preference of 0. Preference values are usually assigned in increments of 5 or 10, so that new servers can be inserted between existing servers without editing the old MX records.
• host
• The name of the mail server to which mail is delivered when it is addressed to the host or domain identified in the name field.

Here is how MX records work. If a remote system has mail to send to a host, it requests the host's MX records. DNS returns all of the X records for the specified host. The remote server chooses the MX with the lowest preference value and attempts to deliver the mail to that server. If it cannot connect to that server, it will try each of the remaining servers in preference order until it can deliver the mail. If no MX records are returned by DNS, the remote server delivers the mail directly to the host to which the mail is addressed. MX records only define how to redirect mail. The remote system and the mail server perform all of the processing that actually delivers the mail.

Because the remote system will first try to use an MX record, many domain administrators include MX records for every host in the zone. any of these MX records point right back to the host to which the mail is addressed, e.g., an MX for crab with a host field of crab.wrotethetutorial.com. These records are used to ensure that the remote computer first attempts delivery to the host, and uses the MX server only if the host cannot accept the mail.

An important use for MX records is to allow mail to non-Internet sites to be delivered using Internet-style addressing. MX records do this by redirecting the mail to computers that know how to deliver the mail to non-Internet networks. For example, sites using uucp can register an Internet domain name with UUNET. UUNET uses MX records to redirect Internet mail addressed to these non-connected sites to uunet.uu.net, which delivers the mail to its final destination via uucp.

Here are some MX examples. All of these examples are for the imaginary domain wrotethetutorial.com. In the first example, mail addressed to clock.wrotethetutorial.com is redirected to crab.wrotethetutorial.com with this MX record:

clock IN MX 10 crab

The second example is an MX record used to simplify mail addressing. People can send mail to any user in this domain without knowing the specific computer that the user reads his mail on. Mail addressed to user@wrotethetutorial.com is redirected by this MX record to crab, which is a mail server that knows how to deliver mail to every individual user in the domain.

wrotethetutorial.com. IN MX 10 crab.wrotethetutorial.com.

The last example is an MX record that redirects mail addressed to any host within the domain to a central mail server. Mail addressed to any host, horseshoe.wrotethetutorial.com, seven.wrotethetutorial.com, or anything.wrotethetutorial.com, is redirected to crab. This is the most common use of the wildcard character (*).

*.wrotethetutorial.com. IN MX 10 crab.wrotethetutorial.com.

In these examples, the preference is 10 so that a mail server with a lower preference number can be added to the zone without changing the existing MX record. Also notice that the hostnames in the first example are specified relative to the wrotethetutorial.com domain, but the other names are not relative because they end in a dot. All of these names could have been entered as relative names because they all are hosts in the wrotethetutorial.com domain; fully qualified names were used only to vary the examples. Finally, the wildcard MX record applies only to hosts that do not have specific MX records. If the specific record for clock is in the same configuration as the wildcard record, the wildcard MX does not apply to clock.

Canonical Name record

The Canonical Name (CNAME) resource record defines an alias for the official name of a host. The CNAME record provides a facility similar to nicknames in the host table. The facility provides alternate hostnames for the convenience of users, and generic hostnames used by applications (such as loghost used by syslogd).

The CNAME record is frequently used to ease the transition from an old hostname to a new hostname. While it is best to avoid hostname changes by carefully choosing hostnames in the first place, not all changes can be avoided. When you do make a name change, it can take a long time before it becomes completely effective, particularly if the hostname is embedded in a mailing list run at a remote site. To reduce problems for the remote site, use a CNAME record until they can make the change.

The format of the CNAME record is:

nickname [ttl] IN CNAME host

• nickname
• This hostname is an alias for the official hostname defined in the host field. The nickname can be any valid hostname.
• ttl
• Time-to-live is usually blank.
• IN
• The address class is IN.
• CNAME
• The canonical name resource record type is CNAME.
• host
• The canonical name of the host is provided here. This hostname must be the official hostname; it cannot be an alias.

One important thing to remember about the CNAME record is that all other resource records must be associated with the official hostname and not with the nickname. This means that the CNAME record should not be placed between a host and the list of RRs associated with that host. The example below shows a correctly placed CNAME record:

rodent IN A 172.16.12.2 IN MX 5 rodent.wrotethetutorial.com. IN RP alana.wrotethetutorial.com. alana IN TXT "Linux workstation in room A15" mouse IN CNAME rodent.wrotethetutorial.com.

In this example, the hostname rodent stays in force for the MX, RP, and TXT records because they all have blank name fields. The CNAME record changes the name field value to mouse, which is a nickname for rodent. Any RRs with blank name fields following this CNAME record would associate themselves with the nickname mouse, which is illegal. An improper CNAME placement is:

rodent IN A 172.16.12.2 mouse IN CNAME rodent.wrotethetutorial.com. IN MX 5 rodent.wrotethetutorial.com. IN RP alana.wrotethetutorial.com. alana IN TXT "Linux workstation in room A15"

This improperly placed CNAME record causes named to display the error message "mouse.wrotethetutorial.com has CNAME and other data (illegal)." Check /var/adm/messages for named error messages to ensure that you have not misplaced any CNAME records.

Domain Name Pointer record

The Domain Name Pointer (PTR) resource records are used to convert numeric IP addresses to hostnames. This is the opposite of what is done by the address record that converts hostnames to addresses. PTR records are used to construct the in-addr.arpa reverse domain files.

Many administrators ignore the reverse domains because things appear to run fine without them. Don't ignore them. Keep these zones up to date. Several programs use the reverse domains to map IP addresses to hostnames when preparing status displays. A good example is the netstat command. Some service providers use the reverse domains to track who is using their services. If they cannot map your IP address back to a hostname, they reject your connection.

The format of the PTR record is:

name [ttl] IN PTR host

• name
• The name specified here is actually a number. The number is defined relative to the current in-addr.arpa domain. Names in an in-addr.arpa domain are IP addresses specified in reverse order. If the current domain is in-addr.arpa, then the name field for rodent (172.16.12.2) is 2.12. These digits (2.12) are added to the current domain (in-addr.arpa) to make the name in-addr.arpa. "Getting Started" discusses the unique structure of in-addr.arpa domain names.
• ttl
• Time-to-live is usually blank.
• IN
• The address class is IN.
• PTR
• The Domain Name Pointer resource record type is PTR.
• host
• This is the fully qualified domain name of the computer whose address is specified in the name field. The host must be specified as a fully qualified name because the name cannot be relative to the current in-addr.arpa domain.

There are many examples of PTR records in the sample reverse-mapping zone file (rev) shown in "Configuring DNS".

Responsible Person record

The Responsible Person (RP) record identifies the point of contact for a host or domain. The format of the RP record is:

[name] [ttl] IN RP mail_address text_pointer

• name
• The name of the domain object for which the responsible person is defined.
• ttl
• Time-to-live is usually blank.
• IN
• The address class is IN.
• RP
• The resource record type is RP.
• mail_address
• The email address of the responsible person. The @ usually included in an email address is replaced with a dot. Thus, craig@wrotethetutorial.com becomes craig.wrotethetutorial.com.
• text_pointer
• The domain name of a TXT record that contains additional information about the responsible person.

Here's an example of how an RP record is used with a TXT record:

crab.wrotethetutorial.com. IN RP craig.wrotethetutorial.com. crabRP crabRP.wrotethetutorial.com. IN TXT "Craig Hunt (301)555-1234 X237"

The RP record states that the person responsible for crab.wrotethetutorial.com can be reached via email at craig@wrotethetutorial.com and that additional information about the person can be obtained in the TXT records for crabRP.wrotethetutorial.com. The TXT record provides the contact person's name and phone number.

Text record

The Text (TXT) resource record holds string data. The text data can be in any format. Some sites define a local format for the information. For example, a TXT record could hold the Ethernet address of a host at one site and a room number at another site.

The format of the TXT record is:

[name] [ttl] IN TXT string

• name
• The name of the domain object with which the string data is associated.
• ttl
• Time-to-live is usually blank.
• IN
• The address class is IN.
• TXT
• The resource record type is TXT.
• string
• The string field contains text data enclosed in quotation marks.

Host Information record

The Host Information (HINFO) resource record provides a short description of the hardware and operating system used by a specific host. The hardware and software are described using standard terminology defined in the Assigned Numbers RFC in the sections on Machine Names (hardware) and System Names (software). There are a large number of hardware and software designators listed in the RFC. Most names use the same general format. Names with embedded blanks must be enclosed in quotes, so some names have a dash (-) where you might expect a blank. A machine name is usually the manufacturer's name in uppercase letters separated from the model number by a dash. The system name is usually the manufacturer's operating system name written in uppercase letters. Naturally the rapid changes in the computer market constantly make the data in the Assigned Numbers RFC out of date. Because of this, many administrators make up their own values for machine names and system names.

The format of the HINFO record is:

[host] [ttl] IN HINFO hardware software

• host
• The hostname of the computer whose hardware and software are described in the data section of this resource record.
• ttl
• Time-to-live is usually blank.
• IN
• The address class is IN.
• HINFO
• HINFO is the resource record type. All of the information that follows is part of the HINFO data field.
• hardware
• This field identifies the hardware used by this host. It contains the machine name defined in the Assigned Numbers RFC. This field must be enclosed in quotes if it contains any blanks. A single blank space separates the hardware field from the software field that follows it.
• software
• This field identifies the operating system software this host runs. It contains the system name defined for this operating system in the Assigned Numbers RFC. Use quotes if the system name contains any blanks.

No widely used application makes use of the HINFO record; the record just provides information. Some security-conscious sites discourage its use. They fear that this additional information helps intruders narrow their attacks to the specific hardware and operating system that they wish to crack. The general-purpose TXT record is more often used to provide information about systems than is the HINFO record.

Well-Known Services record

The Well-Known Services (WKS) resource record names the network services supported by the specified host. The official protocol names and services names used on the WKS record are defined in the Assigned Numbers RFC. The simplest way to list the names of the well-known services is to cat the /etc/services file on your system. Each host can have no more than two WKS records; one record for TCP and one for UDP. Because several services are usually listed on the WKS record, each record may extend through multiple lines.

The format of the WKS record is:

[host] [ttl] IN WKS address protocol services

• host
• The hostname of the computer that provides the advertised services.
• ttl
• Time-to-live is usually blank.
• IN
• The address class is IN.
• WKS
• The resource record type is WKS. All of the information that follows is variable information for the WKS record.
• address
• The IP address of the host written in dotted decimal format, e.g., 172.16.12.2.
• protocol
• The transport-level protocol through which the service communicates -- either TCP or UDP.
• services
• The list of services provided by this host. As few or as many services as you choose may be advertised, but the names used to advertise the services must be the names found in the /etc/services file. Items in the list of services are separated by spaces. Parentheses are used to continue the list beyond a single line.

There are no widely used applications that make use of this record. It is used only to provide general information about the system. Again, security-conscious sites may not wish to advertise their services. Some protocols, such as tftp and finger, are prime targets for intruders. The SRV record is more useful for providing information about the services offered by a specific server.

Server Selection record

The Server Selection (SRV) record provides a standardized way to locate network servers. The SRV record provides a standard convention for creating generic server names, and it adds features for server selection and load-balancing. The format of the SRV record is:

name [ttl] IN SRV preference weight port server

• name
• The SRV record has a unique _service_protocolname format. Dots are used to separate the components in the name field just as in any domain name. The underscore characters (_) are used to prevent the service name and the protocol name from colliding with real domain names. service is the name of the offered service as listed in the /etc/services file. protocol is the protocol name associated with that service in the /etc/services file. name is a standard host or domain name that would be found in any name field. Using these criteria, the name that could be used to find the FTP servers for the wrotethetutorial.com domain would be _ftp._tcp.wrotethetutorial.com.
• ttl
• Time-to-live is usually blank.
• IN
• The address class is IN.
• SRV
• The resource record type is SRV.
• preference
• A number used to select the most preferred server when multiple SRV records exist for the same service. The server with the lowest number is the most preferred. All traffic is sent to the most preferred servers; servers with a higher preference number are used only if the preferred servers are not available.
• weight
• A number that defines the share of traffic sent to a server, with 1 being the base. If server A has a weight of 1 and server B has a weight of 2, B gets twice as much traffic as A. weight is used only to balance the load among servers with the same preference number.
• port
• The port number used for the specified service. Normally, this is the port number defined in the /etc/services file for the specified service. But it is possible to specify a nonstandard port number for services equipped to use nonstandard numbers.
• server
• The canonical hostname of the computer running the requested service.