3. Domain Name Space and RR Definitions
This chapter defines how domain names are encoded in DNS and the format of resource records. This is the core technical specification for implementing DNS.
3.1. Name Space Definitions
Domain Name Encoding
Domain names in messages are expressed in terms of a sequence of labels.
Encoding Format:
Each label is represented as:
[length byte (1 byte)][label content (N bytes)]
Example: www.example.com
Encoded as: 3www7example3com0
Detailed Explanation:
- Each label is represented as a one octet length field followed by that number of octets
- Since every domain name ends with the null label of the root, a domain name is terminated by a length byte of zero
- The high order two bits of every length octet must be zero
- The remaining six bits of the length field limit the label to 63 octets or less
Length Limits:
Single label: ≤ 63 bytes
Complete domain name: ≤ 255 bytes (including length bytes)
Label Content Rules
Byte Values: Labels can contain any 8 bit values in octets that make up a label
Strong Recommendation: Labels should follow the preferred syntax described elsewhere in this memo, which is compatible with existing host naming conventions
Comparison Rules:
- Name servers and resolvers must compare labels in a case-insensitive manner
- Assuming ASCII with zero parity (i.e., A=a)
- Non-alphabetic codes must match exactly
3.2. RR Definitions
3.2.1. Format
All RRs (Resource Records) have the same top level format shown below:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Field Descriptions:
-
NAME: An owner name, i.e., the name of the node to which this resource record pertains.
-
TYPE: Two octets containing one of the RR TYPE codes.
-
CLASS: Two octets containing one of the RR CLASS codes.
-
TTL: A 32 bit signed integer that specifies the time interval that the resource record may be cached before the source of the information should again be consulted. Zero values are interpreted to mean that the RR can only be used for the transaction in progress, and should not be cached.
-
RDLENGTH: An unsigned 16 bit integer that specifies the length in octets of the RDATA field.
-
RDATA: A variable length string of octets that describes the resource. The format of this information varies according to the TYPE and CLASS of the resource record.
3.2.2. TYPE Values
TYPE fields are used in resource records. Note that these types are a subset of QTYPEs.
| TYPE | Value | Meaning |
|---|---|---|
| A | 1 | Host address |
| NS | 2 | Authoritative name server |
| MD | 3 | Mail destination (Obsolete - use MX) |
| MF | 4 | Mail forwarder (Obsolete - use MX) |
| CNAME | 5 | Canonical name for an alias |
| SOA | 6 | Start of a zone of authority |
| MB | 7 | Mailbox domain name (EXPERIMENTAL) |
| MG | 8 | Mail group member (EXPERIMENTAL) |
| MR | 9 | Mail rename domain name (EXPERIMENTAL) |
| NULL | 10 | Null RR (EXPERIMENTAL) |
| WKS | 11 | Well known service description |
| PTR | 12 | Domain name pointer |
| HINFO | 13 | Host information |
| MINFO | 14 | Mailbox or mail list information |
| MX | 15 | Mail exchange |
| TXT | 16 | Text strings |
3.2.3. QTYPE Values
QTYPE fields appear in the question part of a query. QTYPEs are a superset of TYPEs, hence all TYPEs are valid QTYPEs.
| QTYPE | Value | Meaning |
|---|---|---|
| AXFR | 252 | Request for a transfer of an entire zone |
| MAILB | 253 | Request for mailbox-related records (MB, MG or MR) |
| MAILA | 254 | Request for mail agent RRs (Obsolete - see MX) |
| * | 255 | Request for all records |
3.2.4. CLASS Values
CLASS fields appear in resource records.
| CLASS | Value | Meaning |
|---|---|---|
| IN | 1 | The Internet |
| CS | 2 | The CSNET class (Obsolete) |
| CH | 3 | The CHAOS class |
| HS | 4 | Hesiod [Dyer 87] |
3.2.5. QCLASS Values
QCLASS fields appear in the question section of a query. QCLASS values are a superset of CLASS values.
| QCLASS | Value | Meaning |
|---|---|---|
| * | 255 | Any class |
3.3. Standard RRs
The following RR definitions are expected to occur in all implementations.
3.3.1. CNAME RDATA Format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ CNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Where:
- CNAME: A domain name which specifies the canonical or primary name for the owner. The owner name is an alias.
CNAME Usage:
- A CNAME RR identifies its owner name as an alias
- Specifies the corresponding canonical name in the RDATA section
- If a CNAME RR is present at a node, no other data should be present
- This ensures that the data for a canonical name and its aliases cannot be different
3.3.2. HINFO RDATA Format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ CPU /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ OS /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Where:
- CPU: A character string which specifies the CPU type
- OS: A character string which specifies the operating system type
Purpose: HINFO records are used to acquire general information about a host.
3.3.9. MX RDATA Format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFERENCE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ EXCHANGE /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Where:
- PREFERENCE: A 16 bit integer which specifies the preference given to this RR among others at the same owner. Lower values are preferred.
- EXCHANGE: A domain name which specifies a host willing to act as a mail exchange for the owner name.
MX Usage:
- MX records cause type A additional section processing for the host specified by EXCHANGE
- The use of MX RRs is explained in detail in RFC-974
3.3.11. NS RDATA Format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ NSDNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Where:
- NSDNAME: A domain name which specifies a host which should be authoritative for the specified class and domain.
NS Usage:
- NS records cause both the usual additional section processing to locate a type A record
- When used in a referral, they signal a delegation point in the namespace
3.3.12. PTR RDATA Format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ PTRDNAME /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Where:
- PTRDNAME: A domain name which points to some location in the domain name space.
PTR Usage:
- PTR records cause no additional section processing
- These RRs are used in special domains to point to some other location in the domain space
- Used for reverse DNS lookups in the IN-ADDR.ARPA domain
3.3.13. SOA RDATA Format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ MNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ RNAME /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SERIAL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| REFRESH |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RETRY |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| EXPIRE |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| MINIMUM |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Where:
- MNAME: The domain name of the name server that was the original or primary source of data for this zone.
- RNAME: A domain name which specifies the mailbox of the person responsible for this zone.
- SERIAL: The unsigned 32 bit version number of the original copy of the zone. Zone transfers preserve this value.
- REFRESH: A 32 bit time interval before the zone should be refreshed.
- RETRY: A 32 bit time interval that should elapse before a failed refresh should be retried.
- EXPIRE: A 32 bit time value that specifies the upper limit on the time interval that can elapse before the zone is no longer authoritative.
- MINIMUM: The unsigned 32 bit minimum TTL field that should be exported with any RR from this zone.
3.3.14. TXT RDATA Format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ TXT-DATA /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Where:
- TXT-DATA: One or more character strings.
TXT Usage:
- TXT RRs are used to hold descriptive text
- The semantics of the text depends on the domain where it is found
3.4. Internet Specific RRs
3.4.1. A RDATA Format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Where:
- ADDRESS: A 32 bit Internet address.
A Record Usage:
- Hosts that have multiple Internet addresses will have multiple A records
- A records cause no additional section processing
- The RDATA section of an A line in a master file is an Internet address expressed as four decimal numbers separated by dots
Example:
www.example.com. IN A 93.184.216.34
3.4.2. WKS RDATA Format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PROTOCOL | |
+--+--+--+--+--+--+--+--+ |
| |
/ <BIT MAP> /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Where:
- ADDRESS: An 32 bit Internet address.
- PROTOCOL: An 8 bit IP protocol number.
- BIT MAP: A variable length bit map. The bit map must be a multiple of 8 bits long.
WKS Usage: The WKS record is used to describe the well known services supported by a particular protocol on a particular internet address.
3.5. IN-ADDR.ARPA Domain
The IN-ADDR.ARPA domain is used for reverse DNS lookups - mapping IP addresses to domain names.
Structure:
- The domain is organized by IP address octets in reverse order
- Each octet forms a label in the domain name
Example:
IP Address: 93.184.216.34
IN-ADDR.ARPA name: 34.216.184.93.in-addr.arpa.
Usage:
- PTR records in the IN-ADDR.ARPA domain point to the canonical hostname
- This allows applications to map from an address to a name
Example PTR Record:
34.216.184.93.in-addr.arpa. IN PTR www.example.com.
3.6. Defining New Types, Classes, and Special Namespaces
The DNS is designed to be extensible. New RR types and classes can be defined to support new applications and services.
Guidelines:
- New types and classes should be registered with the IANA
- Implementations should be able to handle unknown types gracefully
- Unknown RR types should be preserved and passed through by name servers
- The general format of RRs allows new types to be added without breaking existing implementations
Next: 4. Messages