DATABASE RESOURCES PRICING ABOUT US

{"id": "AKAMAIBLOG:F2E40C84422671B65DD085C9FCA02FB7", "type": "akamaiblog", "bulletinFamily": "blog", "title": "Edge DNS Secondary Implementation: Order of Operations for NS Zone and Registrar Records", "description": "_This article has been updated to include recent industry trends and information about primary implementations._\n\nAkamai [Edge DNS](<https://www.akamai.com/us/en/products/security/fast-dns.jsp>) service delivers edge-based, authoritative domain services for thousands of organizations. These organizations trust Edge DNS to deliver reliable and performant responses, reflected by a 100% uptime service-level agreement. Along with unmatched reliability, Edge DNS boasts an impressive geographically diverse footprint and an intelligently deployed [anycast ](<https://blogs.akamai.com/2021/03/finding-the-best-servers-to-answer-queries-edge-dns-and-anycast.html>)network, ensuring client queries are consistently routed to a nearby nameserver in an efficient manner. From an operations perspective, Akamai offers administrators the flexibility to leverage Edge DNS as either a secondary or primary provider, as well as the option of implementing [DNSSEC](<https://blogs.akamai.com/2021/03/dnssec-how-it-works-key-considerations.html>) to protect against DNS forgery and manipulation.\n\n## Secondary DNS\n\nIn secondary mode, zone administrators establish zone transfers from their primary nameservers to Akamai.\n\n\n\nThis model allows domain owners to continue to rely on their existing provider for record management, while leveraging the Edge DNS network to reliably respond to end-user queries. For a heightened security posture, domain owners can mask their primary nameservers by exclusively delegating zones to Edge DNS. Transactional signatures ([TSIGs](<https://learn.akamai.com/en-us/webhelp/edge-dns/edge-dns-user-guide/GUID-FA4489C8-85EC-45A7-9EF2-41221CBCE943.html>)) can also be implemented to authenticate zone transfers.\n\nSecondary onboarding: updating nameserver and delegation records\n\nOne conundrum DNS administrators encounter is how to properly update their record sets when they're ready to onboard a zone to Edge DNS in a secondary model. Specifically, the order of operations for updating the zone's NS records and the domain registrar's delegation records can be a source of precarious uncertainty during the transition since the primary and secondary zones will advertise identical NS records via axfr calls. Although there are a number of valid implementation strategies involving these two steps, a few core principles should be incorporated into the deployment plan.\n\n1\\. While the IETF DNS spec doesn't provide clarity on the order of operations, certain resolvers may reject a response if the queried nameserver is not listed as authoritative in the zone file's NS records. Consequently, any additions to the NS record set (e.g., adding Akamai nameservers) should be established in the zone file before the registrar's records are updated; conversely, any removals should be reflected first in the delegation records. Examples of an acceptable and an ill-advised zone file setup can be found below.\n\nZone File \n\n| \n\nRegistrar \n \n---|--- \n \n ns1.example.com\n\nns2.example.com\n\nns3.example.com\n\n| \n\nns1.example.com\n\nns2.example.com \n \nZone File \n\n| \n\nRegistrar \n \n---|--- \n \n ns1.example.com\n\nns2.example.com\n\n| \n\nns1.example.com\n\nns2.example.com\n\nns3.example.com \n \n2\\. While not recommended long term, the two record sets can temporarily advertise different values, and there is no IETF-defined technical requirement concerning the timeliness/delay to address such discrepancies. However, the two record sets should ultimately align in the steady state, per the DNS specification. As a result, [DNS as Code](<https://blogs.akamai.com/2020/06/dns-as-code.html>) is becoming an increasingly popular means of executing these steps programmatically in order to reduce delays and manual touchpoints. \n\nDuring the interim period when the Akamai nameservers are only listed in the zone file, certain resolvers will cache the zone's NS records even if another record type is being retrieved. As a result, a percentage of DNS queries will \"leak\" to Edge DNS even before the delegation step is performed:\n\nZone File \n\n| \n\nRegistrar \n \n---|--- \n \nns1.example.com\n\nns2.example.com\n\na12-65.akam.net\n\na13-65.akam.net\n\na2-64.akam.net\n\na3-64.akam.net\n\na4-65.akam.net\n\n \n\n\nIn this scenario, a certain percentage of DNS traffic will be directed to Edge DNS.\n\n| \n\nns1.example.com\n\nns2.example.com \n \nConsequently, zone transfers need to be successfully established before adding the Akamai nameservers to the zone file. The amount of traffic sent to Akamai will be determined by the length of the NS records' time to live (TTL). The greater the TTL, the more traffic will be directed to Edge DNS. Similarly, domain owners should NOT deprovision any legacy nameservers until they're removed from both record sets and the pertinent TTLs have expired.\n\n3\\. The domain owner can add as many or as few of the Akamai nameservers as they see fit for each record update. Thus, the domain owner has the option to execute a hard cutover (add all Edge DNS nameservers at once) or a phased approach (add one or several Edge DNS nameservers at a time).\n\n## Secondary implementation steps: order of operations\n\nWith these key principles in mind, the implementation steps will follow this high-level order of operations:\n\n1\\. Update zone file and add one, several, or all Akamai Edge DNS nameservers (retain current nameservers; i.e., additive change). \n\nZone File \n\n| \n\nRegistrar \n \n---|--- \n \nns1.example.com\n\nns2.example.com\n\na12-65.akam.net\n\na13-65.akam.net\n\na2-64.akam.net\n\na3-64.akam.net\n\na4-65.akam.net\n\nTo reiterate: Some DNS traffic will be directed to Edge DNS after this step is executed.\n\n| \n\nns1.example.com\n\nns2.example.com \n \n2a. Update registrar to add the same Akamai nameservers referenced in step 1a.\n\nZone File \n\n| \n\nRegistrar \n \n---|--- \n \n\n\nns1.example.com\n\nns2.example.com\n\na12-65.akam.net\n\na13-65.akam.net\n\na2-64.akam.net\n\na3-64.akam.net\n\na4-65.akam.net\n\n| \n\nns1.example.com\n\nns2.example.com\n\na12-65.akam.net\n\na13-65.akam.net\n\na2-64.akam.net\n\na3-64.akam.net\n\na4-65.akam.net \n \n2b. Remove legacy nameservers from registrar's NS records (if necessary / a mixed delegation model is also supported).\n\nZone File \n\n| \n\nRegistrar \n \n---|--- \n \n\n\nns1.example.com\n\nns2.example.com\n\na12-65.akam.net\n\na13-65.akam.net\n\na2-64.akam.net\n\na3-64.akam.net\n\na4-65.akam.net\n\n \n\n\nSome DNS traffic will be directed to the legacy DNS infrastructure even after this step is executed since the legacy nameservers are still listed in the zone file.\n\n| \n\na12-65.akam.net\n\na13-65.akam.net\n\na2-64.akam.net\n\na3-64.akam.net\n\na4-65.akam.net \n \n3\\. Remove legacy nameservers from the zone file (if necessary). \n\nZone File \n\n| \n\nRegistrar \n \n---|--- \n \n\n\na12-65.akam.net\n\na13-65.akam.net\n\na2-64.akam.net\n\na3-64.akam.net\n\na4-65.akam.net\n\n| \n\na12-65.akam.net\n\na13-65.akam.net\n\na2-64.akam.net\n\na3-64.akam.net\n\na4-65.akam.net \n \n**** ****\n\n****There are a number of different iterations, but the overall execution will follow this basic template. In addition, it's always best practice to reduce the TTLs for the zone file's authoritative NS records during the implementation in case a rollback is needed.****\n\n## Primary implementations\n\nWhile the above principles also hold true for a primary implementation, the Edge DNS zone records can be edited independently in a primary model, which alleviates the underlying order of operations concern. Each provider simply needs to list themselves as authoritative in the zone's NS records during the transition period.\n\nEdge DNS Zone File \n\n| \n\nLegacy Zone File \n \n---|--- \n \n\n\na12-65.akam.net\n\na13-65.akam.net\n\na2-64.akam.net\n\na3-64.akam.net\n\na4-65.akam.net\n\n| \n\nns1.example.com\n\nns2.example.com \n \nJust like with a secondary implementation, the delegation records should ultimately match the NS records of the zone once the onboarding process is complete; therefore, all providers' zones in a mixed delegation model should advertise the same NS records in the eventual steady state. And, as with any implementation, Akamai's professional services team should be consulted to assist with any additional nuances involved with your Edge DNS implementation.\n\n## Summary\n\n * When Akamai is implemented as a secondary DNS provider, zone transfers are established from their primary nameservers to Edge DNS, which allows domain owners to continue relying on their existing provider for record management, while leveraging the Edge DNS network to reliably respond to end-user queries\n * The zone administrator needs to consider the order of operations of updating the zone's NS records and the registrar's delegation records during the initial deployment onto Edge DNS as a secondary provider\n * A nameserver responding to a query should always be listed as authoritative in its zone file's NS records; therefore, during the initial implementation, any additions to the NS record set should be reflected in the zone file before the registrar's delegation records are updated -- conversely, any removals should be reflected first in the delegation records\n * DNS as code has become a popular approach to programmatically execute these updates to reduce delays and manual touchpoints\n * Primary implementations share the same onboarding principles, but the transition phase is simplified since each provider zone can be edited independently\n\n## Explore diverse DNS-oriented solutions\n\nEverything Akamai deploys depends on our intelligent edge DNS platform, which expands to enable a range of services for domain owners. If you find this blog useful, continue your exploration with these references. \n\n * Learn how Akamai deploys Edge DNS with multiple vectors of global resilience in the \"[Designing DNS for Availability and Resilience Against DDoS Attacks](<https://content.akamai.com/gl-en-pg9295-fast-dns-wp-designing-dns-for-availability.html>)\" white paper\n * Achieve domain stability and resilience with Akamai [Edge DNS service](<https://www.akamai.com/us/en/products/security/fast-dns.jsp>)\n * Load balance your data centers, cloud deployments, and CDNs with Akamai's [cloud-based global server load balancing (GSLB) solution - Global Traffic Management (GTM)](<https://www.akamai.com/uk/en/products/performance/global-traffic-management.jsp>)\n * Massively scale your application with layer 7 load balancing with Akamai's [Application Load Balancer (ALB) Cloudlet](<https://www.akamai.com/us/en/products/performance/cloudlets/application-load-balancer.jsp>)\n * Turn your DNS resolver into a security tool with Akamai's [Enterprise Threat Protection (ETP)](<https://www.akamai.com/us/en/products/security/enterprise-threat-protector.jsp>) and [DNSi/SPS solutions](<https://www.akamai.com/us/en/products/network-operator/security-and-personalization-services.jsp>)\n * [Sign up for and search the Akamai community](<https://community.akamai.com/customers/s/?language=en_US>) to access a range of Akamai resources\n * Akamai's DNS solutions are API- and DevOps-aligned to enable cloud-to-cloud innovation, and [DevOps professionals](<https://developer.akamai.com>) are always welcome to join [developers.akamai.com](<https://developer.akamai.com>)\n\nQuestions about DNS? [Contact us](<https://www.akamai.com/uk/en/contact-us/>) to receive help from Akamai Technical Support.\n\nCopyright 2021by Akamai Technologies, Inc. All Rights Reserved. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system or translated into any language in any form by any means without the written permission of Akamai Technologies, Inc. While every precaution has been taken in the preparation of this document, Akamai Technologies, Inc. assumes no responsibility for errors, omissions, or for damages resulting from the use of the information herein. The information in these documents is subject to change without notice.\n\n", "published": "2021-05-27T14:00:00", "modified": "2021-06-08T18:12:40", "cvss": {"score": 0.0, "vector": "NONE"}, "href": "http://feedproxy.google.com/~r/TheAkamaiBlog/~3/cyS_xoEOJaY/edge-dns-secondary-implementation-order-of-operations-for-ns-zone-and-registrar-records.html", "reporter": "Sam Preston", "references": [], "cvelist": [], "immutableFields": [], "lastseen": "2021-06-08T18:35:40", "viewCount": 31, "enchantments": {"dependencies": {}, "score": {"value": 0.4, "vector": "NONE"}, "backreferences": {}, "exploitation": null, "vulnersScore": 0.4}, "cvss2": {}, "cvss3": {}, "_state": {"dependencies": 1646147165, "score": 1659843777}, "_internal": {"score_hash": "41cf5be0310ea852ac5393d20e722563"}}

{}