Check for abandoned/misconfigured delegations in your Route53 hosted zones.
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


The Red X is a warning placard affixed to a vacant building structure alerting first responders to the existence of structural or interior hazards in the building that warrant extreme caution when conducting interior firefighting or rescue operations with entry occurring only for known life hazards.

In this case, Red-X alerts us of abandoned/misconfigured domain delegations or records pointing at inactive domains from managed services ( or


Preventing misconfigured delegations should be pretty self-explanatory - you need your customers to be able to quickly and reliably resolve your domain names from anywhere in the world.

Preventing abandoned delegations is also very important. For one, to prevent Cloud resource sprawl from draining your coffers and your operations time. But, perhaps more importantly, to prevent DNS zone hijacking.

What's zone hijacking?

Due to the shared infrastructure of Route53 (and other managed AWS services, like CloudFront), it's surprisingly easy to take control of a misconfigured or abandoned zone, CNAME, or A ALIAS.

The particular attack Red-X attempts to prevent is zone hijacking through brute-forcing nameservers. Since Route53 assigns you four nameservers when you create a hosted zone, an attacker that happens upon an abandoned zone can hijack that zone by brute-force creating a hosted zone for that domain again and again until they've matched one or more of the nameservers it was delegated to.

You can find a better explanation here.

What's record hijacking?

Similar to zone hijacking, records pointing to domains from managed services like or can be abandoned and later used to hijack the domain.

What it does

  • Fetches configuration from EC2 Parameter Store
  • Gets a list of all records in the configured Route53 Hosted Zone
  • Pulls out all delegations (NS records)
  • Iterates over the delegations
    • Checks each of the nameservers in the delegation.
    • Ensures each nameserver returns the expected result for NS records.
    • No response implies the delegation is abandoned.
    • Mismatched results implies misconfiguration or zone hijacking.
  • Pulls out all A and CNAME records pointing to beanstalk or cloudfront domains
    • Warns about CNAMEs, since A ALIAS records are more correct
    • Alerts if the or address doesn't resolve.

Then, it can notify you in two ways:

  1. GitLab issues.
    • Open an issue in the configured project for each delegation error.
    • Close any open issues no longer associated with delegation errors.
  2. SNS notifications.
    • Send a summary of delegation errors to the configured SNS topic.


Configuration for this function is controlled by the EC2 Parameter Store. Setting up your configuration (and updating it later) is simplified using the script at the root of this repo.

Running python with credentials for your account will let you create or update your Red-X configuration.

NOTE: If you intend to use the GitLab integration, you should only do this after you have deployed the function, as it will attempt to use the KMS key created by CloudFormation to encrypt your API token.


Deploying this function will create the following resources (in addition to the 'usual' Serverless resources):

  • A KMS key to encrypt secret configuration info (i.e. GitLab API Token)
    • Aliased as 'alias/red-x/settings'
  • An SNS topic Red-X-Reports for publishing delegation error summaries


This is a Python3.6 Lambda function, since the DNS library for node isn't great. So you're kind of straddling two worlds, here.

$ npm install
$ virtualenv env
$ source ./env/bin/activate
$ ./node_modules/.bin/sls deploy

Then, optionally, you can run python to set up the parameters in the EC2 Parameter Store.

You can also invoke the function locally with ./node_modules/.bin/sls invoke local -f check_delegations.