Скільки часу потрібно для розповсюдження записів DNS?

Це канонічне запитання про розповсюдження DNS

Скільки часу потрібно для розповсюдження різних типів записів?
Деякі розмножуються швидше, ніж інші?
Чому потрібен час для розповсюдження записів DNS і як це працює?

"Поширення DNS" саме по собі не є справжнім явищем. Скоріше, це явний ефект функцій кешування, зазначених у протоколі DNS. Скажімо, що зміни "поширюються" між DNS-серверами - це зручна помилка, яку, мабуть, простіше пояснити нетехнічним користувачам, ніж опис усіх деталей протоколу DNS. Однак насправді це не так, як працює протокол.

Рекурсивні сервери DNS роблять запити від імені клієнтів. Рекурсивні сервери DNS, як правило, керуються провайдерами або ІТ-відділами, використовуються клієнтськими комп'ютерами для вирішення імен Інтернет-ресурсів. Рекурсивні сервери DNS кешують результати запитів, які вони роблять для підвищення ефективності. На запити вже кешованої інформації можна відповісти без додаткових запитів. Тривалість кешування результату в секундах повинна базуватися на налаштовуваному значенні під назвою "Час жити" (TTL). Це значення визначається авторитетним сервером DNS для запиту запиту.

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

Доброю практикою є визначення значення TTL, достатньо короткого для розміщення необхідних щоденних змін у записах DNS, але досить довго, щоб створити "виграш" у кешуванні (тобто не такий короткий, щоб занадто швидко застаріти кеш, щоб забезпечити будь-яке підвищення ефективності). Використання збалансованої стратегії зі значеннями TTL призводить до «виграшу» для всіх. Це зменшує як завантаження, так і використання пропускної здатності для авторитетних DNS-серверів для даного домену, кореневих серверів та серверів TLD. Це зменшує використання пропускної здатності вхідного потоку для оператора рекурсивного DNS-сервера. Це призводить до швидших відповідей на запити клієнтських комп'ютерів.

Оскільки TTL запису DNS встановлюється нижчим, а використання пропускної здатності на авторитетних серверах DNS збільшуватиметься, оскільки рекурсивні DNS-сервери не зможуть кешувати результат протягом тривалого часу. Оскільки TTL запису вище, зміни в записах не будуть швидко набирати чинності, оскільки клієнтські комп'ютери продовжуватимуть отримувати кешовані результати, що зберігаються на їх рекурсивних серверах DNS. Встановлення оптимальної TTL зводиться до балансуючого рівня між використанням та здатністю швидко змінювати записи та бачити, що ці зміни відображаються на клієнтах.

Варто зазначити, що деякі Інтернет-провайдери зловживають і ігнорують значення TTL, визначені авторитетними серверами DNS (заміняючи власну адміністративну перевагу, що є порушенням RFC). З цього питання нічого не можна робити. Якщо в операторів зловживаючих DNS-серверів можуть бути звернені скарги на їх системних адміністраторів, це може призвести до їх застосування в практиці найкращої практики (можливо, що є здоровим глуздом для будь-якого мережевого інженера, знайомого з DNS). Цей тип зловживань не є технічною проблемою.

Якщо всі "грають за правилами", зміни до записів DNS можуть "набути чинності" дуже швидко. У разі зміни IP-адреси, призначеної для запису "А", наприклад, буде виконуватися експоненціальний баккофф значення TTL, що призводить до моменту внесення змін. TTL може початися, наприклад, через 1 день, і зменшиться до 12 годин протягом 24 годин, потім 6 годин протягом 12 годин, 3 години протягом 6 годин тощо, аж до деякого відповідного невеликого інтервалу. Після повернення TTL запис можна змінити і TTL повернути до потрібного значення для щоденних операцій. (Не потрібно використовувати експоненціальний баккофф, однак ця стратегія мінімізує час запису буде мати низький TTL і зменшує навантаження на авторитетний сервер DNS.)

Після створення запису зміни DNS слід контролювати журнали змін спроб доступу внаслідок старого запису DNS. У прикладі зміни запису "А" на посилання на нову IP-адресу сервер повинен залишатися присутнім на старій IP-адресі для обробки спроб доступу в результаті клієнтських комп'ютерів, які все ще використовують стару запис "А". Після того, як спроби доступу на основі старої записи досягли прийнятно низького рівня, стару IP-адресу можна використовувати. Якщо запити, пов'язані зі старою записом, швидко не стикаються, можливо, (як описано вище) рекурсивний DNS-сервер ігнорує авторитетний TTL. Знаючи IP-адресу джерела спроби доступу, однак, не надає прямої інформації щодо рекурсивного DNS-сервера, відповідального за надання старого запису.

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