Disclaimer:

I’ve got nearly 25 years experience in the IT game with a range of skills that take in this task – DNS, Email, Web-Servers. However, for the last 15 years or more I’ve more or less outsourced the management of this to a third-party, or it simply hasn’t been my job. Once I used to teach Active Directory DNS to students when I was a Microsoft Certified Trainer, but that was way, way, way back in 1996-2003. Of course, there’s nothing new under the sun, as the Great Bard once said – and so I have gotten by ever since with core fundamentals. So this is both old and new too me, and if I was to be honest I’m not sure if the solution to my problem was the best or easiest. I might have just taken a sledgehammer to drive home a thumb tack. I’d be interesting hear if this process could made infinitely more simpler.

I think the ‘order’ of my process is good – especially as you need valid emails to confirm the transfer and setup of certain domains. But I’d also be interested that is this is the best way of doing it – could it have been done more efficiently in fewer steps. Finally, I’d be interested to know if this the ‘right’ way from a security and best practise perspective as well.

Preamble:

I would have liked to have a more exciting title to this blogpost – and one infinitely shorter!  Being a Hunter S Thompson fan, I had thought of adding “A Strange and Terrible Saga”. But I actually I want to avoid the rabbit of an extended rant, and the convoluted shaggy-dog story of my experiences on Friday. It took me 6hrs to get this working, and I’m still mopping up the blood spatter today. This should have taken 30min-60mins tops including waiting for DNS caches to expire, and DNS records to be propagated on the interweb. However, I will spare you my personal grief this time, and just focus on the back-story, use-case, solution and workarounds in the hope that anyone facing similar heartache in the future will stumble upon this post and I will save them a bag of time. I’m just nice like that – after all I first got started with VMware, by just trying to be helpful. It takes you a long way in life I think.

Advice: If you are budding wannabe blogger who just wants your own domain, linked to Google Apps for email etc – together with your own WordPress setup. Don’t bother with this approach. It’s overkill. I would sign up to any number of hosted WordPress packages online, that will handle all of this for you in a nice simple easy enrollment process. This blog is hosted with Dreamhost.

https://www.dreamhost.com/hosting/wordpress/

The Problem – Back-story/Use-case:

As part of my endeavours to learn more about public cloud I’ve been looking at Amazon AWS. I’ve already put together an environment that leverages Amazon Router53 (DNS) together with multi-region Elastic Load-Balancer (ELB) together with IIS web-based instances running on ‘public’ subnets. I thought it would be good experience to do this using SSL certificates. I established a new DNS domain, registered and hosted with Amazon Route53, and then opted for for .net domain because that allows for the possibility of making my WHOIS information private, whereas this option did not exist for a .co.uk domain. Privacy is important to me, and I don’t think my postal address should be online for all and sundry to see. This is important to note, as it impacts on the SSL certificate enrollment. Registering the domain with Amazon Route 53 and Requesting an SSL certificate was relatively easy.

Where I became unstuck however – was In order for my SSL Provider to verify me and send me certificate they needed a valid email listed under WHOIS. This became tricky because that information as a.) private b.) the email used under the WHOIS information did not match the emails they would usually “expect” to use. That was tricky for me to easily provide because all I have is the raw DNS domain name, with none of the ancillary services that would normally surround it such as web-servers resolving to www.domain.net or any email infrastructure. Nor did I feel inclined to waste precious time putting together such services merely for a one-off email and verification process.

This process would have been relatively simple had I been requesting a certificate for www.michelle.com where those pieces of the puzzle were are in place, and much of the verification process had already been undertaken. However, I specifically wanted to use SSL with Amazon AWS and have it all in that environment, rather than doing the DNS work through dreamhost. Dreamhost is the company that hosts this blog. They are very good by the way.

Solution:

So I hit upon the idea of associating my existing Google Apps subscription which supports my michelle.com domain, to also provide email services to my new mydomain.net domain. It is possible to register the mydomain.net domain as “alias” to mydomain.com. Once recognised by Google I would be able to create an admin@mydomain.net user within my mydomain.com subscription with google. After that I can then update my WHOIS information at Amazon Route53. And then contact my SSL provider to complete the verification process. Of course, working out HOW do this took time. I’m a pretty tech savvy – but this requires an area of skills, often using interfaces and procedures which are different to ones I’ve used in the past. So you need:

• DNS knowledge (with Amazon Route 53)
• Certificate Request Knowledge (Many routes – I used IIS 10 to create a CSR request)
• An account with Google, and knowledge of their Domain Registration/Validation process
• Further updates to Route 53 and the WHOIS information to change default settings

