nicht angemeldet
Problem mit Namensauflösung
1 0 0 Fürs Archiv: Änderungen am DNS, Serverumzug, ToDO
Problem mit Namensauflösung
Moin,
ich habe mir zwei DNS-Server aufgesetzt (primär/sekundär) und eingerichtet. Diese tun auch was sie sollen. Nun habe ich bei meinem Provider die Domain dejungs.de auf meine Nameserver umgestellt, kann aber den Namen nicht mehr auflösen; in der Antwort steht immer nur "SERVFAIL". Hat jemand eine Idee, wo der Fehler liegen könnte? Der Eintrag bei der Denic scheint korrekt zu sein. Ungewöhnlich ist auch, dass auf meinen Servern keine Requests anderer Nameserver eingehen (nur, wenn ich das direkt mit angebe).
Antwort des Google-DNS:
- dig dejungs.de @8.8.8.8
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> dejungs.de @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54563
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;dejungs.de. IN A
;; Query time: 65 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Jun 4 14:07:52 2015
;; MSG SIZE rcvd: 28
Antwort von meinem Server:
- dig dejungs.de @kronos.misterunknown.de
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> dejungs.de @kronos.misterunknown.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22617
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;dejungs.de. IN A
;; ANSWER SECTION:
dejungs.de. 86400 IN A 46.4.101.180
;; AUTHORITY SECTION:
dejungs.de. 86400 IN NS rhea.misterunknown.de.
dejungs.de. 86400 IN NS kronos.misterunknown.de.
;; ADDITIONAL SECTION:
rhea.misterunknown.de. 86400 IN A 5.9.121.40
kronos.misterunknown.de. 86400 IN A 46.4.101.180
;; Query time: 1 msec
;; SERVER: 46.4.101.180#53(46.4.101.180)
;; WHEN: Thu Jun 4 14:08:56 2015
;; MSG SIZE rcvd: 130
Grüße, Marco
akzeptierte Antworten
Problem mit Namensauflösung
Bewertung: +1, 1 Stimme
-
Tach,
ich habe mir zwei DNS-Server aufgesetzt (primär/sekundär) und eingerichtet. Diese tun auch was sie sollen. Nun habe ich bei meinem Provider die Domain dejungs.de auf meine Nameserver umgestellt, kann aber den Namen nicht mehr auflösen; in der Antwort steht immer nur "SERVFAIL". Hat jemand eine Idee, wo der Fehler liegen könnte? Der Eintrag bei der Denic scheint korrekt zu sein. Ungewöhnlich ist auch, dass auf meinen Servern keine Requests anderer Nameserver eingehen (nur, wenn ich das direkt mit angebe).
ich weiß nicht, wo du bei der DENIC nachgeschaut hast; aber nicht auf deren Nameserver:
dig NS dejungs.de @f.nic.de.
; <<>> DiG 9.7.3 <<>> NS dejungs.de @f.nic.de. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63860 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;dejungs.de. IN NS ;; AUTHORITY SECTION: dejungs.de. 86400 IN NS dns1.ispone-business.de. dejungs.de. 86400 IN NS dns2.ispone-business.de. ;; ADDITIONAL SECTION: dns1.ispone-business.de. 86400 IN A 193.151.6.202 dns2.ispone-business.de. 86400 IN A 193.151.4.202 ;; Query time: 5 msec ;; SERVER: 81.91.164.5#53(81.91.164.5) ;; WHEN: Thu Jun 4 15:00:25 2015 ;; MSG SIZE rcvd: 114Nach der Cache-Dauer, die an der Antwort dran steht; hast du auch mindestens 24h in denen noch Probleme auftauchen werden.
mfg
Woodfighter-
Moin,
ich weiß nicht, wo du bei der DENIC nachgeschaut hast; aber nicht auf deren Nameserver:
Hm, sehr komisch. Wenn man ein Whois auf die Domain macht, dann steht da ganz unten bei "Technische Daten" meine beiden korrekten Nameserver -.- Da werde ich mich wohl mal an die Denic wenden müssen, sofern das in 2 Stunden immer noch so ist...
Danke auf jeden Fall für deinen Hinweis :)
Grüße, Marco
-
Tach,
ich weiß nicht, wo du bei der DENIC nachgeschaut hast; aber nicht auf deren Nameserver: Hm, sehr komisch. Wenn man ein Whois auf die Domain macht, dann steht da ganz unten bei "Technische Daten" meine beiden korrekten Nameserver -.- Da werde ich mich wohl mal an die Denic wenden müssen, sofern das in 2 Stunden immer noch so ist...
inzwischen löst es ja auf, zumindest über den Google-Nameserver, die anderen, die das im Cache haben, werden das wohl frühestens morgen „richtig“ machen. In der Whois-Datenbank nachzuschauen, warum ein DNS-Problem vorhanden ist, ist allerdings auch etwas ungewöhnlich; die beiden werden zwar vermutlich aus einer gemeinsamen Datenquelle gespeist, aber das heißt nicht, dass das zeit- und problemlos funktioniert.
mfg
Woodfighter-
Moin,
inzwischen löst es ja auf, zumindest über den Google-Nameserver, die anderen, die das im Cache haben, werden das wohl frühestens morgen „richtig“ machen.
Ah, danke für die Info! Jetzt weiß ich zumindest, dass es kein Fehler meinerseits war, sondern nur Ungeduld :) Dass bis morgen noch Probleme auftreten können ist mir bewusst, aber nicht weiter tragisch, da es nur eine "Spieldomain" ist, mit der ich meinen ersten eigenen Nameserver teste.
In der Whois-Datenbank nachzuschauen, warum ein DNS-Problem vorhanden ist, ist allerdings auch etwas ungewöhnlich; die beiden werden zwar vermutlich aus einer gemeinsamen Datenquelle gespeist, aber das heißt nicht, dass das zeit- und problemlos funktioniert.
Ich hatte dort nur geguckt, ob die Handles korrekt sind, und gesehen, dass die Nameserver da auch korrekt drin stehen. Die Möglichkeit, dass die eigentlichen Nameserver noch die alten Einträge aktiv haben, hatte ich gar nicht auf dem Radar.
Danke dir nochmal!
Grüße, Marco
-
-
-
Moin!
Geplusst.
Regelwerk fürs Nachsehen:
- Im/Mit whois und die DNS-Server nachsehen.
- Die Auflösung mit den im whois-datensatz angegebenen DNS überprüfen: man dig ...
Umstellen des DNS:
- Neue Bameserver und dessen Backup konfigurieren, mit dig nachsehen, ob das klappt.
- Ggf. auch neue IP erst mal in den alten DNS hinterlegen und Cache-Time abwarten, ggf auch kürzere TTL Minimum sind oft 300 Sekunden hinterlegen.
- Beim NIC umstellen
Nur Umstellen der IP eines Servers (z.B. bei Umzug auf neue Server)
- Beide Server müssen eine Weile (48 Stunden reichen meist völlig aus) parallel laufen, ein Sekunden-Übergang ist nicht möglich!
- Bei vielen Diensten (z.B. Webserver mit CMS oder einem Forum) sollten diese in der Übergangszeit die gleiche Datenbank , z.B. auf dem neuen Server benutzen (Auf dem alten Server z.B. Wordpress mit neuer IP konfiguriert, der "Nutzer" muss natürlich Zugriffsrechte haben und Datenbank muss auch an der Internet-IP listen [lauschen])
- Testen des neuen Servers mit lokalem DNS oder host-Einträgen
- Alles O.K.? Dann Umstellen der IP im DNS
- Warten bis keine "normalen" Zugriffe mehr erfolgen - mindestens bis zum Ablauf der TTL des alten DNS-Eintrages - Aber Achtung! Firefox cacht die IP selbst und ich weiss noch nicht, ob er sich an die TTL hält oder, wie früher mal beobachtet, den eigenen Cache und damit die alte IP für die Browsersitzung als gültig betrachtet.
- Falls der alte Server auch Mailserver war: Zwischenzeitlich eingegangene Mails brutal auf den neuen Server kopieren (Mailserver, die auf maildir beruhen - also keine Datenbank benutzen - können das nach meiner Erfahrung ab...
- Alten Server abschalten.
Jörg Reinholz
-
Tach,
- Im/Mit whois und die DNS-Server nachsehen.
das Whois würde ich mir sparen; es spielt keine Rolle.
- Die Auflösung mit den im whois-datensatz angegebenen DNS überprüfen: man dig ...
Besser ausschließlich mit dig oder nslookup überprüfen.
- Warten bis keine "normalen" Zugriffe mehr erfolgen - mindestens bis zum Ablauf der TTL des alten DNS-Eintrages - Aber Achtung! Firefox cacht die IP selbst und ich weiss noch nicht, ob er sich an die TTL hält oder, wie früher mal beobachtet, den eigenen Cache und damit die alte IP für die Browsersitzung als gültig betrachtet.
Zu beachten ist, die TTL gilt für jede Komponente neu, es ist also durchaus möglich, dass man ein mehrfaches des angegebenen Wertes warten muss (Cache beim Provider, Cache im lokalen Netzwerk, Cache im OS, ...)
- Falls der alte Server auch Mailserver war: Zwischenzeitlich eingegangene Mails brutal auf den neuen Server kopieren (Mailserver, die auf maildir beruhen - also keine Datenbank benutzen - können das nach meiner Erfahrung ab...
Besser: die Mails einfach an den neuen Host weiterleiten.
mfg
Woodfighter-
Moin!
Zu beachten ist, die TTL gilt für jede Komponente neu, es ist also durchaus möglich, dass man ein mehrfaches des angegebenen Wertes warten muss (Cache beim Provider, Cache im lokalen Netzwerk, Cache im OS, ...)
Äh. Normalerweise nicht:
Cache beim Provider, Cache im lokalen Netzwerk, Cache im OS,
Sind alle gegenüber den eigentlichen DNS-Servern Clients und senden ihrem jeweiligen Client auch die verbleibende TTL. Die ursprüngliche TTL ist in den Antworten auch nicht (bzw. allenfalls selten. nämlich nur wenn mit der Rest-TTL übereinstimmend) enthalten.
Teste das mal...
Jörg Reinholz
-
Tach,
Moin!
Zu beachten ist, die TTL gilt für jede Komponente neu, es ist also durchaus möglich, dass man ein mehrfaches des angegebenen Wertes warten muss (Cache beim Provider, Cache im lokalen Netzwerk, Cache im OS, ...)
Äh. Normalerweise nicht:
„es ist also durchaus möglich“
Cache beim Provider, Cache im lokalen Netzwerk, Cache im OS,
Sind alle gegenüber den eigentlichen DNS-Servern Clients und senden ihrem jeweiligen Client auch die verbleibende TTL. Die ursprüngliche TTL ist in den Antworten auch nicht (bzw. allenfalls selten. nämlich nur wenn mit der Rest-TTL übereinstimmend) enthalten.
jo, ist die halbe TTL beim Provider schon abgeluafen, habe ich hinterher vielleicht nur noch 1.5-mal statt 3-mal den ursprünglichen Wert, festzuhalten ist: Die TTL ist nicht die obere Grenze.
mfg
Woodfighter-
Moin!
jo, ist die halbe TTL beim Provider schon abgelaufen, habe ich hinterher vielleicht nur noch 1.5-mal statt 3-mal den ursprünglichen Wert, festzuhalten ist: Die TTL ist nicht die obere Grenze.
Nein. Die caches übermitteln immer die verbleibende Restzeit als TTL.
Also nehmen wir an, TTL sei 300 (5 Minuten):
- Cache fragt DNS und bekommt immer volle TTL (300).
- 1 Minute später wird der Cache (nochmals, von einem anderen Client) befragt und liefert - jetzt als Server - 240 als TTL an seinen Client.
- War der Client wieder ein Cache, dann wird er, eine weitere Minute später und als Server, als TTL 180 an seinen Client melden.
- Fragt jetzt 181 weitere Sekunden (oder 301 Sekunden nach dem allerersten Request) ein weiterer Client, dann wird der Cache feststellen, dass seine Information abgelaufen ist (181 Sekunden > TTL 180) und der wird seinen forwarder fragen. Der wird auch sehen, dass sein Cache abgelaufen ist (301 Sekunden > TTL 300) und den DNS fragen und also erneut die IP und die TTL von 300 erhalten.
Im Ganzen wird die TTL also niemals überschritten. Es sei denn natürlich, einer der Caches verhält sich nicht konform und übermittelt statt der Rest-TTL die ihm selbst gemeldete. Dann ist er aber "kaputt".
Jörg Reinholz
-
Moin!
Fall Du Dir das Prinzip mal ansehen willst. Ich hab hier eine DEMO für einen Key-Value-Server, einen Cache und einen Client:
- https://home.fastix.org/Tests/key_value.client.php?q=bar (ist client von 2)
- https://home.fastix.org/Tests/key_value.cache.php?q=bar (ist client von 1)
- https://home.fastix.org/Tests/key_value.db.php?q=bar (ist server)
Geht auch mit 'q=foo' - Der Server-Key muss akzeptiert werden.
Jörg Reinholz
-
Tach,
jo, ist die halbe TTL beim Provider schon abgelaufen, habe ich hinterher vielleicht nur noch 1.5-mal statt 3-mal den ursprünglichen Wert, festzuhalten ist: Die TTL ist nicht die obere Grenze.
Nein. Die caches übermitteln immer die verbleibende Restzeit als TTL.
jup, war mir bekannt und dann trotzdem ein Denkfehler bei mir. Korrekt funktionierende DNS-Server machen das so, wie du beschrieben hast.
mfg
Woodfighter
-
-
-
Moin!
- Im/Mit whois und die DNS-Server nachsehen.
das Whois würde ich mir sparen; es spielt keine Rolle.
Es spielt rein DNS-technisch keine Rolle, geht aber einher mit dem Eintrag, welche Nameserver denn für die Domain zuständig sind.
Folge:
ausschließlich mit dig oder nslookup überprüfen.
... ist sinnlos, so lange der Provider (über einen solchen werden das die meisten machen) die Änderung noch nicht übermittelt hat. Hat er das getan, dann taucht die Änderung auch sofort im whois-Datensatz für die Domain auf.
Jörg Reinholz
-
Tach,
- Im/Mit whois und die DNS-Server nachsehen.
das Whois würde ich mir sparen; es spielt keine Rolle.
Es spielt rein DNS-technisch keine Rolle, geht aber einher mit dem Eintrag, welche Nameserver denn für die Domain zuständig sind.
ja, es sind Meta-Informationen
ausschließlich mit dig oder nslookup überprüfen.
... ist sinnlos, so lange der Provider (über einen solchen werden das die meisten machen) die Änderung noch nicht übermittelt hat. Hat er das getan, dann taucht die Änderung auch sofort im whois-Datensatz für die Domain auf.
Und das hilft mir dann wie? Die Information, dass es sich bald im DNS ändern wird, hatte ich bereits vorher, das habe ich ja schon beauftragt.
mfg
Woodfighter-
Moin!
Und das hilft mir dann wie? Die Information, dass es sich bald im DNS ändern wird, hatte ich bereits vorher, das habe ich ja schon beauftragt.
Wie Du schon sagst: beauftragt. Das heisst nicht, dass es schon durchgeführt wurde. ggf. übermittelt der Provider diese Aufträge erst nach manueller Prüfung oder zeitgesteuert, z.B. in Abhängigkeit von einem Rhythmus in welchem er seine Server anweist, die Konfigurationsdateien neu einzulesen. Um nun festzustellen, welcher DNS-Server für eine Domain zuständig ist, ist die Abfrage des whois eine offensichtlich gut geeignete - und von Caches unabhängige - Möglichkeit.
Jörg Reinholz
-
Tach,
Um nun festzustellen, welcher DNS-Server für eine Domain zuständig ist, ist die Abfrage des whois eine offensichtlich gut geeignete - und von Caches unabhängige - Möglichkeit.
nein, dafür gibt es nur genau eine Möglichkeit, nämlich die tatsächlich zuständigen Nameserver der übergeordneten Domain zu befragen; wie wir in diesem Thread gesehen haben, stehen im Whois durchaus Daten, die nicht die Realität wiederspiegeln.
mfg
Woodfighter-
Moin!
nein, dafür gibt es nur genau eine Möglichkeit, nämlich die tatsächlich zuständigen Nameserver der übergeordneten Domain zu befragen;
Hehe. Bei Subdomains war ich noch gar nicht. Das dann das whois die Delegierung nicht enthalten kann, weil es nur die DNS-Server der second-level-domain ausweist ist aber klar. Mir ging es aber an dieser Stelle um die DNS-Einträge genau jener second-level-domain und nicht etwa einer subdomain.
Jörg Reinholz
-
Tach,
nein, dafür gibt es nur genau eine Möglichkeit, nämlich die tatsächlich zuständigen Nameserver der übergeordneten Domain zu befragen;
Hehe. Bei Subdomains war ich noch gar nicht. Das dann das whois die Delegierung nicht enthalten kann, weil es nur die DNS-Server der second-level-domain ausweist ist aber klar. Mir ging es aber an dieser Stelle um die DNS-Einträge genau jener second-level-domain und nicht etwa einer subdomain.
es ging in diesem Thread um eine Second-Level-Domain und es ist genau der Fall eingetreten, dass im whois, wo misterunknown nachgeschlagen hat, falsche Informationen standen (falsch in dem Sinne, dass sie nicht den Stand im DNS abgebildet haben); hätte er wie ich direkt im DNS nachgesehen, hätte er sofort gesehen, warum seine Namensauflösung noch nicht so funktioniert, wie er sich das vorstellte. Whois ist zum DNS genauso eine (möglicherweise fehlerbehaftete) Zweitquelle wie selfhtml zur HTML5-Spezifikation; da in diesem Falle, aber die Abfrage der Daten etwa gleich kompliziert ist, lohnt es sich nicht hierfür im Whois nachzuschlagen.
mfg
Woodfighter-
Moin!
es ging in diesem Thread um eine Second-Level-Domain und es ist genau der Fall eingetreten, dass im whois, wo misterunknown nachgeschlagen hat, falsche Informationen standen (falsch in dem Sinne, dass sie nicht den Stand im DNS abgebildet haben);
Woraus entnimmst Du das? Ich glaube nicht, dass es hier eine Diskrepanz zwischen den authorisierten Nameservern gab oder das misterunknown eine solche je fest gestellt hat:
ich bei meinem Provider die Domain dejungs.de auf meine Nameserver umgestellt, kann aber den Namen nicht mehr auflösen; in der Antwort steht immer nur "SERVFAIL". Hat jemand eine Idee, wo der Fehler liegen könnte? Der Eintrag bei der Denic scheint korrekt zu sein.
dejungs.de ist, wie Du schon schreibst, eine Second-Level-Domain. Also erscheinen die korrekten DNS-Server für diese Domain im whois.
hätte er wie ich direkt im DNS nachgesehen, hätte er sofort gesehen, warum seine Namensauflösung noch nicht so funktioniert, wie er sich das vorstellte.
Äh. Nein. Dazu hätte er von den cachenden DNS bei Providern, Firme, selbst in DSL-Routern wissen müssen.
Im übrigen hast Du auf
~> nslookup -type=soa www.example.org ~> dig www.example.org +tracenicht hingewiesen, auch nicht auf die Idee, einen der root-server zu befragen, sondern lediglich dig und nslookup erwähnt, was im Hinblick darauf, dass ohne diese "längst nicht jedem bekannten" Optionen der "authorative" Nameserver regelmäßig nicht benannt wird, deutlich weniger zielführend ist als das von mir genannte whois.
Exkurs: DNS-Abfrage zu Fuß über die root-server
Die gegenwärtig 13 root-server sind
- a.root-servers.net
- b.root-servers.net
- …
- m.root-servers.net
Die kann befragen,
~> dig example.org @l.root-servers.net … ;; AUTHORITY SECTION: org. 172800 IN NS a0.org.afilias-nst.info. org. 172800 IN NS a2.org.afilias-nst.info. org. 172800 IN NS b0.org.afilias-nst.org. org. 172800 IN NS b2.org.afilias-nst.org. org. 172800 IN NS c0.org.afilias-nst.info. org. 172800 IN NS d0.org.afilias-nst.org. …was zwar nicht zur IP-Adresse aber immerhin unter "AUTHORITY SECTION" zur Liste der für die Top-Level-Domain zuständigen Nameserver führt, die (einen von denen) man sodann auch gleich fragt:
~> dig example.org @a0.org.afilias-nst.info … ;; AUTHORITY SECTION: example.org. 86400 IN NS a.iana-servers.net. example.org. 86400 IN NS b.iana-servers.net. …um wiederum unter "AUTHORITY SECTION" die Liste der tatsächlich für die Second-Level-Domain zuständigen Nameserver zu erhalten. Geht es jetzt um eine Third-Level-Domain muss man den Vorgang halt wiederholen.
/Exkurs
Aber auch das muss man erst mal wissen und ein dünner Hinweis auf dig oder nslookup ist da nicht wirklich zielführend.
... lohnt es sich nicht hierfür im Whois nachzuschlagen.
Nun. Ja. Wenn man die oben genannten Optionen bzw. Optionsparameter nicht kennt oder die Mühe scheut, hat man mit whois die einzige mir bekannte Chance um festzustellen, dass es der neue Nameserver auch hinterlegt wurde. Aber irgendwie kommen wir hier in den Bereich der Meinung und darüber hinaus in einen, wo man Umstände berücksichtigen muss welche nicht bekannt sind. Und das beginnt hier beim Wissen des Fragestellers.
Fakt ist, man mit whois ganz einfach mal den authorisierten Nameservers sehen (und weiß dann ob der Dienstleister die Umstellung schon veranlasst hat oder nicht.) Danach kann man die Kette der Caches testen - was natürlich nur geht, soweit man vom Caching weiß und diese Caches überhaupt kennt (nicht jedes DSL-Modem gibt den verwendeten DNS preis) oder Zugriff hat (DNS in fremden Netzwerken).
Und das Problem war ja die Kette der Caches, bzw. deren bloße Existenz.
Noch ein Exkurs
Die TTL ist nur auf den zuständigen Nameservern, also an der Quelle des DNS-Eintrages konstant. Die Caches ziehen von der erhaltenen TTL immer das Alter der gecachten Information ab, so dass sich die effektive TTL nicht erhöht, wenn mehrere Caches beteiligt sind. Wenn man jetzt über das Cachen spricht, dann sollte aber auch gleich erwähnen, wo man die die TTL sieht:
a) dig
;; ANSWER SECTION: example.org. 5 IN A 93.184.216.34 ^ ^ ^ hostname TTL IP(v4)- Adressemit nslookup weiß ich nur diesen Weg um an die TTL zu kommen (Ich hab ja unter den von mir betreuten Linuxen regelmäßig dig zur Verfügung):
~$ nslookup > set debug > dejungs.de QUESTIONS: dejungs.de, type = A, class = IN ANSWERS: -> dejungs.de internet address = 46.4.101.180 ttl = 80851 # Da steht die des befragten Servers/Caches den man auch wechseln kann.Jörg Reinholz
-
Tach,
es ging in diesem Thread um eine Second-Level-Domain und es ist genau der Fall eingetreten, dass im whois, wo misterunknown nachgeschlagen hat, falsche Informationen standen (falsch in dem Sinne, dass sie nicht den Stand im DNS abgebildet haben);
Woraus entnimmst Du das? Ich glaube nicht, dass es hier eine Diskrepanz zwischen den authorisierten Nameservern gab oder das misterunknown eine solche je fest gestellt hat:
aus dem OP: „Der Eintrag bei der Denic scheint korrekt zu sein.“ Das war die Whois-Abfrage von der misterunknown, wie er in seiner Antwort erläutert. Eine knappe Stunde nach dem OP habe ich einen der für de zuständigen Nameserver befragt und das Ergebnis war ein anderes, als das im Whois.
Äh. Nein. Dazu hätte er von den cachenden DNS bei Providern, Firme, selbst in DSL-Routern wissen müssen.
Er hat zwei eigene DNS-Server aufgesetzt, ich gehe mal davon aus, dass er das weiß.
Im übrigen hast Du auf
~> nslookup -type=soa www.example.org ~> dig www.example.org +tracenicht hingewiesen,
Ich versuche hier auch nicht die Man-Pages der genutzten Tools abzubilden.
deutlich weniger zielführend ist als das von mir genannte whois.
Solange du bitte einsehen könntest, dass im Whois nicht immer aktuelle Informationen stehen und es deswegen besser ist direkt im DNS nachzusehen, gerade dann wenn man gerade Änderungen beauftragt hat. Natürlich kann ich über Whois sekundäre Informationen bekommen, aber die hätten hier in desem Falle niemandem geholfen (im Gegenteil haben sie misterunknown sogar verwirrt).
Danach kann man die Kette der Caches testen - was natürlich nur geht, soweit man vom Caching weiß und diese Caches überhaupt kennt (nicht jedes DSL-Modem gibt den verwendeten DNS preis) oder Zugriff hat (DNS in fremden Netzwerken).
Caching hatte mit dem ursprünglichen Problem übrigens nichts zu tun. Und ich habe bisher noch keinen DNS-Server getroffen, der mir nicht mitgeteilt hätte, wo er seine Informationen herbekommt.
Und das Problem war ja die Kette der Caches, bzw. deren bloße Existenz.
Wie schon gesagt: nein; das Problem war, dass misterunknown dachte, dass die Informationen im Whois der Realität im DNS entsprechen würde. Der cachende DNS-Server, den er befragt hatte, hatte die selbe Information wie der authorative Nameserver.
Exkurs:
Warum schreibst du deine längeren Anleitungen eigentlich ins Forum und nicht lieber ins Wiki, wo man sie bei zukünftigen Änderungen einfacher aktuell halten könnte?
mfg
Woodfighter-
Moin!
Du hattest das hier ermittelt:
; <<>> DiG 9.7.3 <<>> NS dejungs.de @f.nic.de. … ;; AUTHORITY SECTION: dejungs.de. 86400 IN NS dns1.ispone-business.de. dejungs.de. 86400 IN NS dns2.ispone-business.de. …Ich sehe da, dass auch die Information, welcher DNS zuständig sei, gecacht wird. Einen Tag lang. Wechselt man Nameserver und IP wirkt der längere Cache, es sei denn, man teilt dem alten Nameserver vorher noch die neue IP mit. Am besten setzt man vor einem IP-Wechsel die TTL auf einen vernünftigen Zeitraum z.B. auf 300 runter.
Solange du bitte einsehen könntest, dass im Whois nicht immer aktuelle Informationen stehen und es deswegen besser ist direkt im DNS nachzusehen,
Nana, definiere mal "aktuelle Information". Das whois zeigte die neueren Daten und, jedenfalls von f.nic.de gab's noch die alten.
Das zeigt auf, dass das hier …
Folge:
ausschließlich mit dig oder nslookup überprüfen.
... ist sinnlos, so lange der Provider (über einen solchen werden das die meisten machen) die Änderung noch nicht übermittelt hat. Hat er das getan, dann taucht die Änderung auch sofort im whois-Datensatz für die Domain auf.
… auch stimmt. Denn damit habe ich ja ganz klar gesagt: im whois taucht die Information sofort auf, nachdem der Provider die Information an die DENIC gegeben hat, vorher ist es sinnlos die Angaben mit dig oder nslookup zu überprüfen. Wenn im whois-record noch die alten Daten stehen, dann ist einfach nicht zu erwarten, dass die Daten im DNS geändert wurden.
Jörg Reinholz
-
Moin!
; <<>> DiG 9.7.3 <<>> NS dejungs.de @f.nic.de. … ;; AUTHORITY SECTION: dejungs.de. 86400 IN NS dns1.ispone-business.de. dejungs.de. 86400 IN NS dns2.ispone-business.de. …Ich sehe da, dass auch die Information, welcher DNS zuständig sei, gecacht wird. Einen Tag lang.
Aja. Kein echter Cache. Die DENIC sagt:
"Zurzeit wird die .de-Zone in regelmäßigen Abständen mit den neuesten Domaindaten erstellt und die Information dann auf alle Nameserver überspielt."
Dieser regelmäßige Abstand ist dann wohl ein Tag.
Jörg Reinholz
-
Tach,
Aja. Kein echter Cache. Die DENIC sagt:
natürlich nicht, ein authorative Nameserver für eine Domain kann keine Daten zu dieser Domain cachen, dann wäre er ja nicht mehr authorative.
"Zurzeit wird die .de-Zone in regelmäßigen Abständen mit den neuesten Domaindaten erstellt und die Information dann auf alle Nameserver überspielt."
Dieser regelmäßige Abstand ist dann wohl ein Tag.
Nein, meiner Erfahrung nach aktualisiert die Denic die Daten der DE-Nameserver mehrmals täglich.
mfg
Woodfighter
-
-
Tach,
Solange du bitte einsehen könntest, dass im Whois nicht immer aktuelle Informationen stehen und es deswegen besser ist direkt im DNS nachzusehen,
Nana, definiere mal "aktuelle Information". Das whois zeigte die neueren Daten und, jedenfalls von f.nic.de gab's noch die alten.
mit aktuellen Daten zum Thema Namensauflösung würde ich diejenigen Daten bezeichnen, die die authorative Nameserver haben; das Whois hatte Daten zur Domain, die nicht aktuell sondern zukünftig waren.
Das zeigt auf, dass das hier …
Folge:
ausschließlich mit dig oder nslookup überprüfen.
... ist sinnlos, so lange der Provider (über einen solchen werden das die meisten machen) die Änderung noch nicht übermittelt hat. Hat er das getan, dann taucht die Änderung auch sofort im whois-Datensatz für die Domain auf.
hätte misterunknown direkt im DNS gefragt, hätte er sich seine Verwunderung und diesen Thread gespart und hätte nicht seine korrekten Konfiguration hinterfragt.
… auch stimmt. Denn damit habe ich ja ganz klar gesagt: im whois taucht die Information sofort auf, nachdem der Provider die Information an die DENIC gegeben hat, vorher ist es sinnlos die Angaben mit dig oder nslookup zu überprüfen.
Die Daten im Whois sind für den Einsatz der Domain aber nicht hilfreich, weil sie für die Namensauflösung keinerlei Rolle spielen.
Wenn im whois-record noch die alten Daten stehen, dann ist einfach nicht zu erwarten, dass die Daten im DNS geändert wurden.
Bei der Denic stimmt das im allgemeinen, bei anderen Registries habe ich das schon anders erlebt.
mfg
Woodfighter
-
-
-
-
-
-
-