Hacker News Reader

Comment by 3np | Hacker News Reader

An example to work around this would be to run a validating resolver (for example unbound) on localhost of each host and have it forward to whatever DNS server you use today.

If you're on Ubuntu, you most likely have a local resolver running already.

View on HN

On Ubuntu the default is to use systemd-resolved, which is actually a validating stub resolver. You just need to set DNSSEC=true (see man resolved.conf) and it will work*.

*: this is the definition of "work" that also means it won't resolve anything if anything is wrong with DNSSEC validation, but if you want to be secure you need it to fail closed.

Perhaps a solution such as dnscrypt-proxy and configuring it to forward requests that match certain patterns to a validating resolver on the local network would work? Requests that didn't match could be forwarded to some other resolver that wasn't configured to validate.

There should be an option for "validate but still return invalid data, just reflect validity in the AD bit". Is there?

That way most things will still work even DNSSEC is broken, and apps with higher security requirements can opt-in to "fail if invalid", by passing setting the AD bit on queries, and checking if it is still there on responses.

I believe that is DNSSEC=allow-downgrade which is also the default.

I thought “allow-downgrade” meant it would return unsigned data, but not invalidly signed data? I was talking about the latter case not the former.

You could be right. I guess the documentation isn't terribly clear...

Reply on news.ycombinator.com