Hosted Zones for domains purchased through the Route53 Registrar come with a default comment. This default comment forfeits the opportunity for labelling and control.
When purchasing a domain through AWS Route 53, the domain registrar automatically creates a hosted zone to host the DNS records for the newly acquired domain. Without DNS records the domain is effectively useless as no domain configuration can exist, therefore creation of a hosted zone is a necessary step and a welcome automation after purchasing a domain. However, whilst the Route53 services creates a hosted zone for any newly purchased domain the service also configures the hosted zone with a default comment: HostedZone created by Route53 Registrar.
Whilst this default comment may seem helpful it often crowds out the value of hosted zone comments where organizations can derive additional value by leveraging comments for internal record-keeping and domain management.
For example, given the strategic importance of domains, organizations could implement a policy requiring every purchased domain to have its owning party and associated cost center recorded within the hosted zone comments. This practice clarifies the purpose of each domain, identifies the responsible internal party, ensures authorization and tracks financial accountability. Companies adopting such policies can fully map their domain portfolio, facilitate streamlined domain management and ultimately track renewal and decommissioning back to the owning business units.
Implementing a policy like this also easily illustrates which domains have been purchased without authorisation. If the policy requires business information such as cost centers to be recorded in the Hosted Zone’s comments then ad hoc domain purchases by technical teams that retain the default registrar comment HostedZone created by Route53 Registrar are immediately visible as part of resources scans and can be adopted or disposed of prior to the domain accruing a significant risk profile and blast radius.
This process is an advised policy and depends on the data and business structure for each organisation. Additionally, this is best managed as a centralised policy requiring a centralised team with both visibility and ownership across all accounts. If both of those requirements align then it’s simply a case of establishing the desired policy for what the hosted zone comment should include based on the business information and process available and ensuring a roll out of suitable comments to all hosted zones.
Additionally, it might be worth rolling out SCPs or other restrictive policies preventing the purchase of domains to all accounts. However, this can ultimately prove a blocker to legitimate business operations that would need to be managed to avoid domain purchases happening via other vendors to avoid shadow IT processes.
Our experience is that it’s better to have known violations rather than force movement to unmonitored spaces. In practical terms, we advise it’s best to not deploy blocking policies that would force users to utilise unauthorised third parties but instead let business teams violate policy openly so that it can be tracked and rectified.
SkySiege Cloud Security Assessments scan for this issue and provide same-day reports..
Available for individual projects or organisations.
