Propagacja DNS - trwająca prawie tydzień

[draker 0]

Witam,

 

Mam pewien problem. Ostatnio zmieniałem serwer dedykowany, tak więc konieczna była zmiana DNS'ów dla moich domen .pl. Często musiałem to robić, więc już mam trochę "doświadczenia". Tyle, że teraz pierwszy raz mam taki problem: po 5 albo 6 dniach od zmiany DNS'ów w panelu OVH i biznes-host dla domen nadal większość użytkowników ląduje na starych DNS'ach. Czy to normalne? Zazwyczaj już po kilku godzinach wszystko było zmienione, a teraz czekam już kilka dni na to. Co najdziwniejsze, raz przekierowuje mnie na dobre DNS'y, a za kilka godzin przy próbie wejścia kierowany jestem na stare dns'y i stary serwer. Tak samo użytkownicy mojej strony - obecnie ok. 10% osób korzysta z nowego serwera i nowych DNS'ów, a resztę przekierowuje na stare DNS'y. Szczerze mówiąc, nie mam pojęcia, co mogę zrobić. Konfiguracja binda jest raczej ok, TTL jest ustawiony na 24h. Czy pozostaje mi tylko czekać? Jak tak, to jak długo jeszcze?

 

Adresy domen to modbase.pl i taniograj.pl.

[Miłosz 2311]

To może jeszcze określ co jest Twoim nowym serwerem a co starym. Może jakieś IP?

[draker 0]

Stary:

46.163.76.120 lub 176.31.108.171 (najpierw przeniosłem z 46.163 na 176.31, a teraz przeniesione wszystko na 91)

 

Nowy:

91.121.114.25

 

Tu i tu jest praktycznie to samo: Litespeed jako serwer www + mysql + php5, a jako serwer dns - bind9. Konfiguracja tu i tu binda byla taka sama.

 

Narazie zmieniłem DNS'y modbase.pl na najstarszy serwer (46.163.76.120) mając nadzieję, ze się cos poprafi, prosiłbym o sprawdzanie w razie czego tej drugiej domeny.

Nawet teraz na swoim komputerze po tych 4 czy tam 5 dniach podczas pingowania taniograj.pl nadal korzystam ze starych dns'ów:

 

MacBook-Pro-Krzysztof:~ drake$ ping taniograj.pl
PING taniograj.pl (176.31.108.171): 56 data bytes
64 bytes from 176.31.108.171: icmp_seq=0 ttl=57 time=60.546 ms

 

90% uzytkowników moich witryn według statystyk ma tak samo.

[Miłosz 2311]

Na kimsufie masz jakieś stare SOA. Zaktualizuj serial..

 

;; ANSWER SECTION:
modbase.pl.        86400    IN    SOA    ks200894.kimsufi.com. root.modbase.pl. 2004022300 1200 1200 2419200 86400

 

Poza tym ns.kimsufi.com ma jakieś inne ip dla domeny:

 

;; ANSWER SECTION:
modbase.pl.        86400    IN    A    176.31.108.171

 

Chyba masz jakiś bałagan w tych strefach dns.. Poza tym wydeleguj domene na

ks392018.kimsufi.com i ns.kimsufi.com. A nie skacz między dnsami, bo to i tak NIC nie da, a robi jeszcze większy bałagan

[Piotr GRD 608]

taniograj.pl

Według whois kieruje na ks200894.kimsufi.com i ns.kimsufi.com (ostatnia zmiana 30 grudnia)

ks200894.kimsufi.com kieruje domenę na 91.121.114.25

ns.kimsufi.com kieruje domenę na 176.31.108.171

Problem? Różne rekordy na obydwu używanych serwerach nazw.

SOA na ns.kimsufi.com sugeruje użycie ks392018.kimsufi.com jako primary, i może tu tkwi błąd?

 

modbase.pl

Według whois kieruje na ns2.hans.hosteurope.de i lvps46-163-76-120.dedicated.hosteurope.de (ostatnia zmiana dziś o 16:08).

lvps46-163-76-120.dedicated.hosteurope.de kieruje domenę na 46.163.76.120

ns2.hans.hosteurope.de nic o domenie nie wie

Jednakże widnieją w sieci jeszcze wpisy wcześniejsze kierujące domenę na ks200894.kimsufi.com i ns.kimsufi.com

ks200894.kimsufi.com kieruje domenę na 91.121.114.25

ns.kimsufi.com kieruje domenę na 176.31.108.171

Problem?

Jesli to ma być na hosteurope.de, to zadbaj by ns2.hans miał informację o domenie.

Jeśli problem był z kimsufi, to identycznie jak dla taniograj.

Edytowano Styczeń 3, 2012 przez Piotr GRD (zobacz historię edycji)

[draker 0]

Miłosz:

Serial zaktualizowany, ale nie wiem, czy to w czymś pomoże

To jest dosyć dziwne, bo konfiguracja jest raczej dobra, nie zmieniałem nic od kilku dni (tzn. dzisiaj, by ustawić serial)

 

Piotr GRD:

No i właśnie tutaj jest problem. Oczywiście ns.kimsufi.com to dns secondary, jest OK, ale zbytnio to nie gra roli, bo ks392018 to nazwa mojego starego serwera (ip 176.31.108.171), obecnie być powinno ks200894.kimsufi.com

 

Problem polega właśnie na tym, że od kilku dni raz kieruje na dns primary ks392018.kimsufi.com, mimo, że od dawna zmieniony jest na ks200894.kimsufi.com. Co najdziwniejsze, raz kierowany jestem na odpowiedni DNS, a dosłownie po 5 minutach już na stary.

[Piotr GRD 608]

No to sprawa prosta - ns.kimsufi.com ma wciąż stare wpisy.

Postaraj się, by zaktualizowane zostały na nim na nowe.

 

 

Edycja:

Dla modbase.pl sprawa załatwiona.

Popraw serial SOA dla taniograj.pl.

 

Wygląda na to, że ns.kimsufi.com sprawdza serial SOA. Jeśli pozostaje bez zmian - nie aktualizuje wpisów.

Przy każdej zmianie zmień SOA, by ns.kimsufi.com się zaktualizował.

Edytowano Styczeń 3, 2012 przez Piotr GRD (zobacz historię edycji)

[Miłosz 2311]

W dns secondary w managerze ovh usuń domenę i dodaj ją jeszcze raz, ale tym razem wybierz ip nowego serwera przy dodawaniu. Upewnij się, że nowy serwer dns ma możliwość transferu strefy do ns.kimsufi.com.

 

Delegację DNS już zmieniłeś? W whois widzę, że jeszcze nie.

[draker 0]

Tylko czy DNS secondary "ma coś do gadania" w takiej sytuacji? Według panelu OVH DNS secondary jest ustawiony dobrze, wyślę jeszcze im maila z zapytaniem, czy wszystko jest poprawnie ustawione.

 

@edit

 

przed chwilą zmienione. W panelu OVH jest tak, wydaje mi się, że wszystko jest dobrze

 

Edytowano Styczeń 3, 2012 przez draker (zobacz historię edycji)

[Miłosz 2311]

Widzę, że teraz ns.kimsufi.com ma dobre IP:

 

;; ANSWER SECTION:
modbase.pl.        86400    IN    A    91.121.114.25

[Piotr GRD 608]

Powtórzę, bo chyba nie przeczytano mojej edycji.

 

Dla modbase.pl sprawa załatwiona.

Popraw serial SOA dla taniograj.pl.

 

Wygląda na to, że ns.kimsufi.com sprawdza serial SOA. Jeśli pozostaje bez zmian - nie aktualizuje wpisów.

Przy każdej zmianie zmień SOA, by ns.kimsufi.com się zaktualizował.

[draker 0]

Zmieniony serial dla drugiej domeny, bind zresetowany. Mam nadzieję, że teraz wszystko powinno działać.

[Miłosz 2311]

Na OpenDNS jest już ok. Teraz kwestia propagacji domen..

[draker 0]

Hm, o dziwo nadal jeszcze po trzech, albo czterech dniach DNS'y się nie rozpropagowały. Teraz już z 70% userów korzysta z nowego serwera, ale nadal z 10GB dziennie transferu pożera stary serwer, na który już DNSy nie są kierowane. Według intodns jest okej. Czy to oby normalne, że to aż tyle trwa? U mnie jest to samo - wczoraj przez prawie cały dzień kierowany byłem na nowy serwer, a dzisiaj wchodząc na stronę kieruje mnie na stary serwer.

[Miłosz 2311]

Na starym serwerze wyłaczyłeś DNS? Być może niektóre serwery maja w cache stary adres i odpytują jeszcze starą maszynę i dostają odpowiedź.

[draker 0]

A czy przypadkiem jak wyłącze starego binda na tamtym serwerze, to osoby, które mają właśnie w cache stary adres nie będą otrzymywać komunikatu błędu? Sam nie wiem właśnie, czy powinienem to zrobić.

[Piotr GRD 608]

Moim zdaniem:

 

