I agree, many currently-shipped DNS client library implementations do not provide DNSSEC validity checks.

As i understand it, GnuPG ships and uses its own DNS client implementations, and doesn't use the system resolver unless standard-resolver is set for dirmngr. Given that situation, the GnuPG DNS client implementation should do DNSSEC validation.

Alternately (and perhaps more maintainably), GnuPG could build against a library that already does DNSSEC validation (e.g. unbound or libknot's libdnssec), and use that library's features. That requires thinking about licensing compatibility and platform availability of course, but already things like standard-resolver are not universally-available across platforms.

Is this really necessary to duplicate functionality that already is provided by Web Key Directory?

The description of things needed to be done is already big and it needs to be tested on all systems supported by GnuPG while WKD provides more privacy in a simple, already working package.

I've seen that the PKA is deprecated but I'm left wondering: are there cases where OPENPGPKEY would be preferred over WKD? Not only setting up exotic records and DNSSEC is a lot more effort than getting a Let's Encrypt certificate I guess client support (except GnuPG) is also low.

In T4618#128103, @wiktor-k wrote:

I'm left wondering: are there cases where OPENPGPKEY would be preferred over WKD?

In my opinion, the main adavantage of DANE OPENPGPKEY over WKD is that the former doesn't depend on trusting a centralized CA system. Sure, you still have to trust the DNSSEC root key, but that's a way smaller attack vector than trusting *all* TLS CAs out there.

DNSSEC is a centralized CA system. Just different than the TLS one. Given that Certificate Transparency exists I'd say DNSSEC is less transparent than TLS. For example if you happen to have a .ly domain then the Libyan can silently control your signed zone. Given that there is no CT for DNSSEC they can do so selectively, for any connection they want. It wouldn't be the first problem with them.

I'd refer to the timeless Thomas H. Ptacek for further info on this matter: https://sockpuppet.org/blog/2015/01/15/against-dnssec/

WKD and DANE/OPENPGPKEY offer rather distinct properties. I'd be hard-pressed to say that one is "better" than the other without understanding the threat model and concerns of the evaluator:

• WKD uses the CA system, whereas DANE/OPENPGPKEY uses DNSSEC authorities
• WKD uses a transport security model for authenticity, DANE/OPENPGPKEY uses an object security model
  • this means that DANE/OPENPGPKEY records can be proxied/forwarded, whereas WKD cannot
  • it also means that the domain operator gets to know for sure when you use WKD, but does not necessarily learn when you fetch an OPENPGPKEY record (which could have been cached)
• DANE/OPENPGPKEY requires only the ability to fetch/receive DNS records, whereas WKD depends by necessity on both DNS and HTTPS
• DANE/OPENPGPKEY is more likely to be transmitted in the clear today, until there is wider adoption of private DNS mechanisms like DNS-over-TLS or DNS-over-HTTPS

If you look carefully at Ptacek's anti-DNSSEC arguments (leaving aside whether they are valid arguments or not), you'll notice that many of them don't apply to this particular case. In particular, he focuses on the name-to-IP mapping problem, which is not the problem that we are addressing here.

The same concern has been reported at https://bugs.debian.org/964033 -- if dirmngr is not going to follow the specification, it should at least document (and maybe warn?) about how it is divergent.

DANE for OpenPGP is an experimental RFC (RFC-7929) and it is likely that we will remove the support because it is too hard for most users to add keys to a zone. Further a validating resolver on the desktop is too hard to maintain and the cause of too many other failures. And no, unbound etc is not an option because it is not usable by the majority of GnuPG users.

Granted I'm not familiar with the functions and it may not be applicable, but the DNS resolver functions in the GNU C Library have semi-recently gained parameters (RES_USE_DNSSEC) to check for DNSSEC validation IIRC. Recent versions of glibc also don't trust the 'ad' bit unless an indication of its trustworthiness is set in /etc/resolv.conf, say if using a local validating resolver, so one can be sure that it's trustworthy. It also appears musl libc may support this.

Another dependency for GnuPG may not make sense, but perhaps this would be a small addition to the DNS code.