The Potential Operational Risks Associated with Untrusted Zone Transfers

At the DNS Summer Day 2016 [HTML, JP] held in Tokyo on June 24th it was disclosed [PDF, JP] that an unbounded zone transfer (AXFR) operation can cause operational issues due to resource exhaustion for the server that is receiving the zone transfer. On servers running BIND, Knot, or PowerDNS the receiving server may run out of memory, and on servers running NSD the server may run out of disk space. The presenter does not appear to have investigated the behaviour of any closed-source DNS implementations.

In hindsight this is perhaps completely obvious, albeit not to our knowledge previously written down publicly anywhere. There are no inherent limits in the AXFR protocol, and neither the AXFR specification (RFC 5936) nor the earlier “Threat Analysis of the Domain Name System” (RFC 3833) make mention of this risk.

ISC was contacted by the Japanese Computer Emergency Response Team (JPCERT) on behalf of the presenter a few months ago. Our considered opinion was (and remains) that this is an operational security issue and not a security issue within BIND itself, and we responded accordingly. That notwithstanding, we created an internal feature request ticket at the time to add mitigation features to a future version of BIND but otherwise considered the matter closed.

Our rationale for concluding that this is an operational issue rather than a security one is that in the usual scenario where a secondary server is receiving data from a trusted party it is clearly the responsibility of the operator to ensure that their server is provisioned with adequate resources to handle the expected zone content.

There is an increased risk of resource exhaustion if you are receiving zone updates from an untrusted third party. However, in those circumstances a prudent design would separate out the servers that receive the zone updates from third parties from those that actually serve the zone content. Such a design would ensure that the primary DNS function (that of serving DNS records) would be unaffected in the event of the zone update system failing. In most cases it would also be trivial to disable updates from any zone source that might be causing a problem.

As outlined above, we consider this an operational issue, so were disappointed and surprised to discover on Wednesday that a third party had requested a CVE (Common Vulnerability and Exposures) database entry for BIND without consulting us first nor notifying us of their intent. However, in light of the more widespread knowledge of this issue we have now issued an Operational Advisory and brought forward our plans to release the mitigation feature such that it goes into the next maintenance release for all supported versions of BIND.

The presenter has offered patches for BIND and other servers; however, we don’t consider these an adequate mitigation as there are other mechanisms by which a third party could submit updates to a zone, e.g. IXFR incremental zone transfers (RFC 1995) or DNS UPDATE (RFC 2136), through which they could overwhelm a server’s resources. It is expected that the mitigation feature will be configuration options for limiting both the number of records in a zone and/or the memory consumption of a zone, but by default these will be left unlimited. Whilst we’re still working on the details of our implementation, we anticipate that in the event of a breach of those limits that BIND would continue to serve the existing zone contents.