rama::dns::client::hickory::resolver::net::proto::rr

Enum RData

#[non_exhaustive]pub enum RData {
Show 27 variants
    A(A),
    AAAA(AAAA),
    ANAME(ANAME),
    CAA(CAA),
    CERT(CERT),
    CNAME(CNAME),
    CSYNC(CSYNC),
    HINFO(HINFO),
    HTTPS(HTTPS),
    MX(MX),
    NAPTR(NAPTR),
    NULL(NULL),
    NS(NS),
    OPENPGPKEY(OPENPGPKEY),
    OPT(OPT),
    PTR(PTR),
    SMIMEA(SMIMEA),
    SOA(SOA),
    SRV(SRV),
    SSHFP(SSHFP),
    SVCB(SVCB),
    TLSA(TLSA),
    TSIG(TSIG),
    TXT(TXT),
    Unknown {
        code: RecordType,
        rdata: NULL,
    },
    Update0(RecordType),
    ZERO,
}

Expand description

Record data enum variants for all valid DNS data types.

This is used to represent the generic Record as it is read off the wire. Allows for a Record to be abstractly referenced without knowing it’s internal until runtime.

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 (Non-exhaustive)§

This enum is marked as non-exhaustive

Non-exhaustive enums could have additional variants added in future. Therefore, when matching against variants of non-exhaustive enums, an extra wildcard arm must be added to account for any future variants.

§

A(A)

-- 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 Zone File is an Internet address expressed as four
decimal numbers separated by dots without any embedded spaces (e.g.,
"10.2.0.52" or "192.0.5.6").

§

AAAA(AAAA)

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

§

ANAME(ANAME)

2.  The ANAME resource record

  This document defines the "ANAME" DNS resource record type, with RR
  TYPE value [TBD].

2.1.  Presentation and wire format

  The ANAME presentation format is identical to that of CNAME
  [RFC1033]:

      owner ttl class ANAME target

§

CAA(CAA)

-- RFC 6844          Certification Authority Authorization     January 2013

5.1.  Syntax

A CAA RR contains a single property entry consisting of a tag-value
pair.  Each tag represents a property of the CAA record.  The value
of a CAA property is that specified in the corresponding value field.

A domain name MAY have multiple CAA RRs associated with it and a
given property MAY be specified more than once.

The CAA data field contains one property entry.  A property entry
consists of the following data fields:

+0-1-2-3-4-5-6-7-|0-1-2-3-4-5-6-7-|
| Flags          | Tag Length = n |
+----------------+----------------+...+---------------+
| Tag char 0     | Tag char 1     |...| Tag char n-1  |
+----------------+----------------+...+---------------+
+----------------+----------------+.....+----------------+
| Value byte 0   | Value byte 1   |.....| Value byte m-1 |
+----------------+----------------+.....+----------------+

Where n is the length specified in the Tag length field and m is the
remaining octets in the Value field (m = d - n - 2) where d is the
length of the RDATA section.

§

CERT(CERT)

-- RFC 4398 -- Storing Certificates in DNS       November 1987
The CERT resource record (RR) has the structure given below.  Its RR
type code is 37.

   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              |             key tag           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   algorithm   |                                               /
+---------------+            certificate or CRL                 /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

§

CNAME(CNAME)

  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.

§

CSYNC(CSYNC)

2.1.  The CSYNC Resource Record Format

2.1.1.  The CSYNC Resource Record Wire Format

The CSYNC RDATA consists of the following fields:

                    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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          SOA Serial                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Flags                   |            Type Bit Map       /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                     Type Bit Map (continued)                  /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

§

HINFO(HINFO)

3.3.2. HINFO RDATA format

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                      CPU                      /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                       OS                      /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

CPU             A <character-string> which specifies the CPU type.

OS              A <character-string> which specifies the operating
                system type.

Standard values for CPU and OS can be found in [RFC-1010].

HINFO records are used to acquire general information about a host.  The
main use is for protocols such as FTP that can use special procedures
when talking between machines or operating systems of the same type.

HINFO is also used by RFC 8482

§

HTTPS(HTTPS)

RFC 9460, SVCB and HTTPS RRs

9.  Using Service Bindings with HTTP

   The use of any protocol with SVCB requires a protocol-specific
   mapping specification.  This section specifies the mapping for the
   "http" and "https" URI schemes [HTTP].

   To enable special handling for HTTP use cases, the HTTPS RR type is
   defined as a SVCB-compatible RR type, specific to the "https" and
   "http" schemes.  Clients MUST NOT perform SVCB queries or accept SVCB
   responses for "https" or "http" schemes.

   The presentation format of the record is:

   Name TTL IN HTTPS SvcPriority TargetName SvcParams

