Zmiana numeru seryjnego DNS na dawny

12

Mam kilka serwerów DNS dla naszej organizacji, które zostały skonfigurowane przez mojego poprzednika. Nie używał standardowego formatu dla numerów seryjnych, zamiast tego używał nieparzystego formatu od 2033 roku. Chcę zastąpić jego serwery DNS własnym, ale martwię się o zmianę numeru seryjnego na „właściwy” format za pomocą RRRRMMDDXX, ponieważ będzie to niższa liczba.

To są nasze publiczne serwery DNS i chcę się upewnić, że nie będzie żadnych problemów. Czy ktoś miał doświadczenie w tego rodzaju przejściu?

domain-name-system bind

— Jordan Eunson
źródło

6

Heads-up: Nie ma standardowego formatu numerów seryjnych DNS.

— John Gardeniers,

1

@John Ten format seryjny jest zalecany przez RFC1912 sekcja 2.2. Zobacz: faqs.org/rfcs/rfc1912.html

— Justin Scott

@Justin, to nic innego jak sugestia. To nie jest standard. Poza tym RFC i tak nie jest standardem. Jest to prekursor zalecenia dla normy. Nic więcej.

— John Gardeniers,

@John Nie powiedziałem, że to standard, powiedziałem, że jest „polecany”. Jednak prawie każda strefa DNS, jaką widziałem, używa tego formatu, więc można powiedzieć, że jest to de facto standard.

— Justin Scott,

6

Jeśli jego liczba zaczynająca się od 2033 jest większa niż standard RRRRMMDDXX , możesz zresetować wartość.

Oto artykuł opisujący procedurę. Zasadniczo musisz wykorzystać fakt, że numer seryjny jest 32-bitową liczbą całkowitą i zostanie zawinięty, jeśli użyjesz większych wartości.

— Zoredache
źródło

Dlatego linkowanie do rozwiązania w wymianie stosu tak naprawdę nie dostarcza informacji. Link jest martwy!

— labradort,

@labradort nadal działa dla mnie. Zmieniono na link archive.org jakiś czas temu, który jest nadal aktualny. Oto kilka innych linków unix.stackexchange.com/questions/36869/... microhowto.info/howto/… Tak naprawdę nie chciałem kopiować i wklejać całych stron do odpowiedzi. Ponadto nadal uważam, że wzmianka o 32-bitowej liczbie całkowitej jest prawdopodobnie wystarczająca dla większości osób, aby przeglądać strony za pośrednictwem Google.

— Zoredache,

„Limit czasu bramy 504 Serwer nie odpowiedział na czas”. - z oryginalnego linku. Oto kilka użytecznych informacji ... Powiązanie 9.9 nie wykona transferu strefy poprzez „również-powiadom”, chyba że numer seryjny zostanie zwiększony. Numer seryjny nigdy nie może przekroczyć więcej niż 2147483647 na raz. Odpowiednikiem 99999999 na liczniku przebiegu jest 2 ^ 32 - 1 lub 4294967295. Poczekaj, aż dodatkowy NS otrzyma nowy SOA przed zwiększeniem, aby można było je wszystkie przenieść do przodu do numeru seryjnego o niższej wartości.

— labradort

6

Nie musiałem tego robić sam, ale dodałem do zakładek rozwiązanie ( numery seryjne HOWTO Fix SOA RR ) od autora książki Pro DNS i BIND na wypadek, gdyby sam popełniłem ten błąd.

— Peter Murray
źródło

4

Możesz ustawić numery seryjne na dowolne. Domyślnie serwery pomocnicze nie będą pobierać transferu strefy, chyba że liczba będzie wyższa, ale możesz nakazać im wymuszenie transferu i ponowne załadowanie, o ile masz do nich bezpośredni dostęp. Wystarczy ustawić numer seryjny, co chcesz, a następnie wydać polecenia ponownego transferu na serwery pomocnicze, aby pobierały nowe informacje pomimo niższego numeru seryjnego.

— Justin Scott
źródło

3

A jeśli to nie zadziała (przynajmniej w tym przypadku BIND), po prostu usuń plik (i) strefy z pomocniczego i poproś o ponowne załadowanie, co spowoduje pobranie nowych kopii.

— John Gardeniers,

0

Jak powiedziano, pole SERIAL w rekordzie zasobu SOA nie ma tak zwanego „standardowego formatu”. Nie jest nawet używany przez wszystkie oprogramowanie serwerów DNS. (W dzisiejszych czasach spora część świata nawet nie korzysta z replikacji bazy danych transferu strefy.) Dzięki BIND ISC jest to tylko liczba bez wewnętrznego znaczenia dla jego konkretnej wartości, używana do sprawdzania podczas replikacji bazy danych transferu strefy, czy repliki są poza data i można wybrać dowolny schemat, który mu się podoba, z zastrzeżeniem, jak stwierdzono również, że „nowszy” musi oznaczać „większą liczbę, modulo 32 bity”.

Spotkałeś już tutaj pułapkę. Niezależnie od wybranego schematu, ktoś musi przyjść i (nie posiadając informacji) go nie rozumie lub chce go zmienić, tak jak nie zrozumiałeś i chcesz zmienić schemat osoby, która przyszła przed tobą. Jest to pułapką nieudokumentowania własnych wyborów dotyczących administrowania systemem . Więc udokumentuj swój wybór.

— JdeBP
źródło

Oczywiście istnieje również możliwość, że poprzednik po prostu nie przemyślał wyboru przed jego dokonaniem. Uważam, że tak jest częściej niż „istnieje powód i po prostu nie zostało to udokumentowane”.

— Chris S