AdguardTeam / AdguardTeam/AdGuardDNS

Add IPv6 address to the SAN of the server certificates

オープン
#974 コメント 0 件 リアクション 1 件 担当者 1 名 @Chinaski1 が担当を希望しています GitHub で見る
feature request Priority: P4
主要言語
Go
スター
952
フォーク
82
PR マージ指標
30日以内にマージされた PR はありません

説明

### 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_

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

評価

この issue はまだ評価されていません。

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。