#[non_exhaustive]pub struct Metadata {
pub id: u16,
pub message_type: MessageType,
pub op_code: OpCode,
pub authoritative: bool,
pub truncation: bool,
pub recursion_desired: bool,
pub recursion_available: bool,
pub authentic_data: bool,
pub checking_disabled: bool,
pub response_code: ResponseCode,
}Expand description
Message metadata, including the message ID, flags, response code, and op code.
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.id: u16ID 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.message_type: MessageTypeQR A one bit field that specifies whether this message is a
query (0), or a response (1).op_code: OpCodeOPCODE 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.truncation: boolTC TrunCation - specifies that this message was truncated
due to length greater than that permitted on the
transmission channel.recursion_desired: boolRD 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.recursion_available: boolRA Recursion Available - this be is set or cleared in a
response, and denotes whether recursive query support is
available in the name server.authentic_data: boolRFC 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.checking_disabled: boolSee Metadata::authentic_data for more information on the CD bit.
response_code: ResponseCodeRCODE Response code - this 4 bit field is set as part of
responses. The values have the following
interpretation: <see super::response_code>Implementations§
Source§impl Metadata
impl Metadata
Sourcepub const fn new(id: u16, message_type: MessageType, op_code: OpCode) -> Self
pub const fn new(id: u16, message_type: MessageType, op_code: OpCode) -> Self
Construct a new Metadata with the given id, message_type, and op_code.
Sourcepub fn response_from_request(req: &Self) -> Self
pub fn response_from_request(req: &Self) -> Self
Construct new metadata based off the request metadata.
This copies over the RD (recursion-desired) and CD (checking-disabled), as well as the op_code and id of the request.
See https://datatracker.ietf.org/doc/html/rfc6895#section-2
The AA, TC, RD, RA, and CD bits are each theoretically meaningful
only in queries or only in responses, depending on the bit. The AD
bit was only meaningful in responses but is expected to have a
separate but related meaning in queries (see Section 5.7 of
[RFC6840]). Only the RD and CD bits are expected to be copied from
the query to the response; however, some DNS implementations copy all
the query header as the initial value of the response header. Thus,
any attempt to use a "query" bit with a different meaning in a
response or to define a query meaning for a "response" bit may be
dangerous, given the existing implementation. Meanings for these
bits may only be assigned by a Standards Action.Trait Implementations§
Source§impl PartialOrd for Metadata
impl PartialOrd for Metadata
impl Copy for Metadata
impl Eq for Metadata
impl StructuralPartialEq for Metadata
Auto Trait Implementations§
impl Freeze for Metadata
impl RefUnwindSafe for Metadata
impl Send for Metadata
impl Sync for Metadata
impl Unpin for Metadata
impl UnsafeUnpin for Metadata
impl UnwindSafe for Metadata
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