I did read the canonical Q&A on meta (thank you for the pointer there). I still have a basic question about my DNS plan as I move my sites from shared hosting to a cloud server that gives me a little more knobs/dials.

Here's what I am doing - I would appreciate any critique.

I set up a DNS at AWS Route 53, using a shared delegation set.

For each site, I have a hosted zone within that delegation set that looks like this:

foo.com      A 
mail.foo.com A 
foo.com      MX    10 foo.com  
foo.com      NS    <list of my four AWS NS endpoints>  
foo.com      SOA   <first NS endpoint, hostmaster...etc>  
*.foo.com    CNAME foo.com

What is confusing to me is that my old hosting company had a whole bunch of other A records in the "dns zone" for my sites. For example:

webmail.foo.com A
cpanel.foo.com  A
ftp.foo.com     A
webdisk.foo.com A

Q1: Do I need any of these? I think 'no' because I never access the site from those subdomains, ever.

Q2: I am not sure about the MX record. I read articles that say it should point to mail.foo.com -- but in my old host it was pointing at foo.com which I followed in my new AWS zone. Under my prior host, for all my email accounts on various devices I do specify mail.foo.com as the incoming/outgoing mail server. It works fine.

Q3: Am I missing anything else important?

Trying to establish a simple, solid base set of wiring for my sites. Thanks for any help/advice you can give me.


Do I need any of these?

If you never use them, and none of your tools or scripts need them, then no. Some providers automatically fill every DNS zone with various "helpful" extra records like this.

I am not sure about the MX record.

As long as the value in the MX record contains a name that can be resolved as an A record, and that A record contains the IP address of your inbound mail server, it doesn't technically matter... but...

for all my email accounts on various devices I do specify mail.foo.com as the incoming/outgoing mail server

This is actually unrelated to the MX record. The MX is what external machines use in order to discover what host to contact in order to send incoming mail to you... which is why the target of the MX record could be either mail.example.com or example.com or something else entirely, as long as it points to the correct server.

Am I missing anything else important?

A couple of pointers from mistakes I see others make:

Don't tamper with any of the default values provided by Route 53. If you suspect they are incorrect, they aren't -- the problem is somewhere else.

Don't use a reusable delegation set. It's silly. Or, use one if you must, but not without understanding the implications. Specifically, a reusable delegation set is unlikely to have the same accuracy of results when you use geo or latency based DNS record sets, and you statistically increase the likelihood of a problem in the Route 53 infrastructure (DDoS?) impacting all of your sites, rather than only some or maybe just one of your sites. If you let Route 53 assign name servers to each hosted zone using its own algorithm, you'll find that no two hosted zones have more than 2 assigned nameservers in common, improving your overall resiliency across multiple hosted zones.

| improve this answer | |
  • Thank you for the answer. I actually have two use cases, one without using reusable delegation and the other where I need it due to domains being mapped to a Wordpress multisite. The white-label NS and shared delegation set allows me to tell clients to use a consistent set of nameservers. If the WP installation ever has to move I don't have a whole bunch of domain DNS records to update. I do understand the resiliency implication...thanks! – C C Nov 20 '16 at 21:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.