DNS Multiple QTYPEs (RFC 10029) und SEO-Crawl-Geschwindigkeit

Jedes Mal, wenn ein Crawler Ihre Website besucht, muss er einem DNS-Server (Domain Name System) einige grundlegende Fragen stellen, noch bevor er die eigentliche Seite anfordern kann. Wie lautet die IPv4-Adresse? Wie lautet die IPv6-Adresse? Unterstützt diese Domain HTTPS-Einträge? Jahrelang bedeutete jede dieser Fragen einen separaten Roundtrip (Paketlaufzeit). Der im Juni 2024 standardisierte RFC 10029 ändert das. Er ermöglicht es einem Client, mehrere Abfragetypen (Query Types oder QTYPEs) in einer einzigen DNS-Anfrage zu bündeln. Für Suchmaschinen-Crawler, die täglich Millionen von Domains ansteuern, ist das keine unbedeutende Detailverbesserung. Es ist eine strukturelle Veränderung, die beeinflusst, wie schnell eine Website erfasst und indexiert wird.

Das ist für die Suchmaschinenoptimierung (SEO) von großer Bedeutung, da die DNS-Auflösung ganz am Anfang der Anfragekette steht - noch vor der Time to First Byte (TTFB, Zeit bis zum ersten Byte), vor dem Rendering und vor allem, was Google auf Ihrer Seite messen kann. Wenn die DNS-Auflösung langsam ist, verzögert sich der gesamte nachgelagerte Prozess.

Das DNS-Latenzproblem: Drei Fragen statt einer

Stellen Sie sich vor, der Googlebot erreicht eine Domain, die er vor Kurzem nicht gecrawlt hat. Bevor er eine HTTP-Anfrage senden kann, muss er den Hostnamen auflösen. Im traditionellen DNS-Modell bedeutet dies separate Abfragen für jeden benötigten Eintragstyp: einen A-Record (A-Eintrag) für die IPv4-Adresse, einen AAAA-Record für die IPv6-Adresse und zunehmend einen HTTPS-Record, der dem Client mitteilt, welche TLS-Parameter (Transport Layer Security) und Ports zu verwenden sind.

Jede dieser Abfragen erfordert einen vollständigen Roundtrip: Der Resolver fragt an, wartet und erhält eine Antwort. Bei einer schnellen, bereits aufgebauten Verbindung mag eine einzelne Abfrage nur 10 bis 30 Millisekunden dauern. Das klingt vernachlässigbar, bis man es hochrechnet. Drei aufeinanderfolgende Abfragen statt einer verdreifachen die DNS-bedingte Verzögerung, noch bevor der Crawler überhaupt eine TCP-Verbindung aufbaut. Multiplizieren Sie das nun mit jeder URL, die ein Crawler auflösen muss - einschließlich Subdomains, CDNs (Content Delivery Networks) und auf der Seite referenzierten Drittanbieter-Ressourcen.

Für einen einzelnen menschlichen Besucher sind drei DNS-Abfragen statt einer kaum wahrnehmbar. Für einen Crawler, der in der Größenordnung von Google arbeitet, oder für einen lokalen Crawler, der in einer Sitzung Tausende von URLs analysiert, summiert sich dieser Unterschied spürbar. Dies ist genau die Art von Ineffizienz auf Protokollebene, die in den meisten SEO-Ratgebern übergangen wird, weil sie sich unterhalb der üblichen Analyseebenen abspielt. Artikel über DNS beschränken sich meist auf TTL-Einstellungen (Time to Live) oder die Auswahl eines schnellen DNS-Anbieters. Sie thematisieren selten, was auf Paketebene während der eigentlichen Auflösung geschieht.

RFC 10029: Eine Abfrage, mehrere Antworten

RFC 10029 löst dieses Problem, indem es einem Client erlaubt, mehr als einen QTYPE in einer einzigen DNS-Nachricht anzugeben. Anstatt drei separate Fragen zu stellen, kann ein Resolver fragen: Gib mir die A-, AAAA- und HTTPS-Einträge für diesen Namen, und zwar alle auf einmal. Der autoritative DNS-Server gibt, sofern er den Standard unterstützt, alle Informationen in einem einzigen Antwortpaket zurück.

Die Funktionsweise ist theoretisch einfach, erfordert jedoch die Unterstützung auf beiden Seiten der Verbindung. Der Resolver (also der Client, der die Anfrage stellt) muss wissen, wie er eine Multi-QTYPE-Abfrage konstruiert. Der autoritative DNS-Server, der die Einträge Ihrer Domain verwaltet, muss wissen, wie er darauf antwortet. Wenn eine der beiden Seiten den Standard nicht unterstützt, fällt der Austausch auf die alte, sequentielle Methode zurück. Das ist eine wichtige Nuance: RFC 10029 ändert in der Praxis erst dann etwas, wenn DNS-Anbieter und Resolver die Unterstützung tatsächlich implementieren.

Derzeit gilt das Augenmerk den großen DNS-Anbietern wie Cloudflare, Google Public DNS und AWS Route 53. Bislang hat keiner von ihnen eine vollständige Produktivunterstützung öffentlich bestätigt, und Google Search Central hat sich nicht dazu geäußert, ob die Resolver des Googlebots den neuen Standard bereits nutzen. Hier muss man realistisch bleiben: Es handelt sich um eine neue technologische Entwicklung und nicht um ein fertiges Feature, das Sie heute schon in Ihren Berichten der Google Search Console messen können. Betrachten Sie alle Zahlen zu erwarteten Latenzeinsparungen daher als Richtwerte und nicht als gesicherte Fakten.

