Design Choices When Expanding the DNS
RFC 5507

Document Type RFC - Informational (April 2009; No errata)
Last updated 2015-10-14
Stream IAB
Formats plain text pdf html bibtex
Stream IAB state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
Network Working Group                                                IAB
Request for Comments: 5507                             P. Faltstrom, Ed.
Category: Informational                                  R. Austein, Ed.
                                                            P. Koch, Ed.
                                                              April 2009

                 Design Choices When Expanding the DNS

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This note discusses how to extend the DNS with new data for a new
   application.  DNS extension discussions too often focus on reuse of
   the TXT Resource Record Type.  This document lists different
   mechanisms to extend the DNS, and concludes that the use of a new DNS
   Resource Record Type is the best solution.

IAB, et al.                  Informational                      [Page 1]
RFC 5507         Design Choices When Expanding the DNS        April 2009

Table of Contents

   1. Introduction ....................................................3
   2. Background ......................................................4
   3. Extension Mechanisms ............................................5
      3.1. Place Selectors inside the RDATA of Existing
           Resource Record Types ......................................5
      3.2. Add a Prefix to the Owner Name .............................6
      3.3. Add a Suffix to the Owner Name .............................7
      3.4. Add a New Class ............................................8
      3.5. Add a New Resource Record Type .............................8
   4. Zone Boundaries are Invisible to Applications ...................9
   5. Why Adding a New Resource Record Type Is the Preferred
      Solution .......................................................10
   6. Conclusion and Recommendation ..................................14
   7. Creating a New Resource Record Type ............................14
   8. Security Considerations ........................................15
   9. Acknowledgements ...............................................15
   10. IAB Members at the Time of This Writing .......................16
   11. References ....................................................16
      11.1. Normative References .....................................16
      11.2. Informative References ...................................16

IAB, et al.                  Informational                      [Page 2]
RFC 5507         Design Choices When Expanding the DNS        April 2009

1.  Introduction

   The DNS stores multiple categories of data.  The two most commonly
   used categories are infrastructure data for the DNS system itself (NS
   and SOA Resource Records) and data that have to do with mappings
   between domain names and IP addresses (A, AAAA, and PTR Resource
   Records).  There are other categories as well, some of which are tied
   to specific applications like email (MX Resource Records), while
   others are generic Resource Record Types used to convey information
   for multiple protocols (SRV and NAPTR Resource Records).

   When storing data in the DNS for a new application, the goal must be
   to store data in such a way that the application can query for the
   data it wants, while minimizing both the impact on existing
   applications and the amount of extra data transferred to the client.
   This implies that a number of design choices have to be made, where
   the most important is to ensure that a precise selection of what data
   to return must be made already in the query.  A query consists of a
   triple: {Owner (or name), Resource Record Class, Resource Record
   Type}.

   Historically, extending the DNS to store application data tied to a
   domain name has been done in different ways at different times.  MX
   Resource Records were created as a new Resource Record Type
   specifically designed to support electronic mail.  SRV records are a
   generic type that use a prefixing scheme in combination with a base
   domain name.  NAPTR records add selection data inside the RDATA.  It
   is clear that the methods used to add new data types to the DNS have
   been inconsistent, and the purpose of this document is to attempt to
   clarify the implications of each of these methods, both for the
   applications that use them and for the rest of the DNS.
Show full document text