§

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

§

NAPTR(NAPTR)

RFC 3403 DDDS DNS Database, October 2002

4.1 Packet Format

  The packet format of the NAPTR RR is given below.  The DNS type code
  for NAPTR is 35.

     The packet format for the NAPTR record is as follows
                                      1  1  1  1  1  1
        0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |                     ORDER                     |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |                   PREFERENCE                  |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      /                     FLAGS                     /
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      /                   SERVICES                    /
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      /                    REGEXP                     /
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      /                  REPLACEMENT                  /
      /                                               /
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

  <character-string> and <domain-name> as used here are defined in RFC
  1035 [7].

  ORDER
     A 16-bit unsigned integer specifying the order in which the NAPTR
     records MUST be processed in order to accurately represent the
     ordered list of Rules.  The ordering is from lowest to highest.
     If two records have the same order value then they are considered
     to be the same rule and should be selected based on the
     combination of the Preference values and Services offered.

  PREFERENCE
     Although it is called "preference" in deference to DNS
     terminology, this field is equivalent to the Priority value in the
     DDDS Algorithm.  It is a 16-bit unsigned integer that specifies
     the order in which NAPTR records with equal Order values SHOULD be
     processed, low numbers being processed before high numbers.  This
     is similar to the preference field in an MX record, and is used so
     domain administrators can direct clients towards more capable
     hosts or lighter weight protocols.  A client MAY look at records
     with higher preference values if it has a good reason to do so
     such as not supporting some protocol or service very well.

     The important difference between Order and Preference is that once
     a match is found the client MUST NOT consider records with a
     different Order but they MAY process records with the same Order
     but different Preferences.  The only exception to this is noted in
     the second important Note in the DDDS algorithm specification
     concerning allowing clients to use more complex Service
     determination between steps 3 and 4 in the algorithm.  Preference
     is used to give communicate a higher quality of service to rules
     that are considered the same from an authority standpoint but not
     from a simple load balancing standpoint.

     It is important to note that DNS contains several load balancing
     mechanisms and if load balancing among otherwise equal services
     should be needed then methods such as SRV records or multiple A
     records should be utilized to accomplish load balancing.

  FLAGS
     A <character-string> containing flags to control aspects of the
     rewriting and interpretation of the fields in the record.  Flags
     are single characters from the set A-Z and 0-9.  The case of the
     alphabetic characters is not significant.  The field can be empty.

     It is up to the Application specifying how it is using this
     Database to define the Flags in this field.  It must define which
     ones are terminal and which ones are not.

  SERVICES
     A <character-string> that specifies the Service Parameters
     applicable to this this delegation path.  It is up to the
     Application Specification to specify the values found in this
     field.

  REGEXP
     A <character-string> containing a substitution expression that is
     applied to the original string held by the client in order to
     construct the next domain name to lookup.  See the DDDS Algorithm
     specification for the syntax of this field.

     As stated in the DDDS algorithm, The regular expressions MUST NOT
     be used in a cumulative fashion, that is, they should only be
     applied to the original string held by the client, never to the
     domain name produced by a previous NAPTR rewrite.  The latter is
     tempting in some applications but experience has shown such use to
     be extremely fault sensitive, very error prone, and extremely
     difficult to debug.

  REPLACEMENT
     A <domain-name> which is the next domain-name to query for
     depending on the potential values found in the flags field.  This
     field is used when the regular expression is a simple replacement
     operation.  Any value in this field MUST be a fully qualified
     domain-name.  Name compression is not to be used for this field.

     This field and the REGEXP field together make up the Substitution
     Expression in the DDDS Algorithm.  It is simply a historical
     optimization specifically for DNS compression that this field
     exists.  The fields are also mutually exclusive.  If a record is
     returned that has values for both fields then it is considered to
     be in error and SHOULD be either ignored or an error returned.

§

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 Zone Files.  NULLs are used as placeholders in some
experimental extensions of the DNS.

§

NS(NS)

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.

§

OPENPGPKEY(OPENPGPKEY)

RFC 7929

The RDATA portion of an OPENPGPKEY resource record contains a single
value consisting of a Transferable Public Key formatted as specified
in [RFC4880].

§

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(PTR)

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.

§

SMIMEA(SMIMEA)

RFC 8162

The SMIMEA wire format and presentation format are the same as for the TLSA record

§

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.

