Enum trust_dns::rr::record_data::RData

pub enum RData {
    A(Ipv4Addr),
    AAAA(Ipv6Addr),
    CNAME(Name),
    DNSKEY(DNSKEY),
    DS(DS),
    KEY(KEY),
    MX(MX),
    NULL(NULL),
    NS(Name),
    NSEC(NSEC),
    NSEC3(NSEC3),
    NSEC3PARAM(NSEC3PARAM),
    OPT(OPT),
    PTR(Name),
    SIG(SIG),
    SOA(SOA),
    SRV(SRV),
    TXT(TXT),
}

Record data enum variants

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

3.3. Standard RRs

The following RR definitions are expected to occur, at least
potentially, in all classes.  In particular, NS, SOA, CNAME, and PTR
will be used in all classes, and have the same format in all classes.
Because their RDATA format is known, all domain names in the RDATA
section of these RRs may be compressed.

<domain-name> is a domain name represented as a series of labels, and
terminated by a label with zero length.  <character-string> is a single
length octet followed by that number of characters.  <character-string>
is treated as binary information, and can be up to 256 characters in
length (including the length octet).

Variants

A(Ipv4Addr)

-- RFC 1035 -- Domain Implementation and Specification    November 1987

3.4. Internet specific RRs

3.4.1. A RDATA format

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ADDRESS                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

ADDRESS         A 32 bit Internet address.

Hosts that have multiple Internet addresses will have multiple A
records.

A records cause no additional section processing.  The RDATA section of
an A line in a master file is an Internet address expressed as four
decimal numbers separated by dots without any imbedded spaces (e.g.,
"10.2.0.52" or "192.0.5.6").

AAAA(Ipv6Addr)

-- RFC 1886 -- IPv6 DNS Extensions              December 1995

2.2 AAAA data format

   A 128 bit IPv6 address is encoded in the data portion of an AAAA
   resource record in network byte order (high-order byte first).

CNAME(Name)

  3.3. Standard RRs

The following RR definitions are expected to occur, at least
potentially, in all classes.  In particular, NS, SOA, CNAME, and PTR
will be used in all classes, and have the same format in all classes.
Because their RDATA format is known, all domain names in the RDATA
section of these RRs may be compressed.

<domain-name> is a domain name represented as a series of labels, and
terminated by a label with zero length.  <character-string> is a single
length octet followed by that number of characters.  <character-string>
is treated as binary information, and can be up to 256 characters in
length (including the length octet).

3.3.1. CNAME RDATA format

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                     CNAME                     /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

CNAME           A <domain-name> which specifies the canonical or primary
                name for the owner.  The owner name is an alias.

CNAME RRs cause no additional section processing, but name servers may
choose to restart the query at the canonical name in certain cases.  See
the description of name server logic in [RFC-1034] for details.

DNSKEY(DNSKEY)

RFC 4034                DNSSEC Resource Records               March 2005

2.1.  DNSKEY RDATA Wire Format

   The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1
   octet Protocol Field, a 1 octet Algorithm Field, and the Public Key
   Field.

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Flags            |    Protocol   |   Algorithm   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               /
   /                            Public Key                         /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.1.1.  The Flags Field

   Bit 7 of the Flags field is the Zone Key flag.  If bit 7 has value 1,
   then the DNSKEY record holds a DNS zone key, and the DNSKEY RR's
   owner name MUST be the name of a zone.  If bit 7 has value 0, then
   the DNSKEY record holds some other type of DNS public key and MUST
   NOT be used to verify RRSIGs that cover RRsets.

   Bit 15 of the Flags field is the Secure Entry Point flag, described
   in [RFC3757].  If bit 15 has value 1, then the DNSKEY record holds a
   key intended for use as a secure entry point.  This flag is only
   intended to be a hint to zone signing or debugging software as to the
   intended use of this DNSKEY record; validators MUST NOT alter their
   behavior during the signature validation process in any way based on
   the setting of this bit.  This also means that a DNSKEY RR with the
   SEP bit set would also need the Zone Key flag set in order to be able
   to generate signatures legally.  A DNSKEY RR with the SEP set and the
   Zone Key flag not set MUST NOT be used to verify RRSIGs that cover
   RRsets.

   Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon
   creation of the DNSKEY RR and MUST be ignored upon receipt.

