| Internet-Draft | DNS and Registrar Operations | August 2026 |
| Mela | Expires 28 February 2027 | [Page] |
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.¶
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 (c) 2026 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.¶
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.¶
This document applies to systems that perform one or more of the following functions:¶
This document does not replace registry-specific policy, contractual requirements, applicable law, registry protocol specifications, or the DNS protocol specifications.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
Registration systems should monitor failures involving registry connectivity, provisioning queues, renewal processing, delegation updates, and other state transitions that can affect active domain names.¶
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.¶
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.¶
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.¶
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.¶
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.¶
This document has no IANA actions.¶
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.¶