opcja A) - na starym serwerze zaktualizować można było wszystkie rekordy, by domena kierowana była na nowy adres IP;

opcja B ) sugerowana przez Miłosza - wyłączyć stary serwer DNS, wtedy przy niedostępności (starego) "ns1" zapytanie pójdzie do "ns2" (ns.kimsufi.com), który już ma poprawne dane.

 

 

Poza tym tak na przyszłość to odpowiednio wcześniej przed taką zmianą adresacji pozmniejszaj sobie wszelkie możliwe TTL'e do rozsądnego minimum, by przyspieszyć choć trochę takie procesy. Zmiana zrobiona w sposób właściwy z odpowiednimi wcześniejszymi przygotowaniami do tego może być dokonana w ciągu minut.

Edytowano Styczeń 7, 2012 przez Piotr GRD (zobacz historię edycji)

[Misiek08 285]

Jak miałyby takie przygotowania wyglądać?

[Piotr GRD 608]

Jak miałyby takie przygotowania wyglądać?

 

Jak dla mnie...

 

- Przed planowaną zmianą wybieram dla domeny takie serwery nazw, które będą działać i nad którymi będę miał kontrolę przez cały czas trwania migracji pomiędzy serwerami (przed, w trakcie, po zmianach). Mogą być one z zewnętrznego serwisu lub w ramach posiadanych przez siebie zasobów. Wprowadzam na nich wszystkie dotychczas istniejące rekordy i - jeśli są to inne serwery nazw niż dotychczas używane - ustawiam je jako autorytatywne dla domeny co najmniej 2 dni przed zaplanowaną migracją (ale nic nie szkodzi by dać większy margines, by nigdzie jakiś zapomniany cache nie pozostał).

 

- Zmniejszam TTL dla wszystkich rekordów do najmniejszej rozsądnej wartości (1 sekunda jest nierozsądna, ale np. 300 sekund wydaje się być OK). Musi to być zrobione odpowiednio wcześniej - jeśli np. dotychczasowe TTL'e miały wartość 86400 to co najmniej 24 godziny przed migracją (ale nic nie szkodzi by dać większy margines, by nigdzie jakiś zapomniany cache nie pozostał).

 

- W momencie migracji zmieniam wszystkie potrzebne rekordy A, CNAME i co tam jeszcze konieczne na używanych w obecnej chwili serwerach nazw. NIE zmieniam samych serwerów nazw przypisanych do domeny, ani też adresów tychże serwerów nazw. Migracja zajmuje więc tylko te 5 minut, jeśli TTL'e były ustawione na 300.

 

- Jeśli wszystko działa, mogę wydłużyć TTL'e. Jeśli to konieczne mogę zmienić serwery nazw uzywane dla domeny.

 

 

 

Kluczowym dla mnie jest:

 

- jeśli muszę zmienić serwery nazw to upewniam się, by wszystkie rekordy na starych i nowych były identyczne i aby wszystkie (i stare i nowe) działały poprawnie przez 2-3 dni od momentu zmiany (nie wyłączam starych dopóki zmiany nie rozejdą się wszędzie), w ten sposób zmiana jest kompletnie transparentna i nie powoduje żadnych komplikacji;

 

- jeśli zmianiam lokalizację /adres IP domeny, to robię to tylko poprzez zmianę rekordów A/CNAME, a nie poprzez zmianę serwerów nazw, w ten sposób zmiana trwa tylko czas ustawiony w TTL dla tych rekordów, który może być bardzo krótki (nad czasem propagacji zmian serwerów nazw nie mam kontroli, może to zająć nawet 24 godziny albo i dłużej dla niektórych zakątków internetu w "niesprzyjających warunkach").

 

 

Jednakże w każdym konkretnym przypadku może to wyglądać trochę inaczej. Przykładowo w przypadku drakera można to uprościć. Co najmniej 24 godziny przed migracją zmniejszyłbym TTL dla rekordów A na np. 300 (5 minut). A w momencie migracji natomiast poza zmianą serwerów nazw u rejestratora domeny zaktualizowałbym rekordy A na nowe IP na obydwu - i starym i nowym - BIND'ach, w ten sposób klienci obojętnie na który serwer nazw by trafili w momencie propagacji zmian DNS, kierowani byliby na to samo nowe IP. (Pomijam kwestię kłopotów z "secondary", to osobny nieprzewidziany przez niego niuans, wystarczyło zmieniać serial SOA - co zazwyczaj większość osób robi - by ns.kimsufi.com się prawidłowo zaktualizował.)

Edytowano Styczeń 11, 2012 przez Piotr GRD (zobacz historię edycji)