DNS is hosted with Media Temple - I mentioning this only because I am curious if my logic is wrong or if this is specific to the way the Media Temple front end is translating input from the edit form into the zone file.

MX records point to Google Apps. Three A records point to the web server. Media Temple DNS editor contains 3 fields: name, type, data. The A records are configure as such:

"blank" (literally the field is blank) - A - IP Address of web server 
* (wildcard) - A - IP Address of web server
www - A - IP Address of web server

New website was built on a different host. Each of the above captioned A records was converted into a CNAME record pointing the same 3 "names" (hosts) to ext.squarespace.com.

Mail flow stopped to Google Apps.

My-MacBook-Air:~ me$ dig MX example.com

; <<>> DiG 9.8.3-P1 <<>> MX example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64625
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

 ;example.com.      IN  MX

example.com.    15680   IN  CNAME   ext.squarespace.com.

squarespace.com.    60  IN  SOA ns1.p06.dynect.net.     domains.squarespace.com. 1101726 3600 600 604800 60

When I removed the blank and * records, the same query returned the expected response (Google Servers). My question is: why does this configuration result in the above captioned response? My logic for the record that resolves example.com. (FQDN) to the web host was to deal with the event that an individual does not include the www prefix.

1 Answer 1


Your first record ("blank"/apex/root) can, but probably shouldn't, be a cname; see How to overcome root domain CNAME restrictions? on Stack Overflow:

This is often attempted by inexperienced administrators as an obvious way to allow your domain name to also be a host. However, DNS servers like BIND will see the CNAME and refuse to add any other resources for that name. Since no other records are allowed to coexist with a CNAME, the NS entries are ignored. Therefore all the hosts in the podunk.xx domain are ignored as well!

So, in short: If you have a cname as your apex, all bets are off as to whether or not any other records work inside the zone.

See also:

  • Based on your answer and the resources you linked to it appears that this is specific to setting a CNAME record for the root name. Can it be problematic to set an A record for the root name? I have never had to deal with a web host requested a CNAME instead of an a record. It ended up not being a problem because there is a 301 permanent redirect in place - which is obviously the better solution in retrospect.
    – sardean
    Jan 10, 2014 at 3:53
  • 1
    Having an A record at the root is totally appropriate and normal. Jan 10, 2014 at 3:53
  • Not always: devcenter.heroku.com/articles/apex-domains Jul 25, 2014 at 15:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .