Operational Notification: A party that is allowed control over zone data can overwhelm a server by transferring huge quantities of data.
- Updated on 17 Sep 2018
- 3 minutes to read
Summary: DNS protocols were designed with the assumption that a certain amount of trust could be presumed between the operators of primary and secondary servers for a given zone. However, in current practice some organizations have scenarios which require them to accept zone data from sources that are not fully trusted (for example: providers of secondary name service). A party who is allowed to feed data into a zone (e.g. by AXFR, IXFR, or Dynamic DNS updates) can overwhelm the server which is accepting data by intentionally or accidentally exhausting that server's memory.
Document Version: 1.1
Posting date: 07 July 2016
Program Impacted: BIND
Versions affected: 9.0.x -> 9.9.9-P2, 9.10.0 -> 9.10.4-P2, 9.11.0a1 -> 9.11.0b2
A server is potentially vulnerable if it accepts zone data from another source, as no limit is currently placed on zone data size. A master server can therefore feed excessive data to a slave server, exhausting its memory. Similarly a client allowed to insert records into a zone using dynamic updates can also cause a zone to grow without limit until memory is exhausted. In all cases a trust relationship allowing the attacker to insert zone data must exist between the two parties for an attack to occur using this vector.
A server which is successfully attacked using this method can have its memory exhausted, causing unpredictable behavior or termination by the OS when it runs out of memory.
In a typical case where zone data is accepted only from trusted sources under the control of the same organization, servers are at little risk. The chief risk from this attack vector is to parties who operate secondary name servers which accept zone data from not fully trusted sources.
Operators of servers which accept untrusted zone data can mitigate their risk by operating an intermediary server whose role it is to receive zone data and then (if successful) re-distribute it to client-facing servers. Successful exploitation of the attack against the intermediary server may still occur but denial of service against the client-facing servers is significantly more difficult to achieve in this scenario.
No known active exploits, but a public discussion of the issue has taken place on a public mailing list and a CVE assignment has been requested by a party other than ISC.
In practice this vulnerability has existed for as long as slave servers have taken data from master servers and has no history (of which we are aware) of being exploited as an attack vector because it requires an existing trust relationship as a prerequisite and identification of the attacking party is very easy (at which point the trust relationship can be revoked).
However, it is a possible attack vector and recent public discussion and a CVE assignment requested by an outside party have prompted us to issue a statement on the subject in this Operational Notification.
ISC wishes to stress that the behavior in question is not a failure of BIND to implement DNS protocols correctly, but is if anything an oversight in the protocol. However, for the convenience of operators who take zone data from untrusted sources (such as secondary name service providers), we have committed to delivering a feature in upcoming maintenance releases of BIND which will address the issue by allowing operators to set limits on the maximum zone size BIND will accept.
Document Revision History:
1.0 Public Disclosure, 07 July 2016
1.1 Updated Versions affected to include 9.9.9-P2, 9.10.4-P2, and 9.11.0-b2
Do you still have questions? Questions regarding this advisory should go to firstname.lastname@example.org.
ISC Disclosure Policies: Additional information is available in the ISC Software Defect and Security Vulnerability Disclosure Policy.
This Knowledgebase article is the complete and official operational notification document.
Legal Disclaimer: Internet Systems Consortium (ISC) is providing this notice on an "AS IS" basis. No warranty or guarantee of any kind is expressed in this notice and none should be implied. ISC expressly excludes and disclaims any warranties regarding this notice or materials referred to in this notice, including, without limitation, any implied warranty of merchantability, fitness for a particular purpose, absence of hidden defects, or of non-infringement. Your use or reliance on this notice or materials referred to in this notice is at your own risk. ISC may change this notice at any time. A stand-alone copy or paraphrase of the text of this document that omits the document URL is an uncontrolled copy. Uncontrolled copies may lack important information, be out of date, or contain factual errors.