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

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 “xyzindustries.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.xyzindustries.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.

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

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