What is are DNS zone transfers (AXFR)?

DNS (Domain Name System) is one of the many systems that keeps the Internet humming and is responsible for resolving human-readable hostnames into machine-readable IP addresses. DNS servers host what are known as zones. A DNS zone is a portion of the domain name space that is served by a DNS server, and will contain several DNS records, which are nothing more than key-value pairs of information that will be served to a client depending on the request made to the DNS server.

Since DNS is usually regarded as a critical service for applications to function properly, it’s frequently set-up to be highly-available and possibly even load-balanced. This allows uninterrupted service to clients’ DNS queries if something goes wrong with one DNS server. In order for this setup to work properly, all the DNS servers hosting the same zone must make sure to keep one another updated of any changes — enter DNS zone transfers, or as they are also commonly referred to, AXFR (technically speaking, AXFR refers to the protocol used during a DNS zone transfer).

DNS zone transfers, are one of the many methods available to administrators to replicate DNS databases across a group of DNS servers. While DNS zone transfers are perfectly fine between DNS servers intended to share zones information, they could leak a lot of information that would otherwise not be available to an attacker. While DNS records are not sensitive individually, if an attacker manages to obtain a copy of the entire DNS zone for a domain (for example by means of an attacker-initiated AXFR request), they may obtain a complete listing of all hosts in that zone. It’s also worth bearing in mind that it’s not uncommon for a DNS server to span several network segments, possibly giving an attacker insight into other network segments they were unaware of.

Initiating an AXFR zone-transfer request is as simple as using the following dig command, where example.com is the domain we want to initiate a zone-transfer for, and ns1.example.com is the DNS name server which we are querying. The below is an example site designed to illustrate the vulnerability.

$ dig +short ns zonetransfer.me

nsztm1.digi.ninja.
Nsztm2.digi.ninja.

$ dig axfr zonetransfer.me @nsztm1.digi.ninja.

; <<>> DiG 9.8.3-P1 <<>> axfr zonetransfer.me @nsztm1.digi.ninja.
;; global options: +cmd
zonetransfer.me. 7200 IN SOA nsztm1.digi.ninja. robin.digi.ninja. 2017042001 172800 900 1209600 3600
...

In order to prevent this vulnerability from occurring, the DNS server should be configured to only allow AXFR zone transfers from trusted DNS servers. The following is an example of how this can be accomplished in the BIND DNS server.

# /etc/named.conf
# Requires a restart of the `named` daemon

acl trusted-nameservers {
192.168.0.10; //ns2
192.168.1.20; //ns3
};
zone example.com {
type master;
file "zones/example.com";
allow-transfer { trusted-nameservers; };
};

Additionally, it’s also recommended to make use of transaction signatures (TSIG) when authorizing zone transfers, making it hard for an attacker to spoof an IP address.



This is a Security Bloggers Network syndicated blog post authored by acunetix. Read the original post at: Web Security Blog – Acunetix