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


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

]>


<rfc ipr="trust200902" docName="draft-fujiwara-dnsop-dns-upper-limit-values-00" category="bcp" consensus="true" submissionType="IETF" tocDepth="4" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="dns-upper-limit-value">Upper limit value for DNS</title>

    <author initials="K." surname="Fujiwara" fullname="Kazunori Fujiwara">
      <organization abbrev="JPRS">Japan Registry Services Co., Ltd.</organization>
      <address>
        <email>fujiwara@wide.ad.jp</email>
      </address>
    </author>

    <date year="2024" month="July" day="08"/>

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

    <abstract>


<?line 75?>

<t>There are parameters in the DNS protocol
that do not have clear upper limit values.
If a protocol is implemented without considering the upper limit,
it may become vulnerable to DoS attacks,
and several attack methods have been proposed.
This draft proposes reasonable upper limit values for DNS protocols.</t>



    </abstract>



  </front>

  <middle>


<?line 84?>

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

<t>There are parameters in the DNS protocol that do not have clear upper limits.
For example, the number of alias levels using CNAME Resource records,
the number of name servers,
the number of Resource Records in an RRSet,
the number of delegation levels using unrelated name server names,
and the number of DNSKEYs for each domain name.</t>

<t>I a protocol is implemented without considering the upper limit,
it may become vulnerable to DoS attacks,
and several attack methods have been proposed.</t>

<t>This draft proposes reasonable upper limits for DNS protocols.</t>

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

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

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

</section>
<section anchor="possible-upper-limits"><name>Possible upper limits</name>

<section anchor="number-of-a-aaaa-ns-rrs-in-a-rrset"><name>Number of A, AAAA, NS RRs in a RRSet</name>

<t>Since there are 13 root name servers and 13 name servers for com and net TLDs,
the maximum number of NS RR in an NS RRSet should be 13.</t>

</section>
<section anchor="number-of-alias-levels-using-cnamedname"><name>Number of alias levels using CNAME/DNAME</name>

<t>Many resolver implementations can resolve over 10 CNAME aliases.
However,
a stub resolver that receives a response containing multiple CNAME aliases
must find the final A, AAAA Resource record
that corresponds to the CNAME in each application.
In order to avoid this complexity,
we recommend using up to one level of CNAME/DNAME,
and CNAME/DNAME aliases with more than three levels MAY be treated as
a name resolution error.</t>

</section>
<section anchor="number-of-rrsigsdnskeysdss-in-a-rrset"><name>Number of RRSIGs/DNSKEYs/DSs in a RRSet</name>

<t>KeyTrap <xref target="KeyTrap"></xref> is a vulnerability caused by the fact that
there is no upper limit on the number of DNSKEY RRs, DSs, or RRSIGs.
If there were upper limits on these, the damage could be mitigated.</t>

<t>Therefore, considering the DNSKEY rollover and the multi-signer model,
the maximum number of DNSKEYs for both KSK and ZSK may be 6.
The maximum number of DS RRs in a DS RRSet may be 3.
If that limit is exceeded,
the validating resolvers may result in a name resolution error.</t>

<t>The number of RRSIG RRs for each owner name and type pair may be 6.</t>

</section>
<section anchor="number-of-delegation-levels-using-unrelated-name-server-names"><name>Number of delegation levels using unrelated name server names</name>

<t><xref target="RFC9471"/> states that all in-domain glue records are attached to
the delegation response.
Therefore, using in-domain name server names for DNS delegation
minimizes name resolution costs.</t>

<t>Unrelated (or, rarely sibling) name server names are used/required for
DNS hosting services.</t>

<t>However, using unrelated name server names increases the name resolution costs
and may increase the likelihood of name resolution errors.</t>

<t>This section proposes to use in-domain name servers as much as possible
for name resolution of unrelated name server names
to reduce the name resolution costs.</t>

<t>Unrelated(out-of-bailiwick) name server names are required
for DNS hosting services.
However, using unrelated name server names increases the name resolution costs.
For some domain names,
there are multiple layers of dependence on unrelated name server names
when resolving the name.</t>

