DNS repliziert sich zu langsam

F

franc

Member
Hallo

gibt es irgendeinen Trick, wie ich den DNS-Servern auf der Welt schneller beibringen kann, dass sich die IP meines Servers geändert hat?

Ich habe heute Nacht einen Ubuntu Server umgezogen (Ubuntu 8.04 > 12.04), auf beiden Servern in bind die neue IP genommen und auch bei meinem Provider (Host Europe) die Änderungen eingetragen. Beide Server geben mir auch die neue IP aus, wenn ich danach frage.
Dennoch ist einen halben Tag später gelegentlich immer noch die alte IP am Wirken.

Namentlich der Google DNS (8.8.8.8) macht mir Kopfzerbrechen: der war relativ bald mit der neuen IP bekannt, aber jetzt plötzlich fällt er auf die alte IP zurück!
Während der andere Google DNS (8.8.4.4) die neue IP anzeigt.

Nachtrag: Ich kenne einen Telekom Speedport Router, der hat mir nach zwei Jahren (nach einem vorigen Serverwechsel) noch gelegentlich die alte IP geliefert, die dort fest hinterlegten DNS-Server sind somit unbelehrbar.

Es ist so undurchsichtig und dadurch zum Haareraufen!

Was kann man da tun?

franc
 
Am besten den TTL heruntersetzen, evtl. hilft das?
 
TTL runter setzen hätte nur was gebracht, wenn das rechtzeitig vorher gemacht worden wäre, damit die DNS-Server die alten Einträge nicht so lange cachen.
Grundsätzlich muß man bei einem IP-Wechsel damit rechnen, daß es bis zu 24 Stunden dauert, bis die Änderung sich im DNS rumgesprochen hat.
Auch soll es DNS-Betreiber geben, die Einträge mindestens über einen gewissen Zeitraum cachen, auch wenn die TTL eigentlich kürzer eingestellt ist.
 
Jetzt habe ich die TTL Werte auf jeweils 60 gesetzt.

Was mich verwundert ist, dass relativ bald auf dem Google DNS Server (8.8.8.8 also google-public-dns-a.google.com) die wichtigste meiner Domains auf die neue IP repliziert war. Später wurde dort aber dann wieder die alte IP ausgegeben und danach wieder die neue, das hat sich abgewechselt.

Ich habe dann festgestellt, dass ich den Reverse DNS Eintrag von Host Europe noch auf der alten Server IP stehen hatte, das hatte ich übersehen, vielleicht hat das auch etwas beeinflusst.

Jedenfalls sind alle Domains jetzt bei "normalen" DNS Servern auf die neue IP gesetzt, nur beim DNS Server von Host Europe, dem ns2.hans.hosteurope.de (80.237.128.10), ist immer noch die alte IP hinterlegt.
Dummerweise muss (?) ich den für meine bei Host Europe konnektierten Domains auch als zweiten DNS Server beibehalten.

Kann es sein, dass der DNS von Google sich im Laufe des Tages immer wieder mal vom DNS von HE beeinflussen lassen hat und dadurch auf die alte IP zurückgesprungen ist?
Lustigerweise hat der zweite Google DNS, der 8.8.4.4 aber dann richtig ausgegeben.

Insgesamt hat diese unzuverlässige DNS Ausgabe für einen ordentlichen Mehraufwand gesorgt, beim nächsten Mal würde ich das lieber anders machen.
Aber wie?
 
DNS ist kein Realtimesystem und das ist auch gut so[tm].
Bis zu 72 Stunden muss man für das weltweite Übernehmen geänderter DNS-Records immer einkalkulieren, in Einzelfällen so gar erheblich mehr.
 
Kann es sein, dass der DNS von Google sich im Laufe des Tages immer wieder mal vom DNS von HE beeinflussen lassen hat und dadurch auf die alte IP zurückgesprungen ist?
Lustigerweise hat der zweite Google DNS, der 8.8.4.4 aber dann richtig ausgegeben
Click to expand...
Google hat mehr als 2 Server, auch wenn es nur 2 IP's sind. Diese werden per Anycast auf mehrere geografisch getrennten Server (respektiv Server-Cluster) verteilt wovon verschiedene die Eintraege spaeter als andere gekriegt haben.
 
