nicht angemeldet
Moin!
MX MailExchanger:
Um die Redundanz in Sache E-Mails zu verbessern, kann man für eine
Domain zwei oder mehr MX-Records erstellen, die auf unterschiedliche
Rechner leiten. Falls einer davon ausfällt, wird der Nächste (nach
Priorität) verwendet.
Es ist hierbei allerdings extrem wichtig, dass sämtliche beteiligten Mailserver vernünftig konfiguriert sind. Am allerwichtigsten: Alle müssen wissen, für welche Mailaccounts sie Mails annehmen (und später dann an den Hauptserver weiterleiten) dürfen, und welche Mailadressen ungültig sind. Server, die sämtliche Mails akzeptieren und erst beim endgültigen Auslieferungsversuch an den primären Mailserver feststellen, dass die Adressen ungültig ist, sind gezwungen, eine Unzustellbarkeitsnachricht an den angeblichen Sender zurückzuschicken. Solche Nachrichten braucht aber kein Mensch.
- was passiert eigentlich, wenn der Rechner mitten im Empfang
einer E-Mail abstürtzt? - Bemerkt dies der entfernte SMTP-
Server über z.B. Timeout (oder Socketabbruch) und sendet die E-
Mail erneut an den zweiten/dritten Mail-Server? (rein
interessenshalber)
Ein guter Mailserver macht sowas. Erst wenn der empfangende Mailserver die Bestätigung zurückgeliefert hat, dass alle Daten korrekt empfangen wurden, sollte die Mail aus der Warteschlange entfernt werden.
Die Verfallszeiten dieser
zwischengespeicherten NS-Daten sind natürlich von NS zu NS
unterschiedlich, aber was sind hier typische Werte?
Zum Beispiel:
@ IN SOA ns1.first-ns.de. postmaster.robot.first-ns.de. (
2000091604 ; Serial
14400 ; Refresh
1800 ; Retry
604800 ; Expire
86400 ) ; Minimum
Ansonsten orientieren sich die Werte einfach an den Erfordernissen.
- nach ca. 1 Stunde sollten alle NS die aktuellen Daten haben.
- Cacheverfallszeit wird von SOA-Record der Domain übernommen.
Die Nameserver haben sich mit der Verfallszeit eigentlich nach der SOA-Angabe zu richten. Aber natürlich kann man sich im privaten Bereich selbst was schnitzen - nur beim Anbieten öffentlicher Nameserver macht sich das nicht unbedingt so gut.
Frage: Kann man auch drei/vier unterschiedlich
gehostete *Primäre*-Nameserver einer Domain zuordnen?
Was die Beantwortung von DNS-Anfragen aus dem Internet angeht, gibt es nur Nameserver ohne Unterschied. Jeder macht dasselbe.
Die Unterscheidung nach erster/zweiter/dritter ist eine rein zählende.
Aber "hinter den Kulissen" gibts natürlich schon Unterschiede. Der primäre Nameserver kriegt normalerweise als einziger manuell die Änderungen konfiguriert, alle sekundären Nameserver erhalten die Veränderungen dann vom primären Nameserver. Dazu gibts im DNS-Protokoll (genauer beim Zonentransfer) die Möglichkeit, alle sekundären Nameserver aktiv von der Änderung zu unterrichten - ansonsten fragen die mit Ablauf der Gültigkeitszeit beim primären Nameserver einfach die Zone neu ab.
Dieses DNS-Protokoll ist aber nicht unbedingt optimal für die Aufgabe. Die Transfermenge wird nicht komprimiert, etc. Deshalb ist es auch problemlos möglich, einfach die Zonenkonfigurationsdatei z.B. per rsync zwischen den Nameservern auszutauschen und dann im Prinzip zwei primäre Nameserver zu betreiben.
Das hatte
ich einmal versucht, aber dann war stets der alte Nameserver aktiv
und der Neue wollte einfach nicht zum Zuge kommen, obwohl ich bei
switch.ch die Reihenfolge entsprechend gesetzt habe
Definiere "zum Zuge kommen"? Wie hast du das festgestellt? Wenn mehr als ein Nameserver definiert ist, wird beim Auflösen eines Namens ein beliebiger Nameserver benutzt - die müssen ja alle gleichwertige, authoritative Informationen über die Zone ausliefern, also muß es egal sein, wen man fragt.
Was bedeuten die „IN NS“-Records? – Festlegung der NS für einen
Host? – Denn die NS-Einträge für eine Domain liegen ja beim
Registrar und nicht auf dem eigenen NS, was soll also die NS-
Definition im NS?
Das ist das sogenannte "glue". Indem man der Zone mitgibt, welche Nameserver für die Zone zuständig sind, kann bei DNS-Anfragen nach der Zone diese Information ebenfalls mitgegeben werden. Damit werden Deadlocks (um die IP vom Nameserver rauszufinden, muß ich die IP vom Nameserver rausfinden...) und unnötige zusätzliche DNS-Anfragen verhindert.
Das Problem sehe ich hier
schlicht in der Synchronisationszeit der NS-Server
Dieses Problem ist per DNS nicht lösbar.
- Sven Rautenberg