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! 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 noch die alten Daten stehen, dann ist einfach nicht zu erwarten, dass die Daten im DNS geändert wurden. Jörg Reinholz

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. Jörg Reinholz

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 oder setzt einen vernünftigen Zeitraum vorher die TTL 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, Naja, 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. Jörg Reinholz