From ${URL} : It turns out that most DNS server implementations do not implement reasonable restrictions for zone sizes. This allows an explicitly configured primary DNS server for a zone to crash a secondary DNS server, affecting service of other zones hosted on the same secondary server. Some references: https://lists.dns-oarc.net/pipermail/dns-operations/2016-July/015058.html https://lists.dns-oarc.net/pipermail/dns-operations/2016-July/015075.html https://gitlab.labs.nic.cz/labs/knot/merge_requests/541 https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=790 PowerDNS is reportedly affected as well, but I did not find a public bug for this issue. @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
https://kb.isc.org/article/AA-01390/169/CVE-2016-6170
CVE-2016-6170 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2016-6170): ISC BIND through 9.9.9-P1, 9.10.x through 9.10.4-P1, and 9.11.x through 9.11.0b1 allows primary DNS servers to cause a denial of service (secondary DNS server crash) via a large AXFR response, and possibly allows IXFR servers to cause a denial of service (IXFR client crash) via a large IXFR response and allows remote authenticated users to cause a denial of service (primary DNS server crash) via a large UPDATE message.
(In reply to Christian Ruppert (idl0r) from comment #1) > https://kb.isc.org/article/AA-01390/169/CVE-2016-6170 Given ISC's review of the matter, it would probably be best that we address this with a GLSA discussing the workaround for administrators. This is an inherent flaw within the protocol specifications, but of course can be administratively controlled through the implementation. ISC is going to offer that solution soon and PowerDNS already has patches proposed.
This issue was resolved and addressed in GLSA 201610-07 at https://security.gentoo.org/glsa/201610-07 by GLSA coordinator Kristian Fiskerstrand (K_F).
