Struct trust_dns::op::message::Message [] [src]

pub struct Message { /* fields omitted */ }

The basic request and response datastructure, 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()

Methods

impl Message
[src]

[src]

Returns a new "empty" Message

[src]

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

[src]

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

[src]

see Header::set_id

[src]

see Header::set_message_type

[src]

see Header::set_op_code

[src]

see Header::set_authoritative

[src]

see Header::set_truncated

[src]

see Header::set_recursion_desired

[src]

see Header::set_recursion_available

[src]

see Header::set_authentic_data

[src]

see Header::set_checking_disabled

[src]

see Header::set_response_code

[src]

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

[src]

Deprecated

Adds a slice of Queries to the message

[src]

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

[src]

Add an answer to the Message

[src]

Deprecated

Add an entire set of Answers

[src]

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

[src]

Sets the answers to the specified set of Records.

Panics

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

[src]

Add a name server record to the Message

[src]

Deprecated

Adds a set of name server records to the message

[src]

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

[src]

Sets the name_servers to the specified set of Records.

Panics

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

[src]

A an addtional Record to the message

[src]

Sets the additional to the specified set of Records.

Panics

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

[src]

Add the EDNS section the the Message

[src]

Add a SIG0 record, i.e. sign this message

This must be don't only after all records have been associated. Generally this will be handled by the client and not need to be used directly

[src]

see Header::id()

[src]

see Header::message_type()

[src]

see Header::op_code()

[src]

see Header::authoritative()

[src]

see Header::truncated()

[src]

see Header::recursion_desired()

[src]

see Header::recursion_available()

[src]

see Header::authentic_data()

[src]

see Header::checking_disabled()

[src]

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

[src]

Question        Carries the query name and other query parameters.

[src]

Answer          Carries RRs which directly answer the query.

[src]

Removes all the answers from the Message

[src]

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

[src]

Remove the name servers from the Message

[src]

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

[src]

Remove the additional Records from the Message

[src]

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

[src]

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

[src]

Return value

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

[src]

Return value

the version as defined in the EDNS record

[src]

Decodes a message from the buffer.

[src]

Encodes the Message into a buffer

[src]

Sign the message, i.e. add a SIG0 record to this Message.

Subsequent to calling this, the Message should not change.

Trait Implementations

impl Clone for Message
[src]

[src]

Returns a copy of the value. Read more

1.0.0
[src]

Performs copy-assignment from source. Read more

impl Debug for Message
[src]

[src]

Formats the value using the given formatter.

impl PartialEq for Message
[src]

[src]

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

[src]

This method tests for !=.

impl UpdateMessage for Message
[src]

to reduce errors in using the Message struct as an Update, this will do the call throughs to properly do that.

[src]

see Header::id

[src]

Adds the zone section, i.e. name.example.com would be example.com

[src]

Add the pre-requisite records Read more

[src]

Deprecated

Add all pre-requisites to the UpdateMessage

[src]

Add all the Records from the Iterator to the pre-reqisites section

[src]

Add the Record to be updated

[src]

Deprecated

Add the set of Records to be updated

[src]

Add the Records from the Iterator to the updates section

[src]

Add Records to the additional Section of hte UpdateMessage

[src]

Returns the Zones to be updated, generally should only be one.

[src]

Returns the pre-requisites

[src]

Returns the records to be updated

[src]

Returns the additonal records

[src]

This is used to authenticate update messages. Read more

[src]

Signs the UpdateMessage, used to validate the authenticity and authorization of UpdateMessage

impl BinSerializable<Message> for Message
[src]

[src]

Read the type from the stream

[src]

Write the type to the stream