6.  DNS Servers and Clients

   This section defines the terms used for the systems that act as DNS
   clients, DNS servers, or both.  In past RFCs, DNS servers are
   sometimes called "name servers", "nameservers", or just "servers".
   There is no formal definition of "DNS server", but RFCs generally
   assume that it is an Internet server that listens for queries and
   sends responses using the DNS protocol defined in [RFC1035] and its
   successors.

   It is important to note that the terms "DNS server" and "name server"
   require context in order to understand the services being provided.
   Both authoritative servers and recursive resolvers are often called
   "DNS servers" and "name servers" even though they serve different
   roles (but may be part of the same software package).

   For terminology specific to the public DNS root server system, see
   [RSSAC026].  That document defines terms such as "root server", "root
   server operator", and terms that are specific to the way that the
   root zone of the public DNS is served.

   Resolver:  A program "that extract[s] information from name servers
      in response to client requests."  (Quoted from [RFC1034],
      Section 2.4) A resolver performs queries for a name, type, and
      class, and receives responses.  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.

      A related term is "resolve", which is not formally defined in
      [RFC1034] or [RFC1035].  An imputed definition might be "asking a
      question that consists of a domain name, class, and type, and
      receiving some sort of response".  Similarly, an imputed
      definition of "resolution" might be "the response received from
      resolving".

   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 Section 5.3.1 of [RFC1034].
      They are fully defined in Section 6.1.3.1 of [RFC1123].

   Iterative mode:  A resolution mode of a server that receives DNS
      queries and responds with a referral to another server.
      Section 2.3 of [RFC1034] describes this as "The server refers the
      client to another server and lets the client pursue the query."  A
      resolver that works in iterative mode is sometimes called an
      "iterative resolver".  See also "iterative resolution" later in
      this section.

   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 [RFC1034] describes this
      as "the first server pursues the query for the client at another
      server".  Section 4.3.1 of [RFC1034] says: "in [recursive] mode
      the name server acts in the role of a resolver and returns either
      an error or the answer, but never referrals."  That same section
      also says:

         The recursive mode occurs when a query with RD set arrives at a
         server which is willing to provide recursive service; the
         client can verify that recursive mode was used by checking that
         both RA and RD are set in the reply.

      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".  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.

   Recursive resolver:  A resolver that acts in recursive mode.  In
      general, a recursive resolver is expected to cache the answers it
      receives (which would make it a full-service resolver), but some
      recursive resolvers might not cache.

      [RFC4697] tried to differentiate between a recursive resolver and
      an iterative resolver.

   Recursive query:  A query with the Recursion Desired (RD) bit set to
      1 in the header.  (See Section 4.1.1 of [RFC1035].)  If recursive
      service is available and is requested by the RD bit in the query,
      the server uses its resolver to answer the query.  (See
      Section 4.3.2 of [RFC1034].)

   Non-recursive query:  A query with the Recursion Desired (RD) bit set
      to 0 in the header.  A server can answer non-recursive queries
      using only local information: the response contains either an
      error, the answer, or a referral to some other server "closer" to
      the answer.  (See Section 4.3.1 of [RFC1034].)

   Iterative resolution:  A name server may be presented with a query
      that can only be answered by some other server.  The two general
      approaches to dealing with this problem are "recursive", in which
      the first server pursues the query on behalf of the client at
      another server, and "iterative", in which the server refers the
      client to another server and lets the client pursue the query
      there.  (See Section 2.3 of [RFC1034].)

      In iterative resolution, the client repeatedly makes non-recursive
      queries and follows referrals and/or aliases.  The iterative
      resolution algorithm is described in Section 5.3.3 of [RFC1034].

   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].  This
      term is not properly defined in any RFC.

   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
      (and meets other requirements).

   Priming:  "The act of finding the list of root servers from a
      configuration that lists some or all of the purported IP addresses
      of some or all of those root servers."  (Quoted from [RFC8109],
      Section 2) In order to operate in recursive mode, a resolver needs
      to know the address of at least one root server.  Priming is most
      often done from a configuration setting that contains a list of
      authoritative servers for the root zone.

   Root hints:  "Operators who manage a DNS recursive resolver typically
      need to configure a 'root hints file'.  This file contains the
      names and IP addresses of the authoritative name servers for the
      root zone, so the software can bootstrap the DNS resolution
      process.  For many pieces of software, this list comes built into
      the software."  (Quoted from [IANA_RootFiles]) This file is often
      used in priming.

   Negative caching:  "The storage of knowledge that something does not
      exist, cannot or does not give an answer."  (Quoted from
      [RFC2308], Section 1)

   Authoritative server:  "A server that knows the content of a DNS zone
      from local knowledge, and thus can answer queries about that zone
      without needing to query other servers."  (Quoted from [RFC2182],
      Section 2) An authoritative server is named in the NS ("name
      server") record in a zone.  It is 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.  Authoritative servers also provide "referrals",
      usually to child zones delegated from them; these referrals have
      the AA bit set to 0 and come with referral data in the Authority
      and (if needed) the Additional sections.

   Authoritative-only server:  A name server that only serves
      authoritative data and ignores requests for recursion.  It will
      "not normally generate any queries of its own.  Instead it answers
      non-recursive queries from iterative resolvers looking for
      information in zones it serves."  (Quoted from [RFC4697],
      Section 2.4) In this case, "ignores requests for recursion" means
      "responds to requests for recursion with responses indicating that
      recursion was not performed".

   Zone transfer:  The act of a client requesting a copy of a zone and
      an authoritative server sending the needed information.  (See
      Section 7 for a description of zones.)  There are two common
      standard ways to do zone transfers: the AXFR ("Authoritative
      Transfer") mechanism to copy the full zone (described in
      [RFC5936], and the IXFR ("Incremental Transfer") mechanism to copy
      only parts of the zone that have changed (described in [RFC1995]).
      Many systems use non-standard methods for zone transfer outside
      the DNS protocol.

   Slave server:  See "Secondary server".

   Secondary server:  "An authoritative server which uses zone transfer
      to retrieve the zone."  (Quoted from [RFC1996], Section 2.1)
      Secondary servers are also discussed in [RFC1034].  [RFC2182]
      describes secondary servers in more detail.  Although early DNS
      RFCs such as [RFC1996] referred to this as a "slave", the current
      common usage has shifted to calling it a "secondary".

   Master server:  See "Primary server".

   Primary server:  "Any authoritative server configured to be the
      source of zone transfer for one or more [secondary] servers."
      (Quoted from [RFC1996], Section 2.1) Or, more specifically,
      [RFC2136] calls it "an authoritative server configured to be the
      source of AXFR or IXFR data for one or more [secondary] servers".
      Primary servers are also discussed in [RFC1034].  Although early
      DNS RFCs such as [RFC1996] referred to this as a "master", the
      current common usage has shifted to "primary".

   Primary master:  "The primary master is named in the zone's SOA MNAME
      field and optionally by an NS RR."  (Quoted from [RFC1996],
      Section 2.1) [RFC2136] defines "primary master" as "Master 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 RR.
      There is by definition only one primary master server per zone."

      The idea of a primary master is only used in [RFC1996] and
      [RFC2136].  A modern interpretation of the term "primary master"
      is a server that is both authoritative for a zone and that gets
      its updates to the zone from configuration (such as a master file)
      or from UPDATE transactions.

   Stealth server:  This is "like a slave server except not listed in an
      NS RR for the zone."  (Quoted from [RFC1996], Section 2.1)

   Hidden master:  A stealth server that is a primary server for zone
      transfers.  "In this arrangement, the master name server that
      processes the updates is unavailable to general hosts on the
      Internet; it is not listed in the NS RRset."  (Quoted from
      [RFC6781], Section 3.4.3) An earlier RFC, [RFC4641], said that the
      hidden master's name "appears in the SOA RRs MNAME field",
      although, in some setups, the name does not appear at all in the
      public DNS.  A hidden master can also be a secondary server for
      the zone itself.

   Forwarding:  The process of one server sending a DNS query with the
      RD bit set to 1 to another server to resolve that query.
      Forwarding is a function of a DNS resolver; it is different than
      simply blindly relaying queries.

      [RFC5625] does not give a specific definition for forwarding, but
      describes in detail what features a system that forwards needs 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
      authoritative nameserver chain".  [RFC2308] further says "The
      forwarder typically either has better access to the internet, or
      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-service resolver.

   Policy-implementing resolver:  A resolver acting in recursive mode
      that changes some of the answers that it returns based on policy
      criteria, such as to prevent access to malware sites or
      objectionable content.  In general, a stub resolver has no idea
      whether upstream resolvers implement such policy or, if they do,
      the exact policy about what changes will be made.  In some cases,
      the user of the stub resolver has selected the policy-implementing
      resolver with the explicit intention of using it to implement the
      policies.  In other cases, policies are imposed without the user
      of the stub resolver being informed.

   Open resolver:  A full-service resolver that accepts and processes
      queries from any (or nearly any) client.  This is sometimes also
      called a "public resolver", although the term "public resolver" is
      used more with open resolvers that are meant to be open, as
      compared to the vast majority of open resolvers that are probably
      misconfigured to be open.  Open resolvers are discussed in
      [RFC5358].

   Split DNS:  The terms "split DNS" and "split-horizon DNS" have long
      been used in the DNS community without formal definition.  In
      general, they refer to situations in which DNS servers that are
      authoritative for a particular set of domains provide partly or
      completely different answers in those domains depending on the
      source of the query.  The effect of this is that a domain name
      that is notionally globally unique nevertheless has different
      meanings for different network users.  This can sometimes be the
      result of a "view" configuration, described below.

      Section 3.8 of [RFC2775] gives a related definition that is too
      specific to be generally useful.

   View:  A configuration for a DNS server that allows it to provide
      different responses depending on attributes of the query, such as
      for "split DNS".  Typically, 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 AXFR), whether it is recursive, and so

      on.  Views are often used to provide more names or different
      addresses to queries from "inside" a protected network than to
      those "outside" that network.  Views are not a standardized part
      of the DNS, but they are widely implemented in server software.

   Passive DNS:  A mechanism to collect DNS data by storing DNS
      responses from name servers.  Some of these systems also collect
      the DNS queries associated with the responses, although doing so
      raises some privacy concerns.  Passive DNS databases can be used
      to answer historical questions about DNS zones such as which
      values were present at a given time in the past, or when a name
      was spotted first.  Passive DNS databases allow searching of the
      stored records on keys other than just the name and type, such as
      "find all names which have A records of a particular value".

   Anycast:  "The practice of making a particular service address
      available in multiple, discrete, autonomous locations, such that
      datagrams sent are routed to one of several available locations."
      (Quoted from [RFC4786], Section 2) See [RFC4786] for more detail
      on Anycast and other terms that are specific to its use.

   Instance:  "When anycast routing is used to allow more than one
      server to have the same IP address, each one of those servers is
      commonly referred to as an 'instance'."  It goes on to say: "An
      instance of a server, such as a root server, is often referred to
      as an 'Anycast instance'."  (Quoted from [RSSAC026])

   Privacy-enabling DNS server:  "A DNS server that implements DNS over
      TLS [RFC7858] and may optionally implement DNS over DTLS
      [RFC8094]."  (Quoted from [RFC8310], Section 2) Other types of DNS
      servers might also be considered privacy-enabling, such as those
      running DNS over HTTPS [RFC8484].

