Hokay. Let's talk about the current state of our DNS.
So as we should all be aware of by now, we have new Name Servers on AWS and we want to migrate all users to our Name Servers on AWS. The vast majority of our clients are still using our old Name Servers on Rackspace - this isn't necessarily a bad thing, their sites will still work fine here, but the idea is that both the client and us will want to move their domain to the AWS Name Servers.
So what does all that mean?
Well, essentially any time you have a ticket involving MX records or just about anything DNS related, we will want users to point their nameservers to our new AWS Name Servers:
ns1.rgnameserver.com
ns2.rgnameserver.com
ns3.rgnameserver.com
ns4.rgnameserver.com
OK, so I get that, but what do we do to make their site work still?
Good question! In MCP there is a 'Syncdns' tool that when used, will add their domain to our AWS Route 53 system. If you don't syncdns a site, it will not appear in AWS, so you must do this anytime we recommend a client moves to our new nameservers.
So wait, we were trying to setup their email - isn't there something we need to do about that?
Correct! In MCP under Server Settings there is a 'Dns Records' option. This is used for setting MX records.
The most common ones to use are 'google' for google apps and 'godaddy' for the basic godaddy email. After setting the appropriate option, you will need to syncdns for this site again.
Here are the records for google and godaddy:
Google MX Records:
MX 1 ASPMX.L.GOOGLE.COM
MX 5 ALT1.ASPMX.L.GOOGLE.COM
MX 5 ALT2.ASPMX.L.GOOGLE.COM
MX 10 ALT3.ASPMX.L.GOOGLE.COM
MX 10 ALT4.ASPMX.L.GOOGLE.COM
Godaddy MX Records:
mailstore1.secureserver.net - priority 10
smtp.secureserver.net - priority 0
It's important to note that Godaddy is also a reseller for Office 365, so it's important to make sure you are setting up the right MX records. If the client is unsure and haven't taken the site live, you can try using mxtoolbox.com to check what their current records are.
What about all these crazy records? What's a CNAME/SRV/TXT record?
Well, the most common 'pile of records' we will see in zendesk would be office 365 which is commonly provided through Godaddy.
Here's an example of what a client may send for their office 365 pile of DNS records:
A @ 184.168.221.38 600 seconds Edit
CNAME autodiscover autodiscover.outlook.com 600 seconds Edit
CNAME email email.secureserver.net 600 seconds Edit
CNAME ftp @ 1 Hour Edit
CNAME lyncdiscover webdir.online.lync.com 600 seconds Edit
CNAME msoid clientconfig.microsoftonline-p.net 600 seconds Edit
CNAME sip sipdir.online.lync.com 600 seconds Edit
CNAME www @ 1 Hour Edit
MX @ example-com.mail.protection.outlook.com (Priority: 0) 600 seconds Edit
TXT @ MS=ms23697786 600 seconds Edit
TXT @ v=spf1 include:spf.protection.outlook.com -all 600 seconds Edit
SRV _sip._tls.@ 100 1 443 sipdir.online.lync.com 1/2 Hour Edit
SRV _sipfederationtls._tcp.@ 100 1 5061 sipfed.online.lync.com 1/2 Hour Edit
NS @ ns47.domaincontrol.com 1 Hour
NS @ ns48.domaincontrol.com 1 Hour
It's important to understand the difference between all of these. First that A record is something specific to their old domain with their old vendor/domain provider, in the majority of cases we don't add this A record. Similarly we don't add those nameservers at the end, in this example, those are godaddy's nameservers. All those CNAME/MX/TXT/SRV though need to be added for their DNS records to be set up properly for office 365. For more information on Office 365 DNS records, check this out:
Here is an example of records that are set correctly:
https://console.aws.amazon.com/route53/home?region=us-east-1#resource-record-sets:Z292QSDLUHL1HZ
Example: How to add a CNAME
Step 1: Select "Route 53" in AWS
Step 2: Select "Hosted zones"
Step 3: Search for the Domain Name
Step 4: Select "Create Record Set"
Step 5: Enter in the New Record
This is how the information should be entered
Example: SRV Record
Ok, what I'm seeing doesn't look at all like that... It's just an MX record pointing to an IP address.
Whoa cool! They are using something pretty custom, but we can get that to work too. The way to handle these is you set an MX record that points to mx.theirdomain.com and set an A record that points mx.theirdomain.com to the IP address they provide. Simple.
Anything else?
Well. I think that about covers it. If there's anything I missed, please feel free to update this doc or ask me about it.
More things yay: MX records - double names
If you need to add an MX record, but there's already an MX record with the same name, you need to remove that MX record they had and replace it with the one you need to add.
Also make sure that you take a screenshot and add as an internal note to the ticket before you remove it just in case.