Add IPv6 address to the SAN of the server certificates

[ismxilxrif]

Issue Details

When using systemd-resolved with AdGuard DNS over TLS, I want to avoid using the # suffix:

DNS=94.140.14.14 94.140.15.15 2a10:50c0::ad1:ff 2a10:50c0::ad2:ff

Without the hostname suffix, systemd-resolved performs IP-based certificate validation, meaning the certificate must include the actual IP address in the SAN (iPAddress entries).

This behavior is explicitly documented in the systemd-resolved man page:

DNS=
    ... Each address can optionally take ... a Server Name Indication (SNI)
    separated with "#". ...

DNSOverTLS=
    ... If the hostname was specified in DNS= by using the format
    "address#server_name" it is used to validate its certificate and also to
    enable Server Name Indication (SNI) when opening a TLS connection.
    Otherwise the certificate is checked against the server's IP.

The Problem
The AdGuard DNS certificate currently includes IPv4 addresses in the SAN, so IPv4 IP-based validation succeeds.

However, the IPv6 addresses are not included in the certificate SAN.
Because systemd-resolved falls back to IP-based validation when no hostname suffix is used, IPv6 DoT connections soft-fail validation due to the missing SAN entries.

Why
Additional systemd-resolved issues when using the suffix:

Snap-based browsers often break when the #hostname suffix is used.

With suffix-enabled SNI verification, browsers installed via snapd may fail DNS resolution entirely:

1. IPv6 connectivity tests fail
2. Pages may fail to load on dual-stack networks
3. Only removing the suffix restores correct behavior
4. This makes the hostname-suffix workaround unreliable.

The hostname suffix cannot be configured in the GUI.

The # format is only supported in the systemd-resolved command-line configuration, nmcli and also editing the connection profiles using a text editor, which means:

1. Graphical network configuration interfaces (e.g., GNOME NetworkManager settings) reject such entries as invalid IPs.
2. This prevents most users from configuring SNI-based validation through the GUI at all.

I do acknowledge this is a GUI and also a system limitation, but other providers having the IPv6 SANs is already a thing too, so I would propose that as a fix.

Proposed solution

Allow the IPv6 Addresses to be in the Certificate's SAN, in addition to IPv6, just like other resolvers has done, i.e: cloudflare and quad9

Alternative solution

No response