Enum trust_dns_proto::xfer::dns_response::NegativeType

pub enum NegativeType {
    NameErrorType1,
    NameErrorType2,
    NameErrorType3,
    NameErrorType4,
    NoDataType1,
    NoDataType2,
    NoDataType3,
    Referral,
}

[RFC 2308](https://tools.ietf.org/html/rfc2308#section-2) DNS NCACHE March 1998


2 - Negative Responses

   The most common negative responses indicate that a particular RRset
   does not exist in the DNS.  The first sections of this document deal
   with this case.  Other negative responses can indicate failures of a
   nameserver, those are dealt with in section 7 (Other Negative
   Responses).

   A negative response is indicated by one of the following conditions:

2.1 - Name Error

   Name errors (NXDOMAIN) are indicated by the presence of "Name Error"
   in the RCODE field.  In this case the domain referred to by the QNAME
   does not exist.  Note: the answer section may have SIG and CNAME RRs
   and the authority section may have SOA, NXT [RFC2065] and SIG RRsets.

   It is possible to distinguish between a referral and a NXDOMAIN
   response by the presense of NXDOMAIN in the RCODE regardless of the
   presence of NS or SOA records in the authority section.

   NXDOMAIN responses can be categorised into four types by the contents
   of the authority section.  These are shown below along with a
   referral for comparison.  Fields not mentioned are not important in
   terms of the examples.

   See [NegativeType] below:
       [NegativeType::NameErrorType1]
       [NegativeType::NameErrorType2]
       [NegativeType::NameErrorType3]
       [NegativeType::NameErrorType4]
       [NegativeType::Referral]

   Note, in the four examples of NXDOMAIN responses, it is known that
   the name "AN.EXAMPLE." exists, and has as its value a CNAME record.
   The NXDOMAIN refers to "TRIPPLE.XX", which is then known not to
   exist.  On the other hand, in the referral example, it is shown that
   "AN.EXAMPLE" exists, and has a CNAME RR as its value, but nothing is
   known one way or the other about the existence of "TRIPPLE.XX", other
   than that "NS1.XX" or "NS2.XX" can be consulted as the next step in
   obtaining information about it.

   Where no CNAME records appear, the NXDOMAIN response refers to the
   name in the label of the RR in the question section.

2.1.1 Special Handling of Name Error

   This section deals with errors encountered when implementing negative
   caching of NXDOMAIN responses.

   There are a large number of resolvers currently in existence that
   fail to correctly detect and process all forms of NXDOMAIN response.
   Some resolvers treat a TYPE 1 NXDOMAIN response as a referral.  To
   alleviate this problem it is recommended that servers that are
   authoritative for the NXDOMAIN response only send TYPE 2 NXDOMAIN
   responses, that is the authority section contains a SOA record and no
   NS records.  If a non- authoritative server sends a type 1 NXDOMAIN
   response to one of these old resolvers, the result will be an
   unnecessary query to an authoritative server.  This is undesirable,
   but not fatal except when the server is being used a FORWARDER.  If
   however the resolver is using the server as a FORWARDER to such a
   resolver it will be necessary to disable the sending of TYPE 1
   NXDOMAIN response to it, use TYPE 2 NXDOMAIN instead.

   Some resolvers incorrectly continue processing if the authoritative
   answer flag is not set, looping until the query retry threshold is
   exceeded and then returning SERVFAIL.  This is a problem when your
   nameserver is listed as a FORWARDER for such resolvers.  If the
   nameserver is used as a FORWARDER by such resolver, the authority
   flag will have to be forced on for NXDOMAIN responses to these
   resolvers.  In practice this causes no problems even if turned on
   always, and has been the default behaviour in BIND from 4.9.3
   onwards.

2.2 - No Data

   NODATA is indicated by an answer with the RCODE set to NOERROR and no
   relevant answers in the answer section.  The authority section will
   contain an SOA record, or there will be no NS records there.
   NODATA responses have to be algorithmically determined from the
   response's contents as there is no RCODE value to indicate NODATA.
   In some cases to determine with certainty that NODATA is the correct
   response it can be necessary to send another query.

   The authority section may contain NXT and SIG RRsets in addition to
   NS and SOA records.  CNAME and SIG records may exist in the answer
   section.

   It is possible to distinguish between a NODATA and a referral
   response by the presence of a SOA record in the authority section or
   the absence of NS records in the authority section.

   NODATA responses can be categorised into three types by the contents
   of the authority section.  These are shown below along with a
   referral for comparison.  Fields not mentioned are not important in
   terms of the examples.

   See [NegativeType] below:
       [NegativeType::NoDataType1]
       [NegativeType::NoDataType2]
       [NegativeType::NoDataType3]

   These examples, unlike the NXDOMAIN examples above, have no CNAME
   records, however they could, in just the same way that the NXDOMAIN
   examples did, in which case it would be the value of the last CNAME
   (the QNAME) for which NODATA would be concluded.

2.2.1 - Special Handling of No Data

   There are a large number of resolvers currently in existence that
   fail to correctly detect and process all forms of NODATA response.
   Some resolvers treat a TYPE 1 NODATA response as a referral.  To
   alleviate this problem it is recommended that servers that are
   authoritative for the NODATA response only send TYPE 2 NODATA
   responses, that is the authority section contains a SOA record and no
   NS records.  Sending a TYPE 1 NODATA response from a non-
   authoritative server to one of these resolvers will only result in an
   unnecessary query.  If a server is listed as a FORWARDER for another
   resolver it may also be necessary to disable the sending of TYPE 1
   NODATA response for non-authoritative NODATA responses.
   Some name servers fail to set the RCODE to NXDOMAIN in the presence
   of CNAMEs in the answer section.  If a definitive NXDOMAIN / NODATA
   answer is required in this case the resolver must query again using
   the QNAME as the query label.

3 - Negative Answers from Authoritative Servers

   Name servers authoritative for a zone MUST include the SOA record of
   the zone in the authority section of the response when reporting an
   NXDOMAIN or indicating that no data of the requested type exists.
   This is required so that the response may be cached.  The TTL of this
   record is set from the minimum of the MINIMUM field of the SOA record
   and the TTL of the SOA itself, and indicates how long a resolver may
   cache the negative answer.  The TTL SIG record associated with the
   SOA record should also be trimmed in line with the SOA's TTL.

   If the containing zone is signed [RFC2065] the SOA and appropriate
   NXT and SIG records MUST be added.

Variants

NameErrorType1

           NXDOMAIN RESPONSE: TYPE 1.

           Header:
               RDCODE=NXDOMAIN
           Query:
               AN.EXAMPLE. A
           Answer:
               AN.EXAMPLE. CNAME TRIPPLE.XX.
           Authority:
               XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
               XX. NS NS1.XX.
               XX. NS NS2.XX.
           Additional:
               NS1.XX. A 127.0.0.2
               NS2.XX. A 127.0.0.3

NameErrorType2

           NXDOMAIN RESPONSE: TYPE 2.

           Header:
               RDCODE=NXDOMAIN
           Query:
               AN.EXAMPLE. A
           Answer:
               AN.EXAMPLE. CNAME TRIPPLE.XX.
           Authority:
               XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
           Additional:
               <empty>

NameErrorType3

           NXDOMAIN RESPONSE: TYPE 3.

           Header:
               RDCODE=NXDOMAIN
           Query:
               AN.EXAMPLE. A
           Answer:
               AN.EXAMPLE. CNAME TRIPPLE.XX.
           Authority:
               <empty>
           Additional:
               <empty>

NameErrorType4

           NXDOMAIN RESPONSE: TYPE 4

           Header:
               RDCODE=NXDOMAIN
           Query:
               AN.EXAMPLE. A
           Answer:
               AN.EXAMPLE. CNAME TRIPPLE.XX.
           Authority:
               XX. NS NS1.XX.
               XX. NS NS2.XX.
           Additional:
               NS1.XX. A 127.0.0.2
               NS2.XX. A 127.0.0.3

NoDataType1

           NODATA RESPONSE: TYPE 1.

           Header:
               RDCODE=NOERROR
           Query:
               ANOTHER.EXAMPLE. A
           Answer:
               <empty>
           Authority:
               EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
               EXAMPLE. NS NS1.XX.
               EXAMPLE. NS NS2.XX.
           Additional:
               NS1.XX. A 127.0.0.2
               NS2.XX. A 127.0.0.3

NoDataType2

           NO DATA RESPONSE: TYPE 2.

           Header:
               RDCODE=NOERROR
           Query:
               ANOTHER.EXAMPLE. A
           Answer:
               <empty>
           Authority:
               EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
           Additional:
               <empty>

NoDataType3

           NO DATA RESPONSE: TYPE 3.
           Header:
               RDCODE=NOERROR
           Query:
               ANOTHER.EXAMPLE. A
           Answer:
               <empty>
           Authority:
               <empty>
           Additional:
               <empty>

Referral

           REFERRAL RESPONSE.

           Header:
               RDCODE=NOERROR
           Query:
               AN.EXAMPLE. A
           Answer:
               AN.EXAMPLE. CNAME TRIPPLE.XX.
           Authority:
               XX. NS NS1.XX.
               XX. NS NS2.XX.
           Additional:
               NS1.XX. A 127.0.0.2
               NS2.XX. A 127.0.0.3

           REFERRAL RESPONSE.

           Header:
               RDCODE=NOERROR
           Query:
               ANOTHER.EXAMPLE. A
           Answer:
               <empty>
           Authority:
               EXAMPLE. NS NS1.XX.
               EXAMPLE. NS NS2.XX.
           Additional:
               NS1.XX. A 127.0.0.2
               NS2.XX. A 127.0.0.3

Implementations

impl NegativeType

pub fn is_authoritative(&self) -> bool

The response contains an SOA record

Trait Implementations

impl Clone for NegativeType

fn clone(&self) -> NegativeType

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for NegativeType

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl PartialEq for NegativeType

fn eq(&self, other: &NegativeType) -> bool

This method tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

This method tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl Copy for NegativeType

impl Eq for NegativeType

impl StructuralPartialEq for NegativeType