rama::dns::client::hickory::resolver::net::proto::op

Struct Message

#[non_exhaustive]pub struct Message {
    pub metadata: Metadata,
    pub queries: Vec<Query>,
    pub answers: Vec<Record>,
    pub authorities: Vec<Record>,
    pub additionals: Vec<Record>,
    pub signature: Option<Box<Record<TSIG>>>,
    pub edns: Option<Edns>,
}

Expand description

The basic request and response data structure, used for all DNS protocols.

RFC 1035, DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION, November 1987

4.1. Format

All communications inside of the domain protocol are carried in a single
format called a message.  The top level format of message is divided
into 5 sections (some of which are empty in certain cases) shown below:

    +--------------------------+
    |        Header            |
    +--------------------------+
    |  Question / Zone         | the question for the name server
    +--------------------------+
    |   Answer  / Prerequisite | RRs answering the question
    +--------------------------+
    | Authority / Update       | RRs pointing toward an authority
    +--------------------------+
    |      Additional          | RRs holding additional information
    +--------------------------+

The header section is always present.  The header includes fields that
specify which of the remaining sections are present, and also specify
whether the message is a query or a response, a standard query or some
other opcode, etc.

The names of the sections after the header are derived from their use in
standard queries.  The question section contains fields that describe a
question to a name server.  These fields are a query type (QTYPE), a
query class (QCLASS), and a query domain name (QNAME).  The last three
sections have the same format: a possibly empty list of concatenated
resource records (RRs).  The answer section contains RRs that answer the
question; the authority section contains RRs that point toward an
authoritative name server; the additional records section contains RRs
which relate to the query, but are not strictly answers for the
question.

By default Message is a Query. Use the Message::as_update() to create and update, or Message::new_update()

Fields (Non-exhaustive)§

This struct is marked as non-exhaustive

Non-exhaustive structs could have additional fields added in future. Therefore, non-exhaustive structs cannot be constructed in external crates using the traditional Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.

§metadata: Metadata

Metadata from the message header

§queries: Vec<Query>

Query name and other query parameters

§answers: Vec<Record>

Records which directly answer the query

§authorities: Vec<Record>

Records with describe other authoritative servers

May optionally carry the SOA record for the authoritative data in the answer section.

§additionals: Vec<Record>

Records which may be helpful in using the records in the other sections

§signature: Option<Box<Record<TSIG>>>

TSIG signature for the message, if any

§edns: Option<Edns>

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

Optionally returns a reference to EDNS OPT pseudo-RR

Implementations§

§

impl Message

pub fn query() -> Message

Returns a new “empty” Message

pub fn error_msg( id: u16, op_code: OpCode, response_code: ResponseCode, ) -> Message

Returns a Message constructed with error details to return to a client

§Arguments

id - message id should match the request message id
op_code - operation of the request
response_code - the error code for the response

pub fn response(id: u16, op_code: OpCode) -> Message

Returns a new Message with MessageType::Response and the given header contents

pub fn new(id: u16, message_type: MessageType, op_code: OpCode) -> Message

Create a new Message with the given header contents

pub fn truncate(&self) -> Message

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

pub fn maybe_strip_dnssec_records(self, query_has_dnssec_ok: bool) -> Message

Strip DNSSEC records per RFC 4035 section 3.2.1

Removes DNSSEC records that don’t match the query type from all sections when the DNSSEC OK bit is not set in the original query.

Uses the first query in the message to determine the query type. If there are no queries, returns the message unchanged.

The query_has_dnssec_ok is a required parameter because the dnssec_ok bit in the query might be different from the bit in the response. See discussion in #3340

pub fn add_query(&mut self, query: Query) -> &mut Message

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

pub fn add_queries<Q, I>(&mut self, queries: Q) -> &mut Message
where Q: IntoIterator<Item = Query, IntoIter = I>, I: Iterator<Item = Query>,

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

pub fn add_answer(&mut self, record: Record) -> &mut Message

Add a record to the Answer section.

pub fn add_answers<R, I>(&mut self, records: R) -> &mut Message
where R: IntoIterator<Item = Record, IntoIter = I>, I: Iterator<Item = Record>,

Add all the records from the iterator to the Answer section of the message.

pub fn insert_answers(&mut self, records: Vec<Record>)

Sets the Answer section to the specified set of records.

§Panics

Will panic if the Answer section is already non-empty.

pub fn add_authority(&mut self, record: Record) -> &mut Message

Add a record to the Authority section.

pub fn add_authorities<R, I>(&mut self, records: R) -> &mut Message
where R: IntoIterator<Item = Record, IntoIter = I>, I: Iterator<Item = Record>,

Add all the records from the Iterator to the Authority section of the message.

pub fn insert_authorities(&mut self, records: Vec<Record>)

Sets the Authority section to the specified set of records.

§Panics

Will panic if the Authority section is already non-empty.

pub fn add_additional(&mut self, record: Record) -> &mut Message

Add a record to the Additional section.

pub fn add_additionals<R, I>(&mut self, records: R) -> &mut Message
where R: IntoIterator<Item = Record, IntoIter = I>, I: Iterator<Item = Record>,

Add all the records from the iterator to the Additional section of the message.

pub fn insert_additionals(&mut self, records: Vec<Record>)

Sets the Additional to the specified set of records.

§Panics

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

pub fn set_edns(&mut self, edns: Edns) -> &mut Message

Add the EDNS OPT pseudo-RR to the Message

pub fn into_response(self) -> Message

Returns a clone of the Message with the message type set to Response.

pub fn take_all_sections(&mut self) -> impl Iterator<Item = Record>

Consume the message, returning an iterator over records from all sections

pub fn all_sections(&self) -> impl Iterator<Item = &Record>

All sections chained

pub fn max_payload(&self) -> u16

§Return value

the max payload value as it’s defined in the EDNS OPT pseudo-RR.

pub fn version(&self) -> u8

§Return value

the version as defined in the EDNS record

pub fn signature(&self) -> Option<&Record<TSIG>>

§Return value

the signature over the message, if any

pub fn take_signature(&mut self) -> Option<Box<Record<TSIG>>>

Remove signatures from the Message

pub fn read_queries( decoder: &mut BinDecoder<'_>, count: usize, ) -> Result<Vec<Query>, ProtoError>

Attempts to read the specified number of Querys

pub fn read_records( decoder: &mut BinDecoder<'_>, count: usize, is_additional: bool, ) -> Result<(Vec<Record>, Option<Edns>, Option<Box<Record<TSIG>>>), DecodeError>

Attempts to read the specified number of records

§Returns

This returns a tuple of first standard Records, then a possibly associated Edns, and then finally a Record<TSIG> if applicable.

A Record<TSIG> record is only valid when found in the additional data section. Further, it must always be the last record in that section. It is not possible to have multiple TSIG records.

RFC 8945 §5.1 says: “This TSIG record MUST be the only TSIG RR in the message and MUST be the last record in the additional data section.”