Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

MX / Mail Exchange Resource Record (Type Value 15)

This special record contains information about the mail server(s) to be used for sending e-

mail to the domain. Each record contains two fields as Table 178 illustrates.

TXT / Text Resource Record (Type Value 16)

This descriptive record contains additional descriptive information about the named object

(Table 179).

DNS Name Notation and Message Compression Technique

Obviously, the entire Domain Name System protocol is oriented around dealing with names

for domains, subdomains and objects. We've seen in the preceding topics that there are

many fields in DNS messages and resource records that carry the names of objects, name

servers and so forth. DNS uses a special notation for encoding names in resource records

and fields, a variation of this notation for e-mail addresses, and a special compression

method that reduces the size of messages for efficiency.

Standard DNS Name Notation

In the section describing the DNS name space we saw how DNS names are constructed.

Each node in the name hierarchy has a label associated with it. The fully-qualified domain

name (FQDN) for a particular device consists of the sequence of labels that starts from the

root of the tree and progresses down to that device. The labels at each level in the

hierarchy are listed in sequence, starting with the highest level, from right to left, separated

by dots. This results in the domain names we are used to working with, such as

“www.xyzindustries.com”.

Table 178: DNS Mail Exchange Resource Record Data Format

Subfield Name

Size

(bytes)

Description

Preference 2

Preference Value: The preference level for this mail exchange. Lower

values signify higher preference.

Exchange Variable

Exchange Domain Name: The domain name, encoded using standard

DNS name notation, of a host willing to provide mail exchange services for

this named object.

Table 179: DNS Text Resource Record Data Format

Subfield Name

Size

(bytes)

Description

TXT-Data Variable Text Data: Variable-length descriptive text.

It would be possible to encode these names into resource records or other DNS message

fields directly: put the letter “w” into each of the first three bytes of the name, then put a “.”

into the fourth byte, an “x” into the fifth and so on. The disadvantage of this is that as a

computer was reading the name, it wouldn't be able to tell when each name was finished.

We would need to include a length field for each name.

Instead, DNS uses a special notation for DNS names. Each label is encoded one after the

next in the name field. Before each label, a single byte is used that holds a binary number

indicating the number of characters in the label. Then, the label's characters are encoded,

one per byte. The end of the name is indicated by a null label, representing the root; this of

course has a length of zero, so each name ends with just a “0” character, indicating this

zero-length root label.

Note that the “dots” between the labels aren't necessary, since the length numbers

delineate the labels. The computer reading the name also knows how many bytes are in

each label as it reads the name, so it can easily allocate space for the label as it reads it

from the name.

For example, “www.xyzindustries.com” would be encoded as:

“[3]www[13]xyzindustries[3]com[0]”

I have shown the label lengths in square brackets to distinguish them. Remember that

these label lengths are binary encoded numbers, so a single byte can hold a value from 0 to

255; that “[13]” is one byte and not two, as you can see in Figure 252. Labels are actually

limited to a maximum of 63 characters, and we'll see shortly why this is significant.

Figure 252: DNS Standard Name Notation

In DNS every named object or other name is represented by a sequence of label lengths and then labels, with

each label length taking one byte and each label taking one byte per character. This example shows the

encoding of the name “www.xyzindustries.com”.

3 w w w

13 x y z

i n d u

s t r i

e s 3 c

o m 0

4 8 12 16 20 24 28 320

DNS Electronic Mail Address Notation

Electronic mail addresses are used in certain DNS resource records, such as the RName

field in the Start Of Authority resource record. E-mail addresses of course take the form

“<name>@<domain-name>”. DNS encodes these in exactly the same way as regular DNS

domains, simply treating the “@” like another dot. So, “johnny@somewhere.org” would be

treated as “johnny.somewhere.org” and encoded as:

“[6]johnny[9]somewhere[3]org[0]”.

Note that there is no specific indication that this is an e-mail address. The name is inter-

preted as an e-mail address instead of a device name based on context.

DNS Message Compression

A single DNS message may contain many domain names. Now, consider that when a

