Custom Domain
Chasing that Blue tick
Living in a digital era, anyone can create a digital product with any possible intentions - good or malicious. Organisations like Github, AWS and Twitter for example create a track for authors to be verified in an attempt to establish some credibility of the author.
Installing proprietary software, by a verified author or not, without access to the source code should always scare the heck out of everyone!
Gaining verification status in many of these ecosystems typically relies on having privileges to validate that the author has authority for a domain that identifies the brand, this is typically a domain name (ironically).
Purchasing a domain
Buying a shiny new domain name, is typically what you do before anything days because of CyberSquatting. CyberSquatting simply is the purchase of a domain name with the intent that in the future someone will want to buy it for a much higher cost. There are even marketplaces for trading and buying up domain names going for tens of thousands of dollars!
For this reason, it is not outside the realm of possibility that the common endings would already be taken - and if you're setting up a brand, its likely the be in your best interest to buy up the common domain endings, with the foresight that some malicious actors may end up praying on your customers.
Picking the perfect domain name?
This will come down to three main factors - industry, price points and any cybersquatting on your domain of preference.
For my own custom domain, personally an .io domain is extremely popular within the start-up community and open-source developers, navigating to keit.io - presented with a buy-now screen for a low $280 (example of CyberSquatting).
After trawling through low cost examples keit.website or keit.cooking, I opted for keit.dev - which is synonymous with builders.
Keit.dev
The .dev domain is maintained by Google Registry and has a few benefits like required HTTPS being mandatory.
Google allows the following from their domain site:
DNS Management: Adding/removing of DNS entries
Website Management: Direct linking to Partners like SquareSpace,Wordpress etc
Reports: Hits on google.com for your domain
Email: Using Google Workspace
Security: Configuring DNSSEC
AWS WorkMail > Google Workspace
Why did I pick AWS Workmail over Google Workspace?
Simple, purely cost based. I could not justify the $8.60 VS the $4 a month for an email address that I will use occasionally use to respond to queries that would need to be private. Most communication would be ideally done in the Github Issues/Projects section of the projects that will be created.
Now that that's been decided, what next?
Domain Delegation
With the freshly purchased domain, any requests that are sent to myDomain.dev will be resolved by the default NameServers provided by Google.
With any additional records needing to be added under the "Custom Records" section, to get this to happen via automation would require setting up a Google Cloud Account - which I captured a few screenshots below.
I went through a quick trial and opted for not having another avenue to be billed (or risk any exposure from not having it locked down adequately).
Attempting the CLI for Managing REsource REcords
Using the gcloud cli, using an existing project I had I was prompted to setting up billing.
REVOKING CREDENTIALS
Using the auth revoke combination, removed CLI access using my personal Google account.
Starting point - Google Domain + AWS Control Tower Environment
As indicated in AWS Control Tower Launch , we have an AWS organization and with our domain - the diagram to the left articulates the two components.
In the next few steps, I'll show how to set up the domain delegation to a new AWS account.
Creating an account in AWS Control Tower
Following the prompts via the Control Tower, I supplied details for creating a new account of where I will delegate control for the new domain.
Noting to get the most out of the keit.dev domain, we can exploit this email functionality to create multiple unique emails for AWS billing root user (needs to be unique) - hidden ways to get more from your email addresses. Eg. richard+123@keit.dev will be emailed to richard@keit.dev.
Behind the curtains
AWS leveages AWS Service Catalogue for provisioning accounts.
The above screenshot shows that when I was the user that created this account using my Federated User. Another benefit of using Control Tower is the use of AWS IAM Identity Center which Control Tower sets up automatically, following these steps - for all users MFA can be enforced (which is what I have done for my user also).
Brand New Account Created
From my AWS Control Tower login screen, we can see I have 5 accounts registered.
New Prod Account: will be used for DNS validation among other things
Audit + Log Archive: Security accounts created by Control Tower
"Richard Keit": master account
backup: account I enrolled via this process
I created a small bit of automation to aid with enrollment of existing AWS Accounts in Control Tower: Enroll Old AWS Existing accounts
Creating HostedZone for the domain
Creating a HostedZone in AWS, doesn't automatically make that HostedZone authoritative to respond with records for your domain. Using the below Cloudformation snippet, selecting the "NameServers" from the "Outputs" section, place this in your domain registrars settings.
This will provide the authority for the NameServers in AWS to respond to domain queries for your domain
Editing the domain in domains.google
Github Verified Domain
Setting up the Github verified domain was relatively easy, following the steps described here. Github requires users to add a TXT record under the domain to validate the authority they have of the domain.
Below I have used the preference of using AWS::Route53::RecordSetGroup over AWS::Route53::RecordSet as it allows us to group a number of records in the Cloudformation template logically and makes it quite intuitive if someone were to need to edit (last thing anyone wants is a large edit removal some unintended records).
Verified Domain = success
