AD bit is stripped on DNS responses with glibc 2.31

[iainlane]

systemd version the issue has been seen with

245 (but would apply to all)

Used distribution

Ubuntu 20.04

Expected behaviour you didn't see

SSH fetches the SSHFP record for my server, it's validated with DNSSEC and I can connect

Unexpected behaviour you saw

The DNS reply was untrusted and so I got prompted to verify the key.

Steps to reproduce the problem

1. Be on a system with libc6 2.31, using systemd-resolved and on a system where DNSSEC works, i.e. resolvectl query debian.org prints Data is authenticated: yes
2. Try to SSH to a server with an SSHFP record (if you don't have one to hand, try something from the Debian project like master.debian.org). Pass -v -o VerifyDNSHostKey=yes
3. Look for debug1: found N insecure fingerprints in DNS. If the key is not in your known_hosts you will be prompted to verify it, but the intention is that the value in DNS is trusted.

What's going on
I explained this a bit in Debian bug #960023.

The key part is this from glibc 2.31:

• The DNS stub resolver will optionally send the AD (authenticated
  data) bit in queries if the trust-ad option is set via the options
  directive in /etc/resolv.conf (or if RES_TRUSTAD is set in
  _res.options). In this mode, the AD bit, as provided by the name
  server, is available to applications which call res_search and
  related functions. In the default mode, the AD bit is not set in
  queries, and it is automatically cleared in responses, indicating a
  lack of DNSSEC validation. (Therefore, the name servers and the
  network path to them are treated as untrusted.)

systemd-resolved could work around this behaviour change by setting options trust-ad in resolv.conf, like it sets edns0. I'm really wanting to get peoples thoughts on whether this is a desirable thing to do all the time. Or if not, can we provide a way for people to easily trust particular networks?

[johanfleury]

I believe this issue was fixed by #16072.

[iainlane]

I believe this issue was fixed by #16072.

Looks like it, thanks for noticing!