BIND 9

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability Separately, for a merged upstream patch : up to $15,000 Google Patch Rewards pays for a patch you get accepted upstream and that stays merged, without reverts, for one month, not for the report. BIND sits in the Tier 1 'Other high-impact network services' row. Merge requests go to gitlab.isc.org rather than GitHub, patches must be one to twelve months old at submission and are capped at three per person per month, a maintainer has to accept the patch, and sanctions and territory exclusions apply. CVE history 23 Last 12 months 141 Lifetime Denial of service 45 % Parsing/validation 20 % Memory safety 20 % Info disclosure 10 % Latest advisories Loading the feed Overview BIND 9 is the reference DNS server and still the most widely deployed authoritative and recursive nameserver in existence: the default named on RHEL, Debian, Ubuntu and FreeBSD, the engine in much appliance firmware, and the backbone of a large fraction of enterprise internal DNS and of TLD and registry infrastructure. The same defect frequently reaches every downstream resolver at once, so BIND bugs reliably produce coordinated multi-vendor advisories. CVE-2023-50387, KeyTrap, made a signed but hostile zone drive the validator into unbounded work. The record runs to 141 lifetime and 23 in the last twelve months. ISC pays nothing for a report; its security process is a confidential issue channel with no money attached, so sorona.xyz pays you directly on qualified, reproduced findings. In scope ISC runs a confidential report channel at [email protected] for defects in named and the rest of the open-source BIND 9 tree. An operator's configuration choice is not a defect, ISC's commercial tooling and its separate Stork and Kea projects sit outside, and everything below sits inside The resolver in full: recursion, the cache and its fill logic, and the aggressive-NSEC and synthesised-answer paths where BIND answers from something it derived rather than something it was told DNSSEC end to end, covering validation, signing and key handling, including the algorithmic-complexity surface a signed but hostile zone can drive The authoritative side in full: zone loading, AXFR and IXFR transfer parsing, notify handling, and the dynamic-update and DDNS path, all of which accept structured data from a peer The catalog-zones implementation and dnssec-policy key management, where one zone's contents drive another server's configuration Every transport named accepts, from UDP and TCP through the DoT and DoH termination added in BIND 9.18 and later, and the network-manager rewrite underneath them that handles connection state The tools shipped alongside named in the same tree, since the boundary ISC draws is the open-source server rather than one binary Out of scope Configuration errors: an open resolver by choice, a missing ACL, or a permissive allow-transfer, all of which are operator decisions rather than defects ISC's commercial subscription tooling and the BIND Support portal, which are not the open-source server Stork, ISC's monitoring dashboard, and Kea, its DHCP server, both separate projects with their own scope Denial of service produced by raw query volume rather than by an algorithmic defect in how named handles a particular input One-line patches that fix non-exploitable crashes, including crashes that only amount to resource exhaustion, which the Patch Rewards rules say will not generally be rewarded Most-valued findings A remotely triggerable crash or assertion failure in named reachable from ordinary query traffic, which is 45% of this project's history and directly reachable from the public internet on any recursive resolver Cache poisoning that gets a forged answer accepted and served to every client behind the resolver, the single most consequential outcome available here DNSSEC validation flaws, either a bypass that makes a bad signature verify or a KeyTrap-shaped complexity attack where a small signed response costs the validator unbounded CPU. CVE-2023-50387 is that second shape Memory corruption in zone-transfer, dynamic-update or DoH/DoT parsing driven by a peer, since those paths accept structured input from something the operator does not control A defect in catalog zones or dnssec-policy where one zone's contents reconfigure the server, turning a data-plane input into a control-plane one Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Send a detailed, reproducible report to [email protected] , with the query sequence or zone data that triggers it; if it cannot be reproduced it is not eligible Show a defect in named rather than an operator choice. An open resolver, a missing ACL or a permissive allow-transfer is a configuration decision rather than a bug Expect slow triage and say why your finding is real: ISC reports a historic increase in LLM-generated vulnerability reports and is filtering hard If you also want the Google patch money, land the fix upstream yourself and keep it merged without reverts for one month. That is a separate pathway with its own rules Upstream lives on GitLab at gitlab.isc.org rather than GitHub, so merge requests go there; patches must be one to twelve months old at submission and are capped at three per person per month Google cannot pay anyone on a sanctions list, in a sanctioned territory, or located in Russia or Belarus Disclosure Coordinated with ISC's security officer, who runs a confidential process and publishes an advisory with researcher credit on a scheduled date. ISC also coordinates cross-vendor where a defect touches more than one DNS implementation, which lengthens the timeline; hold the detail until the advisory is out. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability