[DNSOP] New I-D: draft-feng-dnsop-authdns-operator-change-00
冯禹铭 <[email protected]>
| Newsgroups | gmane.ietf.dnsop |
|---|---|
| Message-ID | <[email protected]> |
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]