<t>Furthermore, there are cases where cyclic dependencies in delegation occur,
settings that depend on sibling glue,
and cases where the sibling glue disappears or
some name servers stop responding, making it impossible to resolve names.</t>

<t><xref target="Tsuname2021"/> pointed out attacks and countermeasures that
use increased load due to cyclic dependencies.</t>

<t>Many cyclic delegations are likely due to misconfigurations.</t>

<t>To avoid complex name resolution and misconfigurations,
it is better to avoid using unrelated name server names as much as possible.</t>

<t>Then, unrelated name server names SHOULD be hosted by a domain name 
with at least one in-domain name server name.
In other words, DNS providers SHOULD have at least one in-domain nameserver
for their domain names.</t>

</section>
</section>
<section anchor="RecommendationResolver"><name>Possible upper limit values</name>

<texttable>
      <ttcol align='left'>Name</ttcol>
      <ttcol align='left'>Upper limit value</ttcol>
      <c>Number of CNAME chains</c>
      <c>1 ? 3 ? 9 ? 16 ?</c>
      <c>Number of DS</c>
      <c>3</c>
      <c>Number of DNSKEY</c>
      <c>6</c>
      <c>Number of RRSIG RRs for each name and type</c>
      <c>6</c>
      <c>Number of levels of unrelated only</c>
      <c>1</c>
      <c>Number of RRs in one RRSet</c>
      <c>13</c>
      <c>Number of glue RRs in a delegation</c>
      <c>26</c>
</texttable>

<t>Recursive resolvers MAY return a name resolution error (Server Failure)
if it receives a response from an authoritative server
that exceeds these limits.</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="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="RFC9471">
  <front>
    <title>DNS Glue Requirements in Referral Responses</title>
    <author fullname="M. Andrews" initials="M." surname="Andrews"/>
    <author fullname="S. Huque" initials="S." surname="Huque"/>
    <author fullname="P. Wouters" initials="P." surname="Wouters"/>
    <author fullname="D. Wessels" initials="D." surname="Wessels"/>
    <date month="September" year="2023"/>
    <abstract>
      <t>The DNS uses glue records to allow iterative clients to find the addresses of name servers that are contained within a delegated zone. Authoritative servers are expected to return all available glue records for in-domain name servers in a referral response. If message size constraints prevent the inclusion of all glue records for in-domain name servers, the server must set the TC (Truncated) flag to inform the client that the response is incomplete and that the client should use another transport to retrieve the full response. This document updates RFC 1034 to clarify correct server behavior.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9471"/>
  <seriesInfo name="DOI" value="10.17487/RFC9471"/>
</reference>




    </references>

    <references title='Informative References' anchor="sec-informative-references">

<reference anchor="Tsuname2021" >
  <front>
    <title>TsuNAME: exploiting misconfiguration and vulnerability to DDoS DNS</title>
    <author initials="G. M." surname="Moura" fullname="Giovane C. M. Moura">
      <organization>SIDN Labs</organization>
    </author>
    <author initials="" surname="Sebastian Castro" fullname="Sebastian Castro">
      <organization>InternetNZ</organization>
    </author>
    <author initials="" surname="John S Heidemann" fullname="John S. Heidemann">
      <organization>USC/ISI</organization>
    </author>
    <author initials="" surname="Wes Hardaker" fullname="Wes Hardaker">
      <organization>USC/ISI</organization>
    </author>
    <date year="2021"/>
  </front>
  <seriesInfo name="IMC '21: Proceedings of the 21st ACM Internet Measurement Conference" value=""/>
</reference>
<reference anchor="KeyTrap" >
  <front>
    <title>The KeyTrap Denial-of-Service Algorithmic Complexity Attacks on DNS</title>
    <author initials="" surname="Elias Heftrig" fullname="Elias Heftrig">
      <organization>ATHENE</organization>
    </author>
    <author initials="" surname="Haya Schulmann" fullname="Haya Schulmann">
      <organization>ATHENE</organization>
    </author>
    <author initials="" surname="Niklas Vogel" fullname="Niklas Vogel">
      <organization>TU Darmstadt</organization>
    </author>
    <author initials="" surname="Michael Waidner" fullname="Michael Waidner">
      <organization>Fraunhofer SIT</organization>
    </author>
    <date year="2024"/>
  </front>
