<?xml version="1.0" encoding="utf-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.nl" -->
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []>
<rfc ipr="trust200902" submissionType="IETF" category="std" xml:lang="en" consensus="yes" updates="6195" docName="draft-hunt-note-rr-02">
<?rfc toc="yes"?><?rfc symrefs="yes"?><?rfc sortrefs="yes"?><?rfc compact="yes"?><?rfc subcompact="no"?><?rfc comments="no"?>
<front>
<title abbrev="note-rr">A DNS Resource Record for Confidential Comments (NOTE RR)</title><author initials="E." surname="Hunt" fullname="Evan Hunt"><organization>ISC</organization><address><postal><street>950 Charter St</street>
<city>Redwood City</city>
<code>94063</code>
<country>US</country>
<region>CA</region>
</postal><email>each@isc.org</email>
</address></author>
<author initials="D." surname="Mahoney" fullname="Dan Mahoney"><organization>ISC</organization><address><postal><street>950 Charter St</street>
<city>Redwood City</city>
<code>94063</code>
<country>US</country>
<region>CA</region>
</postal><email>dmahoney@isc.org</email>
</address></author>
<date year="2019" month="July" day="6"></date>
<area>Internet</area><workgroup>DNSOP Working Group</workgroup>
<abstract><t>While the DNS zone master file format has always allowed comments, there is
no existing mechanism to preserve comments once the zone has been loaded
into memory or converted to a binary representation. This note proposes a
new RR type &quot;NOTE&quot;, to be allocated from the Covert-RR type range proposed
in <xref target="I-D.krecicki-dns-covert"></xref>, so that confidential comments can be stored
alongside zone data, and included in zone transfers when Covert semantics
are supported by the secondary.</t>
</abstract>

</front>

<middle>

<section anchor="introduction" title="Introduction">
<t>DNS zone master files may include comments: any text on a line following
an unquoted semicolon is ignored when parsing the file <xref target="RFC1034"></xref>. These
comments are often used by administrators to keep notes about the zone
data; for example, the purpose of a particular host, or the person
responsible for maintaining it.</t>
<t>When the zone is loaded, however, comments may be lost.  Servers which
dump backup copies of dynamically updated or automatically signed zones
may obliterate comments that were in the original zone files.  Secondary
servers do not receive comment text when transferring zones from primary
servers.</t>
<t>Comments could be stored in the zone itself as TXT RRs; these would be
preserved after zone updates and across zone transfers. However, TXT records
are available to any DNS query. Because zone file comments commonly include
information about internal networks and/or personnel that could be of use
to potential attackers, it is better for distribution of comment data to be
restricted.</t>
<t>A Covert Resource Record, as described in <xref target="I-D.krecicki-dns-covert"></xref>,
could be used for the storage of private text information within zone data
itself. This data could be transferred from primary to secondary servers
when Covert semantics are supported, and but would be concealed from normal
DNS queries (except from specific trusted DNS clients) and from secondary
servers that do not signal their support of Covert data transfer.</t>
<t>This document proposes the allocation of a new RR type NOTE from the
Covert-RR type range for this purpose. Comments that the operator wishes
to be stored and transferred with zone data can be encoded as NOTE records.
Traditional zone file comments, indicated by semicolons, would still be
ignored.</t>

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

<section anchor="the-note-rr-type" title="The NOTE RR Type">
<t>The NOTE RR is defined for all classes, with mnemonic NOTE and type code
(TBD). The RDATA and presentation formats are identical to those of the TXT
RR defined in <xref target="RFC1035"></xref>, e.g:</t>

<figure><artwork type="ascii-art">
    $ORIGIN example.com.
    joesbox   7200  IN  A       192.0.2.42
    7200            IN  AAAA    2001:DB8:3F:B019::17
              0     IN  NOTE    &quot;Desktop system for Joe Smith, x7889&quot;

</artwork></figure>

<t>The RR type code MUST be allocated from the Covert-RR type range, and
NOTE record data MUST be treated as Covert <xref target="I-D.krecicki-dns-covert"></xref>.</t>
</section>

<section anchor="iana-considerations" title="IANA Considerations">
<t>IANA is requested to allocate a DNS RR type number from the Covert-RR
type range for the NOTE RR type.</t>
</section>

<section anchor="security-and-privacy-considerations" title="Security and Privacy Considerations">
<t>NOTE data should only be accessible via Covert DNS queries, because zone
file comments commonly include information that could be of use to
potential attackers. Failure to implement the restrictions outlined in
<xref target="I-D.krecicki-dns-covert"></xref> could allow leakage of sensitive information.</t>
</section>

</middle>

<back>
<references title="Normative References">
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.krecicki-dns-covert.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"?>
</references>

</back>

</rfc>
