RRs in Current Use

A (Address)

Defined in RFC 1035, section 3.4.1:

 domainname     A 32-bit-ip-address 

This defines the IP version 4 Internet address of the domain name. The IP address is written in the usual dotted quad format for example, 192.168.55.2.

AAAA (IPv6 Address)

Defined in RFC 1886:

 domainname     A 128-bit-IPv6-address 

IP version 6 uses 128-bit addresses, which is a lot more bits than in the version of IP currently in use, version 4. With IPv6, reverse lookups are performed in the ip6.int domain instead of in-addr.arpa. In addition, a dot exists between each nibble instead of between each octet, and the nibbles are in reverse order of course.

ATMA (ATM Address)

This record is not defined in any RFC and is not implemented in BIND. It is defined in "ATM Name System Specification Version 1.0." It is, however, present in the Windows 2000 DNS server implementation.

CNAME (Canonical Name of an Alias)

Defined in RFC 1035, section 3.3.1:

 domainname     CNAME canonical-name 

The given domain name is an alias for the given canonical name. The domain name can't have any other records associated with it. Earlier, this restriction was not enforced by BIND, so a backward-compatibility setting exists in named.conf:

 options {         …         multiple-cnames yes-or-no;         … } 

Additionally MX, NS, and SOA records can't refer to CNAMEs. If they do, the results are "undefined." It might work, it might not work, or it might work for some of the people some of the time. I would not try my luck with it, though.

HINFO (Host Information)

Defined in RFC 1035, section 3.3.2:

 domainname     HINFO   cpu    os 

Some people consider host information obsolete, or at least redundant. Both the CPU and OS field must be one word, or quoted. A dated list (anno 1994) of standard CPU names (machine names) and OS names (system names) can be found in RFC 1700. Of course, it may well be considered a security risk to give away this information.

MX (Mail Exchanger)

Defined in RFC 1035, section 3.3.9. Introduced in RFC 973 and defined in RFC 974:

 domainname     MX preference# mail-server 

This RR indicates that the given mail server is supposed to handle the mail destined to the given domain name. If multiple MX records with different preference levels exist, the mail transfer agent (MTA) tries to deliver to the mail server given the lowest preference value. If it fails, each mail server sorted by preference is tried. In my experience, seldom does any problem occur with MX records; they usually are quite simple. If you do have a mail problem, the problem usually lies in the MTA or its operator, both of which are complex.

The MX record obsoleted the MD and MF records.

NS (Authoritative Nameserver)

Defined in RFC 1035, section 3.3.11:

 domainname     NS nameserver 

Specifies the nameserver for the given domain. The nameserver should resolve directly to an address record, not a CNAME.

NSAP

Defined in RFC 1706:

 domainname     NSAP nsap-address# 

This record was introduced to support the deployment of CLNP, a OSI connectionless protocol on the Internet. A NSAP is the address of an OSI protocol/transport/connection endpoint. In RFC 1183, an additional record, NSAP_PTR, was defined to accommodate reverse lookups. But in RFC 1706 straight PTR records are used for this. Don't worry if you don't know what OSI is. OSI is on the way out.

PTR (Pointer to Other Name)

Defined in RFC 1035, section 3.3.12:

 domainname     PTR     name 

Although this is usually used for reverse lookup zones, it is really meant as an alias mechanism. It's not useful for much else than reverse zones, though. CNAMEs should be used in forward zones. The given domain name, probably in the in-addr.arpa domain, encodes an IP address, or in the classless-delegation case, something a bit more complex than that. The PTR record provides the name belonging to the address. One of the differences between a PTR and CNAME record is that if the nameserver queried knows the address of the host to which the CNAME record points, it will be returned as well, in the additional section of the query (see dig output several places in this book). This will not, normally, happen for a PTR record.

PX (X.400 Mapping)

Defined in RFC 2163:

 domainname     PX type  X400-address 

The domain name is an X.400 address in domain format. The X.400 address returned is the equivalent in X.400 format. This is (meant to be) used for mail routing between Internet and X.400 email. X.400 is the OSI email standard.

RP (Responsible Person)

Defined in RFC 1183, section 2.2:

 domainname     RP mbox txt-domainname 

