[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 draft-ietf-dnsop-dns-terminology

Network Working Group                                         P. Hoffman
Internet-Draft                                            VPN Consortium
Intended status: Best Current Practice                       A. Sullivan
Expires: July 23, 2015                                               Dyn
                                                             K. Fujiwara
                                                        January 19, 2015

                            DNS Terminology


   The DNS is defined in literally dozens of different RFCs.  The
   terminology used in by implementers and developers of DNS protocols,
   and by operators of DNS systems, has sometimes changed in the decades
   since the DNS was first defined.  This document gives current
   definitions for many of the terms used in the DNS in a single

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 23, 2015.

Copyright Notice

   Copyright (c) 2015 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Hoffman, et al.           Expires July 23, 2015                 [Page 1]

Internet-Draft               DNS Terminology                January 2015

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Names . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  DNS Message Format  . . . . . . . . . . . . . . . . . . . . .   4
   4.  Response Codes  . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Resource Records  . . . . . . . . . . . . . . . . . . . . . .   5
   6.  DNS Servers . . . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   8.  General DNSSEC  . . . . . . . . . . . . . . . . . . . . . . .   9
   9.  DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . .  10
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  12
   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     13.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   The DNS is a simple query-response protocol whose messages in both
   directions have the same format.  The protocol and message format are
   defined in [RFC1034] and [RFC1035].  These RFCs defined some terms,
   but later documents defined others.  Some of the terms from RFCs 1034
   and 1035 now have somewhat different meanings than they did in 1987.

   This document collects a wide variety of DNS-related terms.  Some of
   them have been precisely defined in earlier RFCs, some have been
   loosely defined in earlier RFCs, and some are not defined in any
   earlier RFC at all.

   The definitions here are believed to be the consensus definition of
   the DNS community, both protocol developers and operators.  Some of
   the definitions differ from earlier RFCs, and those differences are
   noted.  The terms are organized loosely by topic.  Some definitions
   are for new terms for things that are commonly talked about in the
   DNS community but that never had terms defined for them.

   In this document, where the consensus definition is the same as the
   one in an RFC, that RFC is quoted.  Where the consensus definition
   has changed somewhat, the RFC is mentioned but the new stand-alone
   definition is given.

Hoffman, et al.           Expires July 23, 2015                 [Page 2]

Internet-Draft               DNS Terminology                January 2015

   Other organizations sometimes define DNS-related terms their own way.
   For example, the W3C defines "domain" at

   Note that capitalization in DNS terms is often inconsistent between
   RFCs and between DNS practitioners.  The capitalization used in this
   document is a best guess at current practices, and is not meant to
   indicate that other capitalization styles are wrong or archaic.

   (Note: the formatting of this early draft is a bit funky.  It will
   improve in later drafts.  Bikeshedding the format, as compared to the
   content, of this draft is probably premature.)

2.  Names

   Domain name -- Section 3.1 of RFC 1034 talks of "the domain name
   space" as a tree structure.  "Each node has a label, which is zero to
   63 octets in length. ... The domain name of a node is the list of the
   labels on the path from the node to the root of the tree. ... To
   simplify implementations, the total number of octets that represent a
   domain name (i.e., the sum of all label octets and label lengths) is
   limited to 255."

   Fully-qualified domain name (FQDN) -- This is often just a clear way
   of saying the same thing as "domain name of a node", as outlined
   above.  However, the term is ambiguous.  Strictly speaking, a fully-
   qualified name would include every label, including the final, zero-
   length label of the root zone: such a name would be written
   "www.example.net." (note the terminating dot).  But because every
   name eventually shares the common root, names are often written
   relative to the root (such as "www.example.net") and are still called
   "fully qualified".

   Host name -- This term and its equivalent, "hostname", have been
   widely used but are not defined in RFC 1034, 1035, 1123, or 2181.
   The DNS was originally deployed into the Host Tables environment as
   outlined in [RFC0952], and it is likely that the term followed
   informally from the definition there.  Over time, the definition
   seems to have shifted.  "Host name" is often meant to be a domain
   name that follows the rules in Section 3.5 of RFC 1034, the
   "preferred name syntax".  Note that any label in any domain name can
   contain any octet value; hostnames are generally considered to be
   domain names where every label follows the rules in the "preferred
   name syntax", with the amendment that labels can start with ASCII
   digits (this amendment comes from Section 2.1 of RFC 1123).

   People also sometimes use the term hostname to refer to just the
   first label of an FQDN.  In addition, people sometimes use this term

Hoffman, et al.           Expires July 23, 2015                 [Page 3]

Internet-Draft               DNS Terminology                January 2015

   to describe any name that refers to a machine, and those might
   include labels that do not conform to the "preferred name syntax".

3.  DNS Message Format

   Header -- The first 12 octets of a DNS message.  Many of the fields
   and flags in the header diagram in section 4.1.1 of RFC 1035 are
   referred to by their names in that diagram.  For example, the
   response codes are called "RCODEs", and the authoritative answer bit
   is often called "the AA flag" or "the AA bit".  RCODEs are covered in
   Section 4.

   TTL -- The "time to live" of a resource record.  A TTL value is an
   unsigned number, with a minimum value of 0, and a maximum value of
   2147483647.  That is, a maximum of 2^31 - 1.  When transmitted, the
   TTL is encoded in the less significant 31 bits of the 32 bit TTL
   field, with the most significant, or sign, bit set to zero.  (Quoted
   from [RFC2181], section 8) (Note that RFC 1035 erroneously stated
   that this is a signed integer; it is fixed in an erratum.)

   The TTL "specifies the time interval that the resource record may be
   cached before the source of the information should again be
   consulted".  (Quoted from RFC 1035, section 3.2.1) Also: "the time
   interval (in seconds) that the resource record may be cached before
   it should be discarded".  (Quoted from RFC 1035, section 4.1.3).
   Despite being defined for a resource record, the TTL of every
   resource record in an RRset is required to be the same (RFC2181,
   section 5.2).

   Glue records -- Resource records which are not part of the
   authoritative data, and are address resource records for the servers
   listed in the message.  They contain data that allows access to name
   servers for subzones.  (Definition from RFC 1034, section 4.2.1)

   Referrals -- Data from the authority section of a non-authoritative
   answer.  RFC 1035 section 2.1 defines "authoritative" data.  However,
   referrals at zone cuts are not authoritative.  Referrals may be a
   zone cut NS resource records and their glue.  NS records on the
   parent side of a zone cut are an authoritative delegation, but are
   not treated as authoritative data by the client.  [[ A more complete
   and precise definition will be needed here. ]]

4.  Response Codes

   Some of response codes that are defined in RFC 1035 have gotten their
   own shorthand names.  Some common response code (RCODE) names that
   appear without reference to the numeric value are "FORMERR",
   "SERVFAIL", and "NXDOMAIN".  All of the RCODEs are listed at

Hoffman, et al.           Expires July 23, 2015                 [Page 4]

Internet-Draft               DNS Terminology                January 2015

   although that site uses mixed-case capitalization, while most
   documents use all-caps.

   NODATA -- This is not an actual response code, but instead is the
   combination of an RCODE of 0 (NOERROR) and an Answer section that is
   empty.  That is, it indicates that the response is no answer, but
   that there was not supposed to be one.  Section 1 of [RFC2308]
   defines it as "a pseudo RCODE which indicates that the name is valid,
   for the given class, but are no records of the given type."

5.  Resource Records

   RR -- A short form for resource record.  (RFC 1034, section 3.6.)

   RRset -- A set of resource records with the same label, class and
   type, but with different data.  (Definition from RFC 2181) Also
   spelled RRSet in some documents.  As a clarification, "same label" in
   this definition means "same owner name".

   OPT -- A pseudo-RR (sometimes called a meta-RR) that is used only to
   contain control information pertaining to the question-and-answer
   sequence of a specific transaction. contains control information
   pertaining to the question-and-answer sequence of a specific
   transaction.  (Definition from [RFC6891], section 6.1.1)

   Owner -- The domain name where a RR is found (RFC 1034, section 3.6).
   Often appears in the term "owner name".

   SOA field names -- DNS documents, including the definitions here,
   often refer to the fields in the RDATA an SOA resource record by
   field name.  Those fields are defined in Section 3.3.13 of RFC 1035.
   The names (in the order they appear in the SOA RDATA) are MNAME,
   meaning of MINIMUM field is updated in Section 4 of RFC 2308; the new
   definition is that the MINIMUM field is only "the TTL to be used for
   negative responses".

6.  DNS Servers

   This section defines the terms used for the systems that act as DNS
   clients, DNS servers, or both.  Some terms about servers describe
   servers that do and do not use DNSSEC; see Section 8 for those

   [[ There is a request to "first describe the iterative and recursive
   resolution processes, and mention the expected values of the RD,RA,AA
   bits.  Then you can describe the distinctions between recursive and

Hoffman, et al.           Expires July 23, 2015                 [Page 5]

Internet-Draft               DNS Terminology                January 2015

   iterative clients, and between recursive and authoritative servers,
   in terms of the roles they play in the different resolution
   processes."  This would require the section to be quite different
   than the other sections in the document. ]]

   Resolver -- A program that extracts information from name servers in
   response to client requests.  (Quoted from RFC 1034, section 2.4) It
   is a program that interfaces user programs to domain name servers.
   The resolver is located on the same machine as the program that
   requests the resolver's services.  (Quoted from RFC 1034, section 
   5.1) A resolver performs queries for a name, type, and class, and
   receives answers.  The logical function is called "resolution".  In
   practice, the term is usually referring to some specific type of
   resolver (some of which are defined below), and understanding the use
   of the term depends on understanding the context.

   Stub resolver -- A resolver that cannot perform all resolution
   itself.  Stub resolvers generally depend on a recursive resolver to
   undertake the actual resolution function.  Stub resolvers are
   discussed but never fully defined in RFC 1034, section 5.3.1.

   Iterative mode -- A resolution mode of a server that receives DNS
   queries and responds with a referral to another server.  Section 2.3
   of RFC 1034 describes this as "The server refers the client to
   another server and lets the client pursue the query".

   Recursive mode -- A resolution mode of a server that receives DNS
   queries and either responds to those queries from a local cache or
   sends queries to other servers in order to get the final answers to
   the original queries.  Section 2.3 of RFC 1034 describes this as "The
   first server pursues the query for the client at another server".  A
   server operating in recursive mode may be thought of as having a name
   server side (which is what answers the query) and a resolver side
   (which performs the resolution function).  Systems operating in this
   mode are commonly called "recursive servers".  Sometimes they are
   called "recursive resolvers".  While strictly the difference between
   these is that one of them sends queries to another recursive server
   and the other does not, in practice it is not possible to know in
   advance whether the server that one is querying will also perform
   recursion; both terms can be observed in use interchangeably.

   Authoritative server -- A system that responds to DNS queries with
   information about zones for which it has been configured to answer
   with the AA flag in the response header set to 1.  It is a server
   that has authority over one or more DNS zones.  Note that it is
   possible for an authoritative server to respond to a query without
   the parent zone delegating authority to that server.

Hoffman, et al.           Expires July 23, 2015                 [Page 6]

Internet-Draft               DNS Terminology                January 2015

   Slave -- An authoritative server which uses zone transfer to retrieve
   the zone.  (Quoted from [RFC1996], section 2.1)

   Master -- Any authoritative server configured to be the source of
   zone transfer for one or more slave servers.  (Quoted from RFC 1996,
   section 2.1)

   Primary master -- The primary master is named in the zone's SOA MNAME
   field and optionally by an NS resource record.  (Quoted from RFC
   1996, section 2.1)

   Stealth server -- This is the same as a slave server except that it
   is not listed in an NS resource record for the zone.  (Quoted from
   RFC 1996, section 2.1) A stealth server is often actually a master
   for zone transfers, and in that case is called a "hidden master".

   DNS forwarder -- A system receives a DNS query, possibly changes the
   query, sends the resulting query to a recursive resolver, receives
   the response from a resolver, possibly changes the response, and
   sends the resulting response to the stub resolver.  Section 1 of RFC
   2308 describes a forwarder as "a nameserver used to resolve queries
   instead of directly using the authoritative nameserver chain".  RFC
   further says "The forwarder typically either has better access to the
   internet, or maintains a bigger cache which may be shared amongst
   many resolvers."

   [RFC5625] does not give a specific definition for DNS forwarder, but
   describes in detail what features they need to support.  The protocol
   interfaces for DNS forwarders are exactly the same as those for
   recursive resolvers (for interactions with DNS stubs) and as those
   for stub resolvers (for interactions with recursive resolvers).

   Full resolver -- This term is used in RFC 1035, but it is not defined
   there.  RFC 1123 defines a "full-service resolver" that may or may
   not be what was intended by "full resolver" in RFC 1035.  In the
   vernacular, a full-service resolver is usually one that would be
   suitable for use by a stub resolver.

   Consensual policy-implementing resolver -- A resolver that changes
   some answers it returns based on policy criteria, such as to prevent
   access to malware sites.  These policy criteria are agreed to by
   systems that query this resolver through some out of band mechanism
   (such as finding out about the resolver from a web site and reading
   the policy).

   Non-consensual policy-implementing resolver -- A resolver that is not
   a consensual policy-implementing resolver that changes the answers it
   returns.  The difference between this and a consensual policy-

