Summary

  • Patrick Sattler berichtete bei RIPE 92, dass die getesteten Chrome- und Firefox-Versionen auf beide DNS-Antworten, A und AAAA, warteten. Ein verspäteter A-Record verzögerte eine Seite trotz nutzbarer IPv6-Adresse; Firefox scheiterte in einigen Testfällen.
  • Safari setzte als einziger Browser dieser untersuchten Gruppe das vollständige Happy-Eyeballs-v2-Verhalten mit DNS-Auflösungsverzögerung um. Bei den anderen geprüften Clients konnte der Timeout des Resolvers die Ladezeit bestimmen.

Die IPv6-Adresse ist angekommen. Der Server wäre erreichbar. Das Browserfenster wartet trotzdem auf eine IPv4-Auskunft. Patrick Sattler zeigte bei RIPE 92, wie ein Verfahren für schnelle Pfadwahl schon vor dem ersten Verbindungsversuch an der Namensauflösung hängen kann.

Happy Eyeballs startet bevorzugt IPv6 und erlaubt IPv4 später aufzuholen. Sattler betrachtete die Phase davor: Der Browser fragt DNS nach AAAA und A. Sein Team baute einen konfigurierbaren Namensserver und Webtest, verzögerte Antworten gezielt und beobachtete die Clients als Blackbox. Die offizielle Vortragsseite hält die wichtigsten Unterschiede fest.

Im Testaufbau vom Mai 2026 fragten Chrome und Firefox beide Record-Typen ab und warteten auf beide Antworten. Die untersuchten Versionen hatten die DNS-Auflösungsverzögerung von v2 nicht umgesetzt. Blieb A aus, stieg die Ladezeit; Firefox brach in einigen Fällen sogar ab, obwohl AAAA bereits vorlag. Safari ging mit einer schnellen AAAA-Antwort über IPv6 weiter, auch wenn A trödelte. War dagegen AAAA verspätet, wechselte es im gezeigten Versuch nach ungefähr 50 Millisekunden zu IPv4.

Die eigentliche Verbindungswahl besitzt eine andere Uhr. Chrome verwendete im Versuch ungefähr 300 Millisekunden, Firefox etwa 250; Safari passte den Abstand dynamisch an. Sattler verwies auch auf Betriebssystem, Proxy und Netzbedingungen. Sein öffentlicher Test war damals nur in München gehostet. Ein neuer Browser-Build braucht einen neuen Versuch.

Der Resolver ist damit an einer vermeintlichen Browser- oder IPv6-Störung beteiligt. Wenn der Client beide DNS-Antworten verlangt, bestimmen Wiederholung und Timeout des Resolvers die Wartezeit für den fehlenden A-Record. Sattler empfahl DNS-Betreibern, diese Einstellungen zu prüfen. Browserentwickler entscheiden auf ihrer Seite, wann eine vorhandene AAAA-Antwort genug ist, um loszulaufen.

Ein brauchbarer Fehlerbericht braucht getrennte Zeiten für A und AAAA, die Client-Version, den Resolver, den Proxy und den ersten Verbindungsversuch. Ein erfolgreiches IPv6-Ping erklärt die stehende Seite nicht. Sattlers Messung zeigt, welcher Schreibtisch den nächsten Blick verdient.

Quellen: RIPE-92-Originaltranskript · offizielle Vortragsseite · RACI-Profil.