Advanced DNS Checker: Back up DNS records in full

What makes the Advanced DNS Checker different to other DNS tools?

The Advanced DNS Checker is designed primarily for backup and probing purposes, solving the problem of few domain providers offering a one-click option to download the DNS. Other great DNS tools exist, but these are more about guiding people through problems and optimisations. None so far offered such a complete list, meaning their utility for backup purposes is limited. They’ve generally been more focused on checking individual records or providing hints for enhancements. I recommend MXToolbox all the time, and my advice is to keep using it. Like all the other DNS tools I found, it’s great. It’s for an entirely different use case.

Key features:

• MANY subdomain records included by default on extended (-x) mode!
• Add any custom known subdomain you like (yourdomain.com%sub1,sub2)!
• Probe multiple domains or subdomains at once!
• Optionally use authoritative name servers!
• Optionally provide just an overview!
• Optionally output the results just to your screen!
• Install it locally, run it with minimal dependencies!
• Free to use locally and open source!

What it does resemble: a zone file

A zone file. A zone file is the authoritative DNS information for your domain. So why not just... download that? Because you usually can’t!

Why you usually can’t access the zone file

• Whenever you aren’t running the name servers yourself, with BIND, PowerDNS, etc., someone else is.

• Even if you have access to DNS tools in cPanel, Plesk, or any other interface, all you are doing is editing records – not the zone file.

• Many providers deliberately prevent exports of those zone files or even the records you entered yourself, because:

  • They want to keep you locked in.

  • They don’t want to reveal too much about their infrastructure.

The limited exceptions

If you run your own name servers, like I did, very briefly, a very long time ago, then you can download the authoritative zone file. Webhosts and people who self-host using their own name servers will not need my tool.  But given that even many people who self-host still leave the DNS part to their webhost or the place they bought the domain, the lack of access to the zone file remains a common problem.

Possibly the most complete DNS backup around

Weaknesses of existing tools

Existing tools tend to focus just on the main domain, a limited set of records, and only a limited number of subdomain records – if included at all. As discussed above, they are absolutely great, and I recommend them! They are just... close to useless if you are trying to obtain a full and detailed backup that resembles a complete zone file.

Even better than Cloudflare... for this use case

One of the first, sceptical remarks by someone who commented without looking at the code was ‘Even Cloudflare doesn’t grab everything’. Indeed, it doesn’t. Cloudflare does a hell of a lot of things right, but right now, my tool goes a lot further.

The point isn’t that the Cloudflare auto-import setup is less good. There are valid reasons to exclude various security or DNSSEC-related records from an automatic import: things can go wrong. Equally, Cloudflare focuses on simplicity and ease of use alongside their specific service. A Cloudflare DNS import is not the same as a DNS backup.

Use it for: Backups, migrations, and CDN integrations

The main use case is backups, for obvious reasons. DNS records rarely change, though. If they do, you’ll know about it! In most cases, they’ll only change when you add a new third-party service or change hosts or name servers, or similar. But things can go wrong, so keeping a backup of how they looked when working properly is a great idea. As detailed above, my tool also picks up more than the auto-import process in Cloudflare. So in keeping with the rhyme, you should consider making a backup before any CDN integration, too.

DO:

• Backup manually on an irregular basis , for example:
  • Before and after adding a more complex third-party service to your setup, e.g. Microsoft 365.
  • Before and after changing anything relating to email settings , since these have a few hidden parts that are easy to miss (but all included in the extended readout).
  • Before and after migrating your website in any way. It saves a tonne of time copying records manually, while eliminating a typical source of error (admittedly, sort of creating another – see below).
• Double check the readout, especially regarding subdomains .
  • Remember, custom subdomains I have no way of guessing will need to be included manually. This includes commonly used testing and staging environments. This was a deliberate choice to reduce unnecessary probing or exposure.
  • Unusual subdomain-like records, e.g. _dmarc, which is technically a subdomain but not really, can be added in the same way. _dmarc is included by default, of course! I mentioned it to give an example of the other type I might miss. If these are commonly used services, please let me know! I can add them to the checks.
• Consider saving your preferences
  • For now, I’d advise saving the default command-line input as a file in the same folder for reference and later use.
    • Later on, I’m likely to add config file functionality or something similar.

DO NOT:

• Automate backups.
  • There is really no need for any normal user to make regular backups . DNS records just don’t change regularly, without your knowledge . This is why the script is based on saving the readout (in technical terms, an output log) rather than caching.
    • The exception: You’re managing websites for others, perhaps as a reseller , and the users occasionally make changes. They may break things.
      • The exception to the exception: Webhosts won’t need this tool. Nor will anyone running a fully self-hosted setup. It might inspire them or present the information in a more human-readable way, but they have access to the zone file records directly and better ways to back up the data. In an ideal world, they’d create a one-click download system to avoid all this being necessary.

Use it for: Sustainability, data protection, data sovereignty, and security probing

The overview (-o) records are enough to pick up a lot of third-party services, just through mail servers, name servers, and text records. You can pick up even more with the extended (-x) results list, but the overview will often be enough to get a quick impression of an organisation’s habits around the use of third parties.

Fun things I learned:

• The German Bundestag has a record relating to their use of Zoom for teleconferencing. It’s been advised to NOT use Zoom since 2020, for a whole host of reasons. Why is this there? If they aren’t using it, it would still need updating.
  • On the other hand, I find it cool that they have a lot of functionality tied to bdtg.de, a domain without any A or AAAA records.
• Tesla ’s DNS records are a hilarious mess. Chaos, man. Chaos.
  • Nah, there’s nothing positive to say here. It’s just chaos. Hilarious chaos.
• The US government , unsurprisingly, is working with every big tech company you can find.
  • The US government and its departments, including doge, seem to have a lot of APIs.
• A fair few sustainable companies aren’t using sustainable internet services across the board.
• Cloudflare uses some name servers with real human names. Namedservers. Ha!

Limitations: Wildcard behaviour, unknown subdomains, and certain CDNS

Wildcard records exist on many subdomains. I run a (peanut-themed) wildcard check against a domain’s A and AAAA records early on, using a subdomain that is unlikely to exist. It’s peanutspeanutspeanuts.<yourdomain.com> – if you do have that subdomain for some reason, reach out, because the universe has decided we should be friends. I store those results in variables and use this as a basis to notify users that wildcard behaviour has been detected, and individual subdomain test results may be unreliable. Subdmains with the same result are then automatically omitted unless were manually included via the command-line interface.

Unknown subdomains are not possible to detect without knowing they exist in the first place. I’ve included a long list of known typical subdomains and subdomain-like DNS records. These are scanned automatically on extended (-x) mode. But I wanted to limit unnecessary probing and exposing things people didn’t choose to make public. I figure, if its your own site, you will likely know what other subdomains to manually include on the command line (e.g., yourdomain.com%sub1,sub2).

I deliberately decided against integration with Sublist3r, at least at this stage, since I figured most legitimate users would be aware of the subdomain records they need to check for. Amass, a brute-force style approach, would be overkill and is ruled out for good due to the unnecessary impact for my use cases. Hence not even linking it.

Behaviour with some CDNs can be a little odd. There’s not much I can do about that, though – it’s down to how those domains are configured, irregular records, and irregular responses to the dig command.

Future enhancements or general roadmap

You can follow the Github to be informed of any updates. I will post about any bigger updates (e.g., hosting it on a website for general use) on my blog. Current considerations/plans/enhancements include:

• Adding config file functionality
• Skipping the wildcard check when doing an overview or non-extended lookup without subdomains
• General updates and improvements based on testing feedback
• Option to check results provided via different sources, e.g. Cloudflare – in addition to existing authoritative nameserver integration
• Potential integration of additional IP-related and server-based performance check
• Adjusted default behaviours, or preset one click backup generation options

Get it on Github: Version 2 out now

Go over to Github for full usage instructions and the latest version. Let me know how you get on! I can only do so many comparisons with comparisons against the DNS records I control.

Will it be available with a GUI or on a website one day?

Possibly... probably? I’ll need to protect it from abuse, but the actual impact is pretty low. So it should be doable. I’d also want to double check with my webhost that they’re fine with it. I have a good thing going, so I don’t want to risk anything! This is more likely to happen after June, once the first version of the W3C Web Sustainability Guidelines are out and I have more time for my own tinkering. It does have a sustainability aspect to it, though, so I can mentally justify it!

In the meantime...

You can reach out to me for manual checks if you provide the input I’d need and an email address to send it to. I’d need the domain and any known subdomains.