I don’t intend to write something step-by-step because as soon as I do – the UI’s will change. I’ve often found that Google help does NOT keep up with their many changes. Amazon on other hand appear to have a better handle on documentation – so there is no point in me trying to compete with Amazon or Google in the documentation stakes. It does illustrate the challenges of them managing such an “agile”  environment compared to conventional shrink-wrapped software company. The documentation gets out of sync with the product…. To be honest I still don’t know WHY some processes provided by Google DID NOT work. And I still dont’ really know if the WAY I have done it the best or most efficient. It does HOWEVER, work. And that to me is what counts. BUT, if anyone can figure out what went wrong or suggest simple/easier way I would be indebted to them for that guidance.

Finally, I dare say Google Domains/Apps could be replaced with a different vendor if you subscription is with some other email supplier other than gmail. For instance I’m sure such a configuration could be achieved with Office360. Of course, any ordinary mortal just wanting a blog with their own domain, and bit of SSL to protect the login would be better of getting a hosting company to orchestrate all this – its much less heartache!

1,000 Foot View:

This is a simple number list that serves as a check-list to anyone (well mainly me) wanting to do this style of configuration…

1. Register new domain with Amazon Route 53
2. Login to Google Domains and create a New Domain Alias
   
3. Use the cname record method to verify your domain
4. Populate the Route 53  with the MX records for Google Mail servers
5. Create a new user in Google Console for your preferred contact for the new domain
   
6. Login to the new account, and (optionally) forward all email to an email address you do actually use!
7. In Amazon Route 53 update your WHOIS information for the new ‘admin” email. receive a flurry of confirmation and validation emails!
8. Generate a CSR for your domain (various methods)
9. Submit CSR for your single host certificate (aka www.mydomain.net) or domain wild card certificate *.mydomain.net
10. Use your new certificate as you see fit. In my case attached to two region specific ELB’s which act the SSL endpoint for inbound https requests – thus offloading the SSL process to ELB and away from your web-servers.
11. Punch the air – and say wow, did I really do that. I must be some sort Cloud God loading over the Olympus of the Internet. Sit back. Have a cup of tea. Feel a little less full of yourself. It’s only software you know… 😉

NOTE: I won’t be covering step 8-11 as they are specific to your environment, and will vary from vendor to vendor. And mainly because this post will be LONG enough without adding that level of detail. My main interest is the interoperability between Amazon Route 53 and Google Apps to get this working.

Now in a LOT more detail…

Note: I didn’t screen grab the entire process as I was troubleshooting and feeling my way. In the effort to be visual some new screen grabs have been taken that don’t use .net or .com.

1. Register a new domain with Amazon Route 53

Then specify your contact details. You have to specify a valid address (in my case the root email account associated with my Amazon AWS Subscription). Notice that this domain type does allow you to “Hide the contact information for the TLD registry”. Whilst this setting makes you more private, it does make it a little bit harder for your SSL supplier to validate you. However, they can request access to the WHOIS information. The email from the SSL provider would be sent to admin@mydomain.net, not admin@mydomain.com. So this information needs to be update ONCE you have got functioning email to and from the new domain.

2. Login to Google Domains and Add New domain

For some reason Google make it quite hard to locate the “admin” console for a Google Subscription, even if you login as the admin. I ended up bookmarking it as I looped around and around trying to find the darn thing!

https://admin.google.com/AdminHome

You need to click at the funny little widget in the top right-corner to find the “Domains” option. This isn’t documented in the Google Help, and when you first use it drives you mad trying to find the menu option! It’s the little things guys, document stuff – and don’t assume we just know!

Click your way thru to the obvious stuff til you can select “Add a domain or domain alias“, in the pop-up box select “Add another domain“, and type in you new domain registered in Amazon Route 53, and click “Continue and Verify Domain Membership“

WARNING: It was this point that things unravelled for me.

3. Use the CNAME Method to verify ownership of the domain

There are 3 ways to verify a domain under “Recommended Methods” you can:

1a. by Selecting a prelisted DNS registar
2a. by Selecting “other” and verifying the domain by either a TXT record*
3a. or CNAME record

There are 3 methods to verify a domain under “Alternative Methods” you can:

4a. by HTML Tag*
5a. by HTML download*
5c. by Google Analytics

Now. Method 1a isn’t available which is really VERY annoying given Amazon Route 53 is such a massive global provider of DNS. The fact they are not listed I feel is a bit shabby, and I’m at lost to understand why Google do not list them. In fairness the pull-down list of providers doesn’t actually DO anything – just give you vendor specific instructors on what to do – and to be fair to Google there are support articles on this process for Amazon – you just have to google to find them. Funny that, isn’t it?

I tried 2a, and it failed. I still don’t know why. I tried 4a and 5a, and that failed as well. Sadly I had 4-5 hours trying to get this work – with errors like this. This included such rabbit holes as temporarily setting up a web-server just to try the HTML verification methods.

I think where I was going wrong with the TXT method was I was creating the record incorrectly in Amazon Route 53. I was creating a record called “google-site-verification” with the value of

“google-site-verification=t7NQPOxJvPPknXqDVCzNvRcFbVWHuCXgCzk7Uu4b1RU”.

