Which releases get a security patch depends on the CVSS v3.0 score:
| CVSS v3.0 | Supported Versions |
|---|---|
| 9.0-10.0 | Releases within the previous three months |
| 4.0-8.9 | Most recent release |
Please report (suspected) security vulnerabilities to cadastros@rafael.net.br. You will receive a response within 48 hours. A confirmed issue is patched as soon as its complexity allows, historically within a few days.
dnstree talks to nameservers it was pointed at by the delegation it is following, which means it talks to hosts a stranger chose. Two things follow from that, and both are worth knowing when judging a report:
- Answers are never trusted beyond their bailiwick. A server may only hand out addresses for names at or below the zone it serves, and anything further afield is resolved on its own instead. A report showing a server able to steer the walk somewhere it should not reach is a vulnerability, not a bug.
- Every walk is bounded. Queries, zone cuts, aliases and nameserver resolutions all have budgets, so a hostile delegation can waste time but cannot make dnstree run forever. A report showing otherwise is a vulnerability.
--rdap asks a registry over HTTPS, at the address IANA's bootstrap file gives
for the TLD. A way for a registry to lead it off HTTPS, or to make it read
without bound, is a vulnerability.
--tlsa connects to the mail servers of the name on port 25, only at the
public addresses DNSSEC proved for hosts DANE covers. A way for a server to
hold it past its timeout, make it read without bound, or have it connect
anywhere else is a vulnerability.
--format dig writes shell commands built from names a zone chose. A name
that makes one do anything but ask dig its question, once pasted into a shell,
is a vulnerability.
dnstree-web runs those walks for strangers. A way to make it query a private, loopback or link-local address, redirect off its own host, or get round its per-client limits is a vulnerability.
The DNSSEC verdicts are diagnostic: dnstree reports what it found so you can see a broken chain, and exits 3 when one is bogus. It is not a validating resolver and nothing should be routed through it as though it were.