Wie ein DNS-Eintrag die Hälfte der Besucher aussperrt

Ein Kunde ruft die Website auf und bekommt eine rote Warnseite:„Ihre Verbindung ist nicht privat." Der Nächste ruft dieselbe Seite auf und sieht sie ganz normal. Beide haben recht — und genau das macht diesen Fehler so tückisch.

Das ist uns bei einer frisch umgezogenen Domain passiert. Der Weg zur Ursache ist lehrreich, weil jede naheliegende Prüfung ihn verfehlt.

Warum es nur die Hälfte trifft

Eine Domain kann mehr als einen A-Record haben — mehr als eine IP-Adresse, auf die sie zeigt. Das ist normalerweise ein Feature für Lastverteilung: Der Resolver wählt zufällig eine aus.

Bei uns sah es so aus:

dig +short otaku-development.de A
216.150.1.1      ← der neue Hoster (richtig)
185.3.235.231    ← ein Parkserver vom alten Hoster

Der zweite Eintrag war beim Umzug übriggeblieben. Er zeigte auf den alten Hosting-Server, der ein Zertifikat für seine eigene Domain ausliefert — nicht für unsere. Trifft ein Besucher diese IP, passt der Name im Zertifikat nicht zur aufgerufenen Adresse, und der Browser schlägt Alarm:ERR_CERT_COMMON_NAME_INVALID.

Zwei A-Records, einer falsch — das ist keine Performance-Frage. Für die Hälfte aller Besucher steht eine Sicherheitswarnung auf der Firmenseite. Gemessen: zehn von zwanzig DNS-Abfragen lieferten die falsche IP.

Warum kein Monitoring anschlägt

Der erste Reflex: „Dann hätte ein Uptime-Check das doch gemeldet." Hätte er nicht. Ein Monitoring ruft die Domain auf, trifft zufällig eine der beiden IPs und bekommt in der Hälfte der Fälle ein sauberes 200 OK. Grün. Alles gut, scheinbar.

Derselbe blinde Fleck steckt in einem schnellen curl von Hand: Man testet einmal, erwischt die richtige IP, sieht kein Problem — und die Kunden sehen trotzdem Warnungen. Der Fehler ist statistisch, nicht deterministisch.

Die Diagnose, die ihn wirklich findet

Der Trick ist, jede IP einzeln zu prüfen, statt der Domain zu vertrauen. curl kann man zwingen, eine bestimmte IP anzusteuern:

# Jede IP der Domain einzeln testen
for ip in $(dig +short otaku-development.de A); do
  code=$(curl -s -o /dev/null -w "%{http_code}" \
         --resolve otaku-development.de:443:$ip \
         https://otaku-development.de/)
  echo "$ip -> $code"
done

216.150.1.1   -> 200      # sauber
185.3.235.231 -> 000      # TLS bricht ab — das ist die Warnung

Die 000 ist der Beweis: Auf dieser IP kommt keine gültige verschlüsselte Verbindung zustande. Wer wissen will, wem die fremde IP gehört, fragt zwei Dinge ab:

dig -x 185.3.235.231 +short          # → host254.checkdomain.de
echo | openssl s_client -connect 185.3.235.231:443 \
  -servername otaku-development.de 2>/dev/null \
  | openssl x509 -noout -subject    # → CN = *.checkdomain.de

Damit ist alles klar: Der Server gehört dem alten Anbieter und liefert dessen Zertifikat aus, das auf unsere Domain natürlich nicht passt.

Der Haken beim Beheben

Man würde erwarten, den störenden Eintrag im DNS-Formular zu finden und zu löschen. War er aber nicht — im Formular stand nur der eine, richtige Record.

Der zweite kam aus einem separaten Dienst des alten Anbieters: einer Domain-Parkfunktion, die eigenständig einen A-Record setzt, außerhalb der normalen DNS-Verwaltung. Solche Anbieter warnen im Kleingedruckten davor („Einstellungen über die Domaindienste funktionieren ggf. nicht mehr") — aber wer sucht dort, wenn er den Eintrag im DNS-Formular erwartet?

Kommt ein gelöschter Record zurück oder taucht einer auf, den man nie gesetzt hat: nicht den Record suchen, sondern den Dienst deaktivieren, der ihn erzeugt.

Damit es nicht wiederkommt

Ein einmaliger Fix reicht nicht, wenn man den Fehler nicht bemerkt hätte. Wir haben daraus ein kleines Prüfskript gemacht, das bei jedem Lauf durchgeht:

• Genau ein A-Record, und der richtige?
• Kein AAAA-Record? (Manche Hoster können kein IPv6 — dann sperrt ein AAAA-Record IPv6-Besucher aus, ein Problem derselben Klasse.)
• Gilt das Zertifikat für diesen Namen, und wie lange noch?
• Liefert jede einzelne IP ein 200?
• Sind die Mail-Einträge unangetastet? (Ein DNS-Umzug killt gern still die E-Mail.)

Es endet mit Exit-Code 1 bei jedem harten Fehler — damit taugt es als Cron-Job oder als Gate vor dem Deploy.

Was ich seitdem anders mache

Nach einem Hosting-Wechsel vergewissere ich mich, dass genau ein A-Record existiert. Der alte verschwindet nicht von selbst, und wenn er aus einem Zusatzdienst statt aus dem DNS-Formular stammt, taucht er dort auch nicht auf.

Das eigentlich Fiese daran: Ein Fehler, der nur die Hälfte der Nutzer trifft, ist schlimmer als einer, der alle trifft. Intern fällt er niemandem auf, kein Monitoring meldet ihn, und der Kunde, der die Warnung sieht, schreibt selten eine E-Mail. Er klickt weg. Solche Sachen findet man nur, wenn man gezielt danach sucht — deshalb läuft bei uns jetzt ein kleiner Wächter, der genau das prüft.