DNS zone transfer, also sometimes known by the inducing DNS query type AXFR, is a type of DNS transaction. It is one of the many mechanisms available for administrators to replicate DNS databases across a set of DNS servers.
Zone transfer consists of a preamble, followed by the actual data transfer. The preamble comprises a lookup of the Start of Authority (SOA) resource record for the "zone apex", the node of the DNS namespace that is at the top of the "zone". The fields of this SOA resource record, in particular the "serial number", determine whether the actual data transfer need to occur at all. The client compares the serial number of the SOA resource record with the serial number in the last copy of that resource record that it has. If the serial number of the record being transferred is greater, the data in the zone are deemed to have "changed" (in some fashion) and the secondary proceeds to request the actual zone data transfer. If the serial numbers are identical, the data in the zone are deemed not to have "changed", and the client may continue to use the copy of the database that it already has, if it has one.
DNS Zone Transfer
The actual data transfer process begins by the client sending a query (opcode 0) with the special query type AXFR (value 252) over the TCP connection to the server. Although DNS technically supports AXFR over User Datagram Protocol (UDP), it is considered not acceptable due to the risk of lost, or spoofed packets.[2][1] The server responds with a series of response messages, comprising all of the resource records for every domain name in the "zone". The first response comprises the SOA resource record for the zone apex. The other data follows in no specified order. The end of the data is signaled by the server repeating the response containing the SOA resource record for the zone apex.
Some zone transfer clients perform the SOA lookup of the preamble using their system's normal DNS query resolution mechanism. These clients do not open a TCP connection to the server until they have determined that they need to perform the actual data transfer. However, since TCP can be used for normal DNS transactions, as well as for zone transfer, other zone transfer clients perform the SOA lookup preamble over the same TCP connection as they then (may) perform the actual data transfer. These clients open the TCP connection to the server before they even perform the preamble.
Zone transfer is entirely client-initiated. Though servers can send a NOTIFY message to clients (that they have been informed about) whenever a change to the zone data has been made, the scheduling of zone transfers is entirely under the control of the clients. Clients schedule zone transfers initially, when their databases are empty, and thereafter at regular intervals, in a pattern controlled by the values in the "refresh", "retry", and "expire" fields in the SOA resource record of the zone apex.
Though it is standardized, full-zone transfer being described as one of the possible database replication mechanisms in RFC 1034 and RFC 5936 (incremental zone transfer described in RFC 1995), zone transfer is the most limited of those database replication mechanisms. Zone transfer operates in terms of "wire format" resource records, i.e. resource records as they are transferred using the DNS protocol. However, the schema of wire format resource records may not be identical to the database schema used by the back ends of the DNS servers themselves.
The preamble portion of zone transfer relies on the serial number, and only the serial number, to determine whether a zone's data have changed, and thus whether the actual data transfer is required. For some DNS server packages, the serial numbers of SOA resource records are maintained by administrators by hand. Every edit to the database involves making two changes, one to the record being changed and the other to the zone serial number. The process requires accuracy: the administrator may forget to change the serial number or change it incorrectly (reduce it). RFC 1912 (section 2.2 SOA records) recommends using the value YYYYMMDDnn as the number (YYYY=year, MM=month, DD=day, nn=revision number). This won't overflow until the year 4294.
Furthermore, the paradigm of database replication for which the serial number check (and indeed zone transfer itself) is designed, which involves a single central DNS server holding the primary version of the database with all other DNS servers merely holding copies, simply does not match that of many modern DNS server packages.[citation needed] Modern DNS server packages with sophisticated database back ends such as SQL servers and Active Directory allow administrators to make updates to the database in multiple places (such systems employ multi-master replication), with the database back end's own replication mechanism handling the replication to all other servers. This paradigm simply does not match that of a single, central, monotonically increasing number to record changes, and thus is incompatible with zone transfer to a large extent.[citation needed] Modern DNS server packages with sophisticated database back ends often will create a "shim" serial number, simulating the existence of a single central place where updates are made, but this is at best imperfect.
Fortunately, for this and several reasons outlined later, DNS servers that use such sophisticated database back ends in general rarely use zone transfer as their database replication mechanism in the first place, and usually instead employ the vastly superior distributed database replication mechanisms that the back ends themselves provide.[citation needed]
Originally, in the actual data transfer each set of resource records for a single domain name and type was transferred in a separate response message from the server to the client. However, this is inefficient, and some DNS server software implemented optimizations, geared at allowing the response compression mechanism in the DNS protocol to reduce the total bandwidth requirements of data transfers, such as:
Some clients were written to expect only the original response format, and would fail to perform data transfer if such optimizations were employed. Several DNS server packages thus have a configuration setting allowing administrators to specify the use of "single answer format" responses for those clients that require it.
The data contained in a DNS zone may be sensitive from an operational security aspect. This is because information such as server hostnames may become public knowledge, which can be used to discover information about an organization and even provide a larger attack surface. In June 2017 the registrar responsible for Russian top-level-domains accidentally enabled DNS zone transfers via AXFR which led to 5.6 million records being accidentally exposed.[4]
In 2008 a court in North Dakota, USA, ruled that performing a zone transfer as an unauthorized outsider to obtain information that was not publicly accessible constitutes a violation of North Dakota law.[5]
DNS zone transfer, also known as DNS query type AXFR, is a process by which a DNS server passes a copy of part of its database to another DNS server. The portion of the database that is replicated is known as a zone.
A full transfer of all the zone information will take place in order to replicate the already existing records for that zone. This a time-consuming and resource-intensive process. Thus, incremental DNS transfers were developed.
When using incremental transfer the SOA record is compared to see whether any changes have been made. If the primary name server has a higher SOA version number than the secondary name server then a zone transfer will be initiated.
When changes have been made to the zone file on the primary name server and there is a DNS notify list, the primary name server immediately notifies the secondary name server that the zone file has been modified. It then instructs it to initiate a zone transfer without waiting for the refresh interval to expire.
This points to a server named _sip._tcp.zonetransfer.me listening on TCP port 5060 for Session Initiation Protocol (SIP) and www.zonetransfer.me is the host providing the service. The priority given here is 0, and the weight is 0.
A zone transfer that is from an external IP address is used as part of an attackers reconnaissance phase. Usually, a zone transfer is a normal operation between primary and secondary DNS servers in order to synchronise the records for a domain. This is typically not something you want to be externally accessible. If an attacker can gather all your DNS records, they can use those to select targets for exploitation.
Whether an attacker or penetration tester, they will attempt to map the footprint of the organization to find areas of weakness to exploit. Usually, the information collected is host names, IP addresses, and IP network blocks that are related to the targeted organization. A successful zone transfer will make this mapping much easier.
Enter the target domain, such as example.com. The dig DNS tool, available on *nix based platforms, will then be used to enumerate all the authority Name Servers for the domain. Each Name Server is then checked remotely for a zone transfer of the target domain. Often, even though the primary name server blocks zone transfers, a secondary or tertiary system may not be configured to block these - hence the check of each name server.
For more information or for a valid transfer mechanism to test head over to the site zonetransfer.me, DigiNinja a well known security researcher has made the domain zonetransfer.me available for testing and learning, so you can test the online zone transfer tool with the deliberately configured zone transfer capable domain.
This API provides an easy way to grab the results of attempted zone transfers, and the full results of the transfer if it is successful. The output is in plain text and will include the results from the dig command against each of the name servers. Access the API using a web browser, curl or any common scripting language. 2ff7e9595c
コメント