Name Server Provider and Domain Name Registrar Operational Framework
draft-vmhosting-fi-nameservers-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Marko Mikael Mela | ||
| Last updated | 2026-08-26 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-vmhosting-fi-nameservers-00
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,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[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,
<https://www.rfc-editor.org/info/rfc2182>.
[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,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
<https://www.rfc-editor.org/info/rfc5730>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
Author's Address
Marko Mikael Mela
VM HOSTING
Finland
Email: marko.mela@outlook.com
Mela Expires 28 February 2027 [Page 11]