RFC 5011                  Trust Anchor Update             September 2007

7.  IANA Considerations

  The IANA has assigned a bit in the DNSKEY flags field (see Section 7
  of [RFC4034]) for the REVOKE bit (8).

DS(DS)

5.1.  DS RDATA Wire Format

The RDATA for a DS RR consists of a 2 octet Key Tag field, a 1 octet
          Algorithm field, a 1 octet Digest Type field, and a Digest field.

                         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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Key Tag             |  Algorithm    |  Digest Type  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                                                               /
    /                            Digest                             /
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.1.1.  The Key Tag Field

   The Key Tag field lists the key tag of the DNSKEY RR referred to by
   the DS record, in network byte order.

   The Key Tag used by the DS RR is identical to the Key Tag used by
   RRSIG RRs.  Appendix B describes how to compute a Key Tag.

5.1.2.  The Algorithm Field

   The Algorithm field lists the algorithm number of the DNSKEY RR
   referred to by the DS record.

   The algorithm number used by the DS RR is identical to the algorithm
   number used by RRSIG and DNSKEY RRs.  Appendix A.1 lists the
   algorithm number types.

5.1.3.  The Digest Type Field

   The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY
   RR.  The Digest Type field identifies the algorithm used to construct
   the digest.  Appendix A.2 lists the possible digest algorithm types.

5.1.4.  The Digest Field

   The DS record refers to a DNSKEY RR by including a digest of that
   DNSKEY RR.

   The digest is calculated by concatenating the canonical form of the
   fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA,
   and then applying the digest algorithm.

     digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);

      "|" denotes concatenation

     DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.

   The size of the digest may vary depending on the digest algorithm and
   DNSKEY RR size.  As of the time of this writing, the only defined
   digest algorithm is SHA-1, which produces a 20 octet digest.

KEY(KEY)

RFC 2535                DNS Security Extensions               March 1999

3.1 KEY RDATA format

 The RDATA for a KEY RR consists of flags, a protocol octet, the
 algorithm number octet, and the public key itself.  The format is as
 follows:

                      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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             flags             |    protocol   |   algorithm   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               /
 /                          public key                           /
 /                                                               /
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

 The KEY RR is not intended for storage of certificates and a separate
 certificate RR has been developed for that purpose, defined in [RFC
 2538].

 The meaning of the KEY RR owner name, flags, and protocol octet are
 described in Sections 3.1.1 through 3.1.5 below.  The flags and
 algorithm must be examined before any data following the algorithm
 octet as they control the existence and format of any following data.
 The algorithm and public key fields are described in Section 3.2.
 The format of the public key is algorithm dependent.

 KEY RRs do not specify their validity period but their authenticating
 SIG RR(s) do as described in Section 4 below.

MX(MX)

3.3.9. MX RDATA format

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                  PREFERENCE                   |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                   EXCHANGE                    /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:

PREFERENCE      A 16 bit integer which specifies the preference given to
                this RR among others at the same owner.  Lower values
                are preferred.

EXCHANGE        A <domain-name> which specifies a host willing to act as
                a mail exchange for the owner name.

MX records cause type A additional section processing for the host
specified by EXCHANGE.  The use of MX RRs is explained in detail in
[RFC-974].

NULL(NULL)

3.3.10. NULL RDATA format (EXPERIMENTAL)

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                  <anything>                   /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Anything at all may be in the RDATA field so long as it is 65535 octets
or less.

