<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version  -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>


<rfc ipr="trust200902" docName="draft-peltan-edns-presentation-format-00" category="std" consensus="true" submissionType="IETF" updates="8427">
  <front>
    <title abbrev="edns-presentation-and-json-format">EDNS Presentation and JSON Format</title>

    <author initials="L." surname="Peltan" fullname="Libor Peltan">
      <organization>CZ.NIC</organization>
      <address>
        <email>libor.peltan@nic.cz</email>
      </address>
    </author>
    <author initials="T." surname="Carpay" fullname="Tom Carpay">
      <organization>NLnet Labs</organization>
      <address>
        <email>tom@nlnetlabs.nl</email>
      </address>
    </author>

    <date />

    
    
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document describes textual and JSON representation format of EDNS option.
It also modifies the escaping rules of JSON representation of DNS messages, previously defined in RFC8427.</t>



    </abstract>



  </front>

  <middle>


<section anchor="introduction"><name>Introduction</name>

<t>A DNS record<xref target="RFC1035"/> of any type can be converted between its binary Wire format and textual Presentation format. The Wire format is used in DNS messages transferred over the Internet, while the Presentation format is used not only in Zone Files (called "master files" in the referenced document), but also to display the contents of DNS messages to humans by debugging utilities, and possible other use-cases.</t>

<t>The Presentation format can be however processed also programatically and also converted back to Wire Format unambiguously.</t>

<t>The EDNS<xref target="RFC6891"/> option pseudorecord does not appear in Zone Files, but it sometimes needs to be converted to human-readable or even machine-readable textual representation.
This document describes such a Presentation Format of the OPT pseudorecord.
It is advised to use this when displaying an OPT pseudorecord to humans.
It is recommended to use this when the textual format is expected to be machine-processed further.</t>

<t>The JSON<xref target="RFC8259"/> representation<xref target="RFC8427"/> of DNS messages is also helpful as both human-readable and machine-readable format (despite the limitation in non-preservation of the order of options, which prevents reversing the conversion unambiguosly), but it did not define JSON representation of EDNS option pseudorecord.
This document defines it.</t>

<t>The aforementioned document<xref target="RFC8427"/> also defined ambiguous and possibly conflicting rules for escaping special characters when representing DNS names in JSON.
This documents modifies and clarifies those rules.</t>

</section>
<section anchor="terminology"><name>Terminology</name>

<t>The key words "<strong>MUST</strong>", "<strong>MUST NOT</strong>", "<strong>REQUIRED</strong>",
"<strong>SHALL</strong>", "<strong>SHALL NOT</strong>", "<strong>SHOULD</strong>", "<strong>SHOULD NOT</strong>",
"<strong>RECOMMENDED</strong>", "<strong>NOT RECOMMENDED</strong>", "<strong>MAY</strong>", and
"<strong>OPTIONAL</strong>" in this document are to be interpreted as described in
BCP 14 <xref target="RFC2119"/><xref target="RFC8174"/> when, and only when, they appear in all
capitals, as shown here.</t>

<t><list style="symbols">
  <t>EDNS(0) signifies EDNS version 0.</t>
  <t>"Decimal value" means an integer displayed in decimals with no leading zeroes.</t>
  <t>Base16 is the representation of arbitrary binary data by an even number of case-insensitive hexadecimal digits (<xref section="8" sectionFormat="comma" target="RFC4648"/>).</t>
  <t>"Followed by" in terms of strings denotes their concatenation, with no other characters nor space between them.</t>
  <t>Backslash is the character called also Reverse Solidus, ASCII code 0x5c.</t>
  <t>Zero-octet is an octet with all bits set to 0, i.e. ASCII code 0x00.</t>
  <t>"Note" denotes a sentence that is not normative. Instead, it points out some non-obvious consequences of previous statements.</t>
</list></t>

</section>
<section anchor="independent"><name>Version-independent Presentation Format</name>

<t>EDNS versions other than 0 are not yet specified, but an OPT pseudorecord with version field set to value other than zero might in theory appear in DNS messages.
This section specifies how to convert such OPT pseudorecord to Presentation format.
This procedure SHOULD NOT be used for EDNS(0).
One possible exception is displaying a malformed EDNS(0) record.</t>

<t>OPT pseudorecord is in this case represented the same way as a RR of unknown type according to <xref section="5" sectionFormat="comma" target="RFC3597"/>.
In specific:</t>

<t><list style="symbols">
  <t>Owner Name is the Owner Name of the OPT record.
Note that this is always <spanx style="verb">.</spanx> (DNS Root Domain Name) unless malformed.</t>
  <t>TTL is Decimal value of the 32-bit big-endian integer appearing at the TTL position of OPT pseudorecord Wire format, see <xref section="6.1.3" sectionFormat="comma" target="RFC6891"/>.</t>
  <t>CLASS is a text representation of the 16-bit integer at the CLASS position of OPT pseudorecord Wire format (UDP payload size happens to appear there).
This will usually result in <spanx style="verb">CLASS####</spanx> (where #### will be the Decimal value), but it might also result for example in <spanx style="verb">IN</spanx> or <spanx style="verb">CH</spanx> if the value is 1 or 4, respectively.</t>
  <t>TYPE is either <spanx style="verb">TYPE41</spanx> or <spanx style="verb">OPT</spanx>.</t>
  <t>RDATA is formatted by <spanx style="verb">\#</spanx>, its length as Decimal value, and data as Base16 as per <xref section="5" sectionFormat="comma" target="RFC3597"/>.</t>
</list></t>

<t>Example:</t>

<figure><artwork><![CDATA[
. 16859136 CLASS1232 TYPE41 \# 6 000F00020015
]]></artwork></figure>

</section>
<section anchor="edns0-presentation-format"><name>EDNS(0) Presentation Format</name>

<t>The EDNS(0) Presentation Format follows RR format of the master file (<xref section="5.1" sectionFormat="comma" target="RFC1035"/>), including quotation of non-printable characters, multi-line format using round brackets, and semicolons denoting comments.</t>

<t>Depending on use-case, implementations MAY choose to display only RDATA.
In the case the resource-record-like Presentation format is desired, the following applies:</t>

<t><list style="symbols">
  <t>Owner Name MUST be <spanx style="verb">.</spanx> (DNS Root Domain Name).</t>
  <t>TTL MAY be omitted.
If it is present, it MUST be <spanx style="verb">0</spanx> (zero).
Note that this differs from DNS RR wire-to-text conversion, as well as <xref target="independent">Version-independent Presentation Format</xref>.</t>
  <t>CLASS MAY be omitted.
If it is present, it MUST be <spanx style="verb">ANY</spanx>.</t>
  <t>TYPE MUST be <spanx style="verb">EDNS0</spanx>.</t>
</list></t>

<t>RDATA consists of at least three &lt;character-string&gt;s (<xref section="5.1" sectionFormat="comma" target="RFC1035"/>), one for each field.
Each field consists of a Field-name, followed by an equal sign (<spanx style="verb">=</spanx>), followed by a Field-value.
If the Field-value is empty or omitted, the equal sign MUST be omitted as well.
For each field, the Field-name and the Field-value are defined by this document, or by the specification of the respective EDNS Option.
If it is not, a generic Field-name and Field-value from <xref target="unrecognized"></xref> applies.
However, those generics MAY be used for any Option at all times.</t>

<t>The first three fields, <xref target="eflags">Flags</xref>, <xref target="extrcode">Extended RCODE</xref>, and <xref target="udpsize">UDP Payload Size</xref> MUST always be present.
The rest of the fields are based on Options in the OPT record <xref section="6.1.2" sectionFormat="comma" target="RFC6891"/>.
They MUST be presented in the same order as they appear in wire format.
It is recommended to use the multi-line format with comments at each field, together with a more human-readable form of the contents of each option when available.
See <xref target="eexamples">Examples</xref>.</t>

<section anchor="eflags"><name>Flags</name>

<t>The first field's Field-name is <spanx style="verb">FLAGS</spanx> and its Field-value is <spanx style="verb">0</spanx> (zero) if the EDNS flags is zero.</t>

<t>Otherwise, the Field-value consists of comma-separated list of the items <spanx style="verb">BIT##</spanx>, where <spanx style="verb">##</spanx> is a Decimal value.
<spanx style="verb">BITn</spanx> is present in the list if and only if <spanx style="verb">n</spanx>-th bit (the most significant bit being <spanx style="verb">0</spanx>-th) of flags is set to <spanx style="verb">1</spanx>.
If the Flag of the bit is specified in <xref target="IANA.EDNS.Flags"/>, the Flag SHOULD be used instead of <spanx style="verb">BIT##</spanx>.
(So far, the only known Flag is <spanx style="verb">DO</spanx>.)</t>

<t>Examples:</t>

<figure><artwork><![CDATA[
FLAGS=0
]]></artwork></figure>

<figure><artwork><![CDATA[
FLAGS=DO,BIT1
]]></artwork></figure>

<figure><artwork><![CDATA[
FLAGS=BIT3,BIT7,BIT15
]]></artwork></figure>

</section>
<section anchor="extrcode"><name>Extended RCODE</name>

