Struct trust_dns_proto::rr::dnssec::rdata::nsec::NSEC

pub struct NSEC { /* private fields */ }

This is supported on crate feature dnssec only.

RFC 4034, DNSSEC Resource Records, March 2005

4.1.  NSEC RDATA Wire Format

   The RDATA of the NSEC RR is as shown below:

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                      Next Domain Name                         /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                       Type Bit Maps                           /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.1.3.  Inclusion of Wildcard Names in NSEC RDATA

   If a wildcard owner name appears in a zone, the wildcard label ("*")
   is treated as a literal symbol and is treated the same as any other
   owner name for the purposes of generating NSEC RRs.  Wildcard owner
   names appear in the Next Domain Name field without any wildcard
   expansion.  [RFC4035] describes the impact of wildcards on
   authenticated denial of existence.

Implementations

impl NSEC

pub fn new(next_domain_name: Name, type_bit_maps: Vec<RecordType>) -> Self

Constructs a new NSEC RData, warning this won’t guarantee that the NSEC covers itself which it should at it’s own name.

Arguments

• next_domain_name - the name labels of the next ordered name in the zone
• type_bit_maps - a bit map of the types that exist at this name

Returns

An NSEC RData for use in a Resource Record

pub fn new_cover_self(
    next_domain_name: Name,
    type_bit_maps: Vec<RecordType>
) -> Self

Constructs a new NSEC RData, this will add the NSEC itself as covered, generally correct for NSEC records generated at their own name

Arguments

• next_domain_name - the name labels of the next ordered name in the zone
• type_bit_maps - a bit map of the types that exist at this name

Returns

An NSEC RData for use in a Resource Record

pub fn next_domain_name(&self) -> &Name

RFC 4034, DNSSEC Resource Records, March 2005

4.1.1.  The Next Domain Name Field

   The Next Domain field contains the next owner name (in the canonical
   ordering of the zone) that has authoritative data or contains a
   delegation point NS RRset; see Section 6.1 for an explanation of
   canonical ordering.  The value of the Next Domain Name field in the
   last NSEC record in the zone is the name of the zone apex (the owner
   name of the zone's SOA RR).  This indicates that the owner name of
   the NSEC RR is the last name in the canonical ordering of the zone.

   A sender MUST NOT use DNS name compression on the Next Domain Name
   field when transmitting an NSEC RR.

   Owner names of RRsets for which the given zone is not authoritative
   (such as glue records) MUST NOT be listed in the Next Domain Name
   unless at least one authoritative RRset exists at the same owner
   name.

pub fn type_bit_maps(&self) -> &[RecordType]

RFC 4034, DNSSEC Resource Records, March 2005

4.1.2.  The Type Bit Maps Field

   The Type Bit Maps field identifies the RRset types that exist at the
   NSEC RR's owner name.

   A zone MUST NOT include an NSEC RR for any domain name that only
   holds glue records.

Trait Implementations

impl Clone for NSEC

fn clone(&self) -> NSEC

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for NSEC

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for NSEC

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error> where
    __D: Deserializer<'de>, 

Deserialize this value from the given Serde deserializer.

impl Display for NSEC

RFC 4034, DNSSEC Resource Records, March 2005

4.2.  The NSEC RR Presentation Format

   The presentation format of the RDATA portion is as follows:

   The Next Domain Name field is represented as a domain name.

   The Type Bit Maps field is represented as a sequence of RR type
   mnemonics.  When the mnemonic is not known, the TYPE representation
   described in [RFC3597], Section 5, MUST be used.

4.3.  NSEC RR Example

   The following NSEC RR identifies the RRsets associated with
   alfa.example.com. and identifies the next authoritative name after
   alfa.example.com.

   alfa.example.com. 86400 IN NSEC host.example.com. (
                                   A MX RRSIG NSEC TYPE1234 )

   The first four text fields specify the name, TTL, Class, and RR type
   (NSEC).  The entry host.example.com. is the next authoritative name
   after alfa.example.com. in canonical order.  The A, MX, RRSIG, NSEC,
   and TYPE1234 mnemonics indicate that there are A, MX, RRSIG, NSEC,
   and TYPE1234 RRsets associated with the name alfa.example.com.

   Assuming that the validator can authenticate this NSEC record, it
   could be used to prove that beta.example.com does not exist, or to
   prove that there is no AAAA record associated with alfa.example.com.
   Authenticated denial of existence is discussed in [RFC4035].

fn fmt(&self, f: &mut Formatter<'_>) -> Result<(), Error>

Formats the value using the given formatter.

impl Hash for NSEC

fn hash<__H: Hasher>(&self, state: &mut __H)

Feeds this value into the given Hasher.

fn hash_slice<H>(data: &[Self], state: &mut H) where
    H: Hasher, 

Feeds a slice of this type into the given Hasher.

impl PartialEq<NSEC> for NSEC

fn eq(&self, other: &NSEC) -> bool

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

fn ne(&self, other: &NSEC) -> bool

This method tests for !=.

impl Serialize for NSEC

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error> where
    __S: Serializer, 

Serialize this value into the given Serde serializer.

impl Eq for NSEC

impl StructuralEq for NSEC

impl StructuralPartialEq for NSEC