NULL records cause no additional section processing.  NULL RRs are not
allowed in master files.  NULLs are used as placeholders in some
experimental extensions of the DNS.

NS(Name)

3.3.11. NS RDATA format

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                   NSDNAME                     /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

NSDNAME         A <domain-name> which specifies a host which should be
                authoritative for the specified class and domain.

NS records cause both the usual additional section processing to locate
a type A record, and, when used in a referral, a special search of the
zone in which they reside for glue information.

The NS RR states that the named host should be expected to have a zone
starting at owner name of the specified class.  Note that the class may
not indicate the protocol family which should be used to communicate
with the host, although it is typically a strong hint.  For example,
hosts which are name servers for either Internet (IN) or Hesiod (HS)
class information are normally queried using IN class protocols.

NSEC(NSEC)

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                           /
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NSEC3(NSEC3)

RFC 5155                         NSEC3                        March 2008

3.2.  NSEC3 RDATA Wire Format

 The RDATA of the NSEC3 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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Hash Alg.   |     Flags     |          Iterations           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Salt Length  |                     Salt                      /
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Hash Length  |             Next Hashed Owner Name            /
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 /                         Type Bit Maps                         /
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Hash Algorithm is a single octet.

 Flags field is a single octet, the Opt-Out flag is the least
 significant bit, as shown below:

  0 1 2 3 4 5 6 7
 +-+-+-+-+-+-+-+-+
 |             |O|
 +-+-+-+-+-+-+-+-+

 Iterations is represented as a 16-bit unsigned integer, with the most
 significant bit first.

 Salt Length is represented as an unsigned octet.  Salt Length
 represents the length of the Salt field in octets.  If the value is
 zero, the following Salt field is omitted.

 Salt, if present, is encoded as a sequence of binary octets.  The
 length of this field is determined by the preceding Salt Length
 field.

 Hash Length is represented as an unsigned octet.  Hash Length
 represents the length of the Next Hashed Owner Name field in octets.

 The next hashed owner name is not base32 encoded, unlike the owner
 name of the NSEC3 RR.  It is the unmodified binary hash value.  It
 does not include the name of the containing zone.  The length of this
 field is determined by the preceding Hash Length field.

3.2.1.  Type Bit Maps Encoding

 The encoding of the Type Bit Maps field is the same as that used by
 the NSEC RR, described in [RFC4034].  It is explained and clarified
 here for clarity.

 The RR type space is split into 256 window blocks, each representing
 the low-order 8 bits of the 16-bit RR type space.  Each block that
 has at least one active RR type is encoded using a single octet
 window number (from 0 to 255), a single octet bitmap length (from 1
 to 32) indicating the number of octets used for the bitmap of the
 window block, and up to 32 octets (256 bits) of bitmap.

 Blocks are present in the NSEC3 RR RDATA in increasing numerical
 order.

    Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+

    where "|" denotes concatenation.

 Each bitmap encodes the low-order 8 bits of RR types within the
 window block, in network bit order.  The first bit is bit 0.  For
 window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
 to RR type 2 (NS), and so forth.  For window block 1, bit 1
 corresponds to RR type 257, bit 2 to RR type 258.  If a bit is set to
 1, it indicates that an RRSet of that type is present for the
 original owner name of the NSEC3 RR.  If a bit is set to 0, it
 indicates that no RRSet of that type is present for the original
 owner name of the NSEC3 RR.

 Since bit 0 in window block 0 refers to the non-existing RR type 0,
 it MUST be set to 0.  After verification, the validator MUST ignore
 the value of bit 0 in window block 0.

 Bits representing Meta-TYPEs or QTYPEs as specified in Section 3.1 of
 [RFC2929] or within the range reserved for assignment only to QTYPEs
 and Meta-TYPEs MUST be set to 0, since they do not appear in zone
 data.  If encountered, they must be ignored upon reading.

 Blocks with no types present MUST NOT be included.  Trailing zero
 octets in the bitmap MUST be omitted.  The length of the bitmap of
 each block is determined by the type code with the largest numerical
 value, within that block, among the set of RR types present at the
 original owner name of the NSEC3 RR.  Trailing octets not specified
 MUST be interpreted as zero octets.