particular name server sends a response containing multiple domain names, they are all

usually in the same zone, or are related to the zone. Most of these names will have

common elements to their names.

Consider our previous mail example of a client asking for an MX record for “xyzindus-

tries.com”. The response to this client will contain, among other things, these two records:

☯ MX Record: An MX record that has “xyzindustries.com” as the Name of the record,

and “mail.xyzindustries.com” in the RData field.

☯ A Record: Assuming the name server knows the IP address of “mail.xyzindus-

tries.com”, the Additional section will contain an A record that has

“mail.xyzindustries.com” as the Name and its address in the RData field.

This is just one small example of name duplication; it can be much more extreme with other

types of DNS messages, with certain string patterns being repeated many times. Normally

this would require that each name be spelled out fully using the encoding method described

above. But this would be wasteful, since a large portion of these names is common.

Using Message Compression to Avoid Duplication of a Full Name

To cut down on duplication, a special technique called message compression is used.

Instead of a DNS name encoded as above using the combination of labels and label-

lengths, a two-byte subfield is used to represent a pointer to another location in the

message where the name can be found. The first two bits of this subfield are set to one (the

value “11” in binary), and the remaining 14 bits contain an offset that species where in the

message the name can be found, counting the first byte of the message (the first byte of the

ID field) as 0.

Let's go back to our example. Suppose that in the DNS message above, the RData field of

the MX record, containing “mail.xyzindustries.com”, begins at byte 47. In this first instance,

we would find the name encoded in full as:

“[4]mail[13]xyzindustries[3]com[0]”.

However, the second instance, where “mail.xyzindustries.com” shows up in the Name field

of the A record, we would instead put two “1” bits, followed by the number 47 encoded in

binary. So, this would be the 16-bit binary pattern “11000000 00101111”, or two numeric

byte values “192” and “47”. This second instance now takes 2 bytes instead of duplicating

the 24 bytes needed for the first instance of the name.

How does a device reading a name field differentiate a pointer from a “real” name? This is

the reason that “11” is used at the start of the field. Doing this guarantees that the first byte

of the pointer will always have a value of 192 or larger. Since labels are restricted to a

length of 63 or less, when the host reads the first byte of a name, if it sees a value of 63 or

less in a byte, it knows this is a “real” name; a value of 192 or more means it is a pointer.

Using Message Compression to Avoid Duplication of Part of a Name

The example above shows how pointers can be used to eliminate duplication of a whole

name: the name “mail.xyzindustries.com” was used in two places and a pointer was used

instead of the second. Pointers are even more powerful than this, however. They can also

be used to point to only part of a real name, or can be combined with additional labels to

provide a compressed representation of a name related to another name in a resource

record. This provides even greater space savings.

In the example above, this means that even the first instance of “mail.xyzindustries.com”

can be compressed. Recall that the MX record will have “xyzindustries.com” in the Name

field and “mail.xyzindustries.com” in the RData field. If the Name field of that record starts at

byte 19, then we can encode the RData field as:

“[4] m a i l [pointer-to-byte-19]”.

The device reading the record will get “mail” for the first label and then read “xyzindus-

tries.com” from the Name field to get the complete name, “mail.xyzindustries.com”.

Similarly, suppose we had a record in this same message that contained a reference to the

parent domain for “xyzindustries.com”, which is of course “com”. This could simply be

encoded as:

“[pointer-to-byte-33]”

The reason is that byte 33 is where we find the “[3] c o m [0]” part of the Name field

containing “[13] x y z i n d u s t r i e s [3] c o m [0]”.

DNS Master File Format

DNS servers answer queries from clients by sending reply messages containing resource

records. We have already seen in this section the binary message formats used to encode

these resource records. These message formats are great for transmitted messages,

because they are compact and efficient, and computers have no problem reading fields

very quickly and knowing how to interpret a particular string of ones and zeroes.

Humans, on the other hand, don't deal well with cryptic codes in binary. Before a resource

record can be provided by a server, it is necessary for a human administrator to tell the

server what those records are and what information they contain. To make this job easier,