SERIAL          The unsigned 32 bit version number of the original copy
                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 Zone File or via a zone transfer.  The
reason for this provision 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

§

SSHFP(SSHFP)

RFC 4255

3.1.  The SSHFP RDATA Format

   The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
   type and the fingerprint of the public host key.

       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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   algorithm   |    fp type    |                               /
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
       /                                                               /
       /                          fingerprint                          /
       /                                                               /
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.1.1.  Algorithm Number Specification

   This algorithm number octet describes the algorithm of the public
   key.  The following values are assigned:

          Value    Algorithm name
          -----    --------------
          0        reserved
          1        RSA
          2        DSS

   Reserving other types requires IETF consensus [4].

3.1.2.  Fingerprint Type Specification

   The fingerprint type octet describes the message-digest algorithm
   used to calculate the fingerprint of the public key.  The following
   values are assigned:

          Value    Fingerprint type
          -----    ----------------
          0        reserved
          1        SHA-1

   Reserving other types requires IETF consensus [4].

   For interoperability reasons, as few fingerprint types as possible
   should be reserved.  The only reason to reserve additional types is
   to increase security.

3.1.3.  Fingerprint

   The fingerprint is calculated over the public key blob as described
   in [7].

   The message-digest algorithm is presumed to produce an opaque octet
   string output, which is placed as-is in the RDATA fingerprint field.

The algorithm and fingerprint type values have been updated in RFC 6594 and RFC 7479.

§

SVCB(SVCB)

RFC 9460, SVCB and HTTPS RRs

2.  The SVCB Record Type

   The SVCB DNS RR type (RR type 64) is used to locate alternative
   endpoints for a service.

   The algorithm for resolving SVCB records and associated address
   records is specified in Section 3.

   Other SVCB-compatible RR types can also be defined as needed (see
   Section 6).  In particular, the HTTPS RR (RR type 65) provides
   special handling for the case of "https" origins as described in
   Section 9.

   SVCB RRs are extensible by a list of SvcParams, which are pairs
   consisting of a SvcParamKey and a SvcParamValue.  Each SvcParamKey
   has a presentation name and a registered number.  Values are in a
   format specific to the SvcParamKey.  Each SvcParam has a specified
   presentation format (used in zone files) and wire encoding (e.g.,
   domain names, binary data, or numeric values).  The initial
   SvcParamKeys and their formats are defined in Section 7.

§

TLSA(TLSA)

RFC 6698, DNS-Based Authentication for TLS

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Cert. Usage  |   Selector    | Matching Type |               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               /
   /                                                               /
   /                 Certificate Association Data                  /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

§

TSIG(TSIG)

RFC 8945, Secret Key Transaction Authentication for DNS

4.2.  TSIG Record Format

  The fields of the TSIG RR are described below.  All multi-octet
  integers in the record are sent in network byte order (see
  Section 2.3.2 of [RFC1035]).

  NAME:  The name of the key used, in domain name syntax.  The name
     should reflect the names of the hosts and uniquely identify the
     key among a set of keys these two hosts may share at any given
     time.  For example, if hosts A.site.example and B.example.net
     share a key, possibilities for the key name include
     <id>.A.site.example, <id>.B.example.net, and
     <id>.A.site.example.B.example.net.  It should be possible for more
     than one key to be in simultaneous use among a set of interacting
     hosts.  This allows for periodic key rotation as per best
     operational practices, as well as algorithm agility as indicated
     by [RFC7696].

     The name may be used as a local index to the key involved, but it
     is recommended that it be globally unique.  Where a key is just
     shared between two hosts, its name actually need only be
     meaningful to them, but it is recommended that the key name be
     mnemonic and incorporate the names of participating agents or
     resources as suggested above.

  TYPE:  This MUST be TSIG (250: Transaction SIGnature).

  CLASS:  This MUST be ANY.

  TTL:  This MUST be 0.

  RDLENGTH:  (variable)

  RDATA:  The RDATA for a TSIG RR consists of a number of fields,
     described 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                         Algorithm Name                        /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |          Time Signed          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |            Fudge              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          MAC Size             |                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+             MAC               /
      /                                                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Original ID          |            Error              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Other Len            |                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           Other Data          /
      /                                                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The contents of the RDATA fields are:

  Algorithm Name:
     an octet sequence identifying the TSIG algorithm in the domain
     name syntax.  (Allowed names are listed in Table 3.)  The name is
     stored in the DNS name wire format as described in [RFC1034].  As
     per [RFC3597], this name MUST NOT be compressed.

  Time Signed:
     an unsigned 48-bit integer containing the time the message was
     signed as seconds since 00:00 on 1970-01-01 UTC, ignoring leap
     seconds.

  Fudge:
     an unsigned 16-bit integer specifying the allowed time difference
     in seconds permitted in the Time Signed field.

  MAC Size:
     an unsigned 16-bit integer giving the length of the MAC field in
     octets.  Truncation is indicated by a MAC Size less than the size
     of the keyed hash produced by the algorithm specified by the
     Algorithm Name.

  MAC:
     a sequence of octets whose contents are defined by the TSIG
     algorithm used, possibly truncated as specified by the MAC Size.
     The length of this field is given by the MAC Size.  Calculation of
     the MAC is detailed in Section 4.3.

  Original ID:
     an unsigned 16-bit integer holding the message ID of the original
     request message.  For a TSIG RR on a request, it is set equal to
     the DNS message ID.  In a TSIG attached to a response -- or in
     cases such as the forwarding of a dynamic update request -- the
     field contains the ID of the original DNS request.

  Error:
     in responses, an unsigned 16-bit integer containing the extended
     RCODE covering TSIG processing.  In requests, this MUST be zero.

  Other Len:
     an unsigned 16-bit integer specifying the length of the Other Data
     field in octets.

  Other Data:
     additional data relevant to the TSIG record.  In responses, this
     will be empty (i.e., Other Len will be zero) unless the content of
     the Error field is BADTIME, in which case it will be a 48-bit
     unsigned integer containing the server's current time as the
     number of seconds since 00:00 on 1970-01-01 UTC, ignoring leap
     seconds (see Section 5.2.3).  This document assigns no meaning to
     its contents in requests.

