Short takes: @ in DNS records; are ‘ and & legal in an email address?; changing the search base for IDfix

A few short items that don’t quite warrant their own blog post…

@ in DNS records

Whilst working with a customer on their Office 365 integration recently, we had a requirement to add various DNS records, including the TXT record for domain verification which included an @ symbol. The DNS provider’s systems didn’t allow us to do this, or to use a space instead to denote the origin of the domain. Try googling for @ and you’ll have some challenges too…

One support call later and we had the answer… use a *.  It seemed to do the trick as soon after that the Microsoft servers were able to recognise our record and we continues with the domain configuration.

Are ‘ and & “legal” in an email address?

Another interesting item that came up was from running the IDfix domain synchronisation error remediation tool to check the on-premises directory before synchronisation.  Some of the objects it flagged as requiring remediation were distribution groups with apostrophes (‘) or ampersands (&) in their SMTP addresses. Fair enough, but that got me wondering how/why those addresses ever worked at all (I once had an argument with someone who alleged that the hyphen in my wife’s domain name was an “illegal” character). Well, it seems that, technically, they are allowable in SMTP (I struggled reading the RFCs, but Wikipedia makes it clearer) but certainly not good practice… and definitely not for synchronisation with Azure AD.

Changing the search base for IDfix

I mentioned the IDfix tool above and, sometimes, running it against a whole domain can be difficult to cope with the results.  As we planned to filter directory synchronisation on certain organizational units (OUs), it made sense to query the domain for issues on those same OUs. This is possible in the settings for IDfix, where the LDAP query for the search base can be changed.

Website moving to a new server…

My hosting provider has told me that they are moving this website to a new server over the weekend.

All being well, the move will be transparent but I will also need to point the domain names at new DNS servers, so, if I disappear offline for a while on Sunday night, please bear with me and I should be back again once the interwebs have updated…

Domain management for Office 365 (Small Business)

A few weeks ago, I wrote about configuring DNS for Exchange Online in Office 365. In that post, I mentioned that Microsoft is only supporting small business customers with domains that are delegated to (i.e. hosted on) Microsoft’s name servers – currently ns1.bdm.microsoftonline.com and ns2.bdm.microsoftonline.com.

I wasn’t entirely comfortable with this (for a start, the Office 365 DNS Manager is best described as “basic”), so I decided to see what happens if I went through the process, but never actually switched over the name server records… as it happens it seems to work quite well (albeit in an unsupported manner).

If you want to retain control of settings, all that’s involved is creating the same records with an external DNS provider.

For reference, on the markwilson.co.uk domain, these would be:

markwilson.co.uk. 3600 IN MX 0 markwilson-co-uk.mail.eo.outlook.com.
autodiscover 3600 IN CNAME autodiscover.outlook.com.
markwilson.co.uk. 3600 IN TXT "v=spf1 include:outlook.com ~all"
SRV _sip _tls 443 1 100 sipdir.online.lync.com. markwilson.co.uk 3600
SRV _sipfederationtls _tcp 5061 1 100 sipfed.online.lync.com. markwilson.co.uk 3600

Of course, if Microsoft changes the server names, you won’t be notified and that might affect your service but the settings seem to be the same as the ones provided to Enterprise customers as part of their domain management process.

Then, go through the normal process to add a domain to Office 365, but just click Next on the Edit Name Server Records page:

Ignore the step that advises changing DNS entries

At the time of writing, Office 365 is still in beta, so things could change (for example, the domain verification process has already switched from using CNAME records to using either TXT or MX records) but it might be worth a try…

[Update 20 June 2011: Microsoft has documented a workaround for domains that do not allow delegation (specifically for .NO and .DK but I see no reason why other domains should not be used in this way)]

Configuring DNS for Exchange Online in Office 365

Readers who follow me on Twitter (@markwilsonit) may have noticed that I was in a mild state of panic last night when I managed to destroy the DNS for markwilson.co.uk.  They might also have seen this website disappear for a few hours until I managed to get things up and running again. So, what was I doing?

