Unrelated name server name requirement

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 2 September 2024.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

[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.¶

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

However, using unrelated name server names increases the name resolution costs and may increase the likelihood of name resolution errors.¶

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

2. Terminology

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Many of the specialized terms used in this document are defined in DNS Terminology [RFC8499].¶

3. Problem Statement

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

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

[Tsuname2021] pointed out attacks and countermeasures that use increased load due to cyclic dependencies.¶

Many cyclic delegations are likely due to misconfigurations.¶

To avoid complex name resolution and misconfigurations, the recommendation to prevent unrelated name server names whenever possible is needed.¶

4. Recommendations for unrelated name server names

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

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

5. IANA Considerations

This document requests no IANA actions.¶

6. Security Considerations

Appendix A. Examples of complex unrelated delegations

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

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

Finally, "nstld.com" depends on "av[1-4].nstld.com.". (in-domain)¶

Author's Address