pub enum NegativeType {
NameErrorType1,
NameErrorType2,
NameErrorType3,
NameErrorType4,
NoDataType1,
NoDataType2,
NoDataType3,
Referral,
}
Expand description
[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§
Source§impl NegativeType
impl NegativeType
The response contains an SOA record
Trait Implementations§
Source§impl Clone for NegativeType
impl Clone for NegativeType
Source§fn clone(&self) -> NegativeType
fn clone(&self) -> NegativeType
Returns a copy of the value. Read more
1.0.0 · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
Performs copy-assignment from
source
. Read moreSource§impl Debug for NegativeType
impl Debug for NegativeType
Source§impl PartialEq for NegativeType
impl PartialEq for NegativeType
impl Copy for NegativeType
impl Eq for NegativeType
impl StructuralPartialEq for NegativeType
Auto Trait Implementations§
impl Freeze for NegativeType
impl RefUnwindSafe for NegativeType
impl Send for NegativeType
impl Sync for NegativeType
impl Unpin for NegativeType
impl UnwindSafe for NegativeType
Blanket Implementations§
Source§impl<T> BorrowMut<T> for Twhere
T: ?Sized,
impl<T> BorrowMut<T> for Twhere
T: ?Sized,
Source§fn borrow_mut(&mut self) -> &mut T
fn borrow_mut(&mut self) -> &mut T
Mutably borrows from an owned value. Read more
Source§impl<T> CloneToUninit for Twhere
T: Clone,
impl<T> CloneToUninit for Twhere
T: Clone,
Source§unsafe fn clone_to_uninit(&self, dst: *mut T)
unsafe fn clone_to_uninit(&self, dst: *mut T)
🔬This is a nightly-only experimental API. (
clone_to_uninit
)