DNS includes a special text representation for zones and resource records. Administrators

edit special master files that describe the zone and the records it contains; these files are

then read into memory by the server's DNS software, and converted into binary form for

responding to client requests. This is described in more detail in the overview topic on

resource records.

Each master file consists of a simple “flat text” file that can be created with any sort of text

editor. Each file contains a number of lines expressed using a simple set of syntax rules that

describe a zone and the records within it. The basic syntactic rules for DNS master files are

specified in RFC 1035, section 5.1. Certain DNS implementations use their own variations

on the syntax in the standard, though they are all pretty similar.

DNS Common Master File Record Format

Just as all resource records are stored internally using a common field format, they also use

a common master file format. Each record normally appears on a separate line of the file.

This format is as follows, with optional fields shown in square brackets:

<domain-name> [<ttl>] <class> <type> <rdata>

The fields are as follows:

☯ <domain-name>: A DNS domain name, which may be either a fully-qualified domain

name (FQDN) or a partially-qualified name (PQDN). See below.

☯ <ttl>: A Time To Live value, in seconds, for the record. If omitted, the default TTL

value for the zone is used. In fact, most resource records do not have a specified TTL,

just using the default provided by the Start Of Authority record.

☯ <class>: The resource record class. For modern DNS this field is optional, and

defaults to “IN” for “Internet”

☯ <type>: The resource record type, specified using a text code such as “A” or “NS”, not

the numeric code.

☯ <rdata>: Resource record data, which is a set of space-separated entries that

depends on the record type.

The “<rdata>” can be either a single piece of information or a set of entries, depending on

the record type. In the case of longer record types, especially the Start Of Authority record,

multiple entry “<rdata>” fields are spread over several lines and enclosed in parentheses;

the parentheses make all the entries act as if they were on a single line. Note that if the

“<ttl>” field is present, the order of it and the “<class>” field may be switched; this causes no

problems because one is a number and the other text (“IN”).

Use and Interpretation of Partially-Qualified Domain Names

Domain names may be mixed between FQDNs and PQDNs. Partially-qualified names are

used to make master files faster to create and more readable, by cutting down on the

common parts of names; they are sort of the “human equivalent” of DNS message

compression. A FQDN is shown as a full domain name ending in a dot (“.”) to represent the

DNS name tree root. A PQDN is given as just a partial name with no root, and is interpreted

as a FQDN by the software reading the master file (see the $ORIGIN directive below for

more.)

It is important to remember the trailing dot to mark FQDNs; if the origin is “xyzindus-

tries.com” and in its zone file the name “bigisp.net” appears, the server will read this as

“bigisp.net.xyzindustries.com”—probably not what you want. Also, e-mail addresses, such

as the <r-name> field in the SOA record, have the “@” of the e-mail address converted to a

dot, following the standard DNS convention.

Master File Directives

In addition to resource records, most master file implementations also support the use of

directives. These are commands that specify certain important pieces of information to

guide how the master file is to be interpreted. Three of the most common directives are:

☯ $ORIGIN: Specifies the domain name that is appended to unqualified specifications;

this is the “base” used to convert PQDNs to FQDNs. For example, if the origin is

“xyzindustries.com.”, then a PQDN such as “sales” will be interpreted as “sales.xyzin-

dustries.com.”. Once defined, the origin can be referenced by just using “@” in place

of a name, as we will see in the example at the end of this topic.

☯ $TTL: Specifies the default Time To Live value to be used for any resource records

that do not specify a TTL value in the record itself. (This value was formerly specified

by the Minimum field in the Start Of Authority record.)

☯ $INCLUDE: Allows one master file to include the contents of another. This is

sometimes used to save the duplication of certain entries that are common between

zones.

Syntax Rules for Master Files

There are a few other syntax rules for DNS master files, some of which are intended to save

further time or energy on the part of administrators:

☯ Multiple-Record Shorthand: If multiple consecutive records pertain to the same

domain, the “<domain-name>” is specified for the first one, and can be then be left

blank for the subsequent ones. The server will assume that any resource records

