You’re setting up a company (or a new division or maybe even a new brand) and you’d like to use email to communicate with your customers. In this series of posts I’m going to touch on some of the things you can do today to make email life easier for you in the future. Today’s final post is on DNS hosting and setup.
5. DNS hosting
DNS is what lets you actually use the domain you’ve registered. It lets people find your website, find your mailserver and everything else you do online. Because of that, it’s a critical service, as if your DNS is down, all your online presence down.
It’s not too difficult to run DNS yourself on your own server – we run part of our DNS infrastructure on a virtual server we rent from chunkhost for a few dollars a month – but it works just as well to use a third-party service for it. There are dedicated DNS providers, such as zoneedit, ultradns, dyndns and many others, but it’s also a service that many of your existing service providers probably offer too. Your web host, your ISP and your domain registrar probably offer DNS hosting bundled for free with your other services – and that’s good enough if you’re just starting out.
There are some things the DNS provider you choose must be able to offer:
- They must be prepared to host your domain. That sounds obvious, but some providers will only serve DNS for domains registered through them, or for websites they host.
- They must provide a way for you to see and edit your DNS yourself, typically via a web interface – some providers will happily host your DNS, but only let their staff modify it. If you’re trying to diagnose a problem in an emergency trying to do that via opening support tickets is going to be painful.
- They must offer MX records, with the ability to point to hosts outside the domain (allowing you to outsource your corporate mail service easily, if needed)
- They must offer TXT records, not just “support SPF”. This is needed to set up SPF records and some implementations of DKIM, needed for email and brand authentication (amongst other things) and is useful to prove you own the domain for things like Google webmaster tools.
- They must offer NS records, allowing you to delegate parts of your domain to someone else. This is needed to set up some implementations of DKIM, needed for email and brand authentication.
6. Set up your DNS
The details will vary but to give you some idea of how a DNS zone can look here’s a sample dns zone for a fairly minimal setup for the domain tupid.org, with DNS hosted by hover, a webserver at 184.105.179.153 and a mailserver (for both inbound and outbound mail) at 66.172.33.225, using SPF but no other authentication. The magic number 86400 is the number of seconds in a day – it means that we’ll ask the internet to cache these results for one day.
; The two nameservers for the domain - these must match the domain registration tupid.org 86400 NS ns1.hover.com tupid.org 86400 NS ns2.hover.com ; The webserver, both with and without it's www. www.tupid.org 86400 A 184.105.179.153 tupid.org 86400 A 184.105.179.153 ; The mailserver tupid.org 86400 MX 10 mail.tupid.org mail.tupid.org 86400 A 66.172.33.225 ; SPF records for the mail we send tupid.org 86400 TXT "v=spf1 ip4:66.172.33.225 ~all"
And here’s how that might evolve, if we keep using our own mailserver, but also send some bulk mail through ExactTarget and we set up a “corporate” mail subdomain – corp.tupid.org – as we discussed in part one. To make things interesting, we’ll host our corporate email via Google Apps, and we’ll set up some DKIM for our customer facing mail (using the DKIMCore approach).
; The two nameservers, just as before tupid.org 86400 NS ns1.hover.com tupid.org 86400 NS ns2.hover.com ; The webserver, just as before www.tupid.org 86400 A 184.105.179.153 tupid.org 86400 A 184.105.179.153 ; Our main mailserver tupid.org 86400 MX 10 mail.tupid.org mail.tupid.org 86400 A 66.172.33.225 ; Our SPF record for our customer facing domain tupid.org 86400 TXT "v=spf1 ip4:66.172.33.225 include:cust-spf.exacttarget.com ~all" ; DKIM for mail sent through us 1330146224.tupid._domainkey.tupid.org. 86400 TXT ( "v=DKIM1;t=s;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCyR8fIJ5EVHkAap+qPnh/hHYQx" "Cw4cMDY8RoHG2C1EfNCl0Kj6sZm5D8I42aB71nSxOyv6SwwlOa7VZx5vFe7VXkXp" "YKHQNR+ulpFCdrT2qp/K6G7wKRgdkzGNhQCvxUaAelOgviWIl+NkfnwvvMMiN5Gy" "yD2oIFhQXB0h1tlf4wIDAQAB") ; DKIM for mail sent through ExactTarget exacttarget._domainkey.tupid.org 86400 NS dkim1.exacttarget.com exacttarget._domainkey.tupid.org 86400 NS dkim2.exacttarget.com email.tupid.org 86400 MX 10 reply.exacttarget.com ; Our corporate email, via google corp.tupid.org 86400 MX 1 aspmx.l.google.com corp.tupid.org 86400 MX 5 alt1.aspmx.l.google.com ; SPF for our corporate domain corp.tupid.org 86400 TXT "v=spf1 ip4:66.172.33.225 include:_spf.google.com ~all"
And that’s it – the basics of setting up DNS for an email-friendly company.
RSS - Posts
Great Information Steve.. You’re spot on.
Once you get everything set up, like Steve mentioned, you can validate it all by sending an email to “mailtest@unlocktheinbox.com” and it will auto-respond letting you know, if everything is setup correctly.
Great advice overall, but some notes;
With regard to the ability to edit DNS yourself (5.2); this can be handy in a pinch, but only if you truly understand DNS, and know what you are doing. A whole lot of people do not understand DNS, including many, many systems administrators.
Due to the cached nature of DNS, editing mistakes can take up to 48 hours to resolve. The opportunities for editing mistakes using most web interfaces I’ve seen are many, because writing a good web interface for DNS that doesn’t require the user to understand what they’re doing while still allowing for full freedom is very hard, if not impossible.
In a properly configured system, DNS changes are rare. They are also best planned in advance, again due to the cached nature of the system. Most DNS emergencies are going to be due to lack of planning, or lack of understanding of the system, and that extra half an hour it takes to get a hold of someone who can fix it for you will rarely make the difference.
So, unless you are comfortable with the ins and outs of DNS, please consider having someone with DNS expertise set up your domains for you according to their intended purpose, help you avoid the common mistakes, and manage it for you.
—
While we’re on the topic of ‘mistakes’, let’s consider the ‘tupid.org’ example above;
1) With the exception of the domain record itself (tupid.org A 184.105.179.153) there should ideally only be a single (1) A record for every IP address in your zone. This record should have a matching reverse (PTR) record as well, especially for the mail server. This record should be a unique name that helps you identify which server this points to, and should ideally be independent of role. Everything else (especially roles such as ‘www’ and ‘mail’) happens with canonical name (CNAME) records.
Staying with the example above and naming our servers ‘audrey’ and ‘marilyn’, you’d end up with;
@ A 184.105.179.153
audrey A 184.105.179.153
marilyn A 66.172.33.225
www CNAME audrey.tupid.org.
mail CNAME marilyn.tupid.org.
This way, if the website ever moves to ‘marilyn’ or mail handling to ‘audrey’, it’s a simple matter of adjusting the CNAME record. And if ‘marilyn’ moves to a different IP address, because she runs on a residential connection and you just switched from DSL to fiber for example, it’s one (1) change that updates all DNS records that point to it.
Again, make sure the reverse DNS matches as well.
2) Avoid specifying the TTL for individual records and use the zone TTL instead, unless you need to make an exception. Less clutter in your DNS zone lowers the chance of mistakes when you are in a hurry to resolve a DNS emergency.
3) I am quite sure the above example would fail to work, because any record specified without a terminating dot (.) is assumed to be a subdomain. If you would query the original zone for its nameservers for example, you’ll likely end up with ‘ns1.hover.com.tupid.org.’ as the answer. Which doesn’t exist, and will therefore fail.
If you want to specify a full name, terminate it properly, like in the CNAME example given above, and the DKIM record in the original example.
—
Again, I would strongly suggest that, unless you are comfortable with DNS management, you let someone who is do it for you. DNS is the foundation on which everything else is built, and mistakes can prove very costly to correct, whether it’s in emergencies, migrations, or what have you.
@Jona The example I give isn’t in bind format. It’s in a generic format that’s similar to the format you get in most web-based zone editors (no IN, no trailing periods, no use of bind macros and so on).
Many of the issues you point out only apply when someone is manually editing a bind-format zone file – and if you’re doing that, you already have some problems with your infrastructure. I’m intimately familiar with DNS (I used to be a developer at UltraDNS) and I don’t manually edit zone files if I can avoid it – I use a web-based interface to my PowerDNS instance for day-to-day work.
As for CNAMEs… in-zone CNAMEs are never a good idea in DNS performance terms, nor in manageability terms so I’d never suggest using them. Where CNAMEs are unavoidable is when you’re pointing to hostname in a zone you don’t control. I know that many of the old bind tutorials (and hence many of the zones you see) use CNAMEs for www. and so on, but it’s poor practice.
An added advantage of avoiding in-zone CNAMEs is that it helps avoid mistakes like the one you make with your MX record. MX and NS records should never, ever point at a CNAME as they’re not being handled as part of additional record processing – which is why it’s explicitly forbidden by RFC 2181. CNAMEs are evil, avoid them whenever possible.
I have re-read my comment and searched the page for ‘MX’, but I really can’t seem to find where I made a mistake with my MX record. In fact, I seem to not have mentioned the MX record at all? Though I guess you could argue that calling a CNAME a ‘canonical name’ instead of an alias is bad, based on the warning in RFC 2181 😉
In my example, the MX record would have been thus;
@ MX 10 marilyn.tupid.org.
Which resolves to an A record. Perfectly valid, right? The ‘mail’ record simply exists as a convenient shorthand (an alias!) for users, to type into their e-mail clients, browsers and the like. Another convenient one would be ‘webmail’, for example.
And yes, pointing it to a CNAME would be very bad. I’ve seen this happen, and it’s one of the reasons why I advocate that people leave their DNS management in the hands of someone who knows to avoid things like this, if they are not as intimately familiar with DNS as you seem to be.
As for CNAMEs being evil, really? Google uses them, for example, and their engineers seem to be rather performance minded. Does that truly make a difference, from the perspective of the actual user at a newly started company?