Hoffman, et al.           Expires July 23, 2015                 [Page 7]

Internet-Draft               DNS Terminology                January 2015

   implementing resolver is that users of this resolver are not expected
   to know that there is a policy to change the answers it returns.

   Negative caching -- The storage of knowledge that something does not
   exist, cannot give an answer, or does not give an answer.  (Quoted
   from Section 1 of RFC 2308)

7.  Zones

   This section defines terms that are used when discussing zones that
   are being served or retrieved.

   Zone -- A unit of organization of authoritative data.  Zones can be
   automatically distributed to the name servers which provide redundant
   service for the data in a zone.  (Quoted from RFC 1034, section 2.4).

   Child -- The entity on record that has the delegation of the domain
   from the Parent.  (Quoted from [RFC7344], section 1.1)

   Parent -- The domain in which the Child is registered.  (Quoted from
   RFC 7344, section 1.1) Earlier, "parent name server" was defined in
   [RFC0882] as "the name server that has authority over the place in
   the domain name space that will hold the new domain".

   Zone cut -- The delimitation point between two zones where the origin
   of one of the zones is the child of the other zone.  (Section 6 of
   RFC 2181 uses this term extensively, although never actually defines
   it.)  Section 4.2 of RFC 1034 uses "cuts" as "zone cut".

   In-bailiwick response -- A response in which the name server
   answering is authoritative for an ancestor of the owner name in the
   response.  The term normally is used when discussing the relevancy of
   glue records.  For example, the parent zone example.com might reply
   with glue records for ns.child.example.com.  Because the
   child.example.com zone is a descendant of the example.com zone, the
   glue is in-bailiwick.

   Out-of-bailiwick response -- A response in which the name server
   answering is not authoritative for an ancestor of the owner name in
   the response.

   Origin -- 1.  The domain name within which a given relative domain
   name appears.  Generally seen in the context of "$ORIGIN", which is a
   control entry defined in RFC 1035, section 5.1, as part of the master
   file format.  For example, if the $ORIGIN is set to "example.org.",
   then a master file line for "www" is in fact an entry for
   "www.example.org.".  2.  The domain name that appears at the top of a
   zone, that is, the owner name of the apex records.

