systemd-resolved cannot do dns over tls with server using self signed certificates

Bug #1952784 reported by Sergio Callegari
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
systemd (Ubuntu)
New
Undecided
Unassigned

Bug Description

While testing functionalities of knot resolver, I am experiencing issues in how systemd-resolved interacts with it. I have the caching and forwarding knot resolver running on a debian machine and systemd-resolved running on an ubuntu focal machine.

It looks like systemd-resolved cannot communicate with kresd, when told to do so using dns over tls. I think that this is because kresd by default uses a self signed certificate for TLS and systemd-resolved does not like it. In fact, if I set dnsovertls on resolved and enable debug logging, I see in the journal entries like:

Failed to invoke gnutls_handshake: Error in the certificate verification.

and the name resolution fails:

resolvectl query lwn.net
lwn.net: resolve call failed: All attempts to contact name servers or networks failed

On the other hand if I set dnsovertls to opportunistic, things seem to work, but the log reports that systemd-resolved is "Using degraded feature set UDP for DNS server".

It is my understanding that systemd-resolved should accept self-signed certificates and should do certificate validation only if a special syntax is used for for specifying the DNS server to also include a hostname for the DNS server (see https://wiki.archlinux.org/title/Systemd-resolved#DNS_over_TLS). In fact, the documentation of systemd-resolved seems to be a bit thin on the matter, particularly because I understand that behaviors are changing across different systemd-resolved versions.

In any case, being able to make systemd-resolved work with DoT with servers using self signed certificages would be very useful for testing and learning.

Unfortunately, trying a more recent version of systemd-resolved is not really easy without firing up a virtual machine because it is impossible to update systemd-resolved independently of all the init system, with some obvious risk of breaking a system.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.