NSEC3PARAM(NSEC3PARAM)

RFC 5155                         NSEC3                        March 2008

4.2.  NSEC3PARAM RDATA Wire Format

 The RDATA of the NSEC3PARAM 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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Hash Alg.   |     Flags     |          Iterations           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Salt Length  |                     Salt                      /
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Hash Algorithm is a single octet.

 Flags field is a single octet.

 Iterations is represented as a 16-bit unsigned integer, with the most
 significant bit first.

 Salt Length is represented as an unsigned octet.  Salt Length
 represents the length of the following Salt field in octets.  If the
 value is zero, the Salt field is omitted.

 Salt, if present, is encoded as a sequence of binary octets.  The
 length of this field is determined by the preceding Salt Length
 field.

OPT(OPT)

RFC 6891                   EDNS(0) Extensions                 April 2013
6.1.2.  Wire Format

       +------------+--------------+------------------------------+
       | Field Name | Field Type   | Description                  |
       +------------+--------------+------------------------------+
       | NAME       | domain name  | MUST be 0 (root domain)      |
       | TYPE       | u_int16_t    | OPT (41)                     |
       | CLASS      | u_int16_t    | requestor's UDP payload size |
       | TTL        | u_int32_t    | extended RCODE and flags     |
       | RDLEN      | u_int16_t    | length of all RDATA          |
       | RDATA      | octet stream | {attribute,value} pairs      |
       +------------+--------------+------------------------------+

The variable part of an OPT RR may contain zero or more options in
   the RDATA.  Each option MUST be treated as a bit field.  Each option
   is encoded as:

                  +0 (MSB)                            +1 (LSB)
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    0: |                          OPTION-CODE                          |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    2: |                         OPTION-LENGTH                         |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    4: |                                                               |
       /                          OPTION-DATA                          /
       /                                                               /
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

PTR(Name)

3.3.12. PTR RDATA format

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                   PTRDNAME                    /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

PTRDNAME        A <domain-name> which points to some location in the
                domain name space.

PTR records cause no additional section processing.  These RRs are used
in special domains to point to some other location in the domain space.
These records are simple data, and don't imply any special processing
similar to that performed by CNAME, which identifies aliases.  See the
description of the IN-ADDR.ARPA domain for an example.

SIG(SIG)

RFC 2535 & 2931   DNS Security Extensions               March 1999
RFC 4034          DNSSEC Resource Records               March 2005

3.1.  RRSIG RDATA Wire Format

   The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a
   1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original
   TTL field, a 4 octet Signature Expiration field, a 4 octet Signature
   Inception field, a 2 octet Key tag, the Signer's Name field, and the
   Signature field.

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Type Covered           |  Algorithm    |     Labels    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Original TTL                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Signature Expiration                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Signature Inception                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Key Tag            |                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         Signer's Name         /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               /
   /                            Signature                          /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SOA(SOA)

3.3.13. SOA RDATA format

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                     MNAME                     /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                     RNAME                     /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    SERIAL                     |
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    REFRESH                    |
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                     RETRY                     |
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    EXPIRE                     |
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    MINIMUM                    |
    |                                               |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

MNAME           The <domain-name> of the name server that was the
                original or primary source of data for this zone.

RNAME           A <domain-name> which specifies the mailbox of the
                person responsible for this zone.

                of the zone.  Zone transfers preserve this value.  This
                value wraps and should be compared using sequence space
                arithmetic.

REFRESH         A 32 bit time interval before the zone should be
                refreshed.

RETRY           A 32 bit time interval that should elapse before a
                failed refresh should be retried.

EXPIRE          A 32 bit time value that specifies the upper limit on
                the time interval that can elapse before the zone is no
                longer authoritative.

