Зміна серійного номера DNS, який вже був у минулому

12

У мене є деякі сервери DNS для нашої організації, які був налаштований моїм попередником. Він не використовував стандартний формат для серійних номерів, натомість використовував непарний формат, починаючи з 2033 року. Що я хочу зробити, це замінити його DNS-сервери на свій, але я переживаю за зміну серійного номера на "належний" формат, використовуючи YYYYMMDDXX, оскільки це буде менша кількість.

Це наші загальнодоступні сервери DNS, і я просто хочу переконатися, що проблем у цьому не буде. Хтось мав досвід у подібному переході?

domain-name-system bind

— Джордан Еунсон
джерело

6

Heads-up: Не існує стандартного формату серійних номерів DNS.

— Джон Гарденєр

1

@John Цей серійний формат рекомендується у розділі 2.2 RFC1912. Дивіться: faqs.org/rfcs/rfc1912.html

— Джастін Скотт

@ Джустін, це не більше, ніж пропозиція. Це не стандарт. Крім того, RFC все одно не є стандартом. Це попередник рекомендації для стандарту. Нічого більше.

— Джон Гарденєр

@John Я не сказав, що це стандарт, я сказав, що це "рекомендується". Однак майже кожна зона DNS, яку я коли-небудь бачив, використовує цей формат, тому можна сказати, що це фактично стандарт.

— Джастін Скотт

6

Якщо його число починаючи з 2033 року більше, ніж стандарт YYYYMMDDXX, тоді ви можете скинути значення.

Ось стаття, яка описує процедуру. В основному, ви повинні використовувати той факт, що серійний номер є 32-бітним цілим числом, і він буде завершеним, якщо використовувати більші значення.

— Зоредаче
джерело

Ось чому посилання на рішення в обміні стеками насправді не забезпечує інформацію. Посилання СУМНА!

— лабрадорт

@labradort все ще працює для мене. Він був змінений на посилання archive.org деякий час тому, що все ще діє. Ось ще кілька посилань unix.stackexchange.com/questions/36869/… microhowto.info/howto/… Я не дуже хотів копіювати та вставляти цілі сторінки у відповідь. Крім того, я все ще думаю, що згадка про те, що це 32-бітове ціле число, ймовірно, достатньо для більшості людей на поточні сторінки через Google.

— Зоредаче

"504 тайм-аут шлюзу. Сервер не вчасно відповів." - із вихідного посилання. Ось корисна інформація ... Прив’язка 9.9 не здійснюватиме передачу зон через "також-повідомляти", якщо не буде збільшено серійний номер. Серійний номер ніколи не може просувати більше ніж 2147483647 одночасно. Еквівалент 99999999 на одометрі дорівнює 2 ^ 32 - 1, або 4294967295. Зачекайте, поки вторинний НС отримає нову SOA перед збільшенням, щоб ви могли отримати їх, щоб вони перекинулися вперед до нижнього значення серійного номера.

— лабрадорт

6

Мені не довелося цього робити самостійно, але я заклав закладки рішення ( HOWTO Fix SOA RR серійні номери ) від автора книг Pro DNS та BIND, якщо я сам помиляюся.

— Пітер Мюррей
джерело

4

Ви можете встановити серійні номери на все, що завгодно. За замовчуванням вторинні сервери не перетягуватимуть зонну передачу, якщо кількість не перевищує, але ви можете наказати їм примусити передачу та перезавантажити, доки у вас є прямий доступ до них. Просто встановіть серійний номер на те, що вам подобається, а потім видайте команди повторної передачі вторинним серверам, щоб вони отримали нову інформацію, незважаючи на нижчий серійний номер.

— Джастін Скотт
джерело

3

І якщо це не працює (принаймні, у такому випадку BIND), просто видаліть зонний файл (-ів) з вторинного і змусіть його перезавантажити, що призведе до отримання нових копій.

— Джон Гарденєр

0

Як було сказано, поле SERIAL в записі ресурсів SOA не має так званого "стандартного формату". Він навіть не використовується всіма програмними програмами сервера DNS. (На сьогоднішній день значна частина світу навіть не використовує реплікацію бази даних передачі зон.) BIND ISC - це лише число, яке не має властивого йому значення, яке використовується для перевірки під час реплікації бази даних передачі в зоні, чи немає реплік дата, і ви можете вибрати будь-яку схему, яка вам подобається для її встановлення, за умови, що також зазначалося, що "новіший" повинен означати "більшу кількість, модуль 32 біт".

Тут ви вже стикалися з підводним каменем. Яку б схему ви не вибрали, хтось зобов'язаний зійти і (не маючи інформації) не зрозуміти її або захоче змінити її так само, як ви цього не зрозуміли і хочете змінити схему того, хто прийшов до вас. У цьому полягає проблема недокументування виборів адміністрації системи . Тому документуйте свій вибір.

— JdeBP
джерело

Звичайно, існує ймовірність, що попередник просто не продумав вибір перед тим, як зробити його. Я вважаю, що таке трапляється частіше, ніж "є причина, і це просто не було задокументовано".

— Кріс Ш