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()
Returns a new "empty" Message
Returns a Message constructed with error details to return to a client
id
- message id should match the request message id
op_code
- operation of the request
response_code
- the error code for the response
Truncates a Message, this blindly removes all response fields and sets trucation to true
see Header::set_message_type
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.
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.
Will panic if name_servers records are already associated to the message.
A an addtional Record to the message
Sets the additional to the specified set of Records.
Will panic if additional records are already associated to the message.
Add the EDNS section the the Message
Gets the header of the Message
see Header::message_type()
see Header::authoritative()
see Header::recursion_desired()
see Header::recursion_available()
see Header::authentic_data()
see Header::checking_disabled()
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.
Answer Carries RRs which directly answer the query.
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.
Remove the name servers from the Message
Additional Carries RRs which may be helpful in using the RRs in the
other sections.
Remove the additional Records from the Message
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.
Returns the EDNS record if it was found in the additional section.
If edns is_none, this will create a new default Edns.
the max payload value as it's defined in the EDNS section.
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).
The sig0, i.e. signed record, for verifying the sending and package integrity
Attempts to read the specified number of Query
s
Attempts to read the specified number of records
This returns a tuple of first standard Records, then a possibly associated Edns, and then finally any optionally associated SIG0 records.
Decodes a message from the buffer.
Encodes the Message into a buffer
Finalize the message prior to sending.
Subsequent to calling this, the Message should not change.
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.
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.
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.
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.
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.
This is the additional record section count, this section may include EDNS options.