Як діє DynamicDNS негайно?

Моє розуміння основної функціональності DNS полягає у наданні послуги іменування / відображення між доменними іменами (наприклад blah-whatever.com) та IP-адресами (наприклад, 100.2.3.4 ).

Крім того, моє розуміння того, як працюють сервери DNS-інтернету, полягає в тому, що при зміні запису відображення домену / IP (скажімо, змінившись blah-whatever.comзараз на 105.2.3.4 тощо), цю зміну потрібно поширювати на кожному DNS-сервері у світі перш ніж зміни можна сказати "завершеними". Цей період поширення іноді може тривати до 24 годин.

Отже, для початку, якщо що-небудь, про що я вже говорив, є хибним чи невірним, почніть, виправляючи мене!

Якщо припустити, що я більш-менш коректний, я не розумію, як такі компанії, як CloudFlare або DynamicDNS, можуть пропонувати послуги "миттєвого перекидання", за допомогою яких ви змінюєте свій запис DNS разом із ними і - бум - зміна впливає негайно.

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

Тож я запитую: що про Dynamic DNS та його конкурентах дозволяє миттєво змінювати відображення DNS (не потребуючи 24 годин для поширення змін DNS, як і всі), і як TTL вписується в цей процес? Заздалегідь спасибі.

Моя попередня відповідь містила неправдиву інформацію, оскільки у мене було кілька помилок щодо розповсюдження змін у DNS. Отже ось друга спроба. Для детального пояснення рекомендую прочитати відповідь Алекса .

Наскільки я розумію, у швидкості поширення зміни DNS є два фактори:

1. Передача зон між серверами DNS, які є авторитетними для зони.
2. Набір TTL для одиночних записів у цій зоні.

Передачі зон

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

Це або шляхом витягування останню версію зони на фіксований інтервал, або в очікуванні NOTIFY від уповноваженого сервера імен.

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

TTL

TTL є тайм - аут визначено для кожного окремого запису ресурсу в зоні. Це значення визначає, як довго слід кешувати запис не-авторськими DNS-провайдерами.

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

Зважаючи на те, що TTL також знаходиться під повним контролем того, хто контролює зону, затримку також можна повністю контролювати.

У вас є деякі помилки, тому я спробую пояснити весь процес. (Мені добре з деталями, оскільки я брав участь в роботі публічної динамічної служби DNS).

Скажімо, ваш домен je example.com , а скажімо, домен example.com, розміщений у динамічній компанії DNS, назвемо це lightfastdns.net (вигадане ім’я). Ваш домен містить запис DNS - somehost.example.com , який наразі вказує на 1.1.1.1 .

1. Коли ви вносите зміни до свого запису DNS, ці зміни спочатку надсилаються на якийсь проміжний сервер, керований lightfastdns.net , наприклад updates.lightfastdns.net . Це відбувається майже миттєво (в частці секунди). Ви можете надіслати своє оновлення через веб-інтерфейс або за допомогою клієнта з динамічними оновленнями або через якийсь API. Це не має значення, у будь-якому випадку це оновлення надійде на якийсь сервер, який обробляє оновлення DNS.

2. Цей сервер оновлень підштовхує вашу оновлену запис (скажімо, 1.2.3.4 ) на " майстер " DNS-сервер для вашого домену. Цей DNS-сервер також працює lightfastdns.net . Як швидко це відбувається: залежить від того, як постачальник DNS розробив своє програмне забезпечення. (Це можна миттєво, і це можна кожні 24 години. Наприклад, gandi.net натискає оновлення DNS один раз на годину.) Звичайно, наш lightfastdns.net зробить це миттєво.

3. Цей головний DNS-сервер буде натискати оновлення на підлеглий DNS-сервери для домену example.com . Цими серверами також керує та сама компанія lightfastdns.net . Як швидко це відбувається: з сучасним майстром програмного забезпечення миттєво надсилає повідомлення NOTIFY рабам , і вони миттєво отримують оновлений запис від ведучого. зі старшим програмним забезпеченням ми мали значення REFRESH та RETRY в записі SOA, але сьогодні це рідко актуально. Звичайно, наш lightfastdns.net реалізує NOTIFY і оновлення розповсюджуються миттєво.

Зараз у нас є те, що всі "авторитетні" сервери для вашого домену отримали оновлений запис ( 1.2.3.4 ). Для lightfastdns.net минуло близько двох секунд.

1. Тепер ми переїдемо до дому Івана в Росію, і Іван хоче відкрити " somehost.example.com " у своєму браузері. Якщо він ніколи цього не відкривав, його браузер не знає адреси, тому браузер запитає його операційну систему. Але якщо він нещодавно відвідав сайт, адреса все-таки може зберігатися всередині браузера, і він буде використовувати стару (застарілу) адресу! Як довго ? - Залежно від браузера, Google Chrome, наприклад, зберігає записи DNS лише до 60 секунд. У нас затримка до 60 секунд . за цим фактом я б сказав, що зміна DNS ще не поширювалася на цей веб-переглядач.

2. У будь-якому випадку через 60 секунд або негайно браузер зрештою попросить операційну систему отримати адресу. Операційна система, можливо, вже знає (старий, застарілий) відповідь і повертає її, в цьому випадку я б сказав, що новий запис ще не поширювався в Іванову ОС. Як довго ОС буде зберігати старе значення - перестаньте сучасні операційні системи, які керуються параметром TTL . TTL в DNS визначає, як довго може зберігатися запис у кеші. Наш lightfastdns.net дозволив використовувати досить низький TTL - 30 секунд, тому ми отримали нову затримку до 30 секунд, загальна - до 90 секунд поки що.

3. Якщо ОС не знає відповіді, або якщо відповідь, про яку вона знала, тепер застаріла TTL, ОС запитає DNS-розв'язник (Іван-провайдер призначив йому DNS-рішення dns.moscow-telecom.ru ). Тут до старого запису може зберігатися кешування до TTL секунд, або dns.moscow-telecom.ru може не знати адреси. Ми отримуємо ще 30 секунд, оскільки dns.moscow-telecom.ru також кешує DNS не довше значення TTL. У нас затримка 120 секунд . Ось що закликало, що новий запис DNS ще не поширювався на сервери DNS Москви-Телекому .

4. Якщо DNS - сервер провайдер не знає відповіді, або якщо відповідь він знав , вже застарів , тому що це TTL закінчився - dns.moscow-telecom.ru задасть один з авторитетних серверів DNS для example.net (ви пам'ятаєте їх?). Ті зміни отримали близько 118 секунд тому, і вони повернуть нову відповідь, ця відповідь буде негайно відправлена ​​ланцюжком до DNS-резолюції, ОС та браузера Івана.

Таким чином, розповсюдження запису зайняло від 2 до 120 секунд, залежно від стану різних кеш-пам'яток. Більш довгі TTL - можливі більш тривалі затримки.

Щоб зробити його повною, деякі провайдери довгий час порушують стандарти та записи кешу. Деякі старі ОС довгий час зберігали старі записи, а також старі браузери. Але для більшості користувачів це буде працювати, як очікувалося.

Ні. Зміна не повинна поширюватися на кожен DNS-сервер у світі .

Якщо ви щось змінили, а хтось запитує змінену запис на сервері DNS, результат миттєвий.

Проблема полягає в тому, якщо ви раніше запитували це ім'я і воно запам’ятовується. Тоді ви отримаєте старий IP, поки кеш не закінчиться. У DNS можна встановити, як довго діє старий запит, і цей період часто встановлюється кількома днями. Для DynDNS зазвичай встановлено нижчий рівень, але не всі DNS-вирішальники цього шанують.