Hallo,
ich nutze dnsforge als Upstream für systemd-resolved mit DNSSEC=true, also mit lokaler Validierung zusätzlich zu eurer. Dabei bin ich auf einen Blocklisten-Eintrag gestoßen, der aus meiner Sicht ungewollte Nebenwirkungen hat. Vorweg: es geht mir ausdrücklich nicht darum, Optimizely-Tracking freizuschalten.
Was Normal aktuell blockt
Ich habe die Zone einmal komplett durchgetestet, A-Records, Normal gegen Hard:
| Name | Normal (49.12.67.122) | Hard (49.12.222.213) |
|---|---|---|
optimizely.com (Apex) |
0.0.0.0 (geblockt) |
216.150.1.1, 216.150.16.1 |
www.optimizely.com |
CNAME vercel-dns-016.com, 216.150.1.1 |
identisch |
cdn.optimizely.com |
0.0.0.0 (geblockt) |
0.0.0.0 (geblockt) |
logx.optimizely.com |
0.0.0.0 (geblockt) |
0.0.0.0 (geblockt) |
api.optimizely.com |
0.0.0.0 (geblockt) |
0.0.0.0 (geblockt) |
dxp.optimizely.com |
NOERROR, kein A-Record | identisch |
support.optimizely.com |
CNAME episerver.zendesk.com | identisch |
foia04aapy36eg.dxp.optimizely.com |
104.18.33.180, 172.64.154.76 |
identisch |
(0.0.0.0 ist die übliche AdGuard-Antwort auf einen Blocklisten-Treffer. dxp.optimizely.com
ist kein Block, die Zone hat schlicht keinen eigenen A-Record, es ist ein reiner Delegationspunkt.)
cdn., logx. und api. sind die eigentlichen Experimentation- und Telemetrie-Endpunkte. Dass
die blockiert sind, ist völlig richtig und soll auch so bleiben.
Der Punkt ist: Normal und Hard verhalten sich auf jedem getesteten Namen identisch, mit genau
einer Ausnahme, dem Apex optimizely.com. Hard blockt exakt dieselben drei Tracking-Hostnamen,
lässt den Apex aber frei. Das ist aus meiner Sicht die korrekte Konfiguration, und es ist der
einzige Unterschied, der den DNSSEC-Fehler auslöst.
Warum der Apex-Eintrag schadet
Optimizely ist neben dem A/B-Testing auch eine Digital-Experience-Plattform. Ganz normale Firmenwebseiten werden dort gehostet und zeigen per CNAME auf *.dxp.optimizely.com:
www.hanwag.com
CNAME www.hanwag.com.dxcloud.episerver.net
CNAME foia04aapy36eg.dxp.optimizely.com
Ihr lasst dxp.optimizely.com bewusst frei, und die A-Records der Kundenhosts darunter liefert
auch Normal sauber aus (siehe foia04aapy36eg.dxp.optimizely.com in der Tabelle oben). Trotzdem
ist www.hanwag.com über Normal nicht auflösbar. Der Grund ist DNSSEC.
Der Block wirkt nicht nur auf A und AAAA, sondern auch auf DS und DNSKEY. Darauf antwortet AdGuard mit einem synthetischen, unsignierten NODATA:
$ dig @49.12.67.122 +dnssec optimizely.com DS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; AUTHORITY SECTION:
optimizely.com. 7200 IN SOA fake-for-negative-caching.adguard.com. hostmaster.optimizely.com. ...
Die Zone com veröffentlicht aber einen echten, signierten DS-Record für optimizely.com
(Keytag 2371, Alg 13). Ein validierender Client weiß damit, dass die Zone signiert sein muss,
und eine unsignierte Antwort ist an dieser Stelle nicht von einem Angriff zu unterscheiden.
systemd-resolved lehnt sie korrekt ab:
DNSSEC validation failed for question optimizely.com IN DS: no-signature
DNSSEC validation failed for question optimizely.com IN DNSKEY: no-signature
DNSSEC validation failed for question foia04aapy36eg.dxp.optimizely.com IN A: no-signature
Entscheidend ist: um irgendetwas unterhalb von optimizely.com zu validieren, muss der Client
die Vertrauenskette com → optimizely.com → dxp.optimizely.com aufbauen. Dafür braucht er
DS und DNSKEY am Apex. Der Apex-Block macht damit genau die Subdomains unbrauchbar, die ihr
absichtlich freigelassen habt. Ergebnis ist kein sauberer Block, sondern SERVFAIL für die
gesamte CNAME-Kette; curl und getent melden nur noch „could not resolve host“.
Der Apex-Eintrag bringt also keinen zusätzlichen Filtereffekt, weil die Tracking-Hostnamen ohnehin
separat geblockt sind. Er kostet aber jede Kundenseite, die auf Optimizely DXP gehostet ist.
Bitte
- Den Apex-Eintrag
optimizely.comaus Normal und Clean entfernen.cdn.,logx.undapi.
bitte ausdrücklich blockiert lassen. Hard macht genau das bereits. - Unabhängig davon zur Diskussion: das Muster trifft grundsätzlich jede signierte Domain auf euren
Listen, sobald ein Client selbst validiert.datadoghq.comverhält sich über Normal identisch.
Für signierte Zonen wäre ein direktes SERVFAIL oder ein Durchreichen vonDSundDNSKEY
sauberer als die unsignierte Synthese. Der Block bliebe für normale Clients wirksam, ohne
validierende Clients in ein schwer diagnostizierbares SERVFAIL laufen zu lassen.
Diagnose-Hinweis für andere Betroffene
Das Problem ist schwer zu erkennen, weil dig www.hanwag.com die CNAME-Records im Answer-Abschnitt
weiterhin ausgibt, obwohl der Header status: SERVFAIL sagt. Mit +noall +answer sieht es dadurch
nach einer erfolgreichen Auflösung aus, während curl und getent scheitern. Das wirkt zunächst
wie ein Client-Bug, ist aber keiner.
Getestet auf Arch Linux, systemd 261, systemd-resolved mit DNSOverTLS=opportunistic und DNSSEC=true.
Ich bin vorerst auf hard.dnsforge.de umgestiegen, dort tritt das Problem nicht auf.
Analyse und Debugging habe ich mit Unterstützung von Claude Code durchgeführt.
Viele Grüße
Gregor