I think this is wrong. The name field should be left blank, and the value field should contain the string “google-site-verification=t7NQPOxJvPPknXqDVCzNvRcFbVWHuCXgCzk7Uu4b1RU”.

Sadly, the webpage surrounding the verification process DOES NOT MAKE THIS CLEAR. [This maybe obvious to some, but not to me. I’ve hardly EVER used the TXT type of record, and I’ve been in the industry some 25 years. [Perhaps I’ve lead a sheltered life!]  However, this does seem to be the case – for example this support article – https://support.google.com/a/answer/183895?hl=en states the following.

IMPORTANT: What worked for me without an issue was method 3a. It worked right away with almost no delay. Sadly, it was the last method I chose to use. Isn’t that ALWAYS the way.!

In the “Recommend Methods” scroll down to “Other” as the Domain Registar or Provider
Under “Having Trouble” click the link to Add a CNAME record

Go back to the Amazon Route 53 Console… Select Hosted Zones… Select your zone… Click Create Record Set... Select the CNAME record type and copy and paste the values from the google webpage…

It can take time for these Route 53 updates to propagate – which is half the problem troubleshooting this…You can use nslookup to query your domain to see if the cname record resolves it self to the URL generated using something like:

nslookup -q=cname 4erh65t3e47j.mydomain.net

Eventually this should result in a verification like so!

Huzzah…!!!

BUT WAIT! YOUR NOT DONE YET! YOU STILL HAVE STEPS 4, 5, 6, 7, 8 and 9 to do yet!

4. Populate the Route 53  with the MX records for Google Mail servers

Now your new domain in Amazon Route 53 needs to have MX records added so when email comes in DNS knows FQDN supporting that SMTP provider. When you click the link “Setup up Google MX Records”. This will simple open a web-page telling you how to do this – and importantly the name of those Google SMTP servers:

The list of MX servers can be found here, and then used to create the entries in Amazon Route 53. Sadly, it’s not possible to simple copy and paste, without editing because the MX records follow the format syntax of the priority value first followed by the MX server address. If you looks Amazon Route 53, where you add the MX record it gives a little overview of the MX record format:

A priority and a domain name that  specifies a mail server. Enter multiple values on separate lines. Format: [priority] [mail server host name] Example:

10 mailserver.example.com.
20 mailserver2.example.com.

There are other Google Support docs that outline this process in a bit more detail, which if you have not done this before – you might find more useful such as this one:

https://support.google.com/a/answer/140034

Once copied head back to Amazon Route 53 to create the MX records like so. Again as with the TXT method of verifying the domain, no “name” value is specified – just type (MX) and value (Priority No, FQDN)

Once this work is done, you can head back to the Google page to click that you have done your work:

Google will then verify the MX configuration and if you have got it right those unsightly yellow exclamation marks will clear themselves. At this stage your more or less “done” with the “Domain” aspect of Google Admin Console. But don’t close it down yet as you have further work to do. You cannot simply send email to your new domain at say admin@mydomain.net and expect it arrive. All we have done is handled the email DNS name resolution/routing issue – there’s no mail box called “admin” in gmail to receive that. I believe there are methods of forwarding some or all email from domain to another or to specified account. It wasn’t clear to me how to make this work.  But for those that are willing to spend the time working that out this support article seems to be the place to look:

https://support.google.com/domains/answer/3251241?hl=en-GB

I’d did something which I think is perhaps more crude, but simple and works. I created a mailbox.

5. Create a new user in Google Console ffor the new domain

I can create a new Google User in Google Admin Console. This has the effect of creating a users who will have two emails admin@mydomain.com, with the alias of admin@mydomain.net. New users can be created in the Google Admin Console, and its simple task that isn’t worth documenting. But once the account has been created if you examine its setting you can see both email addresses are supported, with the alias as a secondary email address.

6. (Optional) Login to the new account, and  forward all email to an existing email address

If you prefer not have to login to the account to check email, you can login as the new user on gmail, and under settings – forward all its email to an account you do want to use – under the Forwarding and POP/IMAP settings

7. In Amazon Route 53 update your WHOIS information for the new “admin” email.

Finally you need to update the WHOIS information to reflect the correct email in order to be validated by the SSL provider and receive the certificate. This is done in Amazon Route 53, under Domains and Registered Domains areas, and clicking the Edit Contacts button. Making this change will create a veritable flurry of emails – 3 to the original email and 3 to the new email.

Conclusion:

And that, as they say, is that. To be fair this blogpost really has nothing to do with my main task – becoming more savvy about public cloud. But despite the heartache I did learn quite a bit which I thought might just help others. Also, as side issue I have a very similiar process to go through with a different DNS supplier together with Office360 which have to do in a few weeks. I’m doing some IT support for a local charity who need assistance managing the move of their WordPress blog from one supplier to a totally different one. Having gone thru this process once with Amazon/Google, I think it should be a very similiar process Dreamhost and Office360