</reference>


    </references>



  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA81YXXPbuBV9x69AnYdmp5Ji2Zlso5lOq1r22rGtpJbcnd1O
pwORkIQ1SXAB0I7i5L/3XACUKJmyt50+VGNLJIF7cXHuuR9gt9tlTrlMDvht
WUrDM5Urx+9FVkk+14aPxhMmZjMj7wc8LWy3olldP6vrZ7FUJ4XIoSA1Yu66
8+oX9SCM6GK2LrutMrZ7eMiYdaJI/yUyXUDYGahiqjT+0rqjw8P3h0dMGCkG
XENeOKULy+4eBvyicNIU0nVHtCJLhBvwWVKyBBNkYSsb1VkH6RzzT6dnjJVq
wDh3OhnwlbThMpWlWw74W9xZbTB9butRu8o3t0xUbqkNKejin3NVYOSyx8/i
bv3DAMOl+FIV2qjtMW0WA/5BlKLgN3KhYNqKT6S5V4m0/ET3OvzKpT0/tYb7
w6ebiX8gc6GyAa+R/cuDSmVPpL1fSsawUg5o7uUA6BXzzR3nU1uRRUeHR/2B
1xMdfYCB8fD6dMDl5zLTyqliwXNlAd9cLaqANIdv+H2VFUB+pjLlVsCLj0Z6
QpQ4CIauQaFPN/5GcH5Q+l4Ukp/0+DX+dBWB2AD13AwP1+RiNOZXYmbbV5jI
mbBOAdET/Bq9o37vsNddc2j8c7vyD3pZ8EmPn0uAnYui2NG+f9yrv52cvLmY
XLTr/hEuPxcmFXfS7KhtHXqiMRUOc8mx/tZKo6Ql78O5F9cn/PfwOP9kdCJl
CudarufcLSU/6lvHhyfX693zaylsZWQuCwcWFnNpZJHIAwa9l3I1NaLcoQ60
xAE+koUSWVfPu5HIfJgtQHy3zFUCbXmZyc9EnKFzIrmDFcVv5M5ppgRwkHNn
1GIHofYxD9Fwen46Pm1XeS5Wgk+SZZW1OHPP4ItKx+ougzF/1wuZ7ahsHfIK
+fSWj4TJkf5S166XX6tkKWTGfxQqLZ6QZO9w0H9mRFUsNXyJCJpuE+YtY91u
FykGESESxxgcaiRHmuUlUksuwQsLIzxd4CxeGo08qTPmlsLxVPNCO74U95In
mRSGV7tVw/bYxZyLtSBX0EdUII7JlD+AH7pynJI1QsdQ8qHFGoo6DMpyseIz
mehcrtNQJn0OQgoSgVEdRlnKynuMZvEhxx6WOrXByJmUBZlSaiuRXqdLWOPr
VP3QctQIqwuv/elm6hq43g625xHMVZpmqFiIJKPTKvE58/GVatx+Y3+iz2/H
mL+MMZY/g0XysyBIO15FUeUzjCPGhY+NDHhklleWoD2hTI+SY5FeEaEGiJoU
wG0LEq8ojQDIJ2Nr2ZsgS5ZTFbuZSLc7N5WZXIT6sWVFVRiZCXJ/YyV/HX24
rQagXJ7+FMCXIlkCE5TAwgsA/4v/V3r9B/xqZxabSpOrQmd6sQKb3OYukmlN
KH4nV/zB++Pg+nYyPeiEXz7+6K9vTv92e3FzOqLryfnw6mp9EWYw3Hy8vYrj
dLWRPPl4fX06HgVhPOU7j66HP+EH2LCDj5+mFx/Hw6uDwGfavU4qX06I78Bz
JjGEjZRGkn/Az1TaxKgZbiDD/nryqf+WPz7+7ubs5Kjff//tW7z5Y//7t7h5
WMrCL4byka3iLTy64gJoIjqIjlmGLrBUTmS2Q0vYpX4oOIUdQL0WxaqugLaU
CYqW+oLVCV0iaDDkqfGpnKvCDzLy05ZrvIXv376HuVjhk7ZW7Tp447CN48Zr
ig87fIhPh0PzzU0IqhBTlF7ow9hEoRaT2TF79I+50UgNzWj1yGBg6xlRC9T2
Y1Tlp1ejGNa5+KzyKm/Eml8/xrS/hgmEX5Wl5Lv+ca9p9r4M82ZE3xvTPeYG
mSOjQF8HaGjieYK14iDXNKF/GBOV10815Fw/UNwhBLl11Wyjy+dIpDGJLhe7
p4GS+n6KeIck4ZvZKnMKS24rZTnOFRw+DekGF4jq6IfdDBnKHa6CekQZqExS
QSPg8nkJFMxU4neFslegAKdkoubiXqs0cCpZN0Id9hD058AirVNjSfNxBgqo
EsgNREMKajyoN+MTHc81BdlSEH2NlLVjEKDkOzr+hJgDip4gHsXK52dpjDZb
voXrL36wb2LyfTOatLOybv/+ES/+SSlY7JwVEuHjarYKUKPV8I5jgcwQKPRW
tdVFawmg0OhwWNIBtNFA318EPQ/0tZVUgx4bK2MqcrEgZkQyY4paECS9WJQR
KJi6Wyvi2kZnmWdnXaA8rbpWLbBRQI9ity+omgVspuGoy8mlV/MzfkPp4e96
Po+3CDcywqiOyCh0HHcPcgbgAKX8TH2+TIMx6FsU2j3aSx0z1kvjDvYHtfvI
MN2u/IS3t2VdiJFWY+EOqKxKamqUaWyqwaj/oh3Y8KzOsd/3UQXQLDuQ3m8c
2R676MaeYEFvKmJb47Okr9NLyu/aA9Iwos4Vvab3g0kbhU9MWlfqjSaGSgD4
v2BwF8pEW+rS2O16j6+16XAD01C+qExgue9aViHbKWjeGPlrpQwEsa6vPEuo
JBttfF8A7XV6fBlQ7CyhFsSjJ9vN9UmGPFjP9VMzdScztdQ6XbeIu5Sxdc9j
ZeiA110Pcho20w6rpRKdV5Q/LS9j7WSE8u4iWPc5rmAR4FSFIvmyJ16jMaTj
6kwgST2o5G6fG2oPsNrzTz3wv3VA6OotdaMNuELNjsV/XdMysSIIfXiVqCN0
YKe89xxQ1DXFdFAnudhLn1WG1sh9KGxWS0KN8ffJKkGR26ym/J6acaWTpEKp
ttI5/7ohnGP8fLIskt6HaihoTfW+LWvM4KmyobXDJg3zoGyRxzpdxlCmtxsd
MPfOh7CjRqNuxTw3QovhMehRRmm8EkNSKbXyZwY6L8SW32c11AvqWPPwbiRs
hwU2B0+mPNMi5Wnll2nBp+4610M1VIFfPrJWtfzuqzcfVHULEbuHJ7TxEbsr
6E82iMYZHNHsQ17maEtAhnKAZvs5uXh0QOanEAkVXzQ5zJlvVKheATnnG539
uTY0UUTDcLbp1Ceke6rP6+X82esZlUGjj17oQnVqju3p1+sD/+Orm7pD86De
xCL6ra2f/zqmDTz7+dryYv0r+9p98fOHlmcQ3FTX0IomS+zMbq/I+/zP/Bj/
7/Hff4evLUE0FXtMpc/x9rMtwdAY7RF8t1+wpZPY7iFe1BD7h62CQAfCINh/
bmmfrYgkoZPasrl/vFfQ56J1I7YJ4SB49G5bkIE1lbE4lDTaLurDceytzN6e
i7+eBPafoSYh2XzH1JwSWdsBZ278kS6+OlXOv+iP0RPOK6ETtKEFXr8wYhfD
8ZDe7vomN6ahx1dKFKKF1MTrx0EcnW4diqksSlQrat69TpHU+WpCu6fG/8ky
No7Ub8Ogu35Effe38DpthuTL/g3cfDyQjRoAAA==

-->

</rfc>

