Wildcard A Records

Wildcard A records are a big no-no unless you know what you are doing (I didn't)

Back in May this year I spotted some bizarre spam on Google that appeared to be coming from a subdomain of this site. This article explains why I shouldn’t be allowed near computers, and how to avoid the mistakes I made.

Here is an example of the spammy subdomains:

Google search results with random subdomains not owned by me displaying
An example of the subdomains in Google search results

This site is static, so there is no backend code to hack. It is hosted on GitHub, which I trust not to be the easiest to hack, so I was a little perplexed as to why someone was able to hack me to put content on my site without me knowing!

I quickly realised what the issue was and tweeted about it, claiming a proper write up was coming “soon”, well I guess nearly half a year later counts as soon on some timescales!

A high-level overview of the issue

As I mentioned, the site is hosted on GitHub, to point a domain to GitHub you need to do two things:

  1. Set up your DNS to point traffic hitting your domain to GitHub’s servers.
  2. Tell your GitHub project which domain is associated with it.

I (very lazily) didn’t want to think about which subdomains I wanted to work or not work when I moved where tosbourn.com was hosted, so during the move I had set a wildcard A record in my DNS to point all subdomains to GitHub’s servers.

This means that www.tosbourn.com would go to GitHub, as would foo.tosbourn.com, blah.tosbourn.com, etc.tosbourn.com.

Now, if the server in question was a server I owned the IP address of, it wouldn’t really matter. So long as I didn’t tell the webserver to listen for traffic on foo.tosbourn.com, it would just drop the request.

I don’t own github.com, which turns out could be a problem!

It turns out anyone can tell their GitHub project to be associated with whatever domain they want. So if I add a setting to my GitHub project saying “listen for traffic from foo.tosbourn.com”, GitHub will happily comply.

This is not an issue with GitHub

I want to be clear at this point, GitHub is not at fault for this, nor is this issue unique to them.

I’d imagine Heroku would have the same issues or any shared service that allows someone to point a domain at their service could be open to abuse.

GitHub should not be in the business of validating domain ownership before allowing a project to be hooked up. Their system works well, if you set up your DNS correctly.

The Fix

The straight forward fix is to avoid wildcard DNS records.

Wildcards look like * or @ in most DNS provider settings. They mean “any subdomain of this domain”.

Even if you own the server you’re pointing to, you should not use wildcard DNS records unless you have a specific reason to. The overhead of adding new subdomains when you need them is less than the issues you may encounter by allowing any old subdomain through.

For me, the fix was to replace * with www in my A Record, because that is the only subdomain I care about right now (I used to do a lot of weird stuff off tosbourn.com, not anymore.)

If you have other subdomains, like blog.site.com, www.site.com, news.site.com that you all need to point to GitHub, you can add these as separate records.

Recent posts View all

Web DevMarketing

Getting more out of Plausible

Some things we've done to up our Plausible analytics game

Web Dev

Creating draft posts in Jekyll

How to create and develop with draft posts in Jekyll