I’ve been using Google Apps for a couple of years now but I’ve never really liked it – Docs lacks functionality that I have become used to in Microsoft Office and Mail, though powerful, has a pretty poor user interface (a subjective view of course – I know some people love it).  When Microsoft announced Office 365 I was keen to get on the beta, and I was fortunate enough to be accepted early in the programme.  Unfortunately, at that time, the small business (P1) plan didn’t allow the use of “vanity domains” (what exactly is vain about having your own domain name? I call it professionalism!) so I waited until I was accepted onto the enterprise (E3) beta. Then I realised that moving my mail to another platform was not a trivial exercise and, by the time I got around to it several weeks had gone by and it is now possible to have vanity domains on a small business plan!

Anyway, I digress: migrating to Office 365, how was it? Well, first up, I should highlight that the DNS issues I had were nothing to do with Microsoft – and, without those issues, everything would have been pretty simple actually.

Microsoft provides a portal to administer Office 365 accounts and this also allows access to the Exchange Online, Lync Online and SharePoint Online components.  In that regard, it’s not dissimilar to Google Apps – just a lot more pleasant to use. So far, I’ve concentrated on the Exchange Online and Outlook Web App components – I’ll probably blog about some of the other Office 365 components as I start to use them.

The e-mail address that Microsoft gave me for my initial mailbox is in the form of user@subdomain.onmicrosoft.com. That’s not much use to me, so I needed to add a domain to the account which involves adding the domain, verifying it (by placing a CNAME record in the DNS for the appropriate domain – using a code provided by Microsoft, resolving to ps.microsoftonline.com.) and then, once verified, configuring the appropriate DNS records. In my case that’s:

markwilson.co.uk. 3600 IN MX 0 markwilson-co-uk.mail.eo.outlook.com.
autodiscover 3600 IN CNAME autodiscover.outlook.com.
markwilson.co.uk. 3600 IN TXT "v=spf1 include:outlook.com ~all"

These are for Exchange – there are some additional records for Lync but they show how external domain names are represented inside Office 365.

[Update 17 June 2011: The DNS entries for Lync are shown below]

SRV _sip _tls 443 1 100 sipdir.online.lync.com. markwilson.co.uk 3600
SRV _sipfederationtls _tcp 5061 1 100 sipfed.online.lync.com. markwilson.co.uk 3600

The . on the end of the names and the quotes on the TXT record are important – without the . the name resolution will not work correctly and I think it was a lack of " " that messed up my DNS when I added the record using the cPanel WebHost Manager (WHM), although I haven’t confirmed that.

With the domain configured, additional email addresses may be added to user accounts and, once DNS propagation has taken place, mail should start to flow.

Before I sign off, there are a few pieces of advice to highlight:

  • After I got everything working on the Office 365 Enterprise (E3) plan, I realised that I’d be better off using the Small Business (P1) plan. This wasn’t a simple subscription choice (I hope it will be in the final product – at the time of writing Office 365 is still in beta) and it involved me removing my “vanity” domains from all user objects, distribution groups, contacts and aliases, then removing the domain from Office 365, and finally going through the process of adding it using a different Microsoft Online account.
  • Before making DNS changes, it’s worthwhile tuning DNS settings to reduce the time to live (TTL) to speed up the DNS propagation process by reducing the time that records are stored in others’ DNS caches.
  • Microsoft TechNet has some useful advice for checking DNS MX record configurations with nslookup.exe but Simon Bisson pointed me in the direction of the Microsoft Exchange Remote Connectivity Analyzer, which is a great resource for checking Exchange ActiveSync, Exchange Web Services and Office Outlook connectivity as well as inbound and outbound SMTP email.
  • Microsoft seems to have decided that, whilst enterprises can host their DNS externally, small businesses need to host their DNS on Microsoft’s name servers (and use a rather basic web interface to manage it).  I’m hoping that decision will change (and I’m led to believe that it’s still possible to host the DNS elsewhere, as long as the appropriate entries are added, although that is an unsupported scenario) – I’m trying that approach with another domain that I own and I may return to the topic in a future blog post.

Now I have my new mailbox up and running, I just need to work out how to shift 3GB of email from Google Apps to Exchange Online!

Using DHCP reserved client options for certain devices

I’ve been struggling with poor Internet connectivity for a while now – the speed is fine (any speed tests I conduct indicate a perfectly healthy 3-5Mbps on on “up to 8Mbps” ADSL line) but I frequently suffer from timeout, only to find that a refresh a few moments later brings the page back quickly.

Suspecting a DNS issue (my core infrastructure server only has a Atom processor and is a little light on memory), I decided to bypass my local DNS server for those devices that don’t really need it because all the services they access are on the Internet (e.g. my iPad).

I wasn’t sure how to do this – all of my devices pick up their TCP/IP settings (and more) via DHCP – but then I realised that the Windows Server 2008 R2 DHCP service (and possibly earlier versions too) allows me to configure reserved client options.

I worked out which IP address my iPad was using, then converted the lease to a reservation. Once I had a reservation set for the device, I could configure the reserved client options (i.e. updating the DNS server addresses to only use my ISP servers, OpenDNS, or Google’s DNS servers).

Unfortunately I’m still experiencing the timeouts and it may just be that my elderly Solwise ADSL modem/router needs replacing… oh well, I guess it’s time to go back to the drawing board!

Managing simultaneous access to resources from both internal and external DNS namespaces

When I originally set up my Active Directory, I used an internal DNS namespace, with a .local TLD (as was the advice at the time – no longer recommended). Essentially, my external domains are managed by my hosting providers and I manage the internal namespace. Simple.

Then I set up a few Internet-facing resources at home. I decided to create a secondary forest using a subdomain of my main external DNS namespace so that:

  • domain.local was the AD-integrated DNS for internal (private) resources.
  • domain.tld was managed by my hosting provider for external resources.
  • subdomain.domain.tld was the AD-integrated DNS for Internet-facing resources under my control.

I also added a forwarding rule on the DNS server to send requests for subdomain.domain.tld to the authoritative DNS server for the domain (under my control) but to send requests for domain.tld and all other domains to the ISP’s DNS servers.

That worked well but, because my mail server is known by two different names internally and externally (mailserver.domain.tld for external access and mailserver.subdomain.domain.tld for internal access) and these actually resolve to the same physical server, I get certificate errors when using the internal name. Furthermore, I’m unable to access the server from inside my firewall using the external name, because the mailserver.domain.tld name actually resolves to the IP address of my router, from where which IP filtering and NAT forwarding rules allow the packets to be forwarded to the mail server.

I needed mail clients to work with the same server name (mailserver.domain.tld) whether they were accessing the server on the internal or external networks, so I made some changes:

  1. My hosting provider sent me a copy of the DNS zone file for mailserver.domain.tld and I imported this to my internal DNS server.
  2. Next, I deleted the forwarding rule for mailserver.domain.tld (leaving the one for subdomain.domain.tld in place).
  3. Then, I edited the entries for the servers that needed to be accessed with the same name internally and externally so that instead of resolving to the external IP address of my router, they resolved to the actual IP address of the server (which uses an RFC 1918 internal IP address range).
  4. Finally, nslookup helped me to confirm that the addresses were resolving correctly on the internal and external networks – effectively getting one set of results in the Internet from my hosting provider and another set on the internal network from my DNS server.

The new setup looks like this (note that the IP addresses have been changed to protect the innocent):

Managing internal and external DNS lookups to the same resource

Now I can seamlessly access my mail server using the same DNS name (mailserver.domain.tld) from wherever I roam to.

Improvements in Windows Server 2008 DNS

Windows administrators have been waiting to see the back of WINS for years but many applications still rely on single name lables (and multiple DNS name suffixes can become unwieldy). Windows Server 2008 DNS will provide an alternative through its GlobalNames zone (one of several improvements in Windows Server 2008 DNS).

Although it’s not listed in the article linked above, I understand (from Scotty McLeod) that Windows Server 2008 DNS allows the application of a conditional forward (globally – i.e. to all DNS servers) at the domain level; unfortunately, forwarder information still has to be defined on a server-by-server basis.

Implementing SenderID Framework records for my e-mail server

I recently read Craig Spiezle and Alexander Nikolayev’s TechNet Magazine article about the SenderID Framework (SIDF) – one of the available schemes to validate mail servers in the fight to reduce unsolicited commercial e-mail (UCE), more commonly known as spam.

SIDF is similar to the Sender Policy Framework (SPF) in that it uses specially-formatted TXT records in DNS (called SPF records) to detail the mail exchange (MX) servers that SMTP e-mail may originate from for a given domain, and any other domain names that may be used.

I’d decided some time ago to implement an SPF record for my domains but my hosting service provider at the time did not support the use of TXT records. Since I moved to ascomi a few months back that’s not been an issue and last night I finally requested that the changes were made.

