Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)       9  Name Systems and TCP/IP Name Registration and Name Resolution            9  TCP/IP Name Systems: Host Tables and Domain Name System (DNS)                 9  TCP/IP Domain Name System (DNS)                      9  DNS Name Servers and Name Resolution                           9  DNS Messaging and Message, Resource Record and Master File Formats

DNS Message Resource Record Field Formats 1 2 3 DNS Master File Format

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.

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”.

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] w w w [13] x y z i n d u s t r i e s [3] c o m [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.

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] j o h n n y [9] s o m e w h e r e [3] o r g [0]”.

Note that there is no specific indication that this is an e-mail address. The name is interpreted as an e-mail address instead of a device name based on context.

DNS Message Resource Record Field Formats 1 2 3 DNS Master File Format