namebench – oder jede Sekunde zählt

Mal wieder ein wirklich gutes Tool, was man sich als road warrior merken sollte: namebench. Damit ermittelt man die optimalsten Nameserver für den jeweiligen Client. Das kann manchmal schon zu einem deutlich flüssigeres Gefühl beim Surfen führen.

Hier das Ergebnis meines lokalen Clients. Obwohl Google gewonnen hat, bleibe ich bei meinen Einstellungen. Die wissen ja sowieso schon alles ;-).

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Google Public DNS

Google Public DNS den Link muss ich mir merken. Google hat doch tatsächlich wieder einen neuen Weg gefunden, wie sie mitbekommen wo Leute surfen. Ich bin skeptisch …

Einen Vorteil hat das Teil jedoch: Mit der IP 8.8.8.8 kann man sich endlich mal eine IP merken, die man in Zukunft immer pingen kann 🙂

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Redundante DNS Server – Teil 2

Die ersten Antworten auf den letzten Artikel sind schon da. Interessant ist, dass manche Leser der Meinung sind sie hätten solche Probleme nicht. Sie verwenden die DNS-Server ja nur intern. Und tragen brav alle verfügbaren in der resolv.conf Datei ein. Für diese Leser ist dieser 2te Artikel gedacht.

Nun im Gegensatz zum Zonenfile spielt die Reihenfolge in der Konfigurationsdatei eine Rolle! Ich zitiere mal die wichtigsten Stellen aus der manpage von resolv.conf:

(…) If there are multiple servers, the resolver library queries them in the order listed. (…) The algorithm used is to try a name server, and if the query times out, try the next, until out of name servers, then repeat trying all the name servers until a maximum number of retries are made. (…)

Die wichtigsten Default Werte sind folgende:

  • MAXNS = 3
  • timeout = 5
  • attempts = 2

Somit ist klar, fällt der ersten Nameserver in der Liste aus, dauert jeder Query mindestens 5 (!!) Sekunden um von den zweiten die entsprechende Antwort zu bekommen. Und mehr wie 3 Nameserver (MAXNS) bringt sowieso nichts. Also selbst wenn man Nameserver „nur“ intern verwendet müssen diese möglichst hochverfügbar sein. „Viel (Nameserver) hilft viel“ gilt hier nicht.

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Redundante DNS Server

Über das Verhalten von DNS Queries diskutiere ich sehr gerne. DNS Abfragen funktionieren anders als die meisten sich das vorstellen. Hat eine Zone mehrere NS Records (etwa ns1.provider.de und ns2.provider.de) wird nicht immer der erste genommen und erst dann auf den zweiten geschwenkt, wenn der erste nicht mehr erreichbar ist. DNS funktioniert anders! Hat ein Nameserver die Zone für eine bestimmte Domain nicht geladen, so wird erst der schnellste Nameserver aus den angebotenen ermittelt. Dieser wird dann immer benutzt. Fällt er mal aus, so erhält der Nameserver eine Strafe und fällt in der Rangliste nach hinten. Läuft er schon länger braucht es aber einige Zeit bis er hinter den zweiten zurückfällt (das kann Stunden dauern). Damit sind die DNS Anfragen beim Ausfall des schnellsten plötzlich sehr sehr langsam und der darüber erreichbare Service kann den Anschein haben er sei ausgefallen. Das dümmste ist also einen der DNS Server (also auch den sekundären) nicht redundant auszustatten. Man weiß ja nie sicher wo die Anfragen landen. Verlangsamt man die Anfragen auf dem „sekundären“ künstlich, damit er immer der sekundäre bleibt, bekommt er zwar normalerweise wenig Anfragen, das Umschalten dauert im Ausfall des ersten dennoch ewig. => Sinnlos

Aber wozu dann überhaupt mehrere NS Einträge / Server?

Ganz einfach! Nachdem immer der schnellste genommen wird, ist es meist auch der nächste Nameserver im Netz. In dem man die verschiedenen Nameserver geschickt platziert verringert man sowohl Antwortzeiten als auch Traffic. Das ist auch der Grund warum etwa Denic Nameserver auf der ganzen Welt platziert, oder warum es nicht nur einen Root-Server gibt.

Immer wenn ich mal Zeit habe versuche ich die Links zu finden, die das Verhalten dokumentieren. Jetzt merke ich mir mal die ersten Links hier:

  • Windows (siehe: Note: If multiple NS records exist for a delegated zone identifying multiple DNS servers available for querying…)
  • Bind

Fortsetzung folgt.

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Apache und localhost

Bei jedem Neustart des Apache und damit auch bei jedem Logrotate der Apache-Logfiles hatte folgende nervige Fehlermeldung bekommen:

Starting httpd: httpd: Could not determine the server's fully qualified domain 
name, using 127.0.0.1 for ServerName

Anfangs hatte ich vermutet, dass die vielen Hostnamen in der /etc/hosts, die ich definiert hatte dafür verantwortlich sind:

127.0.0.1 localhost edel.localhost typo3.localhost intranet.localhost 
sandbox.localhost compete.localhost boston.localhost chicago.localhost 
webservices.localhost miles.localhost statistics.localhost signup.localhost

Ein Ändern auf

127.0.0.1 localhost.localdomain localhost

Hat aber auch nicht geholfen und zudem wollte ich nicht die praktischen Namen verlieren. Die nehme ich nämlich zum Entwickeln und Debuggen.

Also was war letztendlich der Grund? Die Lösung ist einfach: Auf meiner Ubuntu Kiste war einfach der Domainname nicht ordentlich gesetzt. Das folgende Kommando hat geholfen:

hostname localhost.localdomain

Mit dnsdomainname kann man übrigens die Richtigkeit der Konfig checken. Damit ist klar, das auf den Debian Kisten in /etc/hostname auch die Domain mit reingehört. Bei CentOS ist es über /etc/sysconfig/network geregelt. Auch dort gehört unter HOSTNAME der volle Hostname also inkl. Domain rein.

Der Hammer, dass ich mich erst jetzt darum gekümmert habe …

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)