7.  Zones

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

   Zone:  "Authoritative information is organized into units called
      ZONEs, and these zones can be automatically distributed to the
      name servers which provide redundant service for the data in a
      zone."  (Quoted from [RFC1034], 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
      [RFC7344], 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".  (Note
      that [RFC0882] was obsoleted by [RFC1034] and [RFC1035].)
      [RFC819] also has some description of the relationship between
      parents and children.

   Origin:

      There are two different uses for this term:

      (a)  "The domain name that appears at the top of a zone (just
           below the cut that separates the zone from its parent)... The
           name of the zone is the same as the name of the domain at the
           zone's origin."  (Quoted from [RFC2181], Section 6) These
           days, this sense of "origin" and "apex" (defined below) are
           often used interchangeably.

      (b)  The domain name within which a given relative domain name
           appears in zone files.  Generally seen in the context of
           "$ORIGIN", which is a control entry defined in [RFC1035],
           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.".

   Apex:  The point in the tree at an owner of an SOA and corresponding
      authoritative NS RRset.  This is also called the "zone apex".
      [RFC4033] defines it as "the name at the child's side of a zone
      cut".  The "apex" can usefully be thought of as a data-theoretic
      description of a tree structure, and "origin" is the name of the
      same concept when it is implemented in zone files.  The
      distinction is not always maintained in use, however, and one can
      find uses that conflict subtly with this definition.  [RFC1034]
      uses the term "top node of the zone" as a synonym of "apex", but
      that term is not widely used.  These days, the first sense of
      "origin" (above) and "apex" are often used interchangeably.

   Zone cut:  The delimitation point between two zones where the origin
      of one of the zones is the child of the other zone.

      "Zones are delimited by 'zone cuts'.  Each zone cut separates a
      'child' zone (below the cut) from a 'parent' zone (above the
      cut)."  (Quoted from [RFC2181], Section 6; note that this is
      barely an ostensive definition.)  Section 4.2 of [RFC1034] uses
      "cuts" instead of "zone cut".

   Delegation:  The process by which a separate zone is created in the
      name space beneath the apex of a given domain.  Delegation happens
      when an NS RRset is added in the parent zone for the child origin.
      Delegation inherently happens at a zone cut.  The term is also
      commonly a noun: the new zone that is created by the act of
      delegating.

   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 around the bottom edge of the zone."  (Quoted from [RFC1034],
      Section 4.2.1) Note that this definition might inadvertently also
      cause any NS records that appear in the zone to be included, even
      those that might not truly be authoritative because there are
      identical NS RRs below the zone cut.  This reveals the ambiguity
      in the notion of authoritative data, because the parent-side NS
      records authoritatively indicate the delegation, even though they
      are not themselves authoritative data.

      [RFC4033], Section 2, defines "Authoritative RRset", which is
      related to authoritative data but has a more precise definition.

   Lame delegation:  "A lame delegations exists [sic] when a nameserver
      is delegated responsibility for providing nameservice for a zone
      (via NS records) but is not performing nameservice for that zone
      (usually because it is not set up as a primary or secondary for
      the zone)."  (Quoted from [RFC1912], Section 2.8) Another
      definition is that a lame delegation "...happens when a name
      server is listed in the NS records for some domain and in fact it
      is not a server for that domain.  Queries are thus sent to the
      wrong servers, who don't know nothing [sic] (at least not as
      expected) about the queried domain.  Furthermore, sometimes these
      hosts (if they exist!) don't even run name servers."  (Quoted from
      [RFC1713], Section 2.3)

   Glue records:  "...[Resource records] which are not part of the
      authoritative data [of the zone], and are address RRs for the
      [name] servers [in subzones].  These RRs are only necessary if the
      name server's name is 'below' the cut, and are only used as part
      of a referral response."  Without glue "we could be faced with the
      situation where the NS RRs tell us that in order to learn a name
      server's address, we should contact the server using the address
      we wish to learn."  (Quoted from [RFC1034], Section 4.2.1)

      A later definition is that glue "includes any record in a zone
      file that is not properly part of that zone, including nameserver
      records of delegated sub-zones (NS records), address records that
      accompany those NS records (A, AAAA, etc), and any other stray
      data that might appear."  (Quoted from [RFC2181], Section 5.4.1)

      Although glue is sometimes used today with this wider definition
      in mind, the context surrounding the definition in [RFC2181]
      suggests it is intended to apply to the use of glue within the
      document itself and not necessarily beyond.

   Bailiwick:  "In-bailiwick" is a modifier to describe a name server
      whose name is either a subdomain of or (rarely) the same as the
      origin of the zone that contains the delegation to the name
      server.  In-bailiwick name servers may have glue records in their
      parent zone (using the first of the definitions of "glue records"
      in the definition above).  (The word "bailiwick" means the
      district or territory where a bailiff or policeman has
      jurisdiction.)

      "In-bailiwick" names are divided into two types of names for name
      servers: "in-domain" names and "sibling domain" names.

      *  In-domain: a modifier to describe a name server whose name is
         either subordinate to or (rarely) the same as the owner name of
         the NS resource records.  An in-domain name server name needs
         to have glue records or name resolution fails.  For example, a
         delegation for "child.example.com" may have "in-domain" name
         server name "ns.child.example.com".

      *  Sibling domain: a name server's name that is either subordinate
         to or (rarely) the same as the zone origin and not subordinate
         to or the same as the owner name of the NS resource records.
         Glue records for sibling domains are allowed, but not
         necessary.  For example, a delegation for "child.example.com"
         in "example.com" zone may have "sibling" name server name
         "ns.another.example.com".

      "Out-of-bailiwick" is the antonym of "in-bailiwick".  It is a
      modifier to describe a name server whose name is not subordinate
      to or the same as the zone origin.  Glue records for out-of-
      bailiwick name servers are useless.  The following table shows
      examples of delegation types.

   Delegation |Parent|Name Server Name  | Type
   -----------+------+------------------+-----------------------------
   com        | .    |a.gtld-servers.net|in-bailiwick / sibling domain
   net        | .    |a.gtld-servers.net|in-bailiwick / in-domain
   example.org| org  |ns.example.org    |in-bailiwick / in-domain
   example.org| org  |ns.ietf.org       |in-bailiwick / sibling domain
   example.org| org  |ns.example.com    |out-of-bailiwick
   example.jp | jp   |ns.example.jp     |in-bailiwick / in-domain
   example.jp | jp   |ns.example.ne.jp  |in-bailiwick / sibling domain
   example.jp | jp   |ns.example.com    |out-of-bailiwick

   Root zone:  The zone of a DNS-based tree whose apex is the zero-
      length label.  Also sometimes called "the DNS root".

   Empty non-terminals (ENT):  "Domain names that own no resource
      records but have subdomains that do."  (Quoted from [RFC4592],
      Section 2.2.2) 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.

   Delegation-centric zone:  A zone that consists mostly of delegations
      to child zones.  This term is used in contrast to a zone that
      might have some delegations to child zones but also has many data
      resource records for the zone itself and/or for child zones.  The
      term is used in [RFC4956] and [RFC5155], but it is not defined in
      either document.

   Occluded name:  "The addition of a delegation point via dynamic
      update will render all subordinate domain names to be in a limbo,
      still part of the zone but not available to the lookup process.
      The addition of a DNAME resource record has the same impact.  The
      subordinate names are said to be 'occluded'."  (Quoted from
      [RFC5936], Section 3.5)

   Fast flux DNS:  This "occurs when a domain is [found] in DNS using A
      records to multiple IP addresses, each of which has a very short
      Time-to-Live (TTL) value associated with it.  This means that the
      domain resolves to varying IP addresses over a short period of
      time."  (Quoted from [RFC6561], Section 1.1.5, with a typo
      corrected) In addition to having legitimate uses, fast flux DNS
      can used to deliver malware.  Because the addresses change so
      rapidly, it is difficult to ascertain all the hosts.  It should be
      noted that the technique also works with AAAA records, but such
      use is not frequently observed on the Internet as of this writing.

   Reverse DNS, reverse lookup:  "The process of mapping an address to a
      name is generally known as a 'reverse lookup', and the
      IN-ADDR.ARPA and IP6.ARPA zones are said to support the 'reverse
      DNS'."  (Quoted from [RFC5855], Section 1)

   Forward lookup:  "Hostname-to-address translation".  (Quoted from
      [RFC3493], Section 6)

   arpa: Address and Routing Parameter Area Domain:  "The 'arpa' domain
      was originally established as part of the initial deployment of
      the DNS, to provide a transition mechanism from the Host Tables
      that were common in the ARPANET, as well as a home for the IPv4
      reverse mapping domain.  During 2000, the abbreviation was

      redesignated to 'Address and Routing Parameter Area' in the hope
      of reducing confusion with the earlier network name."  (Quoted
      from [RFC3172], Section 2) .arpa is an "infrastructure domain", a
      domain whose "role is to support the operating infrastructure of
      the Internet".  (Quoted from [RFC3172], Section 2) See [RFC3172]
      for more history of this name.

   Service name:  "Service names are the unique key in the Service Name
      and Transport Protocol Port Number registry.  This unique symbolic
      name for a service may also be used for other purposes, such as in
      DNS SRV records."  (Quoted from [RFC6335], Section 5)

