Network Working Group M. M. Mela Internet-Draft VM HOSTING Intended status: Informational 27 August 2026 Expires: 28 February 2027 Name Server Provider and Domain Name Registrar Operational Framework draft-vmhosting-fi-nameservers-00 Abstract This document describes an operational framework for service providers that operate authoritative Domain Name System (DNS) services, domain name registration services, or both. It covers DNS zone provisioning, authoritative name server operation, delegation management, service availability, DNSSEC, domain registration lifecycle operations, access control, monitoring, incident response, abuse handling, and privacy considerations. This document does not define a new DNS protocol, registry protocol, or domain registration policy. It describes operational practices that can be applied by providers using existing DNS and domain registration protocols and interfaces. 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 28 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Mela Expires 28 February 2027 [Page 1] Internet-Draft DNS and Registrar Operations August 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Operational Architecture . . . . . . . . . . . . . . . . . . 4 4.1. Control Plane and DNS Serving Plane . . . . . . . . . . . 4 4.2. Provider Boundaries . . . . . . . . . . . . . . . . . . . 5 5. Authoritative DNS Service Operations . . . . . . . . . . . . 5 5.1. Zone Provisioning . . . . . . . . . . . . . . . . . . . . 5 5.2. Availability and Redundancy . . . . . . . . . . . . . . . 5 5.3. Delegation Management . . . . . . . . . . . . . . . . . . 5 5.4. TTL and Change Management . . . . . . . . . . . . . . . . 6 6. DNSSEC Operations . . . . . . . . . . . . . . . . . . . . . . 6 7. Domain Registration Operations . . . . . . . . . . . . . . . 6 7.1. Registration Lifecycle . . . . . . . . . . . . . . . . . 7 7.2. Registry Communication . . . . . . . . . . . . . . . . . 7 7.3. Registration and DNS Coordination . . . . . . . . . . . . 7 8. Authentication and Access Control . . . . . . . . . . . . . . 7 9. Monitoring and Service Continuity . . . . . . . . . . . . . . 8 9.1. DNS Monitoring . . . . . . . . . . . . . . . . . . . . . 8 9.2. Registration Monitoring . . . . . . . . . . . . . . . . . 8 9.3. Backups and Recovery . . . . . . . . . . . . . . . . . . 8 9.4. Incident Response . . . . . . . . . . . . . . . . . . . . 9 10. Abuse Handling . . . . . . . . . . . . . . . . . . . . . . . 9 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 12. Operational Considerations . . . . . . . . . . . . . . . . . 10 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 14. Security Considerations . . . . . . . . . . . . . . . . . . . 10 15. Informative References . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 Mela Expires 28 February 2027 [Page 2] Internet-Draft DNS and Registrar Operations August 2026 1. Introduction The Domain Name System is a distributed naming system that provides a fundamental dependency for Internet services. Authoritative DNS providers publish DNS data for delegated zones, while domain name registration services manage registration data and communicate registration and delegation information to the applicable registry or registry service. These functions are closely related operationally but are distinct. A domain name may be registered through one provider while its authoritative DNS service is operated by another provider. Conversely, a single service provider may provide both functions. This document describes an operational model intended to keep those responsibilities clearly separated while providing consistent management of domain registrations, DNS zones, delegations, and security controls. The DNS terminology used by this document is intended to be consistent with [RFC9499]. Use of the term "registrar" or "domain registration service" in this document describes an operational role. It does not by itself assert accreditation, contractual status, or authorization under any particular registry, top-level domain, policy authority, or jurisdiction. 2. Scope This document applies to systems that perform one or more of the following functions: * Hosting authoritative DNS zones. * Operating authoritative name server infrastructure. * Provisioning and modifying DNS records. * Managing domain name registrations. * Communicating registration data to registries or upstream registration service providers. * Managing DNS delegations and name server assignments. * Managing DNSSEC configuration and delegation data. This document does not replace registry-specific policy, contractual requirements, applicable law, registry protocol specifications, or the DNS protocol specifications. Mela Expires 28 February 2027 [Page 3] Internet-Draft DNS and Registrar Operations August 2026 3. Terminology Authoritative DNS Service Provider: A service provider that publishes authoritative DNS data for one or more DNS zones. Authoritative Name Server: A DNS server that provides authoritative answers for a zone for which it has authoritative data. Registrant: The person or organization on whose behalf a domain name is registered. Registrar Service: A service responsible for managing domain registration lifecycle operations and communicating those operations to an applicable registry or upstream registration provider. Registry: The system or organization maintaining authoritative registration information for a domain namespace. Delegation: The DNS data establishing authoritative name servers for a child zone from its parent zone. Zone: A portion of the DNS namespace for which authoritative DNS data is maintained. 4. Operational Architecture 4.1. Control Plane and DNS Serving Plane Operational deployments benefit from separating management functions from the systems that directly answer authoritative DNS queries. The control plane can provide authentication, customer interfaces, zone editing, registration management, DNSSEC management, audit logging, and provisioning. The authoritative serving plane can then receive validated and authorized DNS configuration from the control plane. Failure of a customer-facing management interface should not by itself make already-published authoritative DNS data unavailable. Mela Expires 28 February 2027 [Page 4] Internet-Draft DNS and Registrar Operations August 2026 4.2. Provider Boundaries DNS hosting and domain registration should be treated as independent services even when both are operated by the same provider. Registration status should not unnecessarily determine whether previously provisioned DNS infrastructure remains technically available, except where removal is required by expiration, deletion, registry state, security response, contractual requirements, or applicable policy. 5. Authoritative DNS Service Operations 5.1. Zone Provisioning DNS zones should be created, modified, and removed through authenticated and authorized provisioning mechanisms. Changes should be validated before publication to reduce the risk of malformed or internally inconsistent zone data. Zone publication systems should preserve the consistency of essential records, including Start of Authority (SOA) and Name Server (NS) records. The underlying DNS protocol behavior is defined by [RFC1034] and [RFC1035]. 5.2. Availability and Redundancy Authoritative DNS service should not depend on a single server, network path, physical host, or avoidable infrastructure failure domain. Multiple authoritative servers should be deployed in a manner that provides useful operational redundancy. Diversity of network paths, infrastructure, and failure domains can improve resilience where operationally practical. Guidance on secondary authoritative DNS server selection and operation is provided by [RFC2182]. 5.3. Delegation Management Name server information maintained through a registration service should remain consistent with the intended authoritative DNS configuration. Mela Expires 28 February 2027 [Page 5] Internet-Draft DNS and Registrar Operations August 2026 Before a delegation change is submitted, the target authoritative name servers should normally be configured to serve the applicable zone. This reduces the possibility of creating a delegation to servers that are not yet prepared to answer authoritatively. Changes involving in-domain name servers may additionally require registration or modification of address information at the parent registry where glue records are necessary. 5.4. TTL and Change Management Time to Live (TTL) values should be selected according to the expected stability and operational requirements of the data. Extremely low TTL values can increase query load, while very high TTL values can extend the time required for operational changes to become effective throughout caching resolvers. Planned migrations may temporarily use adjusted TTL values when faster cache turnover is operationally useful. 6. DNSSEC Operations DNSSEC provides origin authentication and integrity protection for DNS data. The DNSSEC architecture is described by [RFC4033]. A provider offering DNSSEC should maintain controls for DNSSEC key generation, storage, activation, rollover, retirement, and recovery. Private signing key material should be protected from unauthorized access. DNSSEC configuration should also account for the relationship between a signed child zone and delegation information maintained by the parent zone. Registration and DNS hosting systems should coordinate changes to delegation signer information where the applicable registry supports such operations. DNSSEC does not provide confidentiality for DNS queries or DNS records. Its primary purpose is authentication and integrity of DNS data. 7. Domain Registration Operations Mela Expires 28 February 2027 [Page 6] Internet-Draft DNS and Registrar Operations August 2026 7.1. Registration Lifecycle A domain registration service may manage operations including availability checking, creation, renewal, contact or registration data changes, name server changes, transfer operations, deletion, restoration, and status management where supported by the applicable registry. The exact lifecycle and available operations depend on registry policy and the interface provided by the registry or upstream registration provider. 7.2. Registry Communication Communication with a registry should use the protocol or interface authorized by that registry. Where the Extensible Provisioning Protocol (EPP) is used, its base protocol is defined by [RFC5730] together with the applicable object mappings and registry-specific extensions. Implementations should not assume that all registries expose identical commands, extensions, status values, lifecycle rules, or policy requirements. 7.3. Registration and DNS Coordination A provider that offers both registration and authoritative DNS services may automate delegation configuration when a DNS service is activated. Such automation should preserve a clear separation between registration state and zone content. A customer should also be able to use authoritative DNS servers operated by another provider where permitted by the applicable registration service and registry. 8. Authentication and Access Control Administrative interfaces for DNS and domain registration are security-sensitive because unauthorized changes can redirect or disable Internet services associated with a domain. Providers should apply strong authentication to administrative access. Multi-factor authentication should be available for privileged or customer administrative accounts where practical. Mela Expires 28 February 2027 [Page 7] Internet-Draft DNS and Registrar Operations August 2026 Authorization should follow least-privilege principles. Access to domain registrations, DNS zones, DNSSEC keys, registry credentials, and infrastructure management should be limited according to the role of the authenticated principal. Sensitive changes should be recorded in an audit log containing sufficient information to determine the affected resource, the authenticated actor, the operation performed, and the time of the operation. Registry credentials, API credentials, authentication secrets, and private DNSSEC key material should not be exposed through ordinary customer interfaces or application logs. 9. Monitoring and Service Continuity 9.1. DNS Monitoring Authoritative DNS infrastructure should be monitored from perspectives that can detect server availability, query failures, unexpected response behavior, zone publication failures, DNSSEC validation problems, and significant changes in query traffic. 9.2. Registration Monitoring Registration systems should monitor failures involving registry connectivity, provisioning queues, renewal processing, delegation updates, and other state transitions that can affect active domain names. 9.3. Backups and Recovery Configuration and registration data required to reconstruct service state should be backed up according to an established recovery policy. Backup systems should be protected against unauthorized access and should not become an uncontrolled secondary repository for credentials, private keys, or registrant information. Recovery procedures should be tested periodically rather than assuming that the existence of a backup implies that the backup is usable. Mela Expires 28 February 2027 [Page 8] Internet-Draft DNS and Registrar Operations August 2026 9.4. Incident Response Operators should maintain procedures for investigating and responding to DNS outages, unauthorized configuration changes, compromised credentials, registry communication failures, DNSSEC failures, denial-of-service events, and other incidents that can affect domain resolution or registration state. Incident procedures should identify escalation paths and the authority required to perform emergency changes. 10. Abuse Handling Providers should maintain a documented mechanism for receiving and evaluating reports of abuse involving services under their operational control. Abuse reports should contain sufficient information to identify the affected domain, DNS resource, account, or service. Reports should be handled in accordance with applicable policy, contractual obligations, and law. Security-sensitive evidence and personal information received as part of an abuse report should be protected against unnecessary disclosure. This document does not define categories of prohibited content or establish a global content policy. 11. Privacy Considerations Domain registration systems can process personal and organizational information associated with registrants, administrative users, billing relationships, and security events. Providers should limit collection, storage, replication, logging, and disclosure of personal data to information required for the applicable operational, contractual, security, or legal purpose. Administrative logs may contain IP addresses, account identifiers, domain names, authentication events, and change histories. Access to those logs should therefore be controlled and retention periods should be defined. This document does not define jurisdiction-specific privacy or data protection requirements. Mela Expires 28 February 2027 [Page 9] Internet-Draft DNS and Registrar Operations August 2026 12. Operational Considerations Operators should document change-management procedures for production DNS infrastructure and domain registration systems. Changes capable of affecting large numbers of domains should receive additional review and should support a practical rollback or recovery strategy. Automation can reduce repetitive administrative errors, but automated actions should preserve authorization boundaries, validation, auditability, and failure handling. Providers should avoid unnecessary coupling between customer portal availability and authoritative DNS serving availability. An outage of the management interface should not automatically result in an outage of otherwise valid DNS zones. 13. IANA Considerations This document has no IANA actions. 14. Security Considerations DNS hosting and domain registration systems are high-value targets because unauthorized modification of a domain's registration, delegation, or authoritative DNS data can redirect traffic, interrupt services, or assist impersonation attacks. Operators should protect administrative interfaces, registry credentials, DNS provisioning systems, authoritative name servers, DNSSEC signing systems, and audit data using controls appropriate to their operational environment. Privileged operations should be authenticated and authorized. Credentials should be protected both in storage and in transit, and access should be revoked when it is no longer required. DNS infrastructure should be designed to tolerate expected equipment and network failures and should include capacity planning and response procedures for denial-of-service conditions. DNSSEC can protect against undetected modification of signed DNS data when it is correctly deployed and validated. Incorrect key or delegation management can itself cause resolution failures, so DNSSEC operations require monitoring and tested recovery procedures. Audit logs should be protected against unauthorized modification and should provide sufficient information for investigating significant administrative and security events. Mela Expires 28 February 2027 [Page 10] Internet-Draft DNS and Registrar Operations August 2026 15. Informative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection and Operation of Secondary DNS Servers", BCP 16, RFC 2182, DOI 10.17487/RFC2182, July 1997, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, . [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, . Author's Address Marko Mikael Mela VM HOSTING Finland Email: marko.mela@outlook.com Mela Expires 28 February 2027 [Page 11]