§

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.

§

Unknown

Unknown RecordData is for record types not supported by Hickory DNS

Fields

§code: RecordType

RecordType code

§rdata: NULL

RData associated to the record

§

Update0(RecordType)

Update record with RDLENGTH = 0 (RFC2136)

§

ZERO

👎Deprecated:

Use None for the RData in the resource record instead

This corresponds to a record type of 0, unspecified

Implementations§

§

impl RData

pub fn record_type(&self) -> RecordType

Converts this to a Recordtype

pub fn ip_addr(&self) -> Option<IpAddr>

If this is an A or AAAA record type, then an IpAddr will be returned

pub fn read( decoder: &mut BinDecoder<'_>, record_type: RecordType, length: Restrict<u16>, ) -> Result<RData, ProtoError>

Read data from the decoder

Trait Implementations§

§

impl BinEncodable for RData

§

fn emit(&self, encoder: &mut BinEncoder<'_>) -> Result<(), ProtoError>

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;

Canonical name form for all non-1035 records: RFC 3597

 4.  Domain Name Compression

  RRs containing compression pointers in the RDATA part cannot be
  treated transparently, as the compression pointers are only
  meaningful within the context of a DNS message.  Transparently
  copying the RDATA into a new DNS message would cause the compression
  pointers to point at the corresponding location in the new message,
  which now contains unrelated data.  This would cause the compressed
  name to be corrupted.

  To avoid such corruption, servers MUST NOT compress domain names
  embedded in the RDATA of types that are class-specific or not well-
  known.  This requirement was stated in [RFC1123] without defining the
  term "well-known"; it is hereby specified that only the RR types
  defined in [RFC1035] are to be considered "well-known".

  The specifications of a few existing RR types have explicitly allowed
  compression contrary to this specification: [RFC2163] specified that
  compression applies to the PX RR, and [RFC2535] allowed compression
  in SIG RRs and NXT RRs records.  Since this specification disallows
  compression in these cases, it is an update to [RFC2163] (section 4)
  and [RFC2535] (sections 4.1.7 and 5.2).

  Receiving servers MUST decompress domain names in RRs of well-known
  type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
  NXT, NAPTR, and SRV (although the current specification of the SRV RR
  in [RFC2782] prohibits compression, [RFC2052] mandated it, and some
  servers following that earlier specification are still in use).

  Future specifications for new RR types that contain domain names
  within their RDATA MUST NOT allow the use of name compression for
  those names, and SHOULD explicitly state that the embedded domain
  names MUST NOT be compressed.

  As noted in [RFC1123], the owner name of an RR is always eligible for
  compression.

  ...
  As a courtesy to implementors, it is hereby noted that the complete
   set of such previously published RR types that contain embedded
   domain names, and whose DNSSEC canonical form therefore involves
  downcasing according to the DNS rules for character comparisons,
  consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
  HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV,
  DNAME, and A6.
  ...

§