Nameserver hat falsche ip bei "dig ns.domain.tld"

[BlackEye]

Hallo.

Ich hatte gestern ein Update über providerdomain eines meiner DNS-Server durchgeführt. Wir haben die Domain cps-network.com und cps-network.de
Da ich gerade zwei root-Server habe und von dem einen auf den anderen umziehen will, wollte ich die Domein cps-network.com dazu benutzen, um auf den zweiten langsam zu migrieren.
root-server1: 217.160.131.124
root-server2: 217.160.166.14

Gestern hab ich also über providerdomain die domain cps-network.com mit einem eigenen nameserver ausgestattet und dort gesagt, dass es der ns.cps-network.com sei. Außerdem (wegen GLUE) die ip Adresse eingetragen (217.160.166.14).
Schon seit heute morgen ist eigentlich (angeblich) alles über die Bühne geganen. Doch wenn ich auf einem meiner Rechner ein

mfe@murpy ~ $ dig cps-network.com

; <<>> DiG 9.2.3 <<>> cps-network.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12834
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;cps-network.com. IN A

;; ANSWER SECTION:
cps-network.com. 43200 IN A 217.160.131.124

;; AUTHORITY SECTION:
cps-network.com. 604800 IN NS ns.schlund.de.
cps-network.com. 604800 IN NS ns.cps-network.com.

;; ADDITIONAL SECTION:
ns.schlund.de. 72482 IN A 195.20.224.97
ns.cps-network.com. 158876 IN A 217.160.131.124

ist der ns.cps-network.com noch immer auf der falschen IP. Doch wenn ich meinen root-server direkt anspreche, kommt das richtige erwartete Ergebnis:

mfe@murpy ~ $ dig cps-network.com @217.160.166.14

; <<>> DiG 9.2.3 <<>> cps-network.com @217.160.166.14
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39525
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;; QUESTION SECTION:
;cps-network.com. IN A

;; ANSWER SECTION:
cps-network.com. 43200 IN A 217.160.131.124

;; AUTHORITY SECTION:
cps-network.com. 43200 IN NS ns.cps-network.com.
cps-network.com. 43200 IN NS ns.schlund.de.

;; ADDITIONAL SECTION:
ns.cps-network.com. 43200 IN A 217.160.166.14

ich weiss jetzt nicht mehr, was hier noch richtig ist. Der ns.schlund.de (der secondary für meine Domains) hat ebenfalls die richtigen Daten. Doch wenn ich über internic mal eine ns-Abfrage mache, kommt selbst von dort noch die falsche ip (http://reports.internic.net/cgi/whois?w ... nameserver)

Mein zone-file auf dem 217.160.166.14 schaut so aus:

Code: Select all

root2 pri # cat cps-network.zone
$TTL 1W
@               IN SOA          ns.cps-network.com.     root.cps-network.com. (
                                    2004091003 ; serial
                                    3H  ; refresh
                                    30M ; retry
                                    1W  ; expiry
                                    12h ; ...
)


                43200   IN NS           ns.cps-network.com.
                43200   IN NS           ns.schlund.de.

                43200   IN MX 10        mx.cps-network.com.

                43200   IN A            217.160.131.124
ns              43200   IN A            217.160.166.14
mx              43200   IN A            217.160.131.124
root1           43200   IN A            217.160.131.124
root2           43200   IN A            217.160.166.14
p15140194       43200   IN CNAME        root2
p15105017       43200   IN CNAME        root1
*               43200   IN A            217.160.131.124

das kann doch jetzt nicht verkehrt sein... Muss ich nun noch weiter warten? Oder sollte ich das bei providerdomain nochmal ausfüllen?
Wenn dieser ns.cps-network.com nicht bald mal die korrekte IP überall hat, kann ich mit den anderen Kundendomains nicht umziehen. Denn die ganzen Domains sollten ns.cps-network.com als DNS bekommen, damit ich auf diesem nur noch die IP umstellen muss, wenn ich die Daten vom alten Server auf den neuen übernommen hab. Aber wenn ich nun einfach mal ein ns.cps-network.com für eine Domain angebe, dann schlägt das update fehl, weil der ns.cps-network.com die falsche IP hat.

Wäre über eine Antwort froh!
Danke und Gruß,
Martin

[wgot]

Hallo,

Schon seit heute morgen ist eigentlich (angeblich) alles über die Bühne geganen

nein, nicht alles, nur die Einträge beim zuständigen NIC. Die zuständigen Root(name)server werden die neue Information wohl erst morgen haben.

$TTL 1W

Das stand im alten Zonefile wohl auch drin. Nameserver dürfen die Informationen also bis zu einer Woche cachen, d.h. es kann bis zu einer Woche dauern bis sich die Ã?nderung überall rumgesprochen hat.

Vermutlich ist es aber schon morgen möglich den Nameserver für weitere Domains einzutragen.

Gruß, Wolfgang

PS: nächstes Mal 8 Tage vor dem Serverumzug die TTL auf eine Stunde runtersetzen.

[BlackEye]

ah, ok. Danke für die Antwort!
Aber im Bezug auf die TTL dachte ich, dass der SOA-Eintrag da auschlaggebend sei? Der letzte Zahlenwert dort ist doch ebenfalls ein TTL-Value (minimum).
Sollten sich die beiden Werte decken oder hat das Eine nichts mit dem Anderen zu tun?

Gruß, Martin

[wgot]

Hallo,

der Minimum im SOA gibt an, wie lange vom Nameserver zurückgegebene Fehlermeldungen gecached werden sollen.
ftp://ftp.nordu.net/rfc/rfc2308.txt, insbesondere Punkt 3 und 4.

Minimum sollte zwischen 12h und 4d liegen, TTL sollte (außer bei anstehendem Domainumzug oder DynDNS-Tricks) 7d sein.

Gruß, Wolfgang

[BlackEye]

Alles klar. Danke für die Erklärungen!

Gruß