<?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.6.35 (Ruby 3.1.4) -->


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

]>


<rfc ipr="trust200902" docName="draft-fujiwara-dnsop-unrelated-name-server-00" category="bcp" consensus="true" submissionType="IETF" tocDepth="4" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="unrelated-name-server">Unrelated name server name requirement</title>

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

    <date year="2024" month="March" day="01"/>

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

    <abstract>


<?line 54?>

<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.
This document proposes using in-domain name servers as much as possible
for name resolution of unrelated name server names
to reduce the name resolution costs.</t>



    </abstract>



  </front>

  <middle>


<?line 63?>

<section anchor="introduction"><name>Introduction</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 document proposes to use in-domain name servers as much as possible
for name resolution of unrelated name server names
in order to reduce the name resolution costs.</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="RFC8499"/>.</t>

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

<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,
the recommendation to prevent unrelated name server names whenever possible
is needed.</t>

</section>
<section anchor="Recommendations"><name>Recommendations for unrelated name server names</name>

<t>Although it is acceptable to use unrelated name server names for DNS delegation,
the domain names that host the name server names MUST be resolvable
by delegations using one or more in-domain name server names.</t>

<t>It is desirable for DNS hosting services
that use unrelated name server names in their services
to be able to resolve their name server names
using only in-domain name server names.</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'>



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

<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="RFC8499">
  <front>
    <title>DNS Terminology</title>
    <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
    <author fullname="A. Sullivan" initials="A." surname="Sullivan"/>
    <author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
    <date month="January" year="2019"/>
    <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 sometimes 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 obsoletes RFC 7719 and updates RFC 2308.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="219"/>
  <seriesInfo name="RFC" value="8499"/>
  <seriesInfo name="DOI" value="10.17487/RFC8499"/>
</reference>




    </references>

    <references title='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>


    </references>


<?line 141?>

<section anchor="examples"><name>Examples of complex unrelated delegations</name>

<t>"com" TLD depends on "[a-m].gtld-servers.net" (sibling name server names)</t>

<t>"gtld-servers.net" depends on "av[1-4].nsdlt.com.". (unrelated name
  server names)</t>

<t>Finally, "nstld.com" depends on "av[1-4].nstld.com.". (in-domain)</t>

</section>


  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA9VXXW/bNhR956+4cx+WApaXBAG6GiiwzEkWt3GSxQmGrS0G
WqJtNhKpkZRTN+h/3yEpxZ9x97A9zEhg0STvx7nnHlJJkjAnXS66dKeMyLkT
GSleCLLCzISJz0b8VUkjCqEc46OREbMuVc3yxC9J4nKW6dQPu5QZPnbJuPok
H7jhSaasLpOte5L9fcas4yr7k+daYa8zlWBMliY8Wne4v/96/5BxI3iXdCkM
d1Iry+4futRXThglXHLiHbKUuy6N0pKlWCCUrWxtzjrsLrD+9PaMsVJ2GZHT
aZfmwsbHTJRu2qUjjKw2WD62zaydF4sh45WbauMNJPgnkgoz7zp0Vicbfowo
vONfKqWNXJ3TZtKlt7zkim7ERCK0OQ2BhUyFpZ7utOnCZZ2wtEH77fXNMPwg
Ci7zLjXA/vSpNLaT6s6nkjF4KgDNTHSBnhovRkS3tvIRHe4fHnSDnbroLUxc
Hg9OuyQ+l7mWTqoJFdICvrGcVBFpQm1oVuUKyI9kLt0ceNHJiR7SyeWwFQN9
AsV/kvq7BucXqWdcCep1aIA/XdVALIDatSLANeyfXNIFH9ntHoZixK2TQLSH
b6PXzD87HWw3HLr8Y7vxt3qqaNihcyEz4K/UmvXn54P5u2Hvh/6wv932byj5
OTcZv0f3rJrdOrVhMUM/dckXNgzRU1JYX30Utz/o0feoOF0bnQqRobiW9Jjc
VNDhgXV03Bs8ZU8DwW0VuxwsVGNhhEpFi7EkSUBE4MZTx9iTTuzpyiV6nIzA
SPkg0/uXG8phCU3byEfGQEnPGJpqG4hma9J32Ll+ENjUpsr6iepZLbKALUUr
Wzz5NGp9sjqvAlVTmIa926m0BDGqQjal0aX2O6J1qZJMo4/UsnWEaqmo0qn/
xmorR7kIEa+7AIA74mNoDeRapWJXfAHTQmYZfDBUwGjsCAseX8il4Vf2xn8Y
e3z87uas9/ro1cHXrwS1dCF/7ojn+VJCk7zy7lJtsog9d46nUwTqNPPxZCIX
k9jViKr0KunRQq2RqmjvQqjGvyniwhIrpJKF/ILJ59JdHC57GlU2CC2fk8cY
7p7jTWVF9kNDHu+XbSfPv8we5uWu4POntWFpLu9FLqdaZ54A6xuFMdr4UJ4h
HkiBbP5j5sEs6o7hP6PgrTAonM71ZA7WucWoJl0kHrhB92JOD4FSrcHd8LbV
jt90eRWeb05/vevfnJ745+H58cXF00NcwTC4uruo5/3TYmfvajA4vTyJm/Er
rf00OP4dX6gIa11d3/avLo8vWoARiS3j7NmCpEceYSRSGuERApyZsKmRIwyw
h/3cuz44othKhwcHr9FKcfDjwasjDB6mQgVnpBXoGYeAcE68LAU33gj6DbeM
Ujqe27Z3Yaf6QZHvIGA64GreKKwtRSp5jr5A9wFdGwi9PfhMjKUKk4HjK6WJ
ER69RrjwACkHPQoaeg0IN7I365//iUafwZPVmFpqCdv2KuV1C/9FlTtZ5ug9
PvdtAlxxSRMq8+cSSrSzGXzxotOZj7aJAwieVcb7KILeLbylId6HME7naS7T
hTcZcloWT52mlWkzK5wLp2rQ4rjeR1YrW9DjdhCUZfOBHUsrKJM2MgxJGhZA
WREI63RZ67U/xNuQp/ug045k0UhGbHufcNzte/zxcenmB4aX2jcIQqxcPBru
beB7qivfOEW8AsR0WFSsWMmMcs0zyqrgZgs+DfmfphqoIr+CfM6b/es3zCBH
mvhMSx9LgaJ/3qBNkOX1jYEv4cQr0AxZLA48QAJmvrl2sdRTxDN6IbpoS4V7
ksDtm92s2Izn3i5rjy/Wdnzd1pnHOe7J1WQaSgdo0hSvHbyungd8l4vNozem
v9xAkYm+exe9t2IkKPeoRnbmXbPRfKVesb/xKgYykm+TXfcBINUPqUBqpQmZ
PCchLIT2rSSDPgpplrYFZedrFI+LNhu/iT6ffyNs1j++PPY3XYtre00nf/3i
im8pna/eY7eeXT3lvXYKSBopTcEmTxtSDwVkwr8wbbix9Uxzw4Pt5qc0kCdc
EUfoUMZOP3PfEkEBm+5YQLhcuscXol4b7TK8FLSwpUW3OHVjv1ovUK33PCk+
diYuz+r3cNvBS0CL9hph2oDsZTC2uWPZKp99eH+QHH342FE2yx3eTItOq0N7
qwVntGn4TCocrXMc+crCRScE/ZzpekEw/VRkmPkbwG2juM8QAAA=

-->

</rfc>