There are a variety of tools online to help create SPF records, but the first problem I had was the need to decide whether to use OpenSPF, SenderID, or an alternative (such as Domain Keys). In the end, I decided to go with SenderID – largely because the Microsoft SenderID website helped me create an SPF record which supported the both SenderID Mail From method (identical to the SPF method) and the SenderID Purportedly Responsible Address (PRA) header method. Finally, to validate that my record was correct, I sent an e-mail to check-auth@verifier.port25.com and used the Email Service Provider Coalition verification tools – Microsoft also publishes a short implementation guide for SIDF which is worth a read.

The differences between SPF formats are discussed on the OpenSPF site too (and OpenSPF also has tools to help create the necessary records) but the OpenSPF guys seem to be more interested in saying why SenderID violates the standards and shouldn’t really be called SPF (I call that the “not invented here” syndrome) than in actually helping people work out how to stop spam.

It’s also worth pointing out that my SPF record will not directly affect the volume of spam that I receive; it will, however, help others who perform SPF lookups to determine if mail that appears to come from one of my domains really originated from a server which I authorised. Even then, they may elect to retain the message, or they may drop it – that’s no different to today but as more and more SPF records are published, the volume of spam on the Internet should drop considerably as all messages are effectively authenticated as having passed through an authorised MX for the stated domain name.

Sender verify failed with incorrect reverse DNS record

What a week! Switching hosting providers, setting up a new content management system for this blog (more on that as soon as it’s ready) and all at the same time as suffering e-mail problems as, since the middle of the week, every e-mail that I’ve sent to a particular contact has bounced back with the following message:

This is an automatically generated Delivery Status Notification.

Delivery to the following recipients failed.

someone@somewhere.net

Reporting-MTA: dns;mymailserver.markwilson.co.uk

Final-Recipient: rfc822;someone@somewhere.net
Action: failed
Status: 5.5.0
Diagnostic-Code: smtp;550-Verification failed for <
myalias@markwilson.co.uk>
550-No Such User Here
550 Sender verify failed

I have various anti-spam measures on my mail server, but this appeared to be a problem when sending mail to a particular external host – e-mail sent to the same contact via a different mail server was received with no problems.

I set about researching the 550 Sender verify failed message and found various suggestions as to what might cause such an error – the most useful of which was a message on a newsgroup post which suggested it may be caused by an incorrect reverse DNS (PTR) record (thanks to Ben Winzenz for replying to that group a couple of years ago).

Even though much of my mail was being delivered successfully, that seemed like a perfectly reasonable explanation – the reverse lookup for my IP address would have returned a hostname in the format username.myisp.co.uk, rather than mymailserver.markwilson.co.uk (as confirmed by a DNS report on my domain, which also commented that “RFC1912 2.1 says you should have a reverse DNS for all your mail servers. It is strongly urged that you have them, as many mailservers will not accept mail from mailservers with no reverse DNS entry”), so I set about getting the record updated by my ISP (it has to be done by the owner of the IP address block).

Initially I asked my ISP to add my mail server’s DNS name as a second PTR record for my IP address but in practice I found that DNS responded in a round robin pattern (rather than returning all the matching records) so I couldn’t rely on a consistent response and was still experiencing mail delivery failures. Finally, after reverting to a single PTR record for my IP address and waiting for DNS propagation (again), I was able to successfully send e-mail to the contact with whom I’d previously experienced issues (phew!).

As more and more hosts take action to prevent unsolicited commercial e-mail (UCE – also known as spam), this is likely to be a more common occurrence and it just underlines how important a correct DNS configuration is.

DNS and operations master roles placement with Active Directory

I had a call last night from a client who is implementing Active Directory (AD) in his organisation and was trying to resolve some replication issues. Like so many problems in AD the issue was related to the DNS configuration and once I had made a few configuration changes on the DNS servers to build a forwarding hierarchy from the remote sites to the head office and then on to the ISP, everything started to work.

Whilst I was looking over his domain I also noticed that there was only a single global catalog (GC) server – the first domain controller that he’d installed (the same DC that was holding all the operations master roles, although in his single domain forest the co-hosting of the infrastructure master and GC roles will not cause problems with phantom indexes as described in Microsoft knowledge base article 248047).

Microsoft knowledge base article 825036 describes best practices for DNS client settings in Windows 2000 Server and in Windows Server 2003 whilst Microsoft knowledge base article 223346 discusses the placement and optimisation of operations master roles.