BIND 9 Support
Chapter 8. DNS Resource Records (RRs)
DNS resource records (RRs) describe the characteristics of a zone (or domain) and have a binary or wire-format, which is used in queries and responses, and a text format used in zone files and which is described in this chapter.
Contents
- Zone File Format
- Zone File Directives ($ORIGIN, $TTL, $GENERATE)
- DNS Generic Record Formats
- Resource Record (RR) Types
Zone File Format
A DNS zone file is constructed using Resource Records (RRs) and Directives. The text representation of these records are stored in zone files.
Zone file example
; zone file for example.com
$TTL 2d ; 172800 secs default TTL for zone
$ORIGIN example.com.
@ IN SOA ns1.example.com. hostmaster.example.com. (
2003080800 ; se = serial number
12h ; ref = refresh
15m ; ret = update retry
3w ; ex = expiry
3h ; min = minimum
)
IN NS ns1.example.com.
IN MX 10 mail.example.net.
joe IN A 192.168.254.3
www IN CNAME joe
The above example shows a very simple but fairly normal zone file. The following notes apply to zone files:
- Zone files consist of Comments, Directives and Resource Records
- Comments start with ';' (semicolon) and are assumed to continue to the end of the line. Comments can occupy a whole line or part of a line as shown in the above example.
- Directives start with '$' and are standardized - $ORIGIN and $INCLUDE (defined in RFC 1035) and $TTL (defined in RFC 2308). BIND additionally provides the non-standard $GENERATE directive.
- There are a number of Resource Record (RR) types defined in RFC 1035 and augmented by subsequent RFCs.
- The $TTL directive should be present and appear before the first RR (RFC 2308 implemented in BIND 9).
- The first Resource Record must be the SOA (Start of Authority) record. The generic format is described below.
up icon
DNS Generic Record Format
Resource Records have two representations. A textual format described in this chapter and a binary or wire-format described in Chapter 15.
The textual format has the following generic form:
owner-name ttl class type type-specific-data
Where:
owner-name
The owner-name (or label) of the node in the zone file to which this record belongs. Sometimes referred to as the left-hand name to differentiate it from any name that may appear in the type-specific-data (such as for NS or MX RRs) which is sometimes, surprisingly, called the right-hand name or the target-name. The owner-name field may also take one of the following values:
@
; replace with the current value of $ORIGIN
; blank/space or tab in which case the last
; owner-name used or the value of $ORIGIN
; (or its default value) is substituted
ttl
32 bit value. The Time to Live in seconds (range is 1 to 2147483647) and indicates how long the RR may be cached. The value zero indicates the data should not be cached.
class
A 16 bit value which defines the protocol family or an instance of the protocol. The normal value is IN = Internet protocol (other values are HS and CH both historic MIT protocols).
types
The resource record type which determines the value(s) of
the
type-specific-data field. Type takes one of the values below.
type-specific-data
Data content of each record is defined by the type and class values.
The generic binary or wire-format is:
name ttl class type rdlen rdata
The binary format is described in chapter 15 RR format
up icon
DNS Resource Record (RR) Types
This is an incomplete list but does consist of the main RR types used in forward and reverse map zone together with links to other RR types that are useful, fun, complex or have interesting names. A full list of DNS Resource Record (RR) types may be obtained from IANA DNS Parameters.
RR
Value
RFC
Description
A
1
RFC 1035
IPv4 Address record. An IPv4 address for a host.
AAAA
28
RFC 3596
IPv6 Address record. An IPv6 address for a host. Current IETF recommendation for IPv6 forward-mapped zones.
A6
38
RFC 6563
Obsolete. AAAA is the recommended IPv6 address record. Historical status.
AFSDB
18
RFC 1183
Location of AFS servers. Experimental - special apps only.
CNAME
5
RFC 1035
Canonical Name. An alias name for a host. Causes redirection for a single RR at the owner-name.
DNAME
39
RFC 6672
Redirection in DNS. Like CNAME but affects all RRs below the address space of owner-name.
EUI48
108
RFC 7043
Method of storing EUI (Extended Unique Identifier) 48-bit addresses in the DNS. EUI-48 addresses are used by IEEE defined networks such as Ethernet, Bluetooth and many others. Due to security concerns (discovery of local configuration details that may be used to mount DDoS attacks) it is recommended that EUI48 address are stored only in private namespace DNS. Supported from BIND 9.10+.
EUI64
109
RFC 7043
Method of storing EUI (Extended Unique Identifier) 64-bit addresses in the DNS. EUI-64 addresses are used by IEEE defined networks such as Firewire, 802.15 (WPAN) and others. It is also used by IPv6 as the low order 64 bits of the address in stateless configurations. Due to security concerns (discovery of local configuration details that may be used to mount DDoS attacks) it is recommended that EUI64 address are stored only in private namespace DNS. Supported from BIND 9.10+.
HINFO
13
RFC 1035
Host Information - optional text data about a host.
ISDN
20
RFC 1183
ISDN address. Experimental = special applications only.
LOC
29
RFC 1876
Stores GPS data. Experimental - security considerations have mitigated usage.
MX
15
RFC 1035
Mail Exchanger. A preference value and the host name for a mail server/exchanger that will service this zone. RFC 974 defines valid names.
NAPTR
35
RFC 3403
Naming Authority Pointer Record. Gross misnomer. General purpose definition of rule set to be used by applications for Dynamic Delegation Discovery System (DDDS), for example, VoIP or ENUM. Complex but interesting RR.
NS
2
RFC 1035
Name Server. Defines the authoritative name server(s) for the domain (defined by the SOA record) or the subdomain.
NSEC
47
RFC 4034
DNSSEC. Next Secure record. Ssed to provide proof of non-existence of a name.
NXT
30
DNSSEC Next Domain record type. Obsolete use NSEC.
RP
17
RFC 1183
Information about responsible person. Experimental - special apps only.
RT
21
RFC 1183
Through-route binding. Experimental - special apps only.
SIG
24
RFC 2535
DNSSEC. Obsolete use RRSIG. SIG(0) is synthesised as a special meta RR in DDNS and zone transfer security.
SOA
6
RFC 1035
Start of Authority. Defines the zone name, an e-mail
contact and various time and refresh values applicable to the zone.
SPF
99
RFC 4408
The Sender Policy Framework (v1).
RFC 7208 deprecated the use of the SPF RR. The
TXT RR is now the only method used to define an
SPF configuration.
SRV
33
RFC 2872
Defines services available in the zone, for example, ldap, http, sip etc.. Allows for discovery of domain servers providing specific services.
URI
256
RFC 7553
An alternative to the SRV record whereby the full URI string is returned for the required service. Unlike the
SRV RR where the final URI string must be assembled from a mixture of search and result strings.
WKS
11
RFC 1035
Well Known Services. Deprecated in favour of
SRV.
X25
19
RFC 1183
X.25 address. Experimental - special apps only.
Value is the decimal value of the RR type in binary or wire-format.
DNS Zone File Directives
Directives start with '$' and are standardized - $ORIGIN and $INCLUDE (defined in RFC 1035) and $TTL (defined in RFC 2308). BIND additionally provides the non-standard $GENERATE directive.
Directive
Description
$INCLUDE
Includes the defined file in-line.
$ORIGIN
Defines the base name (aka label) to be used for 'unqualified' name substitution.
$TTL
Defines the default Resource Record TTL value, used if no TTL is defined in a resource record.
up icon
Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or . You will have a warm inner glow for the rest of the day.