For the resource named by the domain name, the responsible person can be reached by mail at the given mailbox. The mailbox address is in the same format as the contact field of the SOA record: address.host.domain, with a (period) instead of the @ (at sign). txt-domainname names a TXT record with further information about the person, such as full name, telephone number, and so forth. If no TXT record is defined, specify . (the root domain name).

This record is a good idea, but not very widely used. Of course, publishing email addresses in DNS might not be a good idea in these days of spam.

RT (Route Through)

Defined in RFC 1183, section 3.3:

 domainname     RT preference# host 

The specified host will act as an intermediate (router) in reaching the named host. The preference field works as in the MX record. See the X25 record for more information. This is not in wide use.

SOA (Start Of Authority)

Defined in RFC 1035, section 3.3.13:

 domainname     SOA origin-host contact (                 serial#                 refresh#                 retry#                 expire#                 minimum#) 

The SOA record is discussed in Chapter 3, "Maintenance and Enhancements." origin-host does not have to be a CNAME.

SRV (Service Locator)

Defined in RFC 2052:

 domainname     SRV priority# weight# port# host 

The SRV record is a very powerful service location facility that went from a good idea to being implemented and used with Windows 2000. Windows 2000 uses SRV records extensively for its active directory service. It could, and should, be used for many other things, too. It is powerful enough to replace the MX and KX records, for example. However, this is not planned.

Using this record, a Web client looking for a server from which to retrieve http://www.penguin.bv/ would look up the SRV record of http.tcp.www.penguin.bv. Likewise for http://penguin.bv/, it would look up the SRV record of http.tcp.penguin.bv.http is the service or protocol name, and tcp is the transport protocol wanted. The rest is the domain name with which the service is associated, the host part of the URL. For mail service in the penguin.bv domain, you would construct a smtp.tcp.penguin.bv SRV record to define the mail server. Note that as of this writing (spring 2000), no HTTP clients or MTAs use the SRV record to find servers, nor is this use planned.

The priority field works as with the MX record, giving rankings to the servers in which the lowest values are the preferred servers. The weight field is used for a weighted random selection of which server to use. The client is required to select a random SRV record among those returned. This provides a rudimentary load distribution mechanism, but with more control than the current A records in the round robin mechanism BIND offers. The weight can be used to indicate the relative power of each server, giving each server the load it can handle. Statistically, the port field is interesting because it provides the port number on the server host to contact. This port number has usually been specified in RFCs and /etc/services.

When we switch to SRV records, the port numbers used for various services will (or can) become more of a local policy matter than a centralized matter for IANA to decide. Therefore, the used port numbers can be published in DNS instead of in the assigned numbers RFC (STD 2, RFC 1700). I doubt that we will stop using assigned numbers for protocols in a firewall context, we're dependent on those numbers to be fixed to provide holes or other mechanisms that let traffic through the firewall.

The host must be a hostname, not an IP number. However, the left side of the record is not strictly a domain name; it's a label. Because it's a label, the restrictions on characters used do not really apply to it. However, things are much less chaotic when these labels follow the restrictions for domain names.

TXT (Text Information)

Defined in RFC 1035, section 3.3.14:

 domainname     TXT "text" 

This record carries free format text information. No syntax or structure is imposed, and the record can be used for anything you desire. Don't expect to use it as a general database storage mechanism, though. BIND will restrict you to about 2K of data, although DNS implementations exist that don't have this restriction. Also DNS over UDP is restricted to replies of 512 bytes. If the reply string is truncated because of this restriction, a new query (and answer) must be sent using a TCP connection.

If you want a distributed database, try using LDAP or some other directory service. Or, if you must use DNS, use the SINK record (it might finally get us the kitchen sink, which DNS has been without for so long), which is defined for such purposes. However, it is unimplemented at this time.

X25 (X25 Routing Information)

Defined in RFC 1183, section 3.1:

 domainname     X25     PSDN-address# 

This record is for routing IP over X25 or X25 over IP (XOI). Cisco supports its use for the latter. It was introduced, together with the ISDN and RT records, in RFC 1183 under the heading "Route Binding." It is apparently meant to be used for IP over X25 over ISDN. The ISDN, RT, and X25 records show which circuits the packets should be routed over. (I'm not well versed in X.25 and should not comment further.)