The Key Advantage of Managing DNS With Terraform

In past articles we've talked about managing Infrastructure-as-Code (IaC) and the advantages it offers. DNS records are part of your infrastructure as well, although fewer businesses think to maintain it outside of manual control via either DNS provider GUIs or old-fashioned text files. Not all the entries are part of other automation efforts - creating VMs and auto-registering the IP in DNS, etc.

At iuvo, we include all our DNS records, which are served from AWS Route 53 in our Terraform automation - and more specifically Cloud LaunchPad, for a very particular reason…so we know why they are there.

One drawback of many DNS provider's interfaces is that they do not offer any way in which to annotate the purpose of a record, or it is too limiting to do so. If you only maintain a few records, you probably know what they do. However, if you maintain a complicated environment, it is helpful to know what each record is for, who is responsible, etc. A prime example is an SPF record. It can have many entries in it to define who can send email on your domain's behalf. For example, you could have an include for SendGrid in there…but do you know why? Do you utilize SendGrid specifically, or do you use a service that in turn uses SendGrid? Do you still need it?

Back in the "old days" - and still commonly practiced in some places, we used to add comments to the BIND text file that had all the records in there to remind us of the details. In the days of GUI based systems, like Route 53, GoDaddy, etc. there isn't always a way to attach a comment or description to the specific records.

Interestingly, AWS allows "tags", which can be used for comments and other data, on almost every resource type you can create - except Route 53 records! So, we need to have an alternative, and Infrastructure-as-Code provides that for us by returning to text files we can make comments in! iuvo's Cloud LaunchPad simplifies the DNS record inputs into easier to read records so we can annotate cleanly.

For example:

…
# Our web server
{ type="A", values=["A.B.C.D"], ttl=300 }
# Our MX record points to Microsoft 365
{ type="MX", values=["10 iuvotech-com.mail.protection.outlook.com."], ttl=86400 },
# Multiple TXT records
{ type="TXT", values=[
    "MS=msXXXXXXXX", # Microsoft domain validation
    "google-site-verification=ReallyLongGoogleIDString", # Google Analytics/website validation
    # The SPF record entries as follows:
    #   - include:spf.protection.outlook.com - includes all the Microsoft 365 servers
    #   - ip4:A.B.C.D - The web server can send email
    #   - include:amazonses.com - AWS Simple Email Service
    #   - include:sendgrid.net - SendGrid - used by XYZ Service
    #   - -all - Don't allow anything else
    "v=spf1 include:spf.protection.outlook.com ip4:A.B.C.D include:amazonses.com include:sendgrid.net -all",
], ttl=900},
…

Note that we can still maintain records manually if we need fast changes, but we'd want to ensure that we backport those updates into Terraform soon after.

Whether you are doing raw Terraform, or more manageable tools like Cloud LaunchPad, the ability to annotate your records easily in the same place you maintain them makes it far easier for everyone to understand why a record exists. Additionally, it makes it easier to remove unneeded clutter from your systems and to avoid perpetually dragging forward legacy entries that may in turn jeopardize your security. If you are interested in learning more about tools like Cloud LaunchPad please don’t hesitate to reach out, our team is happy to assist!

The Key Advantage of Managing DNS With Terraform

Subscribe Here For Our Blogs:

Recent Posts

Categories