d4f said:
Google hat mehr als 2 Server...
Click to expand...
Ahh! Verstehe, die Antwort kommt also von mehr oder weniger zufälligen Servern. Dann ist es klar.

OK, das nächste Mal werde ich eine Woche vorher schon die TTL auf 60 setzen und danach wieder auf Standard.
Hat mich viel Zeit und Nerven gekostet, diese Nachlässigkeit.
 
Das hilft nicht unbedingt.
Zumal einige DSL-Anbieter versuchen ihre hoffnungslos unterdimensionierten, ausfallgefaehrdete und ueberbelastete DNS-Server durch Festsetzen der Mindest-TTL auf bis zu 1 Tag zu entlasten.

Dagegen hilft bei Webseiten nur dass du auf dem alten Server einen reverse-Proxy wie zB haProxy, Nginx, Varnish, ... einrichtest welcher die Anfragen an den neuen Server weiterleiten. Falls du Apache verwendest so kannst du das 'Problem' der falschen REMOTE_ADDR durch mod_rpaf beheben, andere Webserver haben andere Methoden dazu.

Emails sollten eh mehrere Tage vom Absender zwischengespeichert werden, aber indem du einfach einen 2. MX-Eintrag anlegst und den ersten Server vom Netz nimmst sollte direkt auf den anderen uebergesprungen werden.

Eigentlich nicht domain-basierte Dienste wie FTP wo die Kunden und Mitarbeiter aber aus Einfachheitsgruenden gerne Domains als Server-Adresse verwenden muessen halt manuell aktualisiert werden oder auf eine x-beliebige neu-erfundene Subdomain konfiguriert werden. Diese muss direkt von deinem Nameserver bezogen werden und kann somit keinen alten Wert enthalten.
 
d4f said:
Dagegen hilft bei Webseiten nur dass du auf dem alten Server einen reverse-Proxy wie zB haProxy, Nginx, Varnish, ... einrichtest welcher die Anfragen an den neuen Server weiterleiten.
Click to expand...
Viel zu aufwendig, ressourcenfressend und in der Konfiguration zu fehleranfällig!
rinetd erfüllt diesen Zweck zuverlässig, ressourcenschonend und mit minimalster Konfiguration.
 
Ich hatte gerade ein längeres Gespräch mit einem sehr hilfsbereiten und kompetenten Mann bei Host Europe (HE).
Irgendwas hatte noch gefehlt, nämlich ein "Notify" von unserem NS zum (authoritativen) NS von HE.

Unser Fall sei ungewöhnlich, weil wir einen eigenen (primary) NS verwenden und diesen nicht mit Plesk verwalten.
Der NS von HE wurde somit nie informiert.
Er hat das nun von Hand angestossen und nun wird eine DNS Abfrage der Domains über den HE NS endlich auf die neue IP aufgelöst.

Unser Fall sei auch daher ungewöhnlich, weil diejenigen, die so eine Konfiguration haben, also eigenen NS und zweiten von HE, sich normalerweise derart auskennen, dass sie meine Probleme nicht haben ;)

Es ist wohl sinnvoller beide NS bei HE zu betreiben, man kann dann die Domains im "KIS" (einer Konfigurationsweboberfläche) von HE selbst vornehmen, repliziert wird dann natürlich viel schneller.

So werde ich es dann wohl tun, da ich bind eigentlich nur mit unangenehmen Problemen verbinde, weil es (eben in Verbindung mit den HE-NS) nie zuverlässig funktionierte bisher.
Ich betreibe ja schließlich auch keinen DynDNS Dienst, so dass ich einen eigenen NS bräuchte.
 
rinetd erfüllt diesen Zweck zuverlässig, ressourcenschonend und mit minimalster Konfiguration.
Click to expand...
Laut man-Page kann rinetd noch immer nur auf Protokollebene (TCP) und nicht Anwendungsebene (HTTP) arbeiten wodurch er nicht den entsprechenden X-Forwarded-For Header setzen kann welcher fuer korrekte Weiterleitungen Pflicht ist. Somit erfuellt er den Zweck nicht.
 
