{"id":77313,"date":"2026-01-31T17:27:43","date_gmt":"2026-01-31T11:57:43","guid":{"rendered":"https:\/\/2thenew.today\/blog\/?p=77313"},"modified":"2026-02-13T14:40:41","modified_gmt":"2026-02-13T09:10:41","slug":"dns-as-code-in-action-lessons-from-a-client-project-with-ns1-and-terraform","status":"publish","type":"post","link":"https:\/\/2thenew.today\/blog\/dns-as-code-in-action-lessons-from-a-client-project-with-ns1-and-terraform\/","title":{"rendered":"DNS as Code in Action: Lessons from a Client Project with NS1 and Terraform"},"content":{"rendered":"

Introduction<\/strong><\/span><\/h2>\n

DNS is rarely the first thing teams modernise. In most client environments we work with at To The New, CI\/CD, cloud infrastructure, and observability mature quickly. DNS, however, often remains manually managed through dashboards, handled by a few people, and changed mostly during incidents. That gap usually goes unnoticed until traffic needs to be rerouted, a migration is planned, or an issue arises in production.<\/p>\n

\"DNS

DNS As Code<\/p><\/div>\n

This blog shares how, in one of our ad-tech client projects, we transitioned DNS from manual operations to DNS as Code<\/strong>, utilizing NS1 (an IBM product) and Terraform<\/strong>, and what changes occurred afterward.<\/p>\n

What We Found in the Client Setup<\/strong><\/span><\/h2>\n

The client had a reasonably mature DevOps setup:<\/p>\n

    \n
  • Infrastructure managed using Terraform<\/li>\n
  • Clear deployment pipelines<\/li>\n
  • Defined environments<\/li>\n<\/ul>\n

    But DNS changes were different. They were:<\/p>\n

      \n
    • Made directly in the NS1 UI<\/li>\n
    • Applied mostly in production<\/li>\n
    • Not reviewed or documented<\/li>\n
    • Hard to trace during incidents<\/li>\n
    • DNS had effectively become a manual production dependency.<\/li>\n<\/ul>\n

      Why We Pushed for DNS as Code<\/strong><\/span><\/h2>\n

      At To The New, our default approach is simple:<\/p>\n

        \n
      • If it affects production traffic, it should live in Git.<\/li>\n
      • DNS is the very first layer users hit. Managing it outside version control increases operational risk, especially when traffic routing and failover logic are involved.<\/li>\n
      • Since the client already used Terraform extensively, bringing DNS under the same workflow was a natural next step.<\/li>\n<\/ul>\n

        Why NS1 Fits This Approach<\/strong><\/span><\/h2>\n

        NS1 wasn\u2019t just being used as a DNS provider; it was already part of the client\u2019s traffic management strategy. What worked in our favour:<\/p>\n

          \n
        • Support for weighted routing<\/li>\n
        • Metadata-based decisions<\/li>\n
        • Clear Terraform support<\/li>\n
        • This allowed us to model DNS behavior declaratively, rather than treating it as a static configuration.<\/li>\n<\/ul>\n

          Terraform + NS1: The Core Model<\/strong><\/span><\/h2>\n

          In Terraform, you manage:<\/p>\n

            \n
          • Zones<\/strong><\/li>\n
          • Records<\/strong><\/li>\n
          • Answers<\/strong><\/li>\n
          • Metadata<\/strong><\/li>\n
          • Routing behavior<\/strong><\/li>\n
          • Everything lives in Git.<\/strong><\/li>\n<\/ul>\n

            Provider Configuration<\/p>\n

            provider \"ns1\" {\r\n\u00a0 api_key = var.ns1_api_key\r\n}<\/pre>\n
            This makes NS1 just another Terraform provider\u2014no special treatment, no UI dependency. Managing DNS Records Declaratively.<\/p>\n
            Example: Simple A Record<\/p>\n
            resource \"ns1_record\" \"application_1\" {\r\n\u00a0 zone \u00a0 = \"demo.com\"\r\n\u00a0 domain = \"app1.demo.com\"\r\n\u00a0 type \u00a0 = \"A\"\r\n\u00a0 ttl\u00a0 \u00a0 = 60\r\n\u00a0 answers {\r\n\u00a0 \u00a0 answer = [\"10.53.1.98\"]\r\n\u00a0 }\r\n}<\/pre>\n
            A DNS record is now:<\/p>\n
              \n
            • Versioned<\/strong><\/li>\n
            • Reviewable<\/strong><\/li>\n
            • Reproducible<\/strong><\/li>\n<\/ul>\n
              No surprises.<\/p>\n
              Sample Command used for importing existing records into Terraform:<\/p>\n
              terraform import ns1_record.<terraform_resource_name> <zone>\/<domain>\/<type><\/pre>\n
              Moving DNS into Terraform<\/strong><\/span><\/h2>\n
              We started small. Existing records were recreated in Terraform, without changing behavior. The goal was not optimisation, it was control and visibility. Once records lived in code:<\/p>\n
                \n
              • Every change had a history<\/li>\n
              • Reviews became mandatory<\/li>\n
              • Ownership was clear<\/li>\n
              • DNS stopped being something \u201chandled on the side\u201d.<\/li>\n<\/ul>\n
                GitOps in Practice for DNS<\/strong><\/span><\/h2>\n
                After this, DNS changes followed the same workflow as infrastructure changes:<\/p>\n
                  \n
                • Change proposed through a pull request<\/li>\n
                • Terraform plan reviewed by the team<\/li>\n
                • Merge triggered Terraform apply<\/li>\n
                • NS1 updated records automatically<\/li>\n
                • No direct NS1 dashboard access was required for day-to-day work.<\/li>\n<\/ul>\n
                  This alone reduced risky, last-minute DNS changes significantly.<\/p>\n
                  A Real Use Case: Gradual Traffic Migration<\/strong><\/span><\/h2>\n
                  One practical scenario where this helped was a backend migration. Instead of switching traffic in one go, we used weighted DNS routing to:<\/p>\n
                    \n
                  • Route a small percentage of traffic to the new backend<\/li>\n
                  • Observe behavior in real traffic<\/li>\n
                  • Gradually increase the load<\/li>\n
                  • Each weight change was a Git commit.<\/li>\n
                  • Each adjustment was reviewed.<\/li>\n<\/ul>\n
                    There was no ambiguity about what changed or when. Environment Consistency Improved Immediately.<\/p>\n
                    Before Terraform: DNS records for non-production environments were created manually and didn\u2019t always match production logic.<\/p>\n
                    With DNS as Code:<\/strong><\/p>\n
                      \n
                    • Same structure across all environments<\/li>\n
                    • Only the values differed<\/li>\n
                    • No accidental drift<\/li>\n
                    • Debugging environment-specific issues became much easier.<\/li>\n
                    • Rollbacks Stopped Being Stressful<\/li>\n<\/ul>\n
                      Earlier, rolling back a DNS change meant:<\/strong><\/span><\/p>\n
                        \n
                      • Remembering the previous state<\/li>\n
                      • Manually updating records<\/li>\n
                      • Hoping nothing was missed<\/li>\n<\/ul>\n
                        With Terraform:<\/p>\n
                          \n
                        • Revert the commit<\/li>\n
                        • Apply the change<\/li>\n
                        • Done<\/li>\n
                        • DNS rollbacks became routine instead of risky.<\/li>\n<\/ul>\n
                          Lessons from the Implementation<\/strong><\/span><\/h2>\n
                          A few things we learnt during this project:<\/p>\n
                            \n
                          • Keep TTLs low for records involved in routing decisions<\/li>\n
                          • Avoid making \u201cquick fixes\u201d directly in the UI<\/li>\n
                          • Start with simple routing logic and evolve gradually<\/li>\n
                          • Treat DNS changes like application changes<\/li>\n
                          • DNS doesn\u2019t need to be complicated\u2014but it does need discipline.<\/li>\n<\/ul>\n
                            Closing Thoughts<\/strong><\/span><\/h2>\n
                            DNS is often treated as background infrastructure. In reality, it\u2019s a critical part of the request flow and availability. In this client engagement, bringing DNS into the GitOps model using NS1 and Terraform:<\/p>\n
                              \n
                            • Reduced operational risk<\/li>\n
                            • Improved confidence during changes<\/li>\n
                            • Aligned DNS with the rest of the platform<\/li>\n<\/ul>\n
                              At To The New<\/strong>, this approach has now become a standard recommendation for teams using intelligent DNS at scale. DNS may be old, but how we manage it should reflect modern engineering practices.<\/p>\n","protected":false},"excerpt":{"rendered":"
                              Introduction DNS is rarely the first thing teams modernise. In most client environments we work with at To The New, CI\/CD, cloud infrastructure, and observability mature quickly. DNS, however, often remains manually managed through dashboards, handled by a few people, and changed mostly during incidents. That gap usually goes unnoticed until traffic needs to be […]<\/p>\n","protected":false},"author":1601,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":77,"footnotes":""},"categories":[2348],"tags":[8293,6620,1892,8289,8291,7603,6835,8290,7323,8292,1585,2987,6468],"class_list":["post-77313","post","type-post","status-publish","format-standard","hentry","category-devops-technology","tag-clientcasestudy","tag-cloudinfrastructure","tag-devops","tag-dnsascode","tag-dnsautomation","tag-gitops","tag-infrastructureascode","tag-ns1","tag-platformengineering","tag-productionreliability","tag-terraform","tag-tothenew","tag-trafficmanagement"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t