We take security very seriously. If you have found a security issue in NSD, please contact us and we will reply within 24 hours. Please allow us a reasonable timeframe to formulate a response and do not send security issues to public lists. If desired, we will fully credit the reporter.
If a flaw is found we intend to provide security patches, for free, to the general public. In addition, we strive to be transparent about the nature, cause and impact of security flaws. Since the announcement of a security flaw may trigger the creation of exploits, we strive to balance transparency about flaws with the impact exploits might have on the Internet and its users.
We will follow specific internal guidelines, though circumstances may force us to not apply this policy in full. End of support for the software by NLnet Labs will be publicly announced two years in advance. All security vulnerabilities will be identified with a dedicated CERT vulnerability tracking numbers.
In general, the security patches are distributed according to the following priority:
- Customers with a Gold support contract and the party that reported the vulnerability, under non-disclosure
- Special Interest groups, under non-disclosure. These are entities that operate NSD in an environment that is critical to the general public, such as the root name servers, as well as known Open Source platform Operating System maintainers
- Customers with a Silver support contract, under non-disclosure
- Customers with a Bronze support contract, under non-disclosure
- The general public
With regards to these five groups, we will take the following considerations:
- The time scale on which publish/distribute security patches differently depending on the nature of the security issue. If the issue is widely known or exploited at the moment we have developed a patch (zero day) we intend to release the patch as soon as possible to the widest audience possible, which collapses stages 1 through 5 above to the order of days.
- If the issue is not yet public, we intend to release security patches to the general public on a short timescale, in the order of weeks.
- If we cannot find a fix for the security vulnerability, we obviously cannot provide code and may seek assistance. In order to prevent zero-day exploits information about (the existence of) these types of vulnerabilities may only be shared under non-disclosure with category 1, and if circumstances dictate with category 2.
- We provide patches for the latest released software version i.e. the latest major, minor, patch level release.
- In general we provide support for the previous major release for one year after its deprecation. We therefore also provide security patches for major releases from one year past. A major release is the increment in the first version number.
Please keep in mind that NSD is made available under the BSD license and comes with ABSOLUTELY NO WARRANTY.
NSD time sensitive TSIG compare vulnerability
|Credit:||Ondrej Sury (ISC)|
|Affects:||NSD 4.1.22 and earlier versions|
|Not affected:||NSD 4.1.23 and later|
|Impact:||Potential key leakage|
|Solution:||Upgrade to NSD 4.1.23 or newer|
NSD uses TSIG to protect zone transfers. The TSIG code uses a secret key to protect the data. The secret key is shared with both sides of the zone transfer connection. The comparison code in NSD was not time insensitive, causing the potential for an attacker to use timing information to discover data about the key contents.
Denial of service via a zone transfer with unlimited data
|Affects:||NSD 4.1.10 and earlier versions|
|Not affected:||Other versions|
|Impact:||Denial of Service|
|Solution:||Upgrade to NSD 4.1.11 or newer|
NSD before 4.1.11 allows remote DNS master servers to cause a denial of service (/tmp disk consumption and slave server crash) via a zone transfer with unlimited data. size-limit-xfr was implemented in NSD 4.1.11 to stop it from downloading infinite zone transfer data size.