Discovering DNS

07 November 2018

4 minute read

Have you ever heard of DNS? It is basically the address-book for the whole internet. It maps memorable hostnames to IP addresses (for example is (tbh IP addresses are also human-readable, but are much harder to remember). With IPv6 around the corner, IP addresses are going to become even harder to remember.

It's just a phonebook right? What can hackers even do?

You might be surprised as this is actually a lot of information. Maybe you haven't secured an endpoint into your internal network properly and that is all a hacker needs in order to break into your super secure network.

How can I get my hands on such an addressbook?

There are many ways to find hidden DNS hosts. Some of the most common ways are listed below.

AXFR Transfer

AXFR transfers are the easiest and most accurate way to get all the DNS records for a zone.

$ dig AXFR

# Not actual output obviously
; <<>> DiG 9.7.3 <<>> AXFR
;; global options: +cmd	86400	IN	SOA 2018080125 7200 3600 1209600 3600	86400	IN	NS	86400	IN	NS	86400	IN	A    86400   A    86400   A    86400   A

But this method often does not work as domain administrators usually block these types of requests. Why would they you may ask? Well, would you disclose the list of contacts on your phone to anybody who asks for it? I sure hope you don't, especially if I'm on it. The domain admins don't really want you to find out about every machine on their network. You might be able to do it if you are inside their network, but then again most admins are probably smart enough to not let every user of the network see the entire zone file. The last thing you want is to be hacked by an employee.

DNSSEC Zone Walking

DNSSEC is an extension for DNS which allows clients to authenticate that the response returned by an authoritative DNS server is indeed genuine. This is achieved by verifying the cryptographic signature of the response. A valid response would be signed by the key associated with the domain. The domain's key would be signed by the TLD's key which is signed by a root key which everyone trusts.

DNSSEC includes a record called NSEC which is a signed response from the server which tells the client the next hostname in alphabetical order which exists. That way, a rogue DNS server cannot just respond with NXDOMAIN, as the signature would be invalid. However NSEC has a vulnerability which allows the client to check for the existence of hostnames. Since the NSEC record tells the client about the next hostname, the client can just keep querying the next hostname over and over again until they find all your hostnames.

Coming up with an example is too hard as I don't want to expose the insecurity of real websites, so I have linked a tutorial which shows how it can be done.

This has been fixed with the introduction of NSEC3 which hashes the hostname portion so that zone walking cannot be performed. A brute-force attack can still be done if your hostnames are commonly used, but this is not feasible for obscure hostnames.

Just Randomly Guess Hostnames

This option is the last resort to discovering hostnames on a domain, and it's usually the only one that works as well. Let's just try to guess every hostname we can think about at the top of our heads. How about files, admin, staging, mysql or ad?

There are many tools to execute hostname scans, such as dnsscan.

How do I protect myself?

Only allow authorised servers to perform AXFR transfers on your DNS servers. Most DNS servers nowadays disallow AXFR transfers by default as they are a security risk as well as being a DDOS attack vector. So this shouldn't really be a problem.

If you are using DNSSEC, make sure you are using the newer NSEC3 instead of the older NSEC record type. This ensures that people cannot zone walk your domain and get a list of every hostname on your network.

You can try to use obscure hostnames, but this is security through obscurity which is not secure enough. It can be used as a layer of defence, but also make sure that your servers and applications are securely locked down. This includes changing all default passwords to routers and database servers, and only allowing logins via public-key cryptography on SSH servers.

So the moral of this story is to secure your servers and applications people!