@relaycorp/dnssec

@relaycorp/dnssec

Resolver-agnostic DNSSEC library for Node.js.

Alternatives considered

As surprising as it may sound, there's no (reliable) way to do DNSSEC verification in Node.js in 2022, so when you see a JS app or library that claims DNSSEC support, chances are they're just blindly trusting a resolver like Cloudflare or Google -- which, admittedly, is sufficient in many cases and even desirable for performance reasons.

The Node.js team considered adding DNSSEC support but ruled it out due to lack of support in their upstream DNS library. As a consequence, two libraries have tried to fill the vacuum:

• getdns-node. Unfortunately, it was last updated in June 2021 and its dependency on an externally-managed C library has proven extremely problematic (see #8, #33, #38, #42, etc).
• dnssecjs. Unfortunately, it was abandoned shortly after it was (apparently) completed in 2017 and it was never published to NPM (so it's unlikely it was ever used). We decided not to fork it because we won't know how reliable/secure it is (assuming it works) until we spend significant time reviewing the code and testing it, and then we'd have to spend a lot more time to (1) rewrite it to match the tech and best practices available in 2022 (e.g., TypeScript) and (2) thoroughly unit test it (and it doesn't have a single test).

Design decisions

Although this is a general-purpose DNSSEC library, some key design decisions stem from our need to build the library for the sole purpose of using it in Vera.

Resolver agnosticism

DNS resolution is a problem solved in Node.js -- there's just no shortage of reliable UDP-, TLS- or HTTPS-based resolvers on NPM. So we didn't want to create a new resolver or tie our DNSSEC implementation to any particular resolver.

Error handling

As this is primarily a DNSSEC library, we treat DNS and DNSSEC errors differently:

• Any input that violates DNS RFCs in ways from which we can't recover will result in errors.
• Any input that violates DNSSEC RFCs will result in one of the three failure security statuses defined in RFC 4035 (Section 4.3): insecure, bogus or indeterminate.

However, errors are thrown upon attempting to parse malformed RDATA values for DNSSEC records -- we use a third-party library that parses the DNS message eagerly.

Denial of Existence record support

We don't need DoE records in Vera, so we won't be implementing that functionality ourselves, but PRs are welcomed.

Cryptographic Algorithms support

We support all the Zone Signing DNSSEC algorithms as of 2022, except for:

• DSA (3) because it's too insecure and hardly used.
• NSEC3 (6 and 7) because we don't currently support Denial of Existence records.
• GOST (12) due to lack of support in Node.js, and its lack of popularity and security doesn't seem to justify integrating a third party NPM package supporting it (assuming a suitable one exists).
• Private algorithms (253 and 254) because we have no use for those, but we'd welcome PRs to implement them.