Was schnelleres DNS für die TTFB und das Crawling-Budget bedeutet

Die DNS-Auflösungszeit ist eine der Komponenten, die in die Time to First Byte einfließen. Die TTFB wiederum beeinflusst, wie die Core Web Vitals und die Page Experience bewertet werden, und bestimmt, wie schnell sich ein Crawler von einer URL zur nächsten bewegen kann. Selbst das Einsparen von wenigen Millisekunden bei jeder Abfrage summiert sich, wenn ein Crawler dieselbe Domain wiederholt aufruft oder Tausende von Subdomains unter einer übergeordneten Zone crawlt.

Die wichtigere Auswirkung betrifft das Crawling-Budget. Google weist jeder Website eine begrenzte Crawling-Kapazität zu, basierend auf der Servergeschwindigkeit und der geschätzten Relevanz. Wenn eine DNS-Ebene, die früher drei aufeinanderfolgende Abfragen pro Hostnamen erforderte, nun mit einer einzigen auskommt, wird diese Kapazität frei. Der Crawler kann Seiten tatsächlich abrufen und rendern, anstatt auf Netzwerk-Roundtrips zu warten. Für große Websites mit Zehntausenden von URLs oder für Architekturen, die über viele Subdomains verteilt sind, ist diese Protokolleffizienz ein echter Hebel - selbst wenn sie in den meisten Standardberichten unsichtbar bleibt.

Es ist jedoch ratsam, die Erwartungen realistisch zu halten. Branchenschätzungen gehen davon aus, dass die DNS-Auflösung bei einer Erstverbindung zwischen 10 % und 30 % der gesamten Ladezeit einer Seite ausmachen kann. Dieser Bereich variiert jedoch stark je nach Netzwerkbedingungen und wurde unter Produktionsbedingungen noch nicht gezielt mit RFC 10029 gemessen. Betrachten Sie dies als einen Trend, den man beobachten sollte, und nicht als garantierten Gewinn, den man heute schon exakt beziffern kann.

Vorbereitung der Infrastruktur (und des Audit-Prozesses) auf die Änderung

Sie müssen nicht auf eine offizielle Ankündigung von Google warten, um mit den Vorbereitungen zu beginnen. Einige konkrete Schritte sind schon jetzt sinnvoll.

Erstens: Prüfen Sie, ob Ihr DNS-Anbieter eine öffentliche Roadmap oder ein Changelog hat, das die Unterstützung von Multi-QTYPE-Abfragen erwähnt. Cloudflare, Google Cloud DNS und Route 53 veröffentlichen solche Informationen in der Regel in ihren Entwicklerdokumentationen oder Statusseiten.

Zweitens: Messen Sie im Rahmen Ihrer regelmäßigen technischen Audits weiterhin die tatsächliche DNS-Auflösungszeit und nicht nur die kumulierte TTFB. Wenn Sie Crawler vergleichen, um zu sehen, welche Tools Ihnen diese Detailtiefe bieten, zeigt unser Artikel über den Vergleich der besten SEO-Crawler, worauf Sie abseits der einfachen Linkprüfung achten sollten.

Drittens: Vernachlässigen Sie wegen dieser Neuerung nicht die Grundlagen. Sinnvolle TTL-Werte, ein schneller autoritativer DNS-Anbieter und ein CDN mit breiter Anycast-Abdeckung sind heute immer noch wichtiger als ein Standard, der sich noch in der Einführungsphase befindet. RFC 10029 ist eine sinnvolle Ergänzung, aber kein Ersatz für eine solide DNS-Hygiene.

Seodisias ist als kostenloser, plattformübergreifender Desktop-Crawler für Windows, macOS und Linux genau für diese Art von technischem Audit konzipiert. Da die Software lokal auf Ihrem Rechner läuft, verlassen Ihre Crawling-Daten niemals Ihr Gerät. Zudem ist das Rendern von JavaScript direkt integriert, ohne dass diese Funktion hinter einer Paywall versteckt wird. Zu beobachten, wie Protokolländerungen wie RFC 10029 ausgerollt werden und wie sie sich real auf Ihre eigenen Domains auswirken, ist deutlich einfacher, wenn Sie nicht bei jedem Crawl-Versuch gegen ein URL-Limit oder eine Registrierungsschranke stoßen.

Fazit

RFC 10029 is eine kleine Protokolländerung mit spürbarem Potenzial für die Crawling-Effizienz. Sie wird Ihre Rankings nicht über Nacht verändern, und die Verbreitung bei Resolvern und autoritativen DNS-Anbietern steht noch am Anfang. Aber für technische SEOs, die ohnehin in den Kategorien TTFB, Crawling-Budget und Optimierung auf Protokollebene denken, lohnt es sich, dieses Thema schon jetzt zu verfolgen.

Beginnen Sie damit, Ihre eigenen DNS-Auflösungszeiten zu analysieren, und behalten Sie die Unterstützung des Standards durch Ihren Anbieter im Auge. Wenn Sie nach einer kostenlosen, lokalen Möglichkeit suchen, dieses Audit ohne URL-Beschränkungen durchzuführen, testen Sie Seodisias.