without a “<domain-name>” indicated apply to the last “<domain-name>” it saw.

☯ Comments: A semicolon (“;”) marks a comment. Any text from the semicolon until the

end of the line is ignored.

☯ Escape Character: A backslash (“\”) is used to “escape” the special meaning of a

character. For example, a double-quote (") is used to delimit text strings; a literal

double-quote character is indicated by a backslash-double-quote combination (\").

☯ White Space: Tabs and spaces are used as delimiters and blank lines are ignored.

For readability, most smart administrators indent using tabs to make more clear which

records belong with which names, and group records using blank lines and comments.

☯ Case: Like DNS domain names, master file entries are case-insensitive.

Specific Resource Record Syntax and Examples

Table 180 shows the specific formats and examples for each of the common resource

record types. The fields are basically the same as the ones explained in the DNS binary

record formats. I have included explanatory “comments” using the DNS comment format.

Assume that the examples in this table are for the zone “googleplex.edu”:

Table 180: DNS Master File Format Syntax and Examples

Resource

Record

Text Code

Resource

Record

Type

Resource Record Format / Example

A Address

<domain-name> [<ttl>] IN A <ip-address>

admin1.googleplex.edu IN A 204.13.100.3 ; A FQDN.

admin2 IN A 204.13.100.44 ; A PQDN equivalent to

; admin2.googleplex.edu

Name

Server

<domain-name> [<ttl>] IN NS <name-server-name>

googleplex.edu. IN NS custns.bigisp.net ; Secondary NS

CNAME

Canonical

Name

<domain-name> [<ttl>] IN CNAME <canonical-name>

www IN CNAME bigserver ; www.googleplex.edu is really

; bigserver.googleplex.edu.

SOA

Start Of

Authority

<domain-name> [<ttl>] IN SOA <m-name> <r-name> (

<serial-number>

<refresh-interval>

<retry-interval>

<expire-interval>

<default-ttl>)

googleplex.edu. IN SOA ns1.googleplex.edu it.googleplex.edu (

42 ; Version 42 of the zone.

21600 ; Refresh every 6 hours.

3600 ; Retry every hour.

604800 ; Expire after one week.

86400) ; Negative Cache TTL is one day.

PTR Pointer

<reverse-domain-name> [<ttl>] IN PTR <domain-name>

3.100.13.204.IN-ADDR.ARPA. IN PTR admin1.googleplex.edu.

Mail

Exchange

<domain-name> [<ttl>] IN MX <preference-value> <exchange-name>

googleplex.edu. IN MX 10 mainmail.googleplex.edu.

IN MX 20 backupmail.googleplex.edu

TXT Text

<domain-name> [<ttl>] IN TXT <text-information>

googleplex.edu. IN TXT "Contact Joe at X321 for more info."

Note that the PTR record would actually be in the IN-ADDR.ARPA domain, of course.

Table 181 contains a “real-world” example of a DNS master file, taken from my own

“pcguide.com” server (slightly modified), hosted by (and DNS information provided by) the

fine folks at pair.com. Note the use of “@” as a short-cut to mean “this domain”

(“pcguide.com”):

Table 181: Sample DNS Master File

$ORIGIN pcguide.com.

@ IN SOA ns23.pair.com. root.pair.com. (

2001072300 ; Serial

3600 ; Refresh

300 ; Retry

604800 ; Expire

3600 ) ; Minimum

@ IN NS ns23.pair.com.

@ IN NS ns0.ns0.com.

localhost IN A 127.0.0.1

@ IN A 209.68.14.80

IN MX 50 qs939.pair.com.

www IN CNAME @

ftp IN CNAME @

mail IN CNAME @

relay IN CNAME relay.pair.com.

DNS Changes To Support IP Version 6

Version 4 of the Internet Protocol (IPv4) is the basis of today's Internet, and the foundation

upon which the TCP/IP protocol suite is built. While IPv4 has served us well for over two

decades, it has certain important drawbacks that would limit internetworks of the future if it

were to continue to be used. For this reason, the next generation of IP, the Internet Protocol

version 6 (IPv6), has been in development for many years. IPv6 will eventually replace IPv4

and take TCP/IP into the future.

The change from IPv4 to IPv6 will have effects that “ripple” to other TCP/IP protocols,

including the Domain Name System. DNS is a higher-level protocol, so you might think that

based on the principle of layering, a change to IP should not affect it. However, this is

another example of how “strict layering” doesn't always apply. DNS works directly with IP

addresses, and one of the most significant modifications that IPv6 makes to IP is in the area

of addressing, so this means that using DNS on IPv6 requires some changes to how the

protocol works.

IPv6 DNS Extensions

Since DNS is so “architecturally distant” from IP down there at layer three, the changes

required are not extensive. RFC 1886, entitled IPv6 DNS Extensions and published in

December 1995, was the IETF's first formalized attempt to describe the changes needed in

DNS to support IPv6. It defines three specific modifications to DNS for IPv6:

☯ New Resource Record Type—AAAA (IPv6 Address): The regular DNS Address

resource record is defined for a 32-bit IPv4 address, so a new one was created to

allow a domain name to be associated with a 128-bit IPv6 address. The four “A”s

(“AAAA”) are a mnemonic to indicate that the IPv6 address is four times the size of the

IPv4 address. The AAAA record is structured in very much the same way as the A

record in both binary and master file formats; it is just much larger. The DNS resource

record Type value for AAAA is 28.

☯ New Reverse Resolution Hierarchy: A new hierarchical structure similar to IN-

ADDR.ARPA is defined for IPv6 reverse lookups, but the IETF put it in a different top-

level domain. The new domain is IP6.INT, and is used in a way similar to how IN-

ADDR.ARPA works. However, since IPv6 addresses are expressed in hexadecimal

instead of dotted-decimal, IP6.INT has sixteen subdomains “0” through “F”, and each

of those has sixteen subdomains “0” through “F”, and so on, sixteen layers deep. Yes,

this leads to a potentially frightfully large reverse resolution database!

☯ Changes To Query Types And Resolution Procedure: All query types that work

with A records or result in A records being included in the Additional section of a reply

must be changed to also handle AAAA records. Also, queries that would normally

result in A records being returned in the Additional section must return the corre-

sponding AAAA records only in the Answer section, not the Additional section.

Key Concept: Even though DNS resides far above the Internet Protocol in the TCP/

IP protocol suite architecture, it works intimately with IP addresses. For this reason,

changes are required to allow it to support the new IPv6. These changes include the

definition of a new IPv6 address resource record (AAAA), a new reverse resolution domain

hierarchy, and certain changes to how messaging is performed.

Proposed Changes to the IPv6 DNS Extensions

In 2000, the IETF published RFC 2874, DNS Extensions to Support IPv6 Address Aggre-

gation and Renumbering. This standard proposed a replacement for the IPv6 support

introduced in RFC 1886, using a new record type, A6, instead of 1886's AAAA. The main

difference between AAAA and A6 records is that the former are just whole addresses like A

records, while A6 records can contain either a whole or partial address.

The idea behind RFC 2874 was that A6 records could be set up in a manner that comple-

ments the IPv6 format for unicast addresses. Then, name resolution would involve a

technique called chaining to determine a full address for a name from a set of partially-

specified address components. In essence, this would make the addresses behave much

the way hierarchical names themselves work, providing some potential flexibility benefits.

For a couple of years, both RFC 1886 and RFC 2874 were proposed standards, and this

led to considerable confusion. In August 2002, RFCs 3363 and 3364 were published, which

clarified the situation with these two proposals. RFC 3363 represents the “Supreme Court

decision”, which was that RFC 2874 and the A6 record be changed to experimental status

and the AAAA record of RFC 1886 be kept as the DNS IPv6 standard.

The full explanation for the decision can be found in RFC 3364. In a nutshell, it boiled down

to the IETF believing that there were significant potential risks in the successful implemen-

tation of RFC 2874. While the capabilities of the A6 record were “interesting”, it was not

clear that they were needed, and given those risks, they felt sticking with RFC 1886 was the

better move.