Modifica del numero seriale DNS per essere nel passato

12

Ho alcuni server DNS per la nostra organizzazione che sono stati configurati dal mio predecessore. Non ha usato il formato standard per i numeri di serie, invece ha usato un formato dispari a partire dal 2033. Quello che voglio fare è sostituire i suoi server DNS con i miei, ma sono preoccupato di cambiare il numero seriale in un formato "corretto" usando AAAAMMGGXX perché sarà un numero inferiore.

Questi sono i nostri server DNS pubblici e voglio solo assicurarmi che non ci siano problemi a farlo. Qualcuno ha avuto esperienza in questo tipo di transizione?

domain-name-system bind

— Jordan Eunson
fonte

6

Heads-up: non esiste un formato standard per i numeri di serie DNS.

— John Gardeniers,

1

@John Quel formato seriale è raccomandato dalla sezione 2.2 di RFC1912. Vedi: faqs.org/rfcs/rfc1912.html

— Justin Scott

@Justin, non è altro che un suggerimento. Non è uno standard. Inoltre, un RFC non è comunque uno standard. È un precursore di una raccomandazione per uno standard. Niente di più.

— John Gardeniers,

@Giovanni non ho detto che fosse uno standard, ho detto che era "raccomandato". Tuttavia, quasi tutte le zone DNS che abbia mai visto usano quel formato, quindi si potrebbe dire che è uno standard di fatto.

— Justin Scott,

6

Se il suo numero che inizia con 2033 è maggiore dello standard AAAAMMGGXX , è possibile reimpostare il valore.

Ecco un articolo che descrive la procedura. Fondamentalmente devi sfruttare il fatto che il numero seriale è un numero intero a 32 bit e andrà a capo se usi valori più grandi.

— Zoredache
fonte

Questo è il motivo per cui il collegamento a una soluzione nello scambio di stack non fornisce realmente informazioni. Il collegamento è MORTO!

— labradort,

@labradort funziona ancora per me. È stato cambiato in un collegamento archive.org qualche tempo fa che è ancora valido. Ecco un altro paio di link unix.stackexchange.com/questions/36869/… microhowto.info/howto/… Non volevo davvero copiare e incollare tutte le pagine in una risposta. Inoltre, penso ancora che la menzione che è un numero intero a 32 bit sia probabilmente sufficiente per la maggior parte delle persone alle pagine correnti tramite Google.

— Zoredache,

"Timeout gateway 504 Il server non ha risposto in tempo." - dal link originale. Ecco alcune informazioni utili ... Bind 9.9 non eseguirà il trasferimento di zona tramite "notifica anche" a meno che il numero seriale non sia incrementato. Il numero di serie non può mai avanzare più di 2147483647 alla volta. L'equivalente di 99999999 sul contachilometri è 2 ^ 32 - 1 o 4294967295. Attendere che NS secondario ottenga il nuovo SOA prima di incrementare in modo da poterli spostare tutti in avanti al numero seriale di valore inferiore.

— labradort,

6

Non ho dovuto farlo da solo, ma ho aggiunto una soluzione ai segnalibri ( HOWTO Fix SOA RR serial number ) dall'autore del libro Pro DNS e BIND nel caso in cui commetta questo errore.

— Peter Murray
fonte

4

Puoi impostare i numeri di serie come preferisci. Per impostazione predefinita, i server secondari non eseguono il trasferimento di una zona a meno che il numero non sia più elevato, ma è possibile comandarli per forzare un trasferimento e ricaricare fino a quando si ha accesso diretto ad essi. Basta impostare il numero seriale su quello che ti piace, quindi inviare i comandi di trasferimento ai server secondari in modo che possano recuperare le nuove informazioni nonostante il numero seriale inferiore.

— Justin Scott
fonte

3

E se ciò non funziona (almeno in quel caso di BIND) è sufficiente eliminare i file di zona dal secondario e farlo ricaricare, il che gli farà recuperare le nuove copie.

— John Gardeniers,

0

Come detto, il campo SERIAL in un record di risorse SOA non ha il cosiddetto "formato standard". Non è nemmeno utilizzato da tutti i software per server DNS. (Al giorno d'oggi, una buona parte del mondo non usa nemmeno la replica del database di trasferimento di zona.) Con il BIND di ISC, è solo un numero senza significato intrinseco al suo valore specifico, utilizzato per verificare durante la replica del database di trasferimento di zona se le repliche sono fuori data, e si può scegliere qualsiasi schema si desideri per impostarlo, con la condizione, come anche affermato, che "più recente" deve significare "un numero più grande, modulo 32 bit".

Hai già incontrato la trappola qui. Qualunque schema si scelga, qualcuno è tenuto a seguire e (in mancanza di informazioni) non capirlo, o non vuole cambiarlo, proprio come non hai capito e vuoi cambiare lo schema della persona che ti è venuta prima. Questa è la trappola di non documentare le scelte di amministrazione del proprio sistema . Quindi documenta la tua scelta.

— JdeBP
fonte

Ovviamente c'è anche la possibilità che il predecessore semplicemente non abbia pensato alla scelta prima di farlo. Trovo che quello sia il caso più comunemente di "c'è un motivo e non è stato documentato".

— Chris S