Hoffman, et al.           Expires July 23, 2015                 [Page 8]

Internet-Draft               DNS Terminology                January 2015

   Authoritative data -- RRsets in the Answer section of a DNS response
   that has the AA bit in the response header set to 1.

   Delegation -- The process by which a separate zone is created in the
   name space beneath a given domain.  Delegation happens when an NS
   RRset is added in the parent zone for the child origin, and a
   corresponding zone apex is created at the child origin.

   Apex -- The SOA and NS RRsets at the origin of a zone.  This is also
   called the "zone apex".

   Root zone -- The zone whose origin is the zero-length label.  Also
   sometimes called "the DNS root".

   Empty non-terminal -- A domain name that has no RRsets, but has
   descendants that have RRsets.  A typical example is in SRV records:
   in the name "_sip._tcp.example.com", it is likely that
   "_tcp.example.com" has no RRsets, but that "_sip._tcp.example.com"
   has (at least) an SRV RRset.

   Wildcard -- RFC 1034 defined "wildcard", but in a way that turned out
   to be confusing to implementers.  For an extended discussion of
   wildcards, including clearer definitions, see [RFC4592].

8.  General DNSSEC

   Most DNSSEC terms are defined in [RFC4033], [RFC4034], and [RFC4035].
   The terms that have caused confusion in the DNS community are
   highlighted here.

   DNSSEC-aware and DNSSEC-unaware -- Section 2 of RFC 4033 defines many
   types of resolvers and validators.  In specific, the terms "non-
   validating security-aware stub resolver", "non-validating stub
   resolver", "security-aware name server", "security-aware recursive
   name server", "security-aware resolver", "security-aware stub
   resolver", and "security-oblivious 'anything'" are all defined.

   Signed zone -- A zone whose RRsets are signed and that contains
   properly constructed DNSKEY, Resource Record Signature (RRSIG), Next
   Secure (NSEC), and (optionally) DS records.  (Quoted from RFC 4033,
   section 2) It has been noted in other contexts that the zone itself
   is not really signed, but all the relevant RRsets in the zone are
   signed.  It should also be noted that, since the publication of
   [RFC6840], NSEC records are no longer required for signed zones: a
   signed zone might include NSEC3 records instead

   NSEC -- The NSEC resource record lists two separate things: the next
   owner name (in the canonical ordering of the zone) that contains

Hoffman, et al.           Expires July 23, 2015                 [Page 9]

Internet-Draft               DNS Terminology                January 2015

   authoritative data or a delegation point NS RRset, and the set of RR
   types present at the NSEC RR's owner name.  (Quoted from Section 4 of

   NSEC3 -- The NSEC3 resource record is quite different than the NSEC
   resource record.  NSEC3 resource records are defined in [RFC5155].

   Opt-out -- The Opt-Out Flag indicates whether this NSEC3 RR may cover
   unsigned delegations.  (Quoted from Section of RFC 5155)

   DNSSEC Policy (DP) -- A statement that sets forth the security
   requirements and standards to be implemented for a DNSSEC-signed
   zone.  (Quoted from [RFC6841], section 2)

   DNSSEC Practice Statement (DPS) -- A practices disclosure document
   that may support and be a supplemental document to the DNSSEC Policy
   (if such exists), and it states how the management of a given zone
   implements procedures and controls at a high level.  (Quoted from RFC
   6841, section 2)

9.  DNSSEC States

   A validating resolver can determine that a response is in one of four
   states: secure, insecure, bogus, or indeterminate.  These states are
   defined in RFC 4033 and 4035, although the two definitions differ a

   Section 5 of RFC 4033 says:

Hoffman, et al.           Expires July 23, 2015                [Page 10]

Internet-Draft               DNS Terminology                January 2015

   A validating resolver can determine the following 4 states:

   Secure: The validating resolver has a trust anchor, has a chain of
      trust, and is able to verify all the signatures in the response.

   Insecure: The validating resolver has a trust anchor, a chain of
      trust, and, at some delegation point, signed proof of the
      non-existence of a DS record.  This indicates that subsequent
      branches in the tree are provably insecure.  A validating resolver
      may have a local policy to mark parts of the domain space as

   Bogus: The validating resolver has a trust anchor and a secure
      delegation indicating that subsidiary data is signed, but the
      response fails to validate for some reason: missing signatures,
      expired signatures, signatures with unsupported algorithms, data
      missing that the relevant NSEC RR says should be present, and so

   Indeterminate: There is no trust anchor that would indicate that a
      specific portion of the tree is secure.  This is the default
      operation mode.

   Section 4.3 of RFC 4035 says:

