draft-ietf-dnsop-dns-terminology-00.txt   draft-ietf-dnsop-dns-terminology-01.txt 
Network Working Group P. Hoffman Network Working Group P. Hoffman
Internet-Draft VPN Consortium Internet-Draft VPN Consortium
Intended status: Best Current Practice A. Sullivan Intended status: Best Current Practice A. Sullivan
Expires: October 16, 2015 Dyn Expires: October 31, 2015 Dyn
K. Fujiwara K. Fujiwara
JPRS JPRS
April 14, 2015 April 29, 2015
DNS Terminology DNS Terminology
draft-ietf-dnsop-dns-terminology-00 draft-ietf-dnsop-dns-terminology-01
Abstract Abstract
The DNS is defined in literally dozens of different RFCs. The The DNS is defined in literally dozens of different RFCs. The
terminology used in by implementers and developers of DNS protocols, terminology used in by implementers and developers of DNS protocols,
and by operators of DNS systems, has sometimes changed in the decades and by operators of DNS systems, has sometimes changed in the decades
since the DNS was first defined. This document gives current since the DNS was first defined. This document gives current
definitions for many of the terms used in the DNS in a single definitions for many of the terms used in the DNS in a single
document. document.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 16, 2015. This Internet-Draft will expire on October 31, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 34 skipping to change at page 4, line 34
recent years, there have been allocations of TLDs that conform to recent years, there have been allocations of TLDs that conform to
IDNA2008 ([RFC5890], [RFC5891], [RFC5892], [RFC5893], and [RFC5894]); IDNA2008 ([RFC5890], [RFC5891], [RFC5892], [RFC5893], and [RFC5894]);
these are still treated as ccTLDs for policy purposes. these are still treated as ccTLDs for policy purposes.
gTLD -- A "generic" TLD is a TLD that is not a ccTLD, and is not one gTLD -- A "generic" TLD is a TLD that is not a ccTLD, and is not one
of the small number of historical TLDs such as .int and .arpa. There of the small number of historical TLDs such as .int and .arpa. There
is no precise definition for which TLDs that are not ccTLDs are is no precise definition for which TLDs that are not ccTLDs are
gTLDs. gTLDs.
Public suffix -- A domain under which subdomains can be registered, Public suffix -- A domain under which subdomains can be registered,
and on which HTTP cookies ([RFC6265]) should not be set. For and on which HTTP cookies ([RFC6265]) should not be set. There is no
example, at the time this document is published, .com.au is indication in a domaine name whether or not it is a public suffix;
that can only be determined by outside means. The IETF DBOUND
Working Group [DBOUND] deals with issues with public suffixes.
For example, at the time this document is published, .com.au is
considered a public suffix, but .au is not. Note that this term is considered a public suffix, but .au is not. Note that this term is
controversial in the DNS community for many reasons, and may be controversial in the DNS community for many reasons, and may be
significantly changed in the future. One example of the difficulty significantly changed in the future. One example of the difficulty
of calling a domain a public suffix is that designation can change of calling a domain a public suffix is that designation can change
over time as the registration policy for the zone changes, such as over time as the registration policy for the zone changes, such as
the case of the .uk zone around the time this document is published. the case of the .uk zone around the time this document is published.
3. DNS Header and Response Codes 3. DNS Header and Response Codes
The header of a DNS message is first 12 octets. Many of the fields The header of a DNS message is first 12 octets. Many of the fields
skipping to change at page 8, line 13 skipping to change at page 8, line 13
operating in this mode are commonly called "recursive servers". operating in this mode are commonly called "recursive servers".
Sometimes they are called "recursive resolvers". While strictly the Sometimes they are called "recursive resolvers". While strictly the
difference between these is that one of them sends queries to another difference between these is that one of them sends queries to another
recursive server and the other does not, in practice it is not recursive server and the other does not, in practice it is not
possible to know in advance whether the server that one is querying possible to know in advance whether the server that one is querying
will also perform recursion; both terms can be observed in use will also perform recursion; both terms can be observed in use
interchangeably. Resolvers acting in recursive mode are also interchangeably. Resolvers acting in recursive mode are also
sometimes called "caching servers". sometimes called "caching servers".
Full resolver -- This term is used in [RFC1035], 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 [RFC1035].
Full-service resolver -- Section 6.1.3.1 of [RFC1123] defines this Full-service resolver -- Section 6.1.3.1 of [RFC1123] defines this
term to mean a resolver that acts in recursive mode with a cache, as term to mean a resolver that acts in recursive mode with a cache, as
well as other requirements. well as other requirements.
Priming -- The mechanism used by a resolver to determine where to Priming -- The mechanism used by a resolver to determine where to
send queries before there is anything in the resolver's cache. send queries before there is anything in the resolver's cache.
Priming is most often done from a configuration setting that contains Priming is most often done from a configuration setting that contains
a list of authoritative servers for the DNS root zone. a list of authoritative servers for the DNS root zone.
Negative caching -- The storage of knowledge that something does not Negative caching -- The storage of knowledge that something does not
skipping to change at page 8, line 34 skipping to change at page 8, line 38
from Section 1 of [RFC2308]) from Section 1 of [RFC2308])
Authoritative server -- A system that responds to DNS queries with Authoritative server -- A system that responds to DNS queries with
information about zones for which it has been configured to answer 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 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 that has authority over one or more DNS zones. Note that it is
possible for an authoritative server to respond to a query without possible for an authoritative server to respond to a query without
the parent zone delegating authority to that server. Authoritative the parent zone delegating authority to that server. Authoritative
servers also provide "referrals", usually to child zones delegated servers also provide "referrals", usually to child zones delegated
from them; these referrals have the AA bit set to 0 and come with from them; these referrals have the AA bit set to 0 and come with
referral data in the Additional section. referral data in the Authority and (if needed) the Additional
sections.
Primary servers and secondary servers -- These are synonyms for Secondary server -- "An authoritative server which uses zone transfer
"master server" and "slave server", which were the terms used in the to retrieve the zone" (quoted from [RFC1996], section 2.1).
early DNS RFCs, and defined below. The current common usage has [RFC2182] describes secondary servers in detail. Although early DNS
shifted to "primary" and "secondary". RFCs such as [RFC1996] referred to this as a "slave", the current
common usage has shifted to calling it a "secondary".
Slave server -- An authoritative server which uses zone transfer to Slave server -- See secondary server.
retrieve the zone. (Quoted from [RFC1996], section 2.1) [RFC2182]
describes slave servers in detail.
Master -- Any authoritative server configured to be the source of Primary server -- "Any authoritative server configured to be the
zone transfer for one or more slave servers. (Quoted from [RFC1996], source of zone transfer for one or more [secondary] servers" (quoted
section 2.1) [RFC2136] defines "master" as "an authoritative server from [RFC1996], section 2.1) or, more specifically, "an authoritative
configured to be the source of AXFR or IXFR data for one or more server configured to be the source of AXFR or IXFR data for one or
slave servers". more [secondary] servers" (quoted from [RFC2136]). Although early
DNS RFCs such as [RFC1996] referred to this as a "master", the
current common usage has shifted to "primary".
Master server -- See primary server.
Primary master -- The primary master is named in the zone's SOA MNAME Primary master -- The primary master is named in the zone's SOA MNAME
field and optionally by an NS resource record. (Quoted from field and optionally by an NS resource record. (Quoted from
[RFC1996], section 2.1) [RFC2136] defines "primary master" as "Master [RFC1996], section 2.1) [RFC2136] defines "primary master" as "Master
server at the root of the AXFR/IXFR dependency graph. The primary server at the root of the AXFR/IXFR dependency graph. The primary
master is named in the zone's SOA MNAME field and optionally by an NS master is named in the zone's SOA MNAME field and optionally by an NS
RR. There is by definition only one primary master server per zone." RR. There is by definition only one primary master server per zone."
Stealth server -- This is the same as a slave server except that it 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 is not listed in an NS resource record for the zone. (Quoted from
[RFC1996], section 2.1) A stealth server is often actually a master [RFC1996], section 2.1) A stealth server is often actually a master
for zone transfers, and in that case is called a "hidden master". for zone transfers, and in that case is called a "hidden master".
skipping to change at page 9, line 23 skipping to change at page 9, line 30
for zone transfers, and in that case is called a "hidden master". for zone transfers, and in that case is called a "hidden master".
Zone transfer -- The act of a client requesting a copy of a zone and Zone transfer -- The act of a client requesting a copy of a zone and
an authoritative server sending the needed information. There are an authoritative server sending the needed information. There are
two common standard ways to do zone transfers: the AXFR two common standard ways to do zone transfers: the AXFR
("Authoritative Transfer") mechanism to copy the full zone, and the ("Authoritative Transfer") mechanism to copy the full zone, and the
IXFR ("Incremental Transfer") mechanism to copy only parts of the IXFR ("Incremental Transfer") mechanism to copy only parts of the
zone that have changed. Many systems use non-standard methods for zone that have changed. Many systems use non-standard methods for
zone transfer outside the DNS protocol. zone transfer outside the DNS protocol.
Forwarder -- A system that receives a DNS query, possibly changes the Forwarding -- The process of one server sending a DNS query with the
query, sends on the resulting query (usually to a recursive RD bit set to 1 to another server to resolve that query. Forwarding
resolver), receives the response, possibly changes the response, and is a function of a DNS resolver; it is different than simply blindly
sends the resulting response to the source of the query (usually a relaying queries.
stub resolver). Section 1 of [RFC2308] describes a forwarder as "a
[RFC5625] does not give a specific definition for forwarding, but
describes in detail what features a system that forwards need to
support. Systems that forward are sometimes called "DNS proxies",
but that term has not yet been defined (even in [RFC5625]).
Forwarder -- Section 1 of [RFC2308] describes a forwarder as "a
nameserver used to resolve queries instead of directly using the nameserver used to resolve queries instead of directly using the
authoritative nameserver chain". [RFC2308] further says "The authoritative nameserver chain". [RFC2308] further says "The
forwarder typically either has better access to the internet, or forwarder typically either has better access to the internet, or
maintains a bigger cache which may be shared amongst many resolvers." maintains a bigger cache which may be shared amongst many resolvers."
That definition appears to suggest that forwarders normally only
query authoritative servers. In current use, however, forwarders
often stand between stub resolvers and recursive servers. [RFC2308]
is silent on whether a forwarder is iterative-only or can be a full
resolver.
[RFC5625] does not give a specific definition for DNS forwarder, but Policy-implementing resolver -- A resolver acting in recursive mode
describes in detail what features they need to support. The protocol that changes some of the answers that it returns based on policy
interfaces for DNS forwarders are exactly the same as those for criteria, such as to prevent access to malware sites or objectionable
recursive resolvers (for interactions with DNS stubs) and as those content. In general, a stub resolver has no idea whether or not
for stub resolvers (for interactions with recursive resolvers). upstream resolvers implement such policy or, if they do, the exact
Forwarders are also sometimes called "DNS forwarders". They are policy about what changes will be made. In some cases, the user of
sometimes also called "DNS proxies", but that term has not yet been the stub resolver has selected the policy-implementing resolver with
defined (even in [RFC5625]). the explicit intention of using it to implement the policies. In
other cases, policies are imposed without the user of the stub
Full resolver -- This term is used in [RFC1035], but it is not resolver being informed.
defined there. RFC 1123 defines a "full-service resolver" that may
or may not be what was intended by "full resolver" in [RFC1035]. 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-
implementing resolver is that users of this resolver are not expected
to know that there is a policy to change the answers it returns.
Open resolver -- A full resolver that accepts and processes queries Open resolver -- A full resolver that accepts and processes queries
from any (or nearly any) stub resolver. This is sometimes also from any (or nearly any) stub resolver. This is sometimes also
called a "public resolver". called a "public resolver".
Open forwarder -- A DNS forwarder that accepts and forwards queries
from any (or nearly any) stub resolver to a full resolver.
View -- A configuration for a DNS server that allows it to provide View -- A configuration for a DNS server that allows it to provide
different answers depending on attributes of the query. Typically, different answers depending on attributes of the query. Typically,
views differ by the source IP address of a query, but can also be views differ by the source IP address of a query, but can also be
based on the destination IP address, the type of query (such as based on the destination IP address, the type of query (such as
AXFR), and so on. Views are often used to provide more names or AXFR), and so on. Views are often used to provide more names or
different addresses to queries from "inside" a protected network than different addresses to queries from "inside" a protected network than
to those "outside" that network. Views are not a standardized part to those "outside" that network. Views are not a standardized part
of the DNS, but they are widely implemented in server software. of the DNS, but they are widely implemented in server software.
Passive DNS -- A mechanism to collect large amounts of DNS data by Passive DNS -- A mechanism to collect large amounts of DNS data by
storing queries and responses from recursive servers. Passive DNS storing DNS responses from servers. Some of these systems also
databases can be used to answer historical questions about DNS zones collect the DNS queries associated with the responses; this can raise
such as which records were available for them at what times in the privacy issues. Passive DNS databases can be used to answer
past. Passive DNS databases allow searching of the stored records on historical questions about DNS zones such as which records were
keys other than just the name, such as "find all names which have A available for them at what times in the past. Passive DNS databases
records of a particular value". allow searching of the stored records on keys other than just the
name, such as "find all names which have A records of a particular
value".
Child-centric resolver -- A DNS resolver that, instead of serving the Child-centric resolver -- A DNS resolver that, instead of serving the
NS RRset and glue records that it obtained from the parent of a zone, NS RRset and glue records that it obtained from the parent of a zone,
serves data from the authoritative servers for that zone. The term serves data from the authoritative servers for that zone. The term
"child-centric" is meant as the opposite of "parent-centric", which "child-centric" is meant as the opposite of "parent-centric", which
means a resolver that simply serves the NS RRset and glue records for means a resolver that simply serves the NS RRset and glue records for
a zone that it obtained from the zone's parent, without checking the a zone that it obtained from the zone's parent, without checking the
authoritative servers for that zone. authoritative servers for that zone.
6. Zones 6. Zones
skipping to change at page 12, line 33 skipping to change at page 12, line 35
In-bailiwick - 1. An adjective to describe a name server the name of In-bailiwick - 1. An adjective to describe a name server the name of
which is either subordinate to or (rarely) the same as the zone which is either subordinate to or (rarely) the same as the zone
origin. In-bailiwick name servers require glue in their parent zone. origin. In-bailiwick name servers require glue in their parent zone.
2. Data for which the server is either authoritative, or else 2. Data for which the server is either authoritative, or else
authoritative for an ancestor of the owner name. This sense of the authoritative for an ancestor of the owner name. This sense of the
term normally is used when discussing the relevancy of glue records term normally is used when discussing the relevancy of glue records
in a response. For example, the server for the parent zone in a response. For example, the server for the parent zone
example.com might reply with glue records for ns.child.example.com. 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 Because the child.example.com zone is a descendant of the example.com
zone, both glue records are in-bailiwick. zone, the glue records are in-bailiwick.
Out-of-bailiwick - The antonym of in-bailiwick. Out-of-bailiwick - The antonym of in-bailiwick.
Authoritative data -- All of the RRs attached to all of the nodes Authoritative data -- All of the RRs attached to all of the nodes
from the top node of the zone down to leaf nodes or nodes above cuts from the top node of the zone down to leaf nodes or nodes above cuts
around the bottom edge of the zone. (Quoted from Section 4.2.1 of around the bottom edge of the zone. (Quoted from Section 4.2.1 of
[RFC1034]) It is noted that this definition might inadvertently also [RFC1034]) It is noted that this definition might inadvertently also
include any NS records that appear in the zone, even those that might include any NS records that appear in the zone, even those that might
not truly be authoritative because there are identical NS RRs below not truly be authoritative because there are identical NS RRs below
the zone cut. This reveals the ambiguity in the notion of the zone cut. This reveals the ambiguity in the notion of
skipping to change at page 17, line 49 skipping to change at page 17, line 49
These definitions do not change any security considerations for the These definitions do not change any security considerations for the
DNS. DNS.
12. Acknowledgements 12. Acknowledgements
The authors gratefully acknowledge all of the authors of DNS-related The authors gratefully acknowledge all of the authors of DNS-related
RFCs that proceed this one. Comments from Tony Finch, Stephane RFCs that proceed this one. Comments from Tony Finch, Stephane
Bortzmeyer, Niall O'Reilly, Colm MacCarthaigh, Ray Bellis, John Bortzmeyer, Niall O'Reilly, Colm MacCarthaigh, Ray Bellis, John
Kristoff, Robert Edmonds, Paul Wouters, Shumon Huque, Paul Ebersman, Kristoff, Robert Edmonds, Paul Wouters, Shumon Huque, Paul Ebersman,
David Lawrence, Matthijs Mekking, Casey Deccio, and many others in David Lawrence, Matthijs Mekking, Casey Deccio, Bob Harold, and many
the DNSOP Working Group have helped shape this document. others in the DNSOP Working Group have helped shape this document.
13. References 13. References
13.1. Normative References 13.1. Normative References
[ISO3166] International Organization for Standardization (ISO), [ISO3166] International Organization for Standardization (ISO),
"Country Codes - ISO 3166", February 2015, "Country Codes - ISO 3166", February 2015,
<http://www.iso.org/iso/country_codes/country_codes>. <http://www.iso.org/iso/country_codes/country_codes>.
[RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities",
skipping to change at page 19, line 43 skipping to change at page 19, line 43
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
DNSSEC Delegation Trust Maintenance", RFC 7344, September DNSSEC Delegation Trust Maintenance", RFC 7344, September
2014. 2014.
13.2. Informative References 13.2. Informative References
[DBOUND] "DBOUND Working Group", 2015,
<https://datatracker.ietf.org/wg/dbound/charter/>.
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
host table specification", RFC 952, October 1985. host table specification", RFC 952, October 1985.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP
152, RFC 5625, August 2009. 152, RFC 5625, August 2009.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010. RFC 5890, August 2010.
 End of changes. 19 change blocks. 
64 lines changed or deleted 71 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/