Dear DNSOP colleagues,
We have published a new individual Internet-Draft:
Title:
Operational Guidance for Authoritative DNS Operator Changes with Service
Endpoint Migration for Registered Domain Names
Draft:
draft-feng-dnsop-authdns-operator-change-00
Datatracker:
https://datatracker.ietf.org/doc/draft-feng-dnsop-authdns-operator-change/
A registered domain name can change its authoritative DNS operator while the
registrant also migrates service endpoints, such as web, API, CDN, mail, or
cloud-hosted services. The draft addresses an operational case in which a
change of authoritative DNS operator overlaps with a migration of service
endpoints.
During an authoritative DNS operator change, recursive resolvers do not all
observe the parent-side delegation change at the same time. Some resolvers may
continue to query the losing authoritative DNS operator, while others query the
gaining operator. If service RRsets, such as A, AAAA, CNAME, MX, SRV, SVCB, or
HTTPS RRsets, also change during this interval, the two authoritative paths may
return operationally different answers. This can result in cache-dependent and
intermittent service failures.
Established DNS hosting migration practices commonly recommend provisioning and
validating the gaining operator before changing the delegation and retaining
the old hosted zone during cache convergence. This draft does not replace or
redefine those practices. Instead, it focuses on the aspects that need to be
made explicit when the DNS operator change overlaps with a service endpoint
migration.
The main mechanisms described in the draft are:
* defining a consistency profile for the service data that needs to remain
operationally equivalent across the losing and gaining authoritative paths;
* synchronizing provisioning, or using a common source of truth, so that both
paths provide equivalent service data during the transition;
* maintaining the losing authoritative path for a hold period derived from
relevant TTLs and an appropriate safety margin;
* directly comparing responses from the losing and gaining authoritative
servers, including DNSSEC, positive and negative answers, and policy-dependent
responses where applicable;
* defining verifiable exit conditions and classifying observed differences as
planned, service-affecting, or potentially indicative of an unexpected
delegation change.
The draft does not define a new DNS protocol, RR type, resolver behavior, or
EPP extension. It is intended to complement the existing DNS and DNSSEC
specifications and operational guidance, including RFC 1034 and RFC 1035, the
DNSSEC specifications, RFC 6781, RFC 8901,
and the existing zone transfer and child-to-parent signaling mechanisms. Its
specific focus is maintaining service-data consistency across old and new
authoritative paths when operator and endpoint changes overlap.
We would particularly appreciate feedback from the DNSOP working group
on the following questions:
1. Is the scope sufficiently clear and distinct from ordinary DNS hosting
migrations in which service endpoints do not change?
2. Is a consistency profile based on operational equivalence the right
abstraction for comparing the losing and gaining authoritative paths?
3. Are the proposed hold-period considerations, direct authoritative
comparisons, and verifiable exit conditions practical for DNS operators?
4. Is the relationship with existing DNS and DNSSEC operational guidance
adequately described, and are any important deployment scenarios or existing
RFCs missing?
Comments, reviews, operational experience, and suggestions for improving the
document would be very welcome.
Best regards,
Yuming Feng
Yu Zhang
Di Ma
Weizhe Zhang
Rongwei Yang
On behalf of the authors
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
