SBS2008 and SBS2011 External DNS Configuration

In order for the features of SBS2008 and SBS2011 to work correctly several DNS records are required to be configured with your domain registrar. We use 123-reg for all domain name registration and management, so screenshots will be of their control panel. The principles are the same regardless of which registrar is used.

Before you start some basic information will be required:

  • The domain name which you wish to configure. (in this example I’ll be using bluecomp.co.uk)
  • The “external” ip address of your network. This must be what is called a “Static” IP address, and will be assigned to you by your ISP – if you don’t have one of these, or aren’t sure what it is, speak to your ISP (whoever provides your broadband). This should not be an address starting “192.168.”, “10.”, “172.16-31” Or “169.254” – If you believe your external IP address is one of these, speak to your ISP and ask – as it’s almost certainly not!

Once you have this information we’re ready to start configuring DNS with the registrar’s control panel.

There are many types of DNS record – we’re mainly going to be focussing on A and MX records, with a passing look at SRV and TXT records.

  • A records are used to map a Fully-Qualified Domain Name (such as www.bluecomp.co.uk) to an IP address (such as 174.132.189.158) so that the server can be found on the internet.
  • MX records are used to tell mail servers who is responsible for email to a particular domain. They point to an A record, and have an additional attribute called “Priority”, which determines in which order servers with email for the domain will attempt to contact them. For example a common configuration would be to have 2 MX records for bluecomp.co.uk – one with Priority 10 which points to mail.bluecomp.co.uk, and another with Priority 20 which points to mail2.bluecomp.co.uk. These two addresses would in turn respectively point to the “main” and “backup” email servers for the bluecomp.co.uk domain, providing resilience in the even that one of our servers failed. Servers with emails to deliver to @bluecomp.co.uk addresses will first ask for the MX recovers for bluecomp.co.uk, and then attempt contact the in order of priority until one accepts the email. If none of them do, the sending server will retry at intervals of a few hours until either one of the servers responds or the “expiry” limit for the email is exceeded.
  • TXT records can store arbitrary text-based information. They are primarily used as part of the Sender Policy Framework to provide a list of servers that are authorized to send mail from the domain they relate to. Emails received from servers not on this list are likely to be sending spam email and the receiving server can act accordingly, either by refusing to accept the message at all, or by tagging or filtering it as spam.
  • SRV records provide a way of telling client devices where particular services can be found – for example SRV records are used for Email Autodiscovery which allows email clients such as Outlook to determine the correct settings for a particular email address without the user being required to know the details of the servers involved. Like MX records, SRV records have a “Priority” attribute. This is more complex than the other records described, so we’ll leave it until last.

We’ll be looking to set up the following records:

  • One or more MX records. These tells other servers on the internet which server is responsible for emails to this domain – one of these is usually mail.yourdomain.co.uk
  • An A record for remote.yourdomain.co.uk. Several of the useful features of SBS (such as Remote Web Workplace and Outlook Web Access) are configured to live on this address, and if your registrar doesn’t have these configured your users won’t be able to access these features remotely.
  • An A record for each server described in an MX record
  • A TXT record for SPF purposes, to prevent other servers rejecting emails from your users as spam
  • An SRV record for email autodiscovery. This can be extremely useful when configuring phones for remote email access.

For this post I’ll be using the following conventions:

My domain name: bluecomp.co.uk
My static public IP address: 81.2.3.4

And these are the records we’ll be configuring:

Record TypeRecord NameRecord ValuePriorityTTL
MX@mail.bluecomp.co.uk103600
Amail81.2.3.4N/A3600
Aremote81.2.3.4N/A3600
TXT@v=spf1 mx -allN/A3600
SRV_autodiscover._tcp0 443 remote.bluecomp.co.uk103600

 

You’ll notice there’s a couple of parameters here we haven’t yet discussed.

Record Name: This defines the name of the entry, and is prepended to the domain for which you are administering DNS – in this example the entry with a name of “mail” describes the domain name “mail.bluecompute.co.uk”. The “@” symbol is special and denotes that this entry describes the domain being administered itself, ie “bluecompute.co.uk”, as opposed to a subdomain such as “mail.bluecompute.co.uk”.