Hoffman, et al.           Expires July 23, 2015                [Page 11]

Internet-Draft               DNS Terminology                January 2015

   A security-aware resolver must be able to distinguish between four

   Secure: An RRset for which the resolver is able to build a chain of
      signed DNSKEY and DS RRs from a trusted security anchor to the
      RRset.  In this case, the RRset should be signed and is subject to
      signature validation, as described above.

   Insecure: An RRset for which the resolver knows that it has no chain
      of signed DNSKEY and DS RRs from any trusted starting point to the
      RRset.  This can occur when the target RRset lies in an unsigned
      zone or in a descendent of an unsigned zone.  In this case, the
      RRset may or may not be signed, but the resolver will not be able
      to verify the signature.

   Bogus: An RRset for which the resolver believes that it ought to be
      able to establish a chain of trust but for which it is unable to
      do so, either due to signatures that for some reason fail to
      validate or due to missing data that the relevant DNSSEC RRs
      indicate should be present.  This case may indicate an attack but
      may also indicate a configuration error or some form of data

   Indeterminate: An RRset for which the resolver is not able to
      determine whether the RRset should be signed, as the resolver is
      not able to obtain the necessary DNSSEC RRs.  This can occur when
      the security-aware resolver is not able to contact security-aware
      name servers for the relevant zones.

10.  IANA Considerations

   This document has no effect on IANA registries.

11.  Security Considerations

   These definitions do not change any security considerations for the

12.  Acknowledgements

   The authors gratefully acknowledge all of the authors of DNS-related
   RFCs that proceed this one.  Comments from Tony Finch, Stephane
   Bortzmeyer, and others have helped shape this document.  [[ More acks
   will go here as people point out new terms to add and changes to the
   ones we have listed here. ]]

Hoffman, et al.           Expires July 23, 2015                [Page 12]

Internet-Draft               DNS Terminology                January 2015

13.  References

13.1.  Normative References

   [RFC0882]  Mockapetris, P., "Domain names: Concepts and facilities",
              RFC 882, November 1983.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
              Changes (DNS NOTIFY)", RFC 1996, August 1996.

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, July 1997.

   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
              NCACHE)", RFC 2308, March 1998.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements", RFC
              4033, March 2005.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

   [RFC4592]  Lewis, E., "The Role of Wildcards in the Domain Name
              System", RFC 4592, July 2006.

   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
              Security (DNSSEC) Hashed Authenticated Denial of
              Existence", RFC 5155, March 2008.

   [RFC6840]  Weiler, S. and D. Blacka, "Clarifications and
              Implementation Notes for DNS Security (DNSSEC)", RFC 6840,
              February 2013.

   [RFC6841]  Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A
              Framework for DNSSEC Policies and DNSSEC Practice
              Statements", RFC 6841, January 2013.

Hoffman, et al.           Expires July 23, 2015                [Page 13]

Internet-Draft               DNS Terminology                January 2015

   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
              for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.

   [RFC7344]  Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
              DNSSEC Delegation Trust Maintenance", RFC 7344, September

13.2.  Informative References

   [RFC0952]  Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
              host table specification", RFC 952, October 1985.

   [RFC5625]  Bellis, R., "DNS Proxy Implementation Guidelines", BCP
              152, RFC 5625, August 2009.

Authors' Addresses

   Paul Hoffman
   VPN Consortium
   127 Segre Place
   Santa Cruz, CA  95060

   Email: paul.hoffman@vpnc.org

   Andrew Sullivan
   150 Dow St, Tower 2
   Manchester, NH  1604

   Email: asullivan@dyn.com

   Kazunori Fujiwara
   Japan Registry Services Co., Ltd.
   Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
   Chiyoda-ku, Tokyo  101-0065

   Phone: +81 3 5215 8451
   Email: fujiwara@jprs.co.jp

Hoffman, et al.           Expires July 23, 2015                [Page 14]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/