A Recipe for a Long Weekend - AWS Route53, GoDaddy, and the Dark Side

• dns aws route 53 godaddy star wars tld zone file

Do not underestimate the power of the dark side -- Vader

Recently, I transfered the DNS for several sites from GoDaddy over to AWS Route53 Hosted Zones. As is typical for most good devs, I over-optimistically thought that critical updates on Friday would be fine - I know what I'm doing, right?

To start the process, I went to the GoDaddy DNS console for each site and selected the option to export a zone file.

GoDaddy Zone File Export

I then went to the AWS console, navigated to Route53, created a new hosted zone for the domain, and then selected the option to import a zone file.

AWS Route53 Zone File Import

Aside from a couple of tweaks and fixing a txt record that was too long, everything seemed to go splendidly. I proceeded to think happy thoughts and go about enjoying my weekend. However, not all was well with the force.

About 1300 on Sunday, I got a call that one of our customers couldn't receive or send email for their domain - yikes. That's a way to ruin a weekend in a hurry. I didn't have a clue what the problem was until I talked with my boss who said that I forgot the trailing . on for the MX records - he was bitten by the same issue a few months ago.

Clear your mind must be, if you are to find the villains behind this plot -- Yoda

Needless to say, I was pissed and wanted to know why AWS hadn't imported the BIND zone file correctly. It turns out that there's a documented issue (or feature, haha) with the AWS Zone File importer where it adds domains without a trailing . to the current domain.

If you use the GoDaddy export process to create a zone file, you might need to edit the zone file to add a trailing dot to MX resource record sets before you import the zone file into your hosted zone.

The export process currently doesn't add a trailing dot to the fully qualified domain names of MX resource record sets, so the Amazon Route 53 import process adds the domain name to the name of the resource record set.

For example, suppose you're importing resource record sets into the hosted zone example.com and the name of an MX record in the zone file is mail.example.com, with no trailing dot. The Amazon Route 53 import process creates an MX resource record set named mail.example.com.example.com.

In other words, a few MX records turn from this:

; MX Records
@	3600	IN	MX	1	ASPMX.L.GOOGLE.COM
@	3600	IN	MX	10	ALT4.ASPMX.L.GOOGLE.COM
@	3600	IN	MX	5	ALT2.ASPMX.L.GOOGLE.COM
@	3600	IN	MX	10	ALT3.ASPMX.L.GOOGLE.COM
@	3600	IN	MX	5	ALT1.ASPMX.L.GOOGLE.COM

Into a freakish beast of a creature that only Emperor Palpatine would love:

AWS Route53 MX Records Imported without the trailing dot

It doesn't stop at MX records, however:

AWS Route53 CNAME Record Imported without the trailing dot

Yeah, mind blown, right?

I am your father. Search your feelings. You know it to be true. -- Vader

It makes sense if you read the docs, I guess, but oh my it's infuriating that you can't just import a zone file and assume that all is well with the force.

Basically, AWS interprets records without the trailing . as belonging to the domain for the hosted zone. If they contain the . then the importer interprets them as a FQDN (fully qualified domain name).

When the name of a resource record set in the zone file includes a trailing dot (example.com.), the import process interprets the name as a fully qualified domain name and creates an Amazon Route 53 resource record set with that name.

When the name of a resource record set in the zone file does not include a trailing dot (www), the import process concatenates that name with the domain name in the zone file (example.com) and creates an Amazon Route 53 resource record set with the concatenated name (www.example.com).

I hope this saves someone from a long weekend.

If you end your training now - if you choose the quick path as Vader did - you will become an agent of evil (or wreck your weekend, you will) -- Yoda