HE hat noch mal geantwortet, die laufende Nummer in dem hosts Dateien war nicht erhöht worden.
Das hatte ich nicht gewusst, ich hatte die ja nur kopiert und die IP angepasst.
Dadurch wusste der NS von HE nicht dass sich was geändert hatte.

2012-06-06 Nachtrag: Ich habe gestern mal testweise eine andere Domain geändert, nämlich nur den A-Eintrag, ich wollte diesen nämlich testweise auf einen anderen Server leiten, das war nach ein paar Minuten repliziert, ohne Probleme. Der NS von HE hat das auch ruckzuck übernommen, weil sich wohl die laufende Nummer geändert hat.
Das war also der (große) Fehler von mir, dass ich das einfach kopiert hatte ohne genau zu wissen, was die einzelnen Felder bedeuten, insbesondere diese laufende Nummer :(
 
Last edited by a moderator:
X-Forwarded-For ist ein X-Header und somit schon per Definition ein optionaler, beliebig anwendbarer und mit beliebigem Inhalt zu setzender Header. Daher ist er auch keine Pflicht.
Desweiteren sind die paar Stunden ohne X-Forwarded-For verschmerzlich und zudem deckt rinetd noch ein wenig mehr ab, als nur HTTP. Wie willst Du denn SMTP/IMAP/POP3/etc. mit Deinen HTTP-Proxys/Caches abfrühstücken? Für jedes Protokoll einen eigenen Proxy aufsetzen und absichern? Bis Du damit fertig bist, ist das DNS längst weltweit aktualisiert...
 
X-Forwarded-For ist ein X-Header und somit schon per Definition ein optionaler, beliebig anwendbarer und mit beliebigem Inhalt zu setzender Header. Daher ist er auch keine Pflicht.
Click to expand...
Korrekt. Aber viele PHP-Anwendungen, Webserver-Module und Logparser setzen korrekte Client-IP's voraus um ihre Sicherheit oder Analyse durchfuehren zu koennen.
Ob diese nun ein paar Stunden falsche Besucher-IP's verkraften koennen muss analysiert und getestet werden. Pauschal und mit dem Arbeitsaufwand berechnet ist es bedeutend einfacher einfach einen reverse Proxy auf zu setzen.

Wie willst Du denn SMTP/IMAP/POP3/etc. mit Deinen HTTP-Proxys/Caches abfrühstücken?
Click to expand...
Hab ich doch beschrieben; auf Clientseite. Hier gilt in aller Regel ja dass nur eine Handvoll Geraete aktualisiert werden muessen statt jeder Webseitenbesucher.
Ausserdem sind in aller Regel die meisten der Geraete unter der Kontrolle des oder kontaktierbar durch den Serverbesitzer.
Ausserdem kann man hier mit mehreren A-Records fahren; wenige Geraete moegen dies nicht oder handhaben es korrekt und diese kann man manuell aktualisieren.
Die meisten Kunden haben uebrigens gar keine Lust sich die Muehe zu machen und warten einfach ab bis es wieder korrekt funktioniert; schliesslich gehen keine Emails verloren.

Bis Du damit fertig bist, ist das DNS längst weltweit aktualisiert...
Click to expand...
Also sooooo lahm bin ich auch wieder nicht. Mit korrekter Vorbereitung und etwas Uebung ist man unter 10 Minuten Downtime fuer die kritischen Protokolle. Je nach Webseitengroesse, Migrationsprotokoll und Anbindung (sowie natuerlich Know-How) kann man einzelne Webseiten unter 10 Sekunden Downtime migrieren. Dauert dann insgesamt etwas laenger bis alle vHosts rueber sind aber die einzelnen Seiten sind weniger beeinflusst.
 
d4f said:
Die meisten Kunden haben uebrigens gar keine Lust sich die Muehe zu machen und warten einfach ab bis es wieder korrekt funktioniert; schliesslich gehen keine Emails verloren.
Click to expand...
Die meisten Kunden werden Dich mit Supportanfragen bombardieren, wenn sie nicht auf ihre E-Mails zugreifen können. Insbesondere Geschäftskunden wollen/müssen alle paar Minuten pollen und jammern schneller, als die Kiddies wenn Facebook down ist. Das dabei im günstigsten Fall keine Mails verloren gehen interessiert sie dabei herzlich wenig, zumal das nicht garantiert ist, denn im geschäftlichen Umfeld existieren leider noch immer viele Mailsysteme die keinen zweiten Zustellversuch unternehmen.

Für den kleinen 0815-Selfhosting-Hobbyadmin ist das im Regelfall kein Problem, fürs Business kann soetwas schnell mal teuer werden und da spielt dann ein Logfile mit wenigen Stunden "falscher" IP-Adressen eine untergeordnete Rolle, da finanziell nicht relevant.
 
Kann ich nicht nachvollziehen. Schliesslich gibt es solche Sachen wie Newsletter um zumindest deren Webspace-Administrator in Kenntniss zu setzen. Klar gibts immer Leute die meckern, aber meist reicht es aus diese Leute an zu weisen den Router neu zu starten um den darin enthaltenen DNS-Cache zu leeren.

Uebrigens sind die (zumindest alle mit denen ich zu tun hatte) Business-Kunden mit den teuersten Paketen immer die wo am wenigsten Probleme mit etwaigen Umstellungen und Aktualisierungen haben.
Mag dran liegen dass die meisten davon ihre eigenen DNS-Server im Firmennetz betreiben und somit ein Cache-Reset zum vorher abgesprochenen Zeitpunkt keinerlei Probleme macht; Cronjobs ftw.

Aber das Hauptthema hier war ja HTTP und da stimmst du mir ja sicherlich zu dass ein reverse HTTP-Proxy die einfachste und beste Loesung ist =)
 