<t>The second field's Field-name is <spanx style="verb">RCODE</spanx> and its Field-value is <spanx style="verb">RCODE###</spanx>, where <spanx style="verb">###</spanx> stands for the DNS message extended RCODE as Decimal value, computed from both the OPT record and the DNS Message Header.
If the lower four bits of extended RCODE in DNS Message Header can not be used, the Field-value is <spanx style="verb">UNKNOWNRCODE###</spanx>, where <spanx style="verb">###</spanx> stands for the DNS message extended RCODE as Decimal value, with the lower four bits set to zero (i.e. the four-bit left shift still applies).
If the extended RCODE has been computed completely and it is listed in <xref target="IANA.RCODEs"/>, its Name should be used instead of <spanx style="verb">RCODE###</spanx>.
The Name is case-insensitive.</t>

<t>Examples:</t>

<figure><artwork><![CDATA[
RCODE=NXDOMAIN
]]></artwork></figure>
<figure><artwork><![CDATA[
RCODE=RCODE3841
]]></artwork></figure>
<figure><artwork><![CDATA[
RCODE=UNKNOWNRCODE3840
]]></artwork></figure>

</section>
<section anchor="udpsize"><name>UDP Payload Size</name>

<t>The third field's Field-name is <spanx style="verb">UDPSIZE</spanx> and its Field-value is the UDP payload size as Decimal value.</t>

</section>
<section anchor="unrecognized"><name>Unrecognized Option</name>

<t>EDNS options that are not part of this specification and their own specifications do not specify their Field-name and Field-value MUST be displayed according this subsection.
Other options (specified below or otherwise) MAY be displayed so as well.</t>

<t>Unrecognized option Field-name is <spanx style="verb">OPT##</spanx>, where <spanx style="verb">##</spanx> stands for its OPTION-CODE, and Field-value is its OPTION-VALUE displayed as Base16.</t>

</section>
<section anchor="llq-option"><name>LLQ Option</name>

<t>The LLQ (OPTION-CODE 1 <xref target="RFC8764"/>) Field-name is <spanx style="verb">LLQ</spanx> and Field-value is comma-separated tuple of LLQ-VERSION, LLQ-OPCODE, LLQ-ERROR, LLQ-ID, and LLQ-LEASE as Decimal values.
The numeric values of LLQ-OPCODE and LLQ-ERROR MAY be substituted with their textual representations listed in <xref section="3.1" sectionFormat="comma" target="RFC8764"/>.</t>

<t>Examples:</t>

<figure><artwork><![CDATA[
LLQ=1,1,0,0,3600
]]></artwork></figure>
<figure><artwork><![CDATA[
LLQ=1,LLQ-SETUP,NO-ERROR,0,3600
]]></artwork></figure>

</section>
<section anchor="nsid-option"><name>NSID Option</name>

<t>The NSID (OPTION-CODE 3 <xref target="RFC5001"/>) Field-name is <spanx style="verb">NSID</spanx> and Field-value is its OPTION-VALUE displayed as Base16.</t>

<t>It is recommended to add a comment with ASCII representation of the value.</t>

</section>
<section anchor="dau-dhu-and-n3u-options"><name>DAU, DHU and N3U Options</name>

<t>The DAU, DHU, and N3U (OPTION-CODES 5, 6, 7, respectively <xref target="RFC6975"/>) Field-names are <spanx style="verb">DAU</spanx>, <spanx style="verb">DHU</spanx>, and <spanx style="verb">N3U</spanx>, respectively, and their Field-values consist of comma-separated lists of ALG-CODEs as Decimal values or the textual representations of the ALG-CODEs (called mnemonic in the referenced documents) found in their respective IANA registries <xref target="IANA.EDNS.DAU"/><xref target="IANA.EDNS.DHU"/><xref target="IANA.EDNS.N3U"/>.</t>

<t>Examples:</t>

<figure><artwork><![CDATA[
DAU=RSASHA256,RSASHA512,ECDSAP256SHA256,ECDSAP384SHA384,ED25519
DHU=SHA-1,SHA-256,SHA-384
N3U=SHA-1
]]></artwork></figure>
<figure><artwork><![CDATA[
DAU=8,10,13,14,15
DHU=1,2,4
N3U=1
]]></artwork></figure>

</section>
<section anchor="edns-client-subnet-option"><name>Edns-Client-Subnet Option</name>

<t>The EDNS Client Subnet (OPTION-CODE 8 <xref target="RFC7871"/>) Field-name is <spanx style="verb">ECS</spanx> and if FAMILY is neither IPv4 (<spanx style="verb">1</spanx>) nor IPv6 (<spanx style="verb">2</spanx>), its Field-value is the whole OPTION-VALUE as Base16.
Otherwise, it consists of the textual IPv4 or IPv6 address (<xref section="3.4.1" sectionFormat="comma" target="RFC1035"/>, <xref section="2.2" sectionFormat="comma" target="RFC4291"/>), followed by a slash (<spanx style="verb">/</spanx>), followed by SOURCE PREFIX-LENGTH as Decimal value, followed by another slash, followed by SCOPE PREFIX-LENGTH as Decimal value.
If SCOPE PREFIX-LENGTH is zero, it MUST be omitted together with the second slash.</t>

<t>Examples:</t>

<figure><artwork><![CDATA[
ECS=1.2.3.4/24
]]></artwork></figure>
<figure><artwork><![CDATA[
ECS=1234::2/56/48
]]></artwork></figure>
<figure><artwork><![CDATA[
ECS=000520000102030405060708
]]></artwork></figure>

</section>
<section anchor="edns-expire-option"><name>EDNS EXPIRE Option</name>

<t>The EDNS EXPIRE (OPTION-CODE 9 <xref target="RFC7314"/>) Field-name is <spanx style="verb">EXPIRE</spanx> and its Field-value, if present, is displayed as Decimal value.</t>

</section>
<section anchor="cookie-option"><name>Cookie Option</name>

<t>The DNS Cookie (OPTION-CODE 10 <xref target="RFC7873"/>) Field-name is <spanx style="verb">COOKIE</spanx> and its Field-value consists of the Client Cookie as Base16, followed by a comma, followed by the Server Cookie as Base16.
The comma and Server Cookie are displayed only if OPTION-LENGTH is greater than 8.</t>

</section>
<section anchor="edns-tcp-keepalive-option"><name>Edns-Tcp-Keepalive Option</name>

<t>The edns-tcp-keepalive (OPTION-CODE 11 <xref target="RFC7828"/>) Field-name is <spanx style="verb">KEEPALIVE</spanx> and its Field-value is the TIMEOUT in seconds displayed as decimal number with exactly one decimal digit and a dot as decimal separator.</t>

</section>
<section anchor="padding"><name>Padding Option</name>

<t>The Padding (OPTION-CODE 12 <xref target="RFC7830"/>) Field-name is <spanx style="verb">PADDING</spanx> and its Field-value is its OPTION-VALUE displayed as Base16.
If the OPTION-VALUE consists only of zero-octets, it SHOULD be substituted with an alternative Field-value <spanx style="verb">[###]</spanx>, where <spanx style="verb">###</spanx> stands for OPTION-LENGTH as Decimal value.</t>

</section>
<section anchor="chain-option"><name>CHAIN Option</name>

<t>The CHAIN (OPTION-CODE 13 <xref target="RFC7901"/>) Field-name is <spanx style="verb">CHAIN</spanx> and its Field-value, the Closest trust point, is displayed as a textual Fully-Qualified Domain Name.</t>

</section>
<section anchor="edns-key-tag-option"><name>Edns-Key-Tag Option</name>

<t>The edns-key-tag (OPTION-CODE 14 <xref section="4" sectionFormat="comma" target="RFC8145"/>) Field-name is <spanx style="verb">KEYTAG</spanx> and its Field-value is displayed as a comma-separated list of Decimal values.</t>

</section>
<section anchor="extended-dns-error-option"><name>Extended DNS Error Option</name>

<t>The Extended DNS Error (OPTION-CODE 15 <xref target="RFC8914"/>) Field-name is <spanx style="verb">EDE</spanx> and the Field-value is its INFO-CODE as Decimal value.
It is recommended to add a comment with the Purpose of the given code (first presented in <xref section="5.2" sectionFormat="comma" target="RFC8914"/> and then governed by <xref target="IANA.EDNS.EDE"/>).</t>

<t>If the EXTRA-TEXT is nonempty, it MUST be displayed as another field, with Field-name <spanx style="verb">EDETXT</spanx> and Field-value being the EXTRA-TEXT string as-is.</t>

<t>Note that RFC1035-style escaping applies to all non-printable and non-ASCII characters, including some eventual UTF-8 bi-characters and possible trailing zero-octet.
Also note that any presence of spaces requires the whole &lt;character-string&gt; to be enclosed in quotes, not just the Field-value.</t>

<t>Examples:</t>

<figure><artwork><![CDATA[
EDE=18 ; Prohibited
]]></artwork></figure>
<figure><artwork><![CDATA[
EDE=6 ; DNSSEC_Bogus
"EDETXT=signature too short"
]]></artwork></figure>

</section>
</section>
<section anchor="eexamples"><name>Examples of EDNS(0) Presentation Format</name>

<t>The following examples shall illustrate the features of EDNS(0) Presentation format described above.
They may not make really sense and should not appear in normal DNS operation.</t>

<figure><artwork><![CDATA[
. 0 IN EDNS0 (
    FLAGS=DO
    RCODE=BADCOOKIE
    UDPSIZE=1232
    EXPIRE=86400
    COOKIE=36714f2e8805a93d,4654b4ed3279001b
    EDE=18 ; Prohibited
    "EDETXT=bad cookie\000"
    OPT1234=000004d2
    PADDING=[113]
    )
]]></artwork></figure>
<figure><artwork><![CDATA[
. 0 IN EDNS0 ( FLAGS=0 RCODE=BADSIG UDPSIZE=4096 EXPIRE
               NSID=6578616d706c652e636f6d2e ; example.com.
               DAU=8,10 KEEPALIVE=60.0 CHAIN=zerobyte\000.com.
               KEYTAG=36651,6113 PADDING=df24d08b0258c7de )
]]></artwork></figure>

</section>
<section anchor="jindependent"><name>Version-independent JSON representation</name>

<t>EDNS versions other than 0 are not yet specified, but an OPT pseudorecord with version field set to value other than zero might in theory appear in DNS messages.
This section specifies how to represent such OPT pseudorecord in JSON.
This procedure SHOULD NOT be used for EDNS(0).
One possible exception is displaying a malformed EDNS(0) record.</t>

<t>The OPT pseudorecord is in this case represented in JSON as on object called <spanx style="verb">EDNS</spanx> with following members:</t>

<t><list style="symbols">
  <t><spanx style="verb">NAME</spanx> - String with the Owner Name of the OPT record.
Note that this is always <spanx style="verb">.</spanx> (DNS Root Domain Name) unless malformed.
See <xref target="jsonescaping"></xref> for representing DNS names in JSON.</t>
  <t><spanx style="verb">TTL</spanx> - Integer with the 32-bit big-endian value appearing at the TTL position of OPT pseudorecord Wire format, see <xref section="6.1.3" sectionFormat="comma" target="RFC6891"/>.</t>
  <t><spanx style="verb">CLASS</spanx> - Integer with the 16-bit value at the CLASS position of OPT pseudorecord Wire format (UDP payload size happens to appear there).</t>
  <t><spanx style="verb">TYPE</spanx> - Integer with the value 41.
This member MAY be omitted.</t>
  <t><spanx style="verb">RDATAHEX</spanx> - String with the pseudorecord RDATA formatted as Base16.</t>
</list></t>

<t>Example:</t>

<figure><artwork><![CDATA[
"EDNS": {
    "NAME": ".",
    "TTL": 16859136,
    "CLASS": 1232,
    "RDATAHEX": "000f00020015"
}
]]></artwork></figure>

</section>
<section anchor="edns0-representation-in-json"><name>EDNS(0) Representation in JSON</name>

<t>The EDNS(0) OPT record can be represented in JSON as an object called <spanx style="verb">EDNS0</spanx>.
It MUST contain the three members (name-value pairs), <xref target="jflags">Flags</xref>, <xref target="jextrcode">Extended RCODE</xref>, and <xref target="judpsize">UDP Payload Size</xref>.
The rest of the members are based on Options in the OPT record <xref section="6.1.2" sectionFormat="comma" target="RFC6891"/>.
For each member, its name and value are defined by this document, or by the specification of the respective EDNS Option.
If it is not, a generic name and value from <xref target="junrecognized"></xref> applies.
However, those generics MAY be used for any Option at all times.
Note that the order of members is not preserved in JSON.</t>

<section anchor="jflags"><name>Flags</name>

<t>The JSON member name is <spanx style="verb">FLAGS</spanx> and its value is an Array of Strings <spanx style="verb">BIT##</spanx>, where <spanx style="verb">##</spanx> is a Decimal value.
<spanx style="verb">BITn</spanx> is present in the Array if and only if <spanx style="verb">n</spanx>-th bit (the most significant bit being <spanx style="verb">0</spanx>-th) of flags is set to <spanx style="verb">1</spanx>.
If the Flag of the bit is specified in <xref target="IANA.EDNS.Flags"/>, the Flag SHOULD be used instead of <spanx style="verb">BIT##</spanx>.
(So far, the only known Flag is <spanx style="verb">DO</spanx>.)</t>

</section>
<section anchor="jextrcode"><name>Extended RCODE</name>

<t>The JSON member name is <spanx style="verb">RCODE</spanx> and its value is a String containing Field-value from <xref target="extrcode"></xref>.</t>

</section>
<section anchor="judpsize"><name>UDP Payload Size</name>

<t>The JSON member name is <spanx style="verb">UDPSIZE</spanx> and its value is an Integer with UDP payload size.</t>

</section>
<section anchor="junrecognized"><name>Unrecognized Option</name>

<t>EDNS options that are not part of this specification and their own specifications do not specify their JSON member name and value MUST be displayed according this subsection.
Other options (specified below or otherwise) MAY be displayed so as well.</t>

<t>Unrecognized option JSON member name is <spanx style="verb">OPT##</spanx>, where <spanx style="verb">##</spanx> stands for its OPTION-CODE as Decimal value, and its value is a String containing its OPTION-VALUE encoded as Base16.</t>

</section>
<section anchor="llq-option-1"><name>LLQ Option</name>

<t>The LLQ (OPTION-CODE 1 <xref target="RFC8764"/>) JSON member name is <spanx style="verb">LLQ</spanx> and its value is an Object with members <spanx style="verb">LLQ-VERSION</spanx>, <spanx style="verb">LLQ-OPCODE</spanx>, <spanx style="verb">LLQ-ERROR</spanx>, <spanx style="verb">LLQ-ID</spanx>, and <spanx style="verb">LLQ-LEASE</spanx>, each representing the respective value as Integer.
Note that only numeric representation of these values is possible.</t>

<t>Example:</t>

<figure><artwork><![CDATA[
"LLQ": { "LLQ-VERSION": 1, "LLQ-OPCODE": 1, "LLQ-ERROR": 0,
         "LLQ-ID": 0, "LLQ-LEASE": 3600 }
]]></artwork></figure>

</section>
<section anchor="nsid-option-1"><name>NSID Option</name>

<t>The NSID (OPTION-CODE 3 <xref target="RFC5001"/>) JSON member name is <spanx style="verb">NSIDHEX</spanx> and its value is a String with OPTION-VALUE encoded as Base16.</t>

<t>Optionally, one more member of <spanx style="verb">EDNS0</spanx> Object MAY be added as well, with the name <spanx style="verb">NSID</spanx> and the value being a String with the OPTION-VALUE interpreted as UTF-8.
Note that in that case, JSON escaping routines (<xref section="7" sectionFormat="comma" target="RFC8259"/>) take place, possibly using the <spanx style="verb">\uXXXX</spanx> notation.</t>

</section>
<section anchor="dau-dhu-and-n3u-options-1"><name>DAU, DHU and N3U Options</name>

<t>The DAU, DHU, and N3U (OPTION-CODES 5, 6, 7, respectively <xref target="RFC6975"/>) JSON member names are <spanx style="verb">DAU</spanx>, <spanx style="verb">DHU</spanx>, and <spanx style="verb">N3U</spanx>, respectively, and their values are Arrays of Integers with ALG-CODEs.</t>

<t>Example:</t>

<figure><artwork><![CDATA[
"DAU": [ 8, 10, 13, 14, 15 ]
"DHU": [ 1, 2, 4 ]
"N3U": [ 1 ]
]]></artwork></figure>

</section>
<section anchor="edns-client-subnet-option-1"><name>Edns-Client-Subnet Option</name>

<t>The EDNS Client Subnet (OPTION-CODE 8 <xref target="RFC7871"/>) JSON member name is <spanx style="verb">ECS</spanx> and its value is an Object with following members:</t>

<t><list style="symbols">
  <t><spanx style="verb">FAMILY</spanx> - Integer with FAMILY</t>
  <t><spanx style="verb">IP</spanx> - String with the textual IPv4 or IPv6 address (<xref section="3.4.1" sectionFormat="comma" target="RFC1035"/>, <xref section="2.2" sectionFormat="comma" target="RFC4291"/>), or a String with ADDRESS encoded as Base16 if FAMILY is neither <spanx style="verb">1</spanx> or <spanx style="verb">2</spanx></t>
  <t><spanx style="verb">SOURCE</spanx> - Integer with SOURCE PREFIX-LENGTH</t>
  <t><spanx style="verb">SCOPE</spanx> - Integer with SCOPE PREFIX-LENGTH, omitted if zero</t>
</list></t>

<t>Examples:</t>

<figure><artwork><![CDATA[
"ECS": {
    "FAMILY": 1,
    "IP": "1.2.3.4",
    "SOURCE": 24
}
]]></artwork></figure>
<figure><artwork><![CDATA[
"ECS": {
    "FAMILY": 2,
    "IP": "1234::2",
    "SOURCE": 56,
    "SCOPE": 48
}
]]></artwork></figure>
<figure><artwork><![CDATA[
"ECS": {
    "FAMILY": 5,
    "IP": "0102030405060708"
    "SOURCE": 32
}
]]></artwork></figure>

</section>
<section anchor="edns-expire-option-1"><name>EDNS EXPIRE Option</name>

<t>The EDNS EXPIRE (OPTION-CODE 9 <xref target="RFC7314"/>) JSON member name is <spanx style="verb">EXPIRE</spanx> and its value is either an Integer or <spanx style="verb">null</spanx>.</t>

</section>
<section anchor="cookie-option-1"><name>Cookie Option</name>

<t>The DNS Cookie (OPTION-CODE 10 <xref target="RFC7873"/>) JSON member name is <spanx style="verb">COOKIE</spanx> and its value is an Array containing a String with the Client Cookie encoded as Base16 and, if present, another String with Server Cookie encoded as Base16.</t>

</section>
<section anchor="edns-tcp-keepalive-option-1"><name>Edns-Tcp-Keepalive Option</name>

<t>The edns-tcp-keepalive (OPTION-CODE 11 <xref target="RFC7828"/>) JSON member name is <spanx style="verb">KEEPALIVE</spanx> and its value is the TIMEOUT in seconds formatted as a Number <xref section="6" sectionFormat="comma" target="RFC8259"/> (possibly a non-Integer).</t>

</section>
<section anchor="padding-option"><name>Padding Option</name>

<t>The Padding (OPTION-CODE 12 <xref target="RFC7830"/>) JSON member name is <spanx style="verb">PADDING</spanx> and its value is a String containing Field-value from <xref target="padding"></xref>.</t>

</section>
<section anchor="chain-option-1"><name>CHAIN Option</name>

<t>The CHAIN (OPTION-CODE 13 <xref target="RFC7901"/>) JSON member name is <spanx style="verb">CHAIN</spanx> and its value is a String with the OPTION-VALUE in the form of a textual Fully-Qualified Domain Name.
See <xref target="jsonescaping"></xref> for representing DNS names in JSON.</t>

</section>
<section anchor="edns-key-tag-option-1"><name>Edns-Key-Tag Option</name>

<t>The edns-key-tag (OPTION-CODE 14 <xref section="4" sectionFormat="comma" target="RFC8145"/>) JSON member name is <spanx style="verb">KEYTAG</spanx> and its value is an Array of Integers.</t>

</section>
<section anchor="extended-dns-error-option-1"><name>Extended DNS Error Option</name>

<t>The Extended DNS Error (OPTION-CODE 15 <xref target="RFC8914"/>) JSON member name is <spanx style="verb">EDE</spanx> and its value is an Object with following members:</t>

<t><list style="symbols">
  <t><spanx style="verb">INFO-CODE</spanx> - Integer with the INFO-CODE</t>
  <t><spanx style="verb">Purpose</spanx> - String with Purpose of the INFO-CODE (<xref target="RFC8914"/>, Section 5.2)</t>
  <t><spanx style="verb">EXTRA-TEXT</spanx> - String with the EXTRA-TEXT</t>
</list></t>

<t>The EXTRA-TEXT member MUST be omitted if empty.
If its value contains non-printable or special (backslash, quote) characters, they MUST be escaped by the means of JSON Strings (<xref section="7" sectionFormat="comma" target="RFC8259"/>).</t>

</section>
</section>
<section anchor="jexamples"><name>Examples of EDNS(0) Representation in JSON</name>

<t>The following examples are the JSON representations of the examples in <xref target="eexamples"></xref>.
They may not make really sense and should not appear in normal DNS operation.</t>

<figure><artwork><![CDATA[
"EDNS0": {
    "FLAGS": [ "DO" ],
    "RCODE": "BADCOOKIE",
    "UDPSIZE": 1232,
    "EXPIRE": 86400,
    "COOKIE": [ "36714f2e8805a93d", "4654b4ed3279001b" ],
    "EDE": {
        "INFO-CODE": 18,
        "Purpose": "Prohibited",
        "EXTRA-TEXT": "bad cookie\u0000"
    },
    "OPT1234": "000004d2",
    "PADDING": "[113]"
}
]]></artwork></figure>
<figure><artwork><![CDATA[
"EDNS0": { "FLAGS": [ ], "RCODE": "BADSIG", "UDPSIZE": 4096,
           "EXPIRE": null, "NSIDHEX": "6578616d706c652e636f6d2e",
           "NSID": "example.com.", "DAU": [ 8, 10 ], "KEEPALIVE": 60.0,
           "CHAIN": "zerobyte\\000.com.", "KEYTAG": [ 36651, 6113 ],
           "PADDING": "df24d08b0258c7de" }
]]></artwork></figure>

</section>
<section anchor="jsonescaping"><name>Update Representing DNS Messages in JSON</name>

<t>This section is not related to EDNS.
This section updates <xref section="2.6" sectionFormat="comma" target="RFC8427"/>, including erratum 5439, which introduced contradicting MUSTs for escaping of backslashes.</t>

<t>In order to solve this contradiction and correctly represent a DNS name in JSON, it MUST be first converted to textual Presentation format according to <xref section="5.1" sectionFormat="comma" target="RFC1035"/> (called master file format in the referenced document), and the resulting &lt;character-string&gt; subsequently is inserted into JSON as String (<xref section="7" sectionFormat="comma" target="RFC8259"/>).</t>

<t>Note that the previous paragraph prescribes the following escaping strategy:
In the first step every problematic character (non-printable, backslash, dot within Label, or any octet) is either substituted with the sequence <spanx style="verb">\DDD</spanx>, where <spanx style="verb">DDD</spanx> is the three-digit decimal ASCII code, or in some cases (backslash, dot, any printable character) just prepended with a backslash.
In the second step, every quote (<spanx style="verb">"</spanx>) and backslash (<spanx style="verb">\</spanx>) in the resulting &lt;character-string&gt; is prepended with another backslash.
Note that the JSON escaping sequence <spanx style="verb">\uXXXX</spanx> (where <spanx style="verb">XXXX</spanx> is a hexadecimal Unicode code) is thus never needed.</t>

<t>Moreover, following requirements from <xref target="RFC8427"/> still hold:
The name MUST be represented as an absolute Fully-Qualified Domain Name.
Internationalized Domain Name (IDN) labels MUST be expressed in their A-label form, as described in <xref target="RFC5890"/>.</t>

<t>Example: the name with the Wire format <spanx style="verb">04005C2E2203646F6D00</spanx> can be represented in JSON as:</t>

<figure><artwork><![CDATA[
"NAME": "\\000\\\\\\046\".com."
]]></artwork></figure>

<t>but also as (among other ways):</t>

<figure><artwork><![CDATA[
"NAME": "\\000\\092\\.\\\".c\\om."
]]></artwork></figure>

</section>
<section anchor="iana"><name>IANA Considerations</name>

<t>None.</t>

</section>
<section anchor="security"><name>Security Considerations</name>

<t>None.</t>

</section>
<section anchor="acknowledgements"><name>Acknowledgements</name>

<t>TODO</t>

</section>
<section anchor="implementation-status"><name>Implementation Status</name>

<t><strong>Note to the RFC Editor</strong>: please remove this entire appendix before publication.</t>

<t>None yet.</t>

</section>
<section anchor="change-history"><name>Change History</name>

<t><strong>Note to the RFC Editor</strong>: please remove this entire appendix before publication.</t>

<t><list style="symbols">
  <t>edns-presentation-format-00</t>
</list></t>

<ul empty="true"><li>
  <t>Initial public draft.</t>
</li></ul>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference anchor='RFC1035' target='https://www.rfc-editor.org/info/rfc1035'>
<front>
<title>Domain names - implementation and specification</title>
<author fullname='P. Mockapetris' initials='P.' surname='Mockapetris'><organization/></author>
<date month='November' year='1987'/>
<abstract><t>This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System.  It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.</t></abstract>
</front>
<seriesInfo name='STD' value='13'/>
<seriesInfo name='RFC' value='1035'/>
<seriesInfo name='DOI' value='10.17487/RFC1035'/>
</reference>



<reference anchor='RFC6891' target='https://www.rfc-editor.org/info/rfc6891'>
<front>
<title>Extension Mechanisms for DNS (EDNS(0))</title>
<author fullname='J. Damas' initials='J.' surname='Damas'><organization/></author>
<author fullname='M. Graff' initials='M.' surname='Graff'><organization/></author>
<author fullname='P. Vixie' initials='P.' surname='Vixie'><organization/></author>
<date month='April' year='2013'/>
<abstract><t>The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders.  This document describes backward-compatible mechanisms for allowing the protocol to grow.</t><t>This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations.  It also obsoletes RFC 2673 (&quot;Binary Labels in the Domain Name System&quot;) and adds considerations on the use of extended labels in the DNS.</t></abstract>
</front>
<seriesInfo name='STD' value='75'/>
<seriesInfo name='RFC' value='6891'/>
<seriesInfo name='DOI' value='10.17487/RFC6891'/>
</reference>



<reference anchor='RFC8259' target='https://www.rfc-editor.org/info/rfc8259'>
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
<author fullname='T. Bray' initials='T.' role='editor' surname='Bray'><organization/></author>
<date month='December' year='2017'/>
<abstract><t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format.  It was derived from the ECMAScript Programming Language Standard.  JSON defines a small set of formatting rules for the portable representation of structured data.</t><t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t></abstract>
</front>
<seriesInfo name='STD' value='90'/>
<seriesInfo name='RFC' value='8259'/>
<seriesInfo name='DOI' value='10.17487/RFC8259'/>
</reference>



<reference anchor='RFC8427' target='https://www.rfc-editor.org/info/rfc8427'>
<front>
<title>Representing DNS Messages in JSON</title>
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'><organization/></author>
<date month='July' year='2018'/>
<abstract><t>Some applications use DNS messages, or parts of DNS messages, as data.  For example, a system that captures DNS queries and responses might want to be able to easily search them without having to decode the messages each time.  Another example is a system that puts together DNS queries and responses from message parts.  This document describes a general format for DNS message data in JSON.  Specific profiles of the format in this document can be described in other documents for specific applications and usage scenarios.</t></abstract>
</front>
<seriesInfo name='RFC' value='8427'/>
<seriesInfo name='DOI' value='10.17487/RFC8427'/>
</reference>



<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></author>
<date month='March' year='1997'/>
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></author>
<date month='May' year='2017'/>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>



<reference anchor='RFC4648' target='https://www.rfc-editor.org/info/rfc4648'>
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author fullname='S. Josefsson' initials='S.' surname='Josefsson'><organization/></author>
<date month='October' year='2006'/>
<abstract><t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes.  It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4648'/>
<seriesInfo name='DOI' value='10.17487/RFC4648'/>
</reference>



<reference anchor='RFC3597' target='https://www.rfc-editor.org/info/rfc3597'>
<front>
<title>Handling of Unknown DNS Resource Record (RR) Types</title>
<author fullname='A. Gustafsson' initials='A.' surname='Gustafsson'><organization/></author>
<date month='September' year='2003'/>
<abstract><t>Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software.  This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3597'/>
<seriesInfo name='DOI' value='10.17487/RFC3597'/>
</reference>



<reference anchor='RFC8764' target='https://www.rfc-editor.org/info/rfc8764'>
<front>
<title>Apple's DNS Long-Lived Queries Protocol</title>
<author fullname='S. Cheshire' initials='S.' surname='Cheshire'><organization/></author>
<author fullname='M. Krochmal' initials='M.' surname='Krochmal'><organization/></author>
<date month='June' year='2020'/>
<abstract><t>Apple's DNS Long-Lived Queries (LLQ) is a mechanism for extending the DNS protocol to support change notification, thus allowing clients to learn about changes to DNS data without polling the server.  From 2005 onwards, LLQ was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations.  In 2020, the LLQ protocol was superseded by the IETF Standards Track RFC 8765, &quot;DNS Push Notifications&quot;, which builds on experience gained with the LLQ protocol to create a superior replacement. </t><t>The existing LLQ protocol deployed and used from 2005 to 2020 is documented here to give background regarding the operational experience that informed the development of DNS Push Notifications, and to help facilitate a smooth transition from LLQ to DNS Push Notifications.</t></abstract>
</front>
<seriesInfo name='RFC' value='8764'/>
<seriesInfo name='DOI' value='10.17487/RFC8764'/>
</reference>



<reference anchor='RFC5001' target='https://www.rfc-editor.org/info/rfc5001'>
<front>
<title>DNS Name Server Identifier (NSID) Option</title>
<author fullname='R. Austein' initials='R.' surname='Austein'><organization/></author>
<date month='August' year='2007'/>
<abstract><t>With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query.  While existing ad-hoc mechanisms allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable way to obtain the identity of the name server that responded is to have the name server include this information in the response itself. This note defines a protocol extension to support this functionality.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5001'/>
<seriesInfo name='DOI' value='10.17487/RFC5001'/>
</reference>



<reference anchor='RFC6975' target='https://www.rfc-editor.org/info/rfc6975'>
<front>
<title>Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC)</title>
<author fullname='S. Crocker' initials='S.' surname='Crocker'><organization/></author>
<author fullname='S. Rose' initials='S.' surname='Rose'><organization/></author>
<date month='July' year='2013'/>
<abstract><t>The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures.  These digital signatures can be generated using different algorithms.  This document specifies a way for validating end-system resolvers to signal to a server which digital signature and hash algorithms they support.  The extensions allow the signaling of new algorithm uptake in client code to allow zone administrators to know when it is possible to complete an algorithm rollover in a DNSSEC-signed zone.</t></abstract>
</front>
<seriesInfo name='RFC' value='6975'/>
<seriesInfo name='DOI' value='10.17487/RFC6975'/>
</reference>



<reference anchor='RFC7871' target='https://www.rfc-editor.org/info/rfc7871'>
<front>
<title>Client Subnet in DNS Queries</title>
<author fullname='C. Contavalli' initials='C.' surname='Contavalli'><organization/></author>
<author fullname='W. van der Gaast' initials='W.' surname='van der Gaast'><organization/></author>
<author fullname='D. Lawrence' initials='D.' surname='Lawrence'><organization/></author>
<author fullname='W. Kumari' initials='W.' surname='Kumari'><organization/></author>
<date month='May' year='2016'/>
<abstract><t>This document describes an Extension Mechanisms for DNS (EDNS0) option that is in active use to carry information about the network that originated a DNS query and the network for which the subsequent response can be cached.  Since it has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement.</t></abstract>
</front>
<seriesInfo name='RFC' value='7871'/>
<seriesInfo name='DOI' value='10.17487/RFC7871'/>
</reference>



<reference anchor='RFC4291' target='https://www.rfc-editor.org/info/rfc4291'>
<front>
<title>IP Version 6 Addressing Architecture</title>
<author fullname='R. Hinden' initials='R.' surname='Hinden'><organization/></author>
<author fullname='S. Deering' initials='S.' surname='Deering'><organization/></author>
<date month='February' year='2006'/>
<abstract><t>This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol.  The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.</t><t>This document obsoletes RFC 3513, &quot;IP Version 6 Addressing Architecture&quot;.   [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4291'/>
<seriesInfo name='DOI' value='10.17487/RFC4291'/>
</reference>



<reference anchor='RFC7314' target='https://www.rfc-editor.org/info/rfc7314'>
<front>
<title>Extension Mechanisms for DNS (EDNS) EXPIRE Option</title>
<author fullname='M. Andrews' initials='M.' surname='Andrews'><organization/></author>
<date month='July' year='2014'/>
<abstract><t>This document specifies a method for secondary DNS servers to honour the SOA EXPIRE field as if they were always transferring from the primary, even when using other secondaries to perform indirect transfers and refresh queries.</t></abstract>
</front>
<seriesInfo name='RFC' value='7314'/>
<seriesInfo name='DOI' value='10.17487/RFC7314'/>
</reference>



<reference anchor='RFC7873' target='https://www.rfc-editor.org/info/rfc7873'>
<front>
<title>Domain Name System (DNS) Cookies</title>
<author fullname='D. Eastlake 3rd' initials='D.' surname='Eastlake 3rd'><organization/></author>
<author fullname='M. Andrews' initials='M.' surname='Andrews'><organization/></author>
<date month='May' year='2016'/>
<abstract><t>DNS Cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification/ forgery or cache poisoning attacks by off-path attackers.  DNS Cookies are tolerant of NAT, NAT-PT (Network Address Translation - Protocol Translation), and anycast and can be incrementally deployed. (Since DNS Cookies are only returned to the IP address from which they were originally received, they cannot be used to generally track Internet users.)</t></abstract>
</front>
<seriesInfo name='RFC' value='7873'/>
<seriesInfo name='DOI' value='10.17487/RFC7873'/>
</reference>



<reference anchor='RFC7828' target='https://www.rfc-editor.org/info/rfc7828'>
<front>
<title>The edns-tcp-keepalive EDNS0 Option</title>
<author fullname='P. Wouters' initials='P.' surname='Wouters'><organization/></author>
<author fullname='J. Abley' initials='J.' surname='Abley'><organization/></author>
<author fullname='S. Dickinson' initials='S.' surname='Dickinson'><organization/></author>
<author fullname='R. Bellis' initials='R.' surname='Bellis'><organization/></author>
<date month='April' year='2016'/>
<abstract><t>DNS messages between clients and servers may be received over either UDP or TCP.  UDP transport involves keeping less state on a busy server, but can cause truncation and retries over TCP.  Additionally, UDP can be exploited for reflection attacks.  Using TCP would reduce retransmits and amplification.  However, clients commonly use TCP only for retries and servers typically use idle timeouts on the order of seconds.</t><t>This document defines an EDNS0 option (&quot;edns-tcp-keepalive&quot;) that allows DNS servers to signal a variable idle timeout.  This signalling encourages the use of long-lived TCP connections by allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time.</t></abstract>
</front>
<seriesInfo name='RFC' value='7828'/>
<seriesInfo name='DOI' value='10.17487/RFC7828'/>
</reference>



<reference anchor='RFC7830' target='https://www.rfc-editor.org/info/rfc7830'>
<front>
<title>The EDNS(0) Padding Option</title>
<author fullname='A. Mayrhofer' initials='A.' surname='Mayrhofer'><organization/></author>
<date month='May' year='2016'/>
<abstract><t>This document specifies the EDNS(0) &quot;Padding&quot; option, which allows DNS clients and servers to pad request and response messages by a variable number of octets.</t></abstract>
</front>
<seriesInfo name='RFC' value='7830'/>
<seriesInfo name='DOI' value='10.17487/RFC7830'/>
</reference>



<reference anchor='RFC7901' target='https://www.rfc-editor.org/info/rfc7901'>
<front>
<title>CHAIN Query Requests in DNS</title>
<author fullname='P. Wouters' initials='P.' surname='Wouters'><organization/></author>
<date month='June' year='2016'/>
<abstract><t>This document defines an EDNS0 extension that can be used by a security-aware validating resolver configured to use a forwarding resolver to send a single query, requesting a complete validation path along with the regular query answer.  The reduction in queries potentially lowers the latency and reduces the need to send multiple queries at once.  This extension mandates the use of source-IP- verified transport such as TCP or UDP with EDNS-COOKIE, so it cannot be abused in amplification attacks.</t></abstract>
</front>
<seriesInfo name='RFC' value='7901'/>
<seriesInfo name='DOI' value='10.17487/RFC7901'/>
</reference>



<reference anchor='RFC8145' target='https://www.rfc-editor.org/info/rfc8145'>
<front>
<title>Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)</title>
<author fullname='D. Wessels' initials='D.' surname='Wessels'><organization/></author>
<author fullname='W. Kumari' initials='W.' surname='Kumari'><organization/></author>
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'><organization/></author>
<date month='April' year='2017'/>
<abstract><t>The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures.  These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS.  This document specifies two different ways for validating resolvers to signal to a server which keys are referenced in their chain of trust.  The data from such signaling allow zone administrators to monitor the progress of rollovers in a DNSSEC-signed zone.</t></abstract>
</front>
<seriesInfo name='RFC' value='8145'/>
<seriesInfo name='DOI' value='10.17487/RFC8145'/>
</reference>



<reference anchor='RFC8914' target='https://www.rfc-editor.org/info/rfc8914'>
<front>
<title>Extended DNS Errors</title>
<author fullname='W. Kumari' initials='W.' surname='Kumari'><organization/></author>
<author fullname='E. Hunt' initials='E.' surname='Hunt'><organization/></author>
<author fullname='R. Arends' initials='R.' surname='Arends'><organization/></author>
<author fullname='W. Hardaker' initials='W.' surname='Hardaker'><organization/></author>
<author fullname='D. Lawrence' initials='D.' surname='Lawrence'><organization/></author>
<date month='October' year='2020'/>
<abstract><t>This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs.</t></abstract>
</front>
<seriesInfo name='RFC' value='8914'/>
<seriesInfo name='DOI' value='10.17487/RFC8914'/>
</reference>



<reference anchor='RFC5890' target='https://www.rfc-editor.org/info/rfc5890'>
<front>
<title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title>
<author fullname='J. Klensin' initials='J.' surname='Klensin'><organization/></author>
<date month='August' year='2010'/>
<abstract><t>This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version.  It describes the document collection and provides definitions and other material that are common to the set.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5890'/>
<seriesInfo name='DOI' value='10.17487/RFC5890'/>
</reference>




    </references>

    <references title='Informative References'>

<reference anchor="IANA.EDNS.Flags" target="https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-13">
  <front>
    <title>EDNS Header Flags</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="IANA.RCODEs" target="https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6">
  <front>
    <title>DNS RCODEs</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="IANA.EDNS.EDE" target="https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#extended-dns-error-codes">
  <front>
    <title>EDNS Extended Error Codes</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="IANA.EDNS.DAU" target="https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml">
  <front>
    <title>DNS Security Algorithm Numbers</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="IANA.EDNS.DHU" target="https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1">
  <front>
    <title>DNSSEC DS RR Type Digest Algorithms</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="IANA.EDNS.N3U" target="https://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml#dnssec-nsec3-parameters-3">
  <front>
    <title>DNSSEC NSEC3 Hash Algorithms</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>


    </references>



  </back>

<!-- ##markdown-source:
H4sIAHRjfmMAA+U8+3Paxrq/81fsJTPnmowg4mGM3fGdQw1uuHXANbgnbZI5
CJCxEiFRPeLQjPu33++xK+0KkaSnTc+de9Npglar3W+/90uq1+uVxEt890wM
B+OpuI7c2A0SJ/HCQDjBSvz3dDIWl2G0cZKKs1hE7vsz4a6CuL7VZtZhZv1t
DD/ueOYqXAbOBhZdRc5dUt+6fuIE9f3neHrdtisrJ4HpHwf92fCxUlnC1TqM
dmciTlYVbxudiSRK46Rl26d2q/LO3T2E0epMjILEjQI3qQ9wn0oMu6z+6fhh
AGvt3LgSp4uNF8ew1Wy3hbHRcHZZSbe4WXwmep3WSaXipMl9GJ1VRL0i4I8X
wJ2rhrgmmGmIj3LlLcJIHw6j9Zm4+LkxHl3QtbtxPP9M+DivwUf+e+AtG8tf
jbVnDXHhRFtnp609Czf6IK08voKDiStnEeurJ+Hm74EPd3y40Qj8SsULGIve
excOIUb9cb+BtGxc+s46PqOHEydau8mZuE+SbXz27NnDw0PDcwKnATs9cwBB
62ADRImfEYWcCIACxBYvGx/uk43/xBysN9u8hcZFz11n5UaCAKgomG4uJoPh
XwBPVwcHoeGNKwZuhoPhV4DE/ZC4wcpd1fGuG0VhVF+GKzfeQ9BQThRDnCQu
aJIB4KB/+y8AGLvLuuOv60G6WSgoC2MMahFHU3eZRl6yE30f5M5L7jdizPML
YD3/3WDF9SiqJyB+xm9Fu3yk3iwANR1eiAGQ70ag8IqBt3bjJAewANm4/S8g
DHETwF/tAmnLxnNuK7tbb5dAP4a/2uK5E98bYNfrdQHSm0TOMqlUZvdeLEBh
pgiVAEZYRt7CjUUC3JQ6fq6FI1fXnYKlXoR3zFLhFkcblVEiHD8OxSZceXce
rnPvCljU2XrBWkSpD0PwTNmKMIwrbdw4dgDXloC7770wjf0dwHXnBcCwXiBu
Li9Qczb4IBtvtfLdSuUJKuMoXKVLXKtS6dNakbsERf3x43/AQ027ffz4iLs4
wU4gzcXSCcQC/gmD926UwPILN3lw3UB4SSwWXuBEO/EPL3LVYREXCi/X+8ho
iBkcVn8AUJvGDLZ+NLAmThDfgYjCvRD2Jiwpa2KJh3vPd2msZJds0SAE9AeA
HFj9Z7A54tJD7B4tHd+H29WNE8OC4g5HqzgJF4xc2NYNljBBEb1miUUqyZaE
YuXFW9/Z0WzATILMWqQNzrtPN3AIsUDiLNL1GumbJp7vJR4SD3G1DYHfF3CU
EBaLEOr60olB+pDtyg8nSXIfPriIl20ULmFPgJbAg8s1sDw8gYfc0SZ0QyOh
s3yH4BEZ2HMQKZi5hbdOiZfk5si1zBjd3mkTGYM4WGxjN12FzDiAIjgr4tnZ
bl0nMjHNaPMSEYcghN4Gp7ruipBjcJVCVj0Cw+QQPiIBxwvExlneA1/nNxR3
maLROCilcbq8F46JyctMMpGEk+uZcSYSUVjMWb33YgYO6AJTYezhHmCS9Edy
Ai2Kj+eUVwvh+GbD9mRvMYRAnSlnX/fD1l1KzACmFBZyYt+lEXKMJBUqCyZV
r3V8CqQysSNvgU5g8TYYFU+KDHLv+tu7FNQZcCxwY5EgyEh7xJAAHwG6t17C
Aul7G0/iGZghACeSQIneZzoMZwGigHnhgpkqJpEGSqFGI3nCf6MYcSzFjC5h
gYxVgVNrGYetPBZ3VoOHtKemiAskL7IPrgK4SSSCHTipi7fgSU0xGIglLCo1
nImTLuY7PMed74EGzlT9HXK60v4xUN0DRljeO2h74MTMJNlJcBKeAb3SGPGL
By1AH+emBfde+k6kDE0IrEfbNtAezNxo4wWhH653fEpw2wX67bGoPn364nY6
e/q0aqnfYjzJrm+GP9yOboYDvK7A9fR5/+pK3aQLffb0+eT2amBeqfsVWu1i
8uLFcDwYZpPgrigZftH/iX7CufBBEL3RZNzHnVl76zR0QLux9HhoNgCBKE/A
3Uo3oNGpfHtxLZodwYRsNZsgPJKozZMOEBXRz6qaDAlfAkfuNIUHiraCBEyA
AyzcIQblHIBARS7g+Slx3ZFdE+jZMCWIDxVD2zSpOgDSb4D27x0/dasgn2g7
nICgX4OsSK3DtnLFk4E9wGUBxhc+iCQyx69uFBJ5n4pvwZA0uyjfbNaKwuBE
Cw/MLFhwacgh6nLQWsGmpHvZIcWpaJPqEBy5QexhHANn++BIGACwNXoDR4y3
TrfTs9BdpW16j481Pt5l6PtgssD87JhYwHxkNcHNAsCRLCC/7A55EQoKxpgB
QWtlx2QzqYlHAOITb52lm3kmMGMjz798F/vo20kUZI8J6QCQxN6QonHFNPS9
VQoE7E8vRiOBcYGwPxwvaa2fAa31EJ5lywD4o98EFqwFGAQMxDACHGdbwmu4
DXMdW1J5DGesZmd1BFIEnQ0AkDU/KrFAxYsNcHnARXFWFuq4beiRp5GyQSXd
Gi7IAUR8xe4vKS5FWFWeIaAX0EhqAQAAof+RuQ6ouXK3aJNAVMqM48cn2gyI
+HWWjSUdAGZgX5I0BHsH5ycNBjy+ki5TiX0kpCnmh6n+SmGOWF9fG7kZHNj1
fSK9szDSBU+3Y1IJxpLxFBwxOkq4tnQ22B8os9ll7iqvSVZ3lcIpc92FeoV8
TNTfUsAblQmYnsylcz8sXTY1qJY0nwHsqI8bYHgpVYMyQ5U9yLw4U20ohbkc
o3MATB2DJRAP4I06yE4QiwHx0+BdgBqIXHhnieuQIQ2lnmsfn57kMgo+P3gq
GcqWZ8iok4cAiDDGxaX0aCOa46QAR75mHiZQyakAqGIxb8zFEUX5IbDIINw4
cBxcpQZggiWKc2yQhMxmV/i0oQ3Vhu1WHQQNhG1dB770NOXIPEHYTWgqLgOU
8JSy28OrFoRYwDWuyF3dHDXdRrPRRvQAYBdX/emUDkb+WolCxX2bXQIxg4uh
4We/FB5xdDu4Fltn54cOyIb3K+hbPGBAjrNkfxQStyY59MEDHZTGKbn8AFXq
k8DMad8n8Ado8IAPCLzg6Qt21wxE5/4UCx0pSLkeOSofnM3Wd2nt0XiOXvr8
4vlceHx4JhbA08Q7HQsfRT8WNBlFFUDdn66H5N96JORzvO40eSFAyZwm3Qz6
sz7OYnRQzLIT89dP5hbFnb4brFHvFriEzTQZMbglrR/82sJGB/m+MuQjAdP/
9ttvlQYQsHd82mx3mWbNVrslGEjx+onoCtu2L+H/lm03j+kJUKlKiEvUaB5J
HZgAZ0S7GKPk3hlhiRacKtuKAboGfwOCMqCYFyz9lAT8lzTMuZE9b2BE8tRz
k2mJDZDTq/voJ8stU3K0ozAFBC5g3js3kQFq7G68JbiIgTTQOI+jGTIoA7IQ
OIieuYxeASRE6UYdNRbgtwEEIbqfWvxMHhURm/QPmWgndqW7EodptMRYA8UD
oH13MNYHhw6EZ0V+mcQnaYLt1gcDUFRn5MsC8x9WTJkeQrBhZggBTYLqaXSH
okEWgQAhq5ytZ8N6aLBqe9oQvPE7dFbuonDDGc8bkMHIrSdhnXRJHt6Q//jg
+hSHvfpCY/3mSDfWNU1d/b4T9Mc/zXMxzYaRfW28wYKJroYXc8oDTgieZ4zn
jECH/s1Pvsk4rc6e3d/WyTfxpzk4ZE4ULsSX7BE0KsPst7mhuMSxOgZAliQ2
6wf0Wn/BKBrdbHE0P5/XChPko6QsCBXIL9oYKabNNtmhOpIoY6bSFlZYkfcV
uRqVS+MAlrY4wsqZscJ+6DipgHGxM+MXC4FYcJJJWWbD0uS6lcOJicovKhKD
tAI3ibULrO8ti7DocBBfvkoDlDUIUX51V8BR+mVNCVOj8pzzTpaMJuXqseK0
zCfCFCKDhEyCPjIlgGQ8fedFGdMQvkDdvKJyBOzs3uEPoN6rLA1PJQK89SGJ
0KOusXZ6hYbyWhrKKUCKcK+2aDJrTCnphQBkkuMbtH+EmWqJSN6fiLFwEHwA
mSGPVU4w93QOugkttCYzDAwVh+R+mlyFXDVOfDhxMYh8yO3/J/NGbon6Jo9a
aWVEt8GH4dolY8vBitiAx1FM7uA6Ch16RpPWkfkSSkQ47x3Px0calSmQ7pW0
nkQ16RzEqH/AySBqQhjB1HzU6U6Q/WessyQcd3551f9uOifCopkvSGauX5W7
QWxPq+N9vIUONJ71wUMrVBQ3XY8gtpx67GKBAEnkezlDeBAwwX7fjmZP0OVg
x2mOThR5f4bT0ajgvGCu6VRFblrSu8uTB/B7HszrQAV0EY+IliHMkXmBpRMk
dGfhovmC88LUGgKVnVHGSfPmPNdfcE8BvmDBz2IwhOTjx0LB8fHRyh+UAY0S
XI+jTVxPHr9ROZqG4s6J+CE6BwcX9DzSZTCZN2qZIxVLT4qIeW6zj5QPDCYW
LNwsDsNYG2+c0F3lWT0RpgJAbpIKQPIThHshoPcAQ9FDhxmKbj8xaQxEpiI1
J+bIQc6DTOGa4Ox7oMBW2xT5iVQq5VEL+kPZAVz2hVyWy7EZSdFigeMH/g/n
FVAQzY1l7Gs+T5UBjMMlNfcFAA99O/5+PPnH+CucnfRLGfySaymYP6LUCDtq
aUSxku/egQzce/h3gpGJtDW1DCGFre8xRY2pngzb+MN3E1cWPFgMUP4MGeA6
M/I/QkXOYHwfpv6qlP8zDLHFUKFwMRXW2ON8evB8/HIwedEfjWkoH6a/271O
szCukwVu25kEFC0cyIC0cFIEwGuIDkoAPD0d/XxYBhC7e8FmkbSsz281f0BZ
9o+Gl6CyRDKlzw6wSg6BopUKNtdQy7yNhbN+qFeMe+gP0eM8upPzPuHLKOub
p0u1BAjtnS5kkqjBxiKD9yhXnAsXmJjcQGVOasrDyReG2Djz/ioGeqTJLBAD
tEDRoGjyhtThhHYdmcDaOxmmVfI5P/avbof6KVXIy9S6uvpBEom5BK+PtOUh
RJd57pNuB5zwIqwwf14GQdFuJinmA4Cu8ED9x+HNFDaw6GJyzcfA38Obm8kN
/xwN+GT4+2rYn+5rkpgFLgA3GP1WHlNb8KrZCrSwogxSNvES0ghKGQGzlFcM
Tf2gMJH7dG2MTfaFGzY9b1pNy4b/2l3bzsSYbyBM0+Hs9toaT+SptXlImPF0
NDAoQwMGadoSoGPbbpaQBh8opc0Xckepc+msYJLyIRl7nL8uT3NpemHQv7XE
4PktQTRu3yrfmU+n7lrZbf2oUwHRYNcSJ2aqSDnZpyfH5vnZS5/DoiBGc1h2
zuvOYeG5uYalqRUNT7HyAg85gcRp/avvCL54nzmFNI2HuEoiKF9BdRtsAncT
BsDQh/sM4hpaxUAFDAC5FuShCYPrtYdhNcChO3aAEKxbGW1A5gAgqIyd4cHz
m2l/+rzfOu5a/Ou42bKGF4Np/xrG5B2+BsME1/C3NRy0jo+bpxXY5xyG6k0L
/8aZ+C/MqMCGfCeTENyrZzVtq9m2mh0LvDx8umm1LJ7dzL0+bIu6AB8gSOrT
dIFtdrrEkJHh20LeNuSnJ/nnpHdSJj/DCxVk3InL/ovR1U8ULcuU5Oj6fUcc
gYddo9oSXHbhsoXJhAP28+E+9F1T8DRx0+IRLzFCEJ2LaFe1HchihInx0pxJ
u9FBzWTJM3ZaeiDawjB0L+3BRbCj+bNiRmQ6ub25GIrrm+Hl6CVo4/F3s+cl
jp2ZZeHyDK1ZWO1icv25xcilK5soAzgjH6VSLGYEm+RuPwGxz9RA4HMIyBuA
qmetTsZ/NNxqd87OWs+Ou886PeOObdvHLfjLbtotu2137GO7a5/YvZwpqS/w
5fXoZrjPjXLcYMNTxYbtZpmF5UdKPTMLWTPP0MWmIi/xzS7C8J3nGmCRjPCw
afftXDraJWBdTCbfjw44jEXulTIot8mYvsh/pGbNQXx66kbYwFR8mq0/PUNA
FKZFugemwmp5wJyX1pHrJKqK2GvkWmW23Na/d0Hj+6hTdYRR83MCt99lt03E
NTPEtXoliPt+OLzuX41+/LSzPRu9GE5uZ6jhmYkLxFVFdVl7J453PzjLxN9R
mtQounN3F5iPRH9U2rMw4mNfgzpB5zdz2bc8IMMHdds8ays7a9suOet1fzAY
jb87eNIv80RGWRkxn5izGJIW+OzXrPIek3LIMxZ77p6DrRjYIUi1cwOm+SuI
5N4cDnZNBjogZM8hnDNYhkdMzCnn7eS01HmjRw4IPYtUGGNukrrpueK/rwGc
zG5cpr6/q/8APzlu0coYGtN/7+7qM2e9z+7v4EbiFImv2mF6zY5meMp02PfD
n2b9w2xQAPpQzq3o/RuJH9Ku1IRtKN392+YZjtUZTsuVr8oLlaRI8CCj8eWk
XprnOJCcLfGfqTs1jbaYJpcKc+29p7TFCnQLp0KNJHEOsl4jaWFvGYMaiDU2
w8p6ge7fwYG41UYK1fDl7KZfn8E/XAoIqLBhmFeTOtKuy6QxHUDDGSJs9nK2
H3ZwrrKwIxd+YNm6h+TMq2HSm6nHyc7Xmp5lwofw6PuFyiXuiCOynUarY+aF
T2qHocZBFIrb2WW9JxZeXesTMpptk8jxfNUtxcqlUeljrTvIQMX6BRNnSeSj
JiMk+y+pF7m653eo6CW7z2ABlGkiMBZosS0WMxpv0zgpsl+JLzMYnjd74htx
HYX33sIDTsndFrjXhVvczP7Pb8N1GleqTKlzTCo7SUpNcCHmuaKkmhWs5R6q
JfJQbfpjntRX+fusuqpuwNJIM8/3U2yYl02gdy7tfXgHWbnIe/GcRYjJNKqg
bJwdoWjjvMM4iboaMOHGzCBzdmbTMbVM+YLTT24km4JlTd8GeSYwbHFEbwGo
XDRdcALu2/6AXR8ak3kz9BdbNMDe2nmv24FYHgd48nm7e9Ls3LXcXs8+dk7b
K6vTPe4sOu6q3QILYDcX/HQJFXFcEWvhYA4THZzX4IFW6R6oM/RW0TG17c6K
wZCG9/xVs9l+QyO1jB3Mc8oz2vnxpqPvsnN17NOuPBOtov3B9MJ59/ik1212
Vyd2d9k9brnddveuu2q5cARJ+AboukbxWRXiicwZOu/aDZsN5TlK22KX0BlL
H2dzAjjtHjetLhwxO+/qrtVZ2b2F3TruLU9AfdYUL5eVyMu6fz8+eft/q6Et
O9+BljazOfiv7GGblTTVf7KPTYKKdghTTIu3cGbVo0ndB3PGca59Ni69+0S9
HfNx/wVY87qYstnJjO9f0bFGVVB8s1IZszdHT/TLGiH3c/3beIrZ7AoPMZKd
Y9kp9pveZPPA12954/6xUqhkn5sE5at3uRGCfroelsLCQHSaktWZN/ZaX3AJ
amB5PnxZxi0GnNzpkvef6flTs2OsivxZPRMfWaEjL8JVtVG1eACoAteqq0wO
EqZwGMyLHFKg4cOgH+9Uk1m18ljsM7sxNZvkIrPVTKs4yheGDgicUypw2O4z
kq4iNgQ4MmnJHRtS+sQRsrF0BLcO+LM1rYvj7eEujrdf0MbxVvVx7DdsqO3/
jI6NrGuHF+UkX1ZY+je06RT25tact4XenLdfqzlHV4raSzoK47I/Xb7Q42pG
Ru/4eKt3fBCfSZE81OmRhV7AjP0ocijwn8r3Av5wHwav+P+nEaOsbeJtoW+i
lCqFdomcKkpXSk2AP/fbx9QOepdW41AJ+61Zwy4FZ692rbOJYQSKhuRTBeu3
/56K9d4JcxH/31SxLiXE76pbH2jL/ixD7aUMIW4OV39CYbv0SFl5u8hXE7aF
xFZK68212jbWHfM6tLqiSq+6GA1UVTKrccMAGRnDDyxYB2lrYsXaujImaVcF
8dKKbOyq+iQqQOm+7zsrABH6KqKqHQn9EItH+FTaAB0Mrm0rj9WqfEga5Qs6
I1xjoVs8/pFSdymx8DFy2g4zEtHrs+zDsGA6gXuOqRVS7oaalj0fxQNSepzV
Km/z1bqcOC+WF+NzT5TNhrMfj+jwFV5KpJyVTnIyXvS6N5YOCS/5RwLCNKH3
U4/yl35z3+YEEZlg6gSkfgkPZ2+fptn7tPPX6Uv4M0dNpXIlf0ktv0jgf7Gi
L3kdnyXzTokmKTjypcisAr8vBbAbcOsr0bNEE3i42Yb/OxYmjd/Azed8E0Sg
ZYkODgEsPAQXX6lGXcr4eaX6E1rqQFDMle29eImHccLouiwK+koFafQ5jb36
g8HNEKLFPTEtr8rP5TtCrTmCznXrvbOVlbNpOtab92fvV6GtrOTsceFpLx1b
BZLkwR7DSeqSB0bXGL7J2rOKABksuNHqyFjuEyu1zJW4XL230rEKJOkQMNDp
fX7pY2PpYp27Wtii3ao8/nm173L2LlTA85cwmOiam4e0D1Lfn//xencpKMWq
935Eorkq+5rdLITv8zQsa9b0VblFX8gsdB9wf/7sInYpNkpK2Z8rYhupEkd+
m0iUmafu46M4ykySQ7UdSeZaWcX695SpS0+zV6z+nYGNrJdDXCN/1f5IPbic
/cyq8AH/psSHkJ3U/PbGF5aF/6SU5Z9fXD7Ai2aJuTRXoCz/16kdlyuv8lD5
i2xzVl0uTWdmd3GqLCAXTXWhrpyXq4900I0qcg2Xy4u0ZcY/vysxlZd0VVK1
0JoFOo0KyzKfpTAh5SkulHLpWw38hZOjhfo6g8VV0ZpR2k30F6mIMfO+If4y
hvpElkoTHXSFG4cqnuVpVE6WfK7oSR8XuS/9zkzWHZVNhpVfZYXUwptSX6He
SRlpW3MAMNlG/mt1MKmKNyrhLEO9alb5VG6GTLyY+Wk21jBGJVCVx+bnaO1i
JRS/2FIshua7D2nvj1lUWc1YGLft5eFmVbI6QppXT6vahJxLcY5WSk3trJj6
KLeVRVWZZKe6qjq1NBN4i6qrVcOjUijV0fnGMrE4HX2Hh87Rh1VWSy9y5lhE
ZwbmytAWFzhUcq2aK+ATOF0vw+KuRkxDoGVWHMaxCmuuQyYHF8qqsllZtkoP
o9qlFbkcK6ge+8ZcRMNZsUJbzRIB4pa+55nLm7IoL7JPUOWip9mhx4pZAZXJ
58j1HfllLMqlmpPkt0OVBu+0TvRgpEsv/2RtIy7YjyTdiONO+1R9gMqTH8mj
t4rgt7OSn2tCbVT4XBMIeqbGqHFpFMicOQAXh/57+aEvbSGZPFyGUeRSU19e
xnUyM6sQYrTrcL+Q8c20T3xpr+yzHyUvX+fd6drXBtSb9Z/6Hp7KePDHIXCb
g20wlL7ET9PgcakMHPMJANVhVoeStuhTatwsTmRfuMF2snXkbOnjYdnHGU29
nX1gi1pU1rsz9cEBxiqcfYv9QxH2/IRgqugDetoHg44MQ2YJzXph9yVaUEDX
lbNwfQ52gx1/IqimxTNl76cI9dUeMX89GAzyLCteKH+bqm51bvlUXZ7514Vo
Q3TFsQmKvh5oWNcV1Zeom2nvYxA17kICvG3ZJZLvCGePZx9mUB3XgChLYorM
tjiaV+c1YofsIRh7DWMZ/3yWQ7hmY4Ag4yMNEJP6ZkJMQ6LMa8nPncz5ilxp
/ZtVt4FHXXhUpWA0p5htwAAMP1FIBeMXYeSGVE7LOUn2f/Gb1hQfGN+A4xcY
70N/dcYvMelfnNArsFx5dRagJYAfPu2w82cvHc5dUrZeuy2ORoNxTfjIenHu
Mn3AreLs3XMvEv06zSHptorfQVNp2N6pbXwVJc90Zgyrl/DnNvgCxxetYatl
t7ud7mV3YNvzT1ecVSZFVcrJ7rymP3an+7rKJohtR/bVTQD3yNmEqHP5TQBn
F9cOrGSftl6/bsBysNTr1/liT/gVmgvsMF5JlwnLlfjt2UfULgEVjvJP7e7N
jOUdfXZ/iVU4UKFrZgowWpPBhHYzPoICCg5sDdx++pQ5OSRsAtIhjPKSMHr6
9Exs8WMaiLhNqGwH2suIuz2ClfcB8IqfIhTbdOHLilODocFuJYLo4t4J8KVg
L4ZVd19nw6cl3xjPvxVe+S+IarwE/Xx+jD8zjh8gwy/SolBX/gcSSI7m2VwA
AA==

-->

</rfc>