MINIMUM         The unsigned 32 bit minimum TTL field that should be
                exported with any RR from this zone.

SOA records cause no additional section processing.

All times are in units of seconds.

Most of these fields are pertinent only for name server maintenance
operations.  However, MINIMUM is used in all query operations that
retrieve RRs from a zone.  Whenever a RR is sent in a response to a
query, the TTL field is set to the maximum of the TTL field from the RR
and the MINIMUM field in the appropriate SOA.  Thus MINIMUM is a lower
bound on the TTL field for all RRs in a zone.  Note that this use of
MINIMUM should occur when the RRs are copied into the response and not
when the zone is loaded from a master file or via a zone transfer.  The
reason for this provison is to allow future dynamic update facilities to
change the SOA RR with known semantics.

SRV(SRV)

RFC 2782                       DNS SRV RR                  February 2000

The format of the SRV RR

 _Service._Proto.Name TTL Class SRV Priority Weight Port Target

TXT(TXT)

3.3.14. TXT RDATA format

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                   TXT-DATA                    /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

TXT-DATA        One or more <character-string>s.

TXT RRs are used to hold descriptive text.  The semantics of the text
depends on the domain where it is found.

Methods

impl RData

fn parse(
    record_type: RecordType,
    tokens: &Vec<Token>,
    origin: Option<&Name>
) -> ParseResult<Self>

Parse the RData from a set of Tokens

fn read(
    decoder: &mut BinDecoder,
    record_type: RecordType,
    rdata_length: u16
) -> DecodeResult<Self>

Read the RData from the given Decoder

fn emit(&self, encoder: &mut BinEncoder) -> EncodeResult

RFC 4034, DNSSEC Resource Records, March 2005

6.2.  Canonical RR Form

   For the purposes of DNS security, the canonical form of an RR is the
   wire format of the RR where:

   ...

   3.  if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
       HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
       SRV, DNAME, A6, RRSIG, or (rfc6840 removes NSEC), all uppercase
       US-ASCII letters in the DNS names contained within the RDATA are replaced
       by the corresponding lowercase US-ASCII letters;

fn to_record_type(&self) -> RecordType

Converts this to a Recordtyp

Trait Implementations

impl From<DNSKEY> for RData

fn from(key: DNSKEY) -> RData

Performs the conversion.

impl From<KEY> for RData

fn from(key: KEY) -> RData

Performs the conversion.

impl Debug for RData

fn fmt(&self, __arg_0: &mut Formatter) -> Result

Formats the value using the given formatter.

impl PartialEq for RData

fn eq(&self, __arg_0: &RData) -> bool

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

fn ne(&self, __arg_0: &RData) -> bool

This method tests for !=.

impl Clone for RData

fn clone(&self) -> RData

Returns a copy of the value.

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

Performs copy-assignment from source.

impl Eq for RData

impl PartialOrd<RData> for RData

fn partial_cmp(&self, other: &RData) -> Option<Ordering>

This method returns an ordering between self and other values if one exists.

fn lt(&self, other: &Rhs) -> bool

This method tests less than (for self and other) and is used by the < operator.

fn le(&self, other: &Rhs) -> bool

This method tests less than or equal to (for self and other) and is used by the <= operator.

fn gt(&self, other: &Rhs) -> bool

This method tests greater than (for self and other) and is used by the > operator.

fn ge(&self, other: &Rhs) -> bool

This method tests greater than or equal to (for self and other) and is used by the >= operator.

impl Ord for RData

fn cmp(&self, other: &Self) -> Ordering

This method returns an Ordering between self and other.

fn max(self, other: Self) -> Self

🔬 This is a nightly-only experimental API. (ord_max_min)

Compares and returns the maximum of two values.

fn min(self, other: Self) -> Self

🔬 This is a nightly-only experimental API. (ord_max_min)

Compares and returns the minimum of two values.