franc said:
HE hat noch mal geantwortet, die laufende Nummer in dem hosts Dateien war nicht erhöht worden.
Das hatte ich nicht gewusst, ich hatte die ja nur kopiert und die IP angepasst.
Click to expand...
BIND mit statischen Zonendateien? Der wirft dann aber eine dicke fette Meldung:
general: error: zone xxx/IN: zone serial unchanged
Click to expand...
 
d4f said:
Aber das Hauptthema hier war ja HTTP und da stimmst du mir ja sicherlich zu dass ein reverse HTTP-Proxy die einfachste und beste Loesung ist =)
Click to expand...
Die beste Lösung, ja, wenn man sich damit auskennt, was beim OP jedoch nicht der Fall ist. Daher ist für den OP rinetd die einfachste Lösung ;)

BTW: Deine Kunden werden garantiert meckern und gegebenenfalls Schadenersatz fordern, wenn deren Kunden zum Ausfallzeitpunkt einen JIT-Auftrag nicht zustellen konnten und deren Mailsystem keinen zweiten Zustellversuch unternimmt. Oder eine Rechnung/Mahnung/whatever und dadurch vermeidbare Folgekosten entstehen.

Mail ist im geschäftlichen Umfeld einer der wichtigsten Kommunikationskanäle und verzeiht keine Ausfälle, solange es da draussen kaputte Mailserver gibt.

Ich habe schon einen Mailserver gesehen, der einen 450 wie einen 550 behandelte, den Bounce geschmeidig nach /dev/null schob und auch noch das Logging wegen missverstandenem Datenschutz deaktiviert hatte. Bis ich das Ganze dort dem unterbezahlten fachfremden Teilzeitadmin und seinem Boss endlich auf DAU-Niveau verständlich machen konnte, vergingen mehrere Tage. Das Unternehmen hatte zu der Zeit knapp 600 Angestellte, war also nicht wirklich klein und hätte sich einen erfahrenen SysAdmin locker leisten können (das wurde dann glücklicherweise nachgeholt).

Nur eine Anekdote von vielen...


Zusammenfassend können wir festhalten, dass man Serverumzüge möglichst weit im Voraus sorgfältig plant/testet und beide Systeme mindestens eine Woche parallel betreibt, um etwaigen externen Problemen aus dem Weg zu gehen.
Am Besten ist es, wenn für solche Szenarien bereits einen ständig aktualisierten Masterplan in der Schublade hat, auch wenn man ihn durch glückliche Zufälle vielleicht nie brauchen sollte.
 
You must log in or register to reply here.
Back
Top