We have already covered the bases of DNS, so you know what it is and how does it work. This article will help you understand one of the concepts inside the DNS – zone transfer.
It is a process of sharing DNS records, the whole zone file, or only the most recent DNS records. In order to explain it, let’s first see what a zone file is.
DNS zone and DNS zone files
The DNS zones are a part of the DNS that can be administrated through an authoritative DNS server. The whole DNS is organized with a hierarchical structure – root level, TLD, domain name, subdomain, etc. There are different levels that can be managed independently. The purpose of the division is exactly to facilitate the administration of the DNS. DNS zones allow exactly this, to manage a partition of the domain namespace. The DNS administrator of a higher level needs to delegate a Master DNS zone to another administrator, so he or she can manage a lower level zone. The DNS zones have zone files that define them.
Zone files are simple text files with DNS records. A zone file will contain the whole information for a domain:
- SOA record, which indicates the start of authority.
- A records for IPv4 addresses.
- AAAA records for IPv6 addresses.
- CNAME records for canonical records that indicate the canonical domain.
- MX records for the receiving email servers for the domain.
- TXT records for various verification methods
- SRV records for services.
- PTR for a reverse DNS lookup.
- And more.
DNS zone file format
The DNS zone file format is described in RFC 1035 (section 5) and RFC 1034 (section 3.6.1). This file contains a sequence of line-oriented entries. Each of them is a directive or a text description of a particular DNS resource record.
Directives serve as control entries, and their presence affects the entire zone file. They are presented with a dollar sign followed by the name. Here are some examples of directives:
- $ORIGIN – It shows a domain name that is used as the origin for any following subsets of domain names.
- $INCLUDE – It shows one or several file names to include too. Optionally, it can add other origin domain names.
- $TTL – It shows a number, which is the default TTL (Time-to live) value for the file itself.
- $GENERATE – It is a non-standard extension that is used to insert several resource records with a single entry.
Every resource record entry contains several fields. They could be ordered in two ways, and both of them are acceptable:
name – ttl – record class – record type – record data
name – record class – ttl – record type – record data
- Name – It shows the name of the precise individual record that the administrator created. This field also could be left blank.
- TTL – It shows the specific amount of time (in seconds) after which the record should be discarded, and a new DNS resolution process should be completed to obtain the new data. In other words, this value shows for how long the information should be kept inside the DNS cache. It is possible to be omitted. In this case, the resulting value is going to be established from the default TTL.
- Record class – This field shows the namespace of the record information. Most commonly, here, you will see the parameter IN, which represents the Internet namespace. It is possible to be omitted, so then the resulting value is going to be established from the previous record.
- Record type – This field shows an abbreviation of the kind of information held in the last field, record data. In other words, here is specified the precise type of DNS record, for example, A (hostname to IPv4 address), AAAA (hostname to IPv6 address), MX (receiving email server for the domain), SOA (start of authority), NS (shows the authoritative name server), TXT (text record), PTR (IP address to a hostname), etc.
- Record data – This field shows the information that the precise record has. It is possible to consist of one or several information elements, depending on the type of the DNS record. For instance, the A record shows the link between a hostname and an IPv4 address, requiring only an address. On the other hand, an MX record also requires a domain name and priority.
What is DNS Master Zone
The DNS Master Zone (also known as DNS Primary Zone) is the part of the namespace to which you have the control to add and remove DNS records, and that way, you can manage your domain name. Each host (part of the domain) that you can manage needs a DNS Master Zone so that you can administrate it, and also, you can have just one per host.
It hosts your zone file, which is the text document that contains all the DNS records for your domain name/host.
The DNS Master Zone permits read and write. It is located inside a Master authoritative nameserver.
For better security, availability, and redundancy in general, you will need DNS Slave Zones (DNS Secondary Zones) inside Slave DNS servers (Secondary DNS). The Slave Zones are read-only copies of the original Master Zone.
DNS Zone transfer
In DNS, you can copy data from the Master DNS zone to the Secondary DNS zones through a process called DNS Zone transfer. There are two types of zone transfer:
- Full zone transfer (AXFR) – a complete zone transfer, where the Secondary DNS servers copy the whole zone file.
- Partial zone transfer (IXFR) – In this case, the Secondary servers will check all the new changes that happened since their last update (deleted and added DNS records) and get only them.
To function correctly, the system needs to keep been updated. That could happen in two ways:
- Push – The Master DNS server can propagate a zone transfer to the Secondary DNS servers.
- Pull – The Secondary DNS server can check for changes inside the Master zone, and if they find any differences by comparing the SOA records, they can start a zone transfer.
You can do it manually with the Dig command (if you have permission) or automatically if you have set it before. It is very important who can perform zone transfer and how. A good practice is to use the Whitelisting technique for your Secondary DNS servers. That way, only their IP addresses will be inside a whitelist, and only they can get access to the zone file and the new DNS changes.
Allowing everybody to be able to perform zone transfer can be a huge risk. It can show to the person who is performing it, the whole zone file, and there can be DNS records that are only for internal use.
AXFR zone transfer (Full zone transfer)
AXFR zone transfers are the full DNS zone transfers of all DNS data. The Primary DNS server sends the whole zone file that contains all the DNS records to the Secondary DNS servers. This assures that the secondary DNS server is well synced. It will have all the latest changes that were made to the Master DNS zone.
You will use full DNS zone transfer when:
- You are adding new Secondary DNS servers. They will be empty, and that way, you can directly add all of the records at the same time.
- You want to be sure that all of the Secondary DNS servers are up to date. If you have some DNS servers that, for some reason, were out of sync, this is an easy way to do it.
People often prefer IXFR zone transfers over AXFR transfers because they don’t take so much bandwidth. Fewer data travels, and fewer resources are used.
IXFR zone transfer (Partial zone transfer)
IXFR zone transfer is just a partial zone transfer that involves transferring only the newest changes from the Master DNS server to the Secondary DNS servers.
The incremental transfers IXFR are not complete transfers. They don’t copy the whole zone file.They are ideal when you have added or deleted just a few new A records, for example, and you don’t want to push a heavy AXFR transfer.
When we are talking about partial zone transfer, the SOA record plays a big part. The Secondary DNS servers will periodically check the SOA record of the Master DNS server, and if its number is higher, they will ask for the changes since they were last updated. The same record will also provide a refresh rate that will show how often the Secondary servers should check for changes and retry rate if the procedure fails.
The Master DNS server also can directly tell the Secondary DNS servers that there were new changes with a notification called DNS NOTIFY. This can trigger an IXFR zone transfer.
The advantage of the partial DNS zone transfer is that it uses far fewer resources because only the new changes will be updated.
Why Is DNS Zone Transfer Needed?
DNS Zone Transfer is needed to:
- Set up newly added Secondary DNS servers. They need to get the DNS records from the Primary because they will be empty at first.
- The zone file at each DNS server needs to be up to date. If the data inside a Secondary DNS server is too old, it won’t be valid anymore and will be deleted. This will leave the network with one less DNS server that could answer queries.
- Old DNS data could stop services from working. If there were changes made in the Primary DNS server, but the changes were not propagated, the Secondary DNS server might have A records, leading to old IP addresses that are no longer in use.
- Manually editing DNS records at each DNS server is time-consuming and could be an impossible task if there are many DNS records and many DNS servers.
Transferring a DNS zone using Dig
You can perform a full DNS zone transfer using the popular Dig command. You can go ahead and try it with zonetransfer.me. and its nameserver. It is a website created for testing. Later you can try with yours.
Follow these steps:
- Open the Terminal application on your Linux computer.
- Type “dig zonetransfer.me -t ns”. In the answer section, you will see the nameservers for the domain name. We will use one of them for our next dig command, the @nsztm1.digi.ninja.
- Now type “ dig axfr zonetransfer.me @nsztm1.digi.ninja.”. Wait a few seconds, and you will see all the DNS records – SOA, TXT, A, AAAA, MX, NS, etc.
Common reasons for a failed zone transfer
A DNS zone transfer can be a useful way to get information about different domains and networks, however, it is not a guarantee that the transfer will always be successful. Common reasons why a DNS zone transfer may fail include unsupported file formats, incorrect information in the DNS records, and an improperly configured firewall.
One of the most frequent reasons for a failed DNS zone transfer is unsupported file formats. DNSSEC is an emerging protocol that is not supported by all DNS servers and can therefore lead to a failed transfer. An incorrect entry in the DNS records, such as a missing domain name server, can also cause the transfer to fail. Other issues, such as an improperly configured firewall, can also be to blame. To ensure successful transfers, it is important to use supported file formats, double check DNS records regularly, and audit firewall settings to make sure they are not blocking certain types of traffic.
Zone transfers and hackers’ attacks
Hackers can obtain the zone file by performing an AXFR request. You can prevent this if you allow just trusted DNS servers to perform AXFR queries. You can use Whitelisting to add the IP addresses of the allowed DNS servers that can perform DNS zone transfer.
A good way to perform Secure zone transfers is to use DNS Transaction Signatures – TSIG. It is a way to secure the communication between two points using symmetric encryption (hmac-sha224, hmac-sha256, hmac-sha384, hmac-sha512).
Inside the zone file, there are DNS records that can be for inside use only. You can imagine that this kind of information could be dangerous in the hands f a cyber-criminal.
DNS zone transfer is the method of sharing DNS records from the Primary DNS server to the Secondary DNS servers. If you create a new DNS zone, you will need to perform an AXFR zone transfer. If you already have set up all the DNS zones and you just make changes to the primary DNS zone, then it will be an IXFR zone transfer.
Hi, I’m Martin Pramatarov. I have two degrees, a Technician of Computer Networks and an MBA (Master of Business Administration). My passion is storytelling, but I can’t hide my nerdish side too. I never forgot my interest in the Hi-tech world. I have 10 years and thousands of articles written about DNS, cloud services, hosting, domain names, cryptocurrencies, hardware, software, AI, and everything in between. I have seen the Digital revolution, the Big migration to the cloud, and I am eager to write about all the exciting new tech trends in the following years. AI and Big Data are here already, and they will completely change the world!
I hope you enjoy my articles and the excellent services of ClouDNS!