{"id":726,"date":"2012-02-15T16:04:34","date_gmt":"2012-02-15T15:04:34","guid":{"rendered":"http:\/\/blog.imagmbh.de\/?p=726"},"modified":"2019-01-13T23:11:39","modified_gmt":"2019-01-13T22:11:39","slug":"google-dns-server-und-seine-merkwurdigkeiten","status":"publish","type":"post","link":"https:\/\/blog.imagmbh.de\/index.php\/google-dns-server-und-seine-merkwurdigkeiten\/","title":{"rendered":"Google-DNS-Server und seine „Merkw\u00fcrdigkeiten“"},"content":{"rendered":"

Google betreibt f\u00fcr die \u00d6ffentlichkeit unter den IP-Adressen 8.8.8.8 und 8.8.4.4 DNS-Server<\/a>. Hierdurch ist ein Surfer nicht auf die DNS seines Providers angewiesen und Administratoren von eigenen DNS-Servern, z. B. f\u00fcr die eigenen Dom\u00e4nen, k\u00f6nnen \u00fcberpr\u00fcfen, ob Ihre Eintr\u00e4ge korrekt ausgeliefert werden. Obwohl Google nur zwei IP-Adressen nennt, verbergen sich hinter jeder dieser Adressen anscheinen mehrere unabh\u00e4ngige Rechner. Anders ist das folgende Verhalten nicht zu erkl\u00e4ren:<\/p>\n

Es geht um einen DNS-A-Record f\u00fcr eine Dom\u00e4ne, nennen wir den Namen www.abcdef.de und die zugeh\u00f6rige IP-Adresse 1.2.3.4. Kurz vor dem Nachfolgenden wird die IP-Adresse des Namens zu 4.3.2.1 ge\u00e4ndert. Der TTL-Wert liegt bei den klassischen 86400 Sekunden, also einem Tag. Nameserver, die also den Namen vor kurzem abgerufen haben, w\u00fcrden aus ihrem Cache noch die alte IP-Adresse 1.2.3.4 ausliefern, Nameserver, die die Adresse nicht im Cache haben, w\u00fcrden die Adresse neu holen und 4.3.2.1 ausliefern.<\/p>\n

Von einem Rechner im Netz A in einer Stadt, angebunden \u00fcber einen Provider wurde der Google-DNS-Server 8.8.8.8 nach einer Namensaufl\u00f6sung gefragt.Der Google-DNS lieferte 4.3.2.1. Google hatte die Adresse also nicht im Cache und neu vom originalzust\u00e4ndigen DNS geholt.<\/p>\n

Kurz danach wurde der DNS 8.8.8.8 von einem anderen Rechner in einer anderen Stadt und \u00fcber einen anderen Provider ein zweites Mal angefragt – und lieferte: 1.2.3.4 – als h\u00e4tte er die Adresse gecached – und zwar vor der \u00c4nderung der IP-Adresse im Original-DNS. Dies bei\u00dft sich jedoch eindeutig mit der Antwort der vorherigen Anfrage.<\/p>\n

Um dies zu verifizieren wurden die selben Anfragen erneut zu nahezu identischen Zeiten durchgef\u00fchrt und lieferten wieder diese Ergebnisse. Ein Blick auf die in den Ergebnissen genannte noch verbleibende TTL-Zeit offenbarte ebenfalls Erstaunliches: Diese Zeiten waren nicht gleich, sondern unterschieden sich deutlich. Dieses Verhalten ist nur zu erkl\u00e4ren, wenn sich hinter derselben IP-Adresse „8.8.8.8“ unterschiedliche Rechner verbergen, die Ihre Daten unabh\u00e4ngig voneinander auswerten.<\/p>\n

Ein solches Loadbalancing-Verhalten ist bei – laut Google – 70 Milliarden Anfragen pro Tag auf den DNS-Dienst sicherlich wahrscheinlich. \u00c4rgerlich ist nur, dass dieses Loadbalancing zu unterschiedlichen Anfrageergebnissen f\u00fchrt. Interessant ist, dass dieses Verhalten \u00fcber einen l\u00e4ngeren Zeitraum verifizierbar war, also eine gewisse Wahrscheinlichkeit besteht, dass der Loadbalancer entweder sich die Adressen der Anfragenden merkt, um neue Anfragen dann wieder zum selbem Rechner weiterzuleiten um m\u00f6glichst Konsistenz herzustellen – eine unwahrscheinliche L\u00f6sung, da hierf\u00fcr ein erheblicher Verwaltungsaufwand notwendig ist. Oder dass der Loadbalancer geografisch oder netzbasiert arbeitet und deswegen die Anfragen immer wieder zum gleichen Rechner geschickt hat. Nat\u00fcrlich kann es sich auch um Zufall gehandelt haben. Bei der Anzahl der durchgef\u00fchrten Versuche liegt die Wahrscheinlicheit hierf\u00fcr jedoch bei unter 2%.<\/p>\n

 <\/p>\n

 
\n