pub struct DnsResponse(_);
Expand description

A DNS response object

For Most DNS requests, only one response is expected, the exception is a multicast request.

Implementations

Retrieves the SOA from the response. This will only exist if it was an authoritative response.

Looks in the authority section for an SOA record from the response, and returns the negative_ttl, None if not available.

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

5 - Caching Negative Answers

  Like normal answers negative answers have a time to live (TTL).  As
  there is no record in the answer section to which this TTL can be
  applied, the TTL must be carried by another method.  This is done by
  including the SOA record from the zone in the authority section of
  the reply.  When the authoritative server creates this record its TTL
  is taken from the minimum of the SOA.MINIMUM field and SOA's TTL.
  This TTL decrements in a similar manner to a normal cached answer and
  upon reaching zero (0) indicates the cached negative answer MUST NOT
  be used again.

  A negative answer that resulted from a name error (NXDOMAIN) should
  be cached such that it can be retrieved and returned in response to
  another query for the same <QNAME, QCLASS> that resulted in the
  cached negative response.

  A negative answer that resulted from a no data error (NODATA) should
  be cached such that it can be retrieved and returned in response to
  another query for the same <QNAME, QTYPE, QCLASS> that resulted in
  the cached negative response.

  The NXT record, if it exists in the authority section of a negative
  answer received, MUST be stored such that it can be be located and
  returned with SOA record in the authority section, as should any SIG
  records in the authority section.  For NXDOMAIN answers there is no
  "necessary" obvious relationship between the NXT records and the
  QNAME.  The NXT record MUST have the same owner name as the query
  name for NODATA responses.

  Negative responses without SOA records SHOULD NOT be cached as there
  is no way to prevent the negative responses looping forever between a
  pair of servers even with a short TTL.

  Despite the DNS forming a tree of servers, with various mis-
  configurations it is possible to form a loop in the query graph, e.g.
  two servers listing each other as forwarders, various lame server
  configurations.  Without a TTL count down a cache negative response
  when received by the next server would have its TTL reset.  This
  negative indication could then live forever circulating between the
  servers involved.

  As with caching positive responses it is sensible for a resolver to
  limit for how long it will cache a negative response as the protocol
  supports caching for up to 68 years.  Such a limit should not be
  greater than that applied to positive answers and preferably be
  tunable.  Values of one to three hours have been found to work well
  and would make sensible a default.  Values exceeding one day have
  been found to be problematic.

Does the response contain any records matching the query name and type?

Retrieve the type of the negative response. The Various types should be handled when caching or otherwise differently.

See NegativeType

Methods from Deref<Target = Message>

Truncates a Message, this blindly removes all response fields and sets truncated to true

see Header::set_id

see Header::set_message_type

see Header::set_op_code

see Header::set_authoritative

see Header::set_truncated

see Header::set_recursion_desired

see Header::set_recursion_available

see Header::set_authentic_data

see Header::set_checking_disabled

see Header::set_response_code

Add a query to the Message, either the query response from the server, or the request Query.

Adds an iterator over a set of Queries to be added to the message

Add an answer to the Message

Add all the records from the iterator to the answers section of the Message

Sets the answers to the specified set of Records.

Panics

Will panic if answer records are already associated to the message.

Add a name server record to the Message

Add all the records in the Iterator to the name server section of the message

Sets the name_servers to the specified set of Records.

Panics

Will panic if name_servers records are already associated to the message.

Add an additional Record to the message

Sets the additional to the specified set of Records.

Panics

Will panic if additional records are already associated to the message.

Add the EDNS section to the Message

Gets the header of the Message

see Header::id()

see Header::message_type()

see Header::op_code()

see Header::authoritative()

see Header::truncated()

see Header::recursion_desired()

see Header::recursion_available()

see Header::authentic_data()

see Header::checking_disabled()

Return value

The ResponseCode, if this is an EDNS message then this will join the section from the OPT record to create the EDNS ResponseCode

Question        Carries the query name and other query parameters.

Provides mutable access to queries

Removes all the answers from the Message

Answer          Carries RRs which directly answer the query.

Provides mutable access to answers

Removes all the answers from the Message

Authority       Carries RRs which describe other authoritative servers.
                May optionally carry the SOA RR for the authoritative
                data in the answer section.

Provides mutable access to name_servers

Remove the name servers from the Message

Additional      Carries RRs which may be helpful in using the RRs in the
                other sections.

Provides mutable access to additionals

Remove the additional Records from the Message

All sections chained

RFC 6891, EDNS(0) Extensions, April 2013

6.1.1.  Basic Elements

 An OPT pseudo-RR (sometimes called a meta-RR) MAY be added to the
 additional data section of a request.

 The OPT RR has RR type 41.

 If an OPT record is present in a received request, compliant
 responders MUST include an OPT record in their respective responses.

 An OPT record does not carry any DNS data.  It is used only to
 contain control information pertaining to the question-and-answer
 sequence of a specific transaction.  OPT RRs MUST NOT be cached,
 forwarded, or stored in or loaded from Zone Files.

 The OPT RR MAY be placed anywhere within the additional data section.
 When an OPT RR is included within any DNS message, it MUST be the
 only OPT RR in that message.  If a query message with more than one
 OPT RR is received, a FORMERR (RCODE=1) MUST be returned.  The
 placement flexibility for the OPT RR does not override the need for
 the TSIG or SIG(0) RRs to be the last in the additional section
 whenever they are present.
Return value

Returns the EDNS record if it was found in the additional section.

If edns is_none, this will create a new default Edns.

Return value

the max payload value as it’s defined in the EDNS section.

Return value

the version as defined in the EDNS record

RFC 2535, Domain Name System Security Extensions, March 1999

A DNS request may be optionally signed by including one or more SIGs
 at the end of the query. Such SIGs are identified by having a "type
 covered" field of zero. They sign the preceding DNS request message
 including DNS header but not including the IP header or any request
 SIGs at the end and before the request RR counts have been adjusted
 for the inclusions of any request SIG(s).
Return value

The sig0 and tsig, i.e. signed record, for verifying the sending and package integrity

RFC 2535, Domain Name System Security Extensions, March 1999

A DNS request may be optionally signed by including one or more SIGs
 at the end of the query. Such SIGs are identified by having a "type
 covered" field of zero. They sign the preceding DNS request message
 including DNS header but not including the IP header or any request
 SIGs at the end and before the request RR counts have been adjusted
 for the inclusions of any request SIG(s).
Return value

The sig0 and tsig, i.e. signed record, for verifying the sending and package integrity

Remove signatures from the Message

Encodes the Message into a buffer

Finalize the message prior to sending.

Subsequent to calling this, the Message should not change.

Methods from Deref<Target = Header>

A method to get all header flags (useful for Display purposes)

ID              A 16 bit identifier assigned by the program that
                generates any kind of query.  This identifier is copied
                the corresponding reply and can be used by the requester
                to match up replies to outstanding queries.
QR              A one bit field that specifies whether this message is a
                query (0), or a response (1).
OPCODE          A four bit field that specifies kind of query in this
                message.  This value is set by the originator of a query
                and copied into the response.  The values are: <see super::op_code>
AA              Authoritative Answer - this bit is valid in responses,
                and specifies that the responding name server is an
                authority for the domain name in question section.

                Note that the contents of the answer section may have
                multiple owner names because of aliases.  The AA bit
                corresponds to the name which matches the query name, or
                the first owner name in the answer section.
TC              TrunCation - specifies that this message was truncated
                due to length greater than that permitted on the
                transmission channel.
RD              Recursion Desired - this bit may be set in a query and
                is copied into the response.  If RD is set, it directs
                the name server to pursue the query recursively.
                Recursive query support is optional.
RA              Recursion Available - this be is set or cleared in a
                response, and denotes whether recursive query support is
                available in the name server.

RFC 4035, DNSSEC Resource Records, March 2005


3.1.6.  The AD and CD Bits in an Authoritative Response

  The CD and AD bits are designed for use in communication between
  security-aware resolvers and security-aware recursive name servers.
  These bits are for the most part not relevant to query processing by
  security-aware authoritative name servers.

  A security-aware name server does not perform signature validation
  for authoritative data during query processing, even when the CD bit
  is clear.  A security-aware name server SHOULD clear the CD bit when
  composing an authoritative response.

  A security-aware name server MUST NOT set the AD bit in a response
  unless the name server considers all RRsets in the Answer and
  Authority sections of the response to be authentic.  A security-aware
  name server's local policy MAY consider data from an authoritative
  zone to be authentic without further validation.  However, the name
  server MUST NOT do so unless the name server obtained the
  authoritative zone via secure means (such as a secure zone transfer
  mechanism) and MUST NOT do so unless this behavior has been
  configured explicitly.

  A security-aware name server that supports recursion MUST follow the
  rules for the CD and AD bits given in Section 3.2 when generating a
  response that involves data obtained via recursion.

see is_authentic_data()

RCODE           Response code - this 4 bit field is set as part of
                responses.  The values have the following
                interpretation: <see super::response_code>
QDCOUNT         an unsigned 16 bit integer specifying the number of
                entries in the question section.
Return value

If this is a query, this will return the number of queries in the query section of the

ANCOUNT         an unsigned 16 bit integer specifying the number of
                resource records in the answer section.
Return value

For query responses this is the number of records in the answer section, should be 0 for requests, for updates this is the count of prerequisite records.

for queries this is the nameservers which are authorities for the SOA of the Record for updates this is the update record count

NSCOUNT         an unsigned 16 bit integer specifying the number of name
                server resource records in the authority records
                section.
Return value

For query responses this is the number of authorities, or nameservers, in the name server section, for updates this is the number of update records being sent.

ARCOUNT         an unsigned 16 bit integer specifying the number of
                resource records in the additional records section.
Return value

This is the additional record section count, this section may include EDNS options.

Trait Implementations

Returns a copy of the value. Read more

Performs copy-assignment from source. Read more

Formats the value using the given formatter. Read more

The resulting type after dereferencing.

Dereferences the value.

Mutably dereferences the value.

Performs the conversion.

Performs the conversion.

Auto Trait Implementations

Blanket Implementations

Gets the TypeId of self. Read more

Immutably borrows from an owned value. Read more

Mutably borrows from an owned value. Read more

Returns the argument unchanged.

Calls U::from(self).

That is, this conversion is whatever the implementation of From<T> for U chooses to do.

The resulting type after obtaining ownership.

Creates owned data from borrowed data, usually by cloning. Read more

🔬 This is a nightly-only experimental API. (toowned_clone_into)

Uses borrowed data to replace owned data, usually by cloning. Read more

The type returned in the event of a conversion error.

Performs the conversion.

The type returned in the event of a conversion error.

Performs the conversion.