8.  Wildcards

   Wildcard:  [RFC1034] 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].  Special
      treatment is given to RRs with owner names starting with the label
      "*".  "Such RRs are called 'wildcards'.  Wildcard RRs can be
      thought of as instructions for synthesizing RRs."  (Quoted from
      [RFC1034], Section 4.3.3)

   Asterisk label:  "The first octet is the normal label type and length
      for a 1-octet-long label, and the second octet is the ASCII
      representation [RFC20] for the '*' character.  A descriptive name
      of a label equaling that value is an 'asterisk label'."  (Quoted
      from [RFC4592], Section 2.1.1)

   Wildcard domain name:  "A 'wildcard domain name' is defined by having
      its initial (i.e., leftmost or least significant) label, in binary
      format: 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)".
      (Quoted from [RFC4592], Section 2.1.1) The second octet in this
      label is the ASCII representation for the "*" character.

   Closest encloser:  "The longest existing ancestor of a name."
      (Quoted from [RFC5155], Section 1.3) An earlier definition is "The
      node in the zone's tree of existing domain names that has the most
      labels matching the query name (consecutively, counting from the
      root label downward).  Each match is a 'label match' and the order
      of the labels is the same."  (Quoted from [RFC4592],
      Section 3.3.1)

   Closest provable encloser:  "The longest ancestor of a name that can
      be proven to exist.  Note that this is only different from the
      closest encloser in an Opt-Out zone."  (Quoted from [RFC5155],
      Section 1.3) See Section 10 for more on "opt-out".

   Next closer name:  "The name one label longer than the closest
      provable encloser of a name."  (Quoted from [RFC5155],
      Section 1.3)

   Source of Synthesis:  "The source of synthesis is defined in the
      context of a query process as that wildcard domain name
      immediately descending from the closest encloser, provided that
      this wildcard domain name exists.  'Immediately descending' means
      that the source of synthesis has a name of the form:
      <asterisk label>.<closest encloser>."
      (Quoted from [RFC4592], Section 3.3.1)