ISC does not pay bug bounties.
If you suspect you have found a security defect in BIND, ISC DHCP, Kea DHCP, or Stork, or if you wish to inquire about a security issue that you have learned about which has not yet been publicly announced, ISC requests you to follow the process described at https://www.isc.org/security-report/.
We ask reporters to
- Notify us as soon as possible after you discover a real or potential security issue.
- Provide us a reasonable amount of time to resolve the issue before you disclose it publicly.
- Do not submit a high volume of low-quality reports.
ISC's commitment
- Within 3 business days, we will acknowledge that your report has been received. If you do not hear back from ISC within 3 days, please consider that there has been a communication failure and re-submit your report.
- To the best of our ability, we will confirm the existence of the vulnerability to you and be as transparent as possible about what steps we are taking during the remediation process, including on issues or challenges that may delay resolution.
- We will maintain an open dialogue to discuss issues and we request that reporters also be responsive to questions we may have to clarify the issue or verify the solution.
- When we publish a security advisory, we will acknowledge the reporter. Typically we ask the reporter how they would like to be acknowledged.
We attempt to publish our vulnerabilities and release fixes on a measured cadence to achieve the best result in operational practice. This is based on our long experience in managing critical infrastructure software with a large user base. Releasing patches at random or frequent intervals puts excessive burden on operators, so we request that reporters be patient with our disclosure policy.
Learn more about our Security Vulnerability Disclosure Policy here: ISC Software Defect and Security Vulnerability Disclosure Policy.
Defects that span multiple DNS implementations
If you believe you have found a security vulnerability that applies to DNS implementations generally, and you want to report this responsibly to a number of implementers, you might consider using the Open Source DNS Vulnerability mailing list, managed by DNS-OARC.