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


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>


<rfc ipr="trust200902" docName="draft-fujiwara-dnsop-ranking-data-01" category="std" consensus="true" submissionType="IETF" updates="2181" tocDepth="4" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="ranking">Clarifications to the DNS Ranking Data</title>

    <author initials="K." surname="Fujiwara" fullname="Kazunori Fujiwara">
      <organization abbrev="JPRS">Japan Registry Services Co., Ltd.</organization>
      <address>
        <postal>
          <country>Japan</country>
        </postal>
        <email>fujiwara@jprs.co.jp</email>
      </address>
    </author>
    <author initials="W." surname="Toorop" fullname="Willem Toorop">
      <organization>NLnet Labs</organization>
      <address>
        <postal>
          <street>Science Park 400</street>
          <city>Amsterdam</city>
          <code>1098 XH</code>
          <country>Netherlands</country>
        </postal>
        <email>willem@nlnetlabs.nl</email>
      </address>
    </author>

    <date year="2026" month="March" day="02"/>

    <area>operations</area>
    
    <keyword>Internet-Draft</keyword>

    <abstract>


<?line 44?>

<t>This document obsoletes Section 5.4.1 (Ranking data) of RFC 2181,
and specifies directives whereby the source of the data determines for what purposes it may be used.</t>



    </abstract>



  </front>

  <middle>


<?line 49?>

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

<t>The DNS server assumed in Section <xref target="RFC2181" section="5.4.1" sectionFormat="bare">Ranking data</xref> of <xref target="RFC2181"/> is considered to
be a model with a shared database described in Section <xref target="RFC1035" section="2.2" sectionFormat="bare">Common configurations</xref> of <xref target="RFC1035"/> that
has both Authoritative server and Recursive Resolver functions.
It is assumed that information obtained from zone files, zone transfers,
and name resolution will be mixed together.</t>

<t>However, at the time of writing, this is no longer the practice of name servers and resolvers.
Zone transfers transfer the same data from primaries to
secondary servers without any modification.
An authoritative name server function does not mix and return information
obtained from name resolution.</t>

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

<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" 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>

<?line -18?>

<t>Many of the specialized terms used in this document are defined in
DNS Terminology <xref target="RFC9499"/>.</t>

</section>
<section anchor="problem-statement"><name>Problem Statement</name>

<t>In the past, recursive resolvers would return data from referral responses, such
as delegation information or glue, in the answer section of responses;
however, modern recursive resolvers complete name resolution
with an authoritative response from an authoritative server
that has authority through delegation.
However, there is no clear documentation of this.</t>

<t>"The Ranking Data" only indicates the priority among data, not its validity.
Attacks using responses that do not correspond to queries
and additional data that is not required have been considered and reported,
so unnecessary data should be discarded.</t>

<t><xref target="RFC1034"/> already describes resolver's answer as follows.</t>

<t>"The ideal answer is one from a server authoritative for the query which
either gives the required data or a name error.  The data is passed back
to the user and entered in the cache for future use if its TTL is
greater than zero." (Quoted from RFC 1034, Section 5.3.3)</t>

<t>"The simplest mode for the client is recursive,
since in this mode the name server acts in the role of a resolver
and returns either an error or the answer, but never referrals."
(Quoted from RFC 1034, Section 4.3.1)</t>

<t>Currently, responses from authoritative servers are considered to include
authoritative name resolution results (NXDOMAIN, NODATA, the RRSet requested),
non-authoritative delegation information,
unnecessary data, and other types of errors,
and each of these is considered to affect how resolvers handle the data.
Therefore, directives on how to handle the data are needed.</t>

</section>
<section anchor="directives"><name>Directives</name>

<t><list style="numbers" type="1">
  <t>Authoritative servers <bcp14>MUST NOT</bcp14> merge zone data. (zone data should be
  retrieved from a source (zone file, internal database, zone
  transfer)</t>
  <t>Name resolution results (Answer section, or NXDOMAIN, NODATA)
  <bcp14>MUST</bcp14> be authoritative responses from authoritative servers
  that has authority through delegation.</t>
  <t>Non-authoritative responses (referral/delegation responses) from
  authoritative servers <bcp14>MUST</bcp14> only be used to query the delegated
  authoritative server during the name resolution.</t>
  <t>Names and IP addresses of the authoritative name servers for zones (such as the root zone) that are built-in or loaded from "hints" files, <bcp14>MUST</bcp14> only be used for priming a resolver for those zones <xref target="RFC9609"/>.</t>
  <t>Multi-function name server  <vspace blankLines='1'/>
Name servers with multiple functions will act as
an Authoritative, Recursive Resolver (Full-Service Resolver),
or Forwarder depending on the namespace to which the query name belongs,
the server IP address, the "Recursion Desired" bit, etc.
The data handled by each function <bcp14>MUST</bcp14> be separated.</t>
</list></t>

</section>
<section anchor="additional-considerations"><name>Additional Considerations</name>

<t>[ Further directives could be made,
they may be DNS software implementation guidelines,
which would be large in scale,
so it is necessary to consider whether to proceed with them. ]</t>

<t><list style="symbols">
  <t>If a DNS server plays different roles for different namespaces
(authoritative server, recursive resolver, forwarder), it <bcp14>MUST NOT</bcp14>
 merge DNS data for each role.  <vspace blankLines='1'/>
For example, a recursive resolver that returns a fixed zone
as a split-horizon DNS can be interpreted as
acting as an authoritative server below a certain domain name,
but as a recursive resolver otherwise.</t>
  <t>The Additional Section returned as the result of name resolution
<bcp14>MUST</bcp14> be exactly the same as the Additional Section that came from
the authoritative response from the authoritative server, or a
separate authoritative response resulting from name resolution.</t>
  <t>Full-service resolvers <bcp14>SHOULD</bcp14> only accept the following data
from authoritative servers:  <list style="symbols">
      <t>NS and DS RRSets (+RRSIG) in the Authority Section
of the delegation response and Glue A/AAAA in the Additional Section,</t>
      <t>SOA RRs (+RRSIG) in the Authority Section
of authoritative NXDOMAIN and NODATA responses in response to the query,</t>
      <t>the Answer Section (+RRSIG) of the authoritative response
in response to the query, and</t>
      <t>any additional sections allowed by type (delegated domain name),</t>
    </list>
and <bcp14>SHOULD NOT</bcp14> accept any other information.</t>
</list></t>

</section>
<section anchor="iana"><name>IANA Considerations</name>
<t>This document requests no IANA actions.</t>

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

</section>


  </middle>

  <back>


    <references title='Normative References' anchor="sec-normative-references">



<reference anchor="RFC2181">
  <front>
    <title>Clarifications to the DNS Specification</title>
    <author fullname="R. Elz" initials="R." surname="Elz"/>
    <author fullname="R. Bush" initials="R." surname="Bush"/>
    <date month="July" year="1997"/>
    <abstract>
      <t>This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="2181"/>
  <seriesInfo name="DOI" value="10.17487/RFC2181"/>
</reference>

<reference anchor="RFC1035">
  <front>
    <title>Domain names - implementation and specification</title>
    <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/>
    <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="RFC2119">
  <front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    <author fullname="S. Bradner" initials="S." surname="Bradner"/>
    <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">
  <front>
    <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
    <author fullname="B. Leiba" initials="B." surname="Leiba"/>
    <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="RFC9499">
  <front>
    <title>DNS Terminology</title>
    <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
    <author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
    <date month="March" year="2024"/>
    <abstract>
      <t>The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.</t>
      <t>This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="219"/>
  <seriesInfo name="RFC" value="9499"/>
  <seriesInfo name="DOI" value="10.17487/RFC9499"/>
</reference>

<reference anchor="RFC1034">
  <front>
    <title>Domain names - concepts and facilities</title>
    <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/>
    <date month="November" year="1987"/>
    <abstract>
      <t>This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.</t>
    </abstract>
  </front>
  <seriesInfo name="STD" value="13"/>
  <seriesInfo name="RFC" value="1034"/>
  <seriesInfo name="DOI" value="10.17487/RFC1034"/>
</reference>

<reference anchor="RFC9609">
  <front>
    <title>Initializing a DNS Resolver with Priming Queries</title>
    <author fullname="P. Koch" initials="P." surname="Koch"/>
    <author fullname="M. Larson" initials="M." surname="Larson"/>
    <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
    <date month="February" year="2025"/>
    <abstract>
      <t>This document describes the queries that a DNS resolver should emit to initialize its cache. The result is that the resolver gets both a current NS resource record set (RRset) for the root zone and the necessary address information for reaching the root servers.</t>
      <t>This document obsoletes RFC 8109.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="209"/>
  <seriesInfo name="RFC" value="9609"/>
  <seriesInfo name="DOI" value="10.17487/RFC9609"/>
</reference>




    </references>




  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA5VY7XbbxhH9j6fYsj8qNSAjynJqs2kSVrJiJfqKKJ8kTXJ6
lsCSXBvAIruAGNrH79Jn6ZP1ziwWBESqaX3sY3CBnc87d2Z3OBxGla4yNRGn
mbR6oRNZaVM4URlRrZQ4u56JO1m808VSnMlKRnI+t+phIqxfjFKTFDLH/tTK
RTVc1G/1Wlo5TAtnymHz1TDF1uHROIpcJYv0nzIzBbZUtlZRpEvLj646Pjp6
eXQcSavkRJhSWW9L9G49ERdFpWyhquEZ6Ylg5kS4Ko0SfKAKV7tGnKuwO8f3
r+7Po7qEYoVXx+MXUF7qSSTgWTIRG+X8Y6rKajURJ/jljMXmhQtv3Sbf/oxk
Xa2MJQFD/BNCF3jz7UicNx7zog/Ft/J9XRir+++MXU7EN7KUhbhTSw1DN2Km
7INOlBOnZhSLyyod8achyN/c3s14QeVSZxMRovvV29K6UWJGb0t+nZi6gLhG
fN/E70fi3hhryo6B3+ssU3l3nY27vkSAxaWcO16jUCqEeZZoVSRK3Er7Tpwc
HXmVuoK+ae6QllTmjRkphI+PXr4QP7zuG3atgCabIfmu69CaDfmqyKA4g95R
kUURQpcj8w9qAnAUi86v4XCI2MAumVRRdL/STgB/da6KSpi5M5lCthHUhHAj
no9ORmNxEOBLGDwUZiHuzk8ZEHEEc4QrVQLcY1+qLe18wOMaxqr5hkvAmdrC
e2ykXyRFpNBjc13gS5iHr2UlytqWxmFFVyKXGzFXonYKCWWrc52mGcAOGFuT
1t7AD3/UnZ8fo7/RH/LL150DOJQV0jl4mCKb4sOH3/PtD3COfPv4USA4VBw6
hSspoB7BIily5ChD3KsVfriVpHe0ey4dnFMusXr+WNnx6FgcnJo8xzNELvSy
bkqz1Tk+evYcOitEIlpJJ+YGCqZcMrri9LXuIOZ3Kqmto8U7hazR8qIuWJkb
RRcV2R7cJpGihQEsMPNKIvSpWFiTi/dgErHQmXKxfwY4CrdQ1vn0EuCFJS01
7ybEUW5y/RtHZcnARJZem7WCIbGAOkp0pXNO+hoOIMQxFmEV/hZGgL6WsJk+
KwmL2uODdXk3HftpG+/g1D96trVPHmG0j4HFLpVW5+BiRSQcOYWIpxJcEQRT
7kxdQcGGstly9iiaFkL2Qt4xqA0wKkaRExWFoLGyqm3RjXHUj/GjGCJYACkX
gMnMcgMcV9tfDYy3UH6nNmJtbOrE4OrN7H4Q+//F9Q0/37367s3F3aszep69
nl5etg9R88Xs9c2by7Pt03bn6c3V1avrM78Zq6K3FA2upj/iDfk4uLm9v7i5
nl4OCNpVjzlQA9TuAApNTaZEPOC5dFGvHP5+evvvf41PUBa+xsYvgXf/48X4
Lyf4AdIovDZTZJvmJ/K7iWRZKmlJigT6ElkiQRkAi0JxK7MuBNENwvrnnygy
v0zE5/OkHJ980SyQw73FELPeIsdsd2Vnsw/inqU9atpo9tYfRbpv7/TH3u8Q
987i519mwJYYjl98+QWQdEVAbtiVyVhm+j3VJjDlmEP3pyxVC4aoLiJiyx4g
OS0vT14iRwjrrTVz6nczlIWi/VuIbqF6Ufh6lq6KAfZAUG0JA8N11hbLtlox
IihrZUZfljSMIK+uTlYRkguqVUvPWj0Gs2KZ1Sr2foGVC7dGhbqGbhGLVtZf
o1XgJWJuaN5nWmLyknrf40qNPM8/poUg3Tuw89oTRsTES1we3lI7tKZerjp+
jba8STyqGoJMMsJ7SJcMblESkY8B0UJ3qhz4itFFSlxGxMfMqr1Wib7jW1zM
vKUrJx4AkhQvQXpVJZN3BBSS1gbO943U8I7EWP+CGF/8WitiV24PMoUUWIf8
cUp9t/H8aNWvtab+uJKIylypottQPXOWmBlVGkfOiLooFEY5R1zNslDahBjw
SqpdIm3K04DHJvolUYbMMK2mm7bxujapf3IBFpKGjCwz6zZ0sAD2Nq9hLLdA
TmXbZHsJpRmFIkqOEy9poFNpypdY8rhDL1tv2XbskB5NALexIyHuw/ADhSgS
Kss5Ah81BwXUqe/tijg01KwC2SUrb8GiRuXwh0IvOIn395eQFi0Rg4pbIaD4
XlkzGoiD72pThf5DAxsFLO6Mds9Gzw6bcDhN6HcVV0jrbJJpYgrtthWDNGka
ZAOd8Pf0bbdPop27YLzFREm4lW1aom3DdKKJIazmIIlGs09MLOZo0gXVRssR
bjSIfsezE3g2hmenNSBbVNkm7mDaJ3lPsTpmxN64Bx+SrE5VtGck6MxDeKwz
eHxw/cPZzdX04jpGGzib3k+5oMXd3Uz5SkCAVXoYYzovhn2R+1kujh4XRNMb
OWbVpoQ/CC1HrpnVFLDSdAKnduZXIRcLBEmAEDvUB8xgsG5H8xGNHAi3saDX
zkAP22gfpDzawIErlPLFedbu2NcixqO9I60ToUmLXNml8nMoWyMO2uctHeAA
BASBgh4CDGQ4ZBy042zsh5FATDSe+wGXjq3N8AiYHI/E9VMZnfbaSkzwfJzk
Q0hj4+lssLdH/DfQkSn/W5OInsHOHeBsdRyECvm0A6b29SHbAG37oc8OcANp
zlyB5P35rZGo0icEiLS21DpaIuhNuic+wH6ev7ilhoH3zoOXq/2pidufDSll
8I8mAmJyzypoLrR+6MNHCJzXOquGmmeDzMg0IGOwAgzcIJxwdl0lHXRgIA+2
NNWwIM6jjQHNRPTZkZ+Ino/EFUCih+2poGN4RCf0664jPEbktAFEuz2q+cMU
CJOGZbq2KPr1Ee876B2c11k2bC4+2mUQC99CiHNj19QqkRZVKgwE8MsUbXJc
KROe1rmLdboa2z9XdDJzLIvHSZ/gbdo8qQ0asyD3TDlqegMx1xj7VJXwBUzb
6zxZoGg3npzacIWicaqUlsCFoE63s8RpQ1zNBdYeLvn5J3FeW+bCDk0lYWLI
AYE4osNDuEzgGwGzqNYEF+5429FqWUMZDdVw3QdmHQRlkhgJwMIEkikeVLSf
cFpuRjQD0dKhxfOzAapMAl70ycdiPhI//4Izirighti5oCgzuaHbE9AztSzu
mh7827U2dwSUg31luG/ojkmKh8NhTHYHoqUkea4lO/wwDn2cI1I/Igyf08pv
kkIVc208Fu/LL3RziOA7gYZkidNwHsl0NSRb3xNYoCsByHdPioKqgEvQPTVP
MzjXkJkoS4drzKY5/UeRIcDStMA699jJPXOtHZ8RPTw7YAujg3eEDWomOmoE
7cVE51ggtqyPACWYMrb3EM3mPfI5Wgl909DxHv7rHy1234dc03xJEkL9PCXG
+0CRfeImAuFgQnENoWwng+ZQy2wpk0SV/l7Hz9Lh0oxseLrB0W2vGAqkndj/
bObHIdD5J3i4+PowzInTtvk1seI7zvbKcLelsbyvcQYU00+n+NMK2ol67E2Y
3Uyh/P/R3HcoNH5W7Ht/p/3qjmXNPM+s2ihnRX6YCFho7djbBYMwb8yT0skY
r4GuADpHsWZkcXRdguMl8y9NjOKgbebd8vHNw3egVGwvM0La+YKBaa0znwI7
F9Pr6SOqpjtZWciPu5RNrP1h0rztXz034zGffFmmDFeZ0YyKmdKzo8Y1b8K1
L2SHJWLjj/7emI9Y/wFHOHIOphkAAA==

-->

</rfc>