TTL: TTL stands for “Time to live” and determines how long (in seconds) the records are considered valid for once they have been retrieved. This allows other servers on the internet to save time by remembering (or “caching”) the answers they receive to DNS queries. This saves bandwidth and time, but means that it may take longer for changes to be fully effected. The TTL in this case is set to 3600 seconds, or 1 hour, which means that servers who look up this information assume it will continue to be valid for up to 1 hour after they retrieve it, and not bother to look it up again until that time expires. Your registrar may not allow you to define this manually, or may only allow it for certain record types.

Now let’s look at the records individually:

The first record is the MX record. The “@” symbol indicates that this record applies to “bluecomp.co.uk”, and the “Value” tells servers that if they have mail to deliver to @bluecomp.co.uk addresses it should contact the server “mail.bluecomp.co.uk” and deliver the messages there. As there is only one MX record for this domain, the “Priority” is ignored.

The second record is for mail.bluecomp.co.uk. This tells servers that need to contact “mail.bluecomp.co.uk” (probably to deliver email) where on the internet they can find this server. MX records must point to a domain name such as “mail.bluecomp.co.uk” and cannot point to an IP address such as 81.2.3.4. This means that the domain name in the MX record must be accompanied by an A record that points the domain name to an IP address.

The third record is for remote.bluecomp.co.uk. This is actually the same IP address as mail.bluecomp.co.uk, so technically it would have been fine to use “remote.bluecomp.co.uk” as the MX record value, and not bother adding an A record for mail.bluecomp.co.uk. The downside to this is that if in future you decided to move one or other of these services more changes would be required – with it set up this way if email was hosted externally it would only be the A record for mail.bluecomp.co.uk that required changing. It also make more logical sense to configure the separate services individually as in most environments they are entirely separate.

The fourth record is the TXT record for SPF. The “v=spf1” section specifies which version of SPF is being used (version 1 in this case) in case future versions use a different format. The “MX” section specifies which servers which are authorized to send email from @bluecompute.co.uk – in this example we simply use “MX” to indicate that any server listed in an MX record for this domain is allowed to send mail. The “-all” indicates that email received from the @bluecomp.co.uk from any server other than those listed in the “MX” section should be rejected as spam.

The final record is the SRV record for email autodiscovery. Email Autodiscovery records always have the name “_autodiscover._tcp”, and the value has a prescribed format:
<weight> <port number> <server address>
With a space separating each parameter.
The weight is similar to the priority, but is used for simple load-balancing rather than resilience. If there are multiple SRV records for a particular service, they are used according to their relative weights. Higher weights are more likely to be used, and thus see a heavier load – a server with a weight of 60 can expect to see six times as much traffic as one with a weight of 10 – specifically the probability of a particular server being selected is equal to the weight of this particular server divided by the sum of the weights for all servers for this service.
The port number tells the client which port on the server it should connect to when using the service, and the server address tells the client the name of the server it should be connecting to. As with MX records, this must be a domain name, not an IP address, and thus must be accompanied by an A record for that domain name.
In the case of Exchange Autodiscovery, the port number will almost always be 443, as this is the standard port for HTTPS connections, and this is how autodiscover information is provided.

Here’s how the records look in our 123-reg control panel. Different registrars have different systems for managing DNS – yours may not look the same as this but should be functionally equivalent.

bluecomp-dns-zone

4 Comments

  1. Thank you for posting. Great advice that came into use when we were moving to a new internet line for our SBS2008 server.

    • Admin

      Sorry for the delay approving the comment; the anti-spam-bot script caught this one and I didn’t notice. Glad the post helped you out 🙂

  2. Helped me understand and configure properly my autodiscover records. Thanks for the post.

  3. Steve

    Great article thank you very much helped me understand the txt and spf more clearly and why its needed.

    Keep up the good work

Leave a Comment

*