Найпоширеніша реалізація, яку я бачив на рівні клієнтів, наприклад, Інтернет-провайдери у всьому світі, полягає в наступному:
- Хтось (як абонент широкосмугового зв’язку) просить DNS-сервери провайдера вирішити запис A для foo.example.com.
- ISP перевіряє власний кеш, і якщо цей запис є кешованим і все ще вважається "свіжим", він негайно повертається через кеш. ( Ось так працюють усі кеші DNS, щоб вони непотрібно напружували DNS-сервери відповідного сайту. )
- Якщо у них не було кешованого запису або якщо кеш вважається "застарілим / застарілим", ISP знає, що йому потрібно вирішити останню запис знову.
- Тепер ISP повинен знати, які сервери імен запитувати про останню запис.
- ISP починається з перевірки свого кешованого списку авторитетних серверів імен для домену (це ns1.example.com, ns2.example.com тощо, а також їх IP-адреси). Якщо ці записи все ще вважаються свіжими, вони переходять до кроку 8.
- Якщо кешовані записи сервера імен вважалися закінченими, або якщо у них не було жодних кешованих записів для цього домену, ISP запитує кореневих серверів імен TLD (наприклад, реєстр .com, якщо це домен .com), щоб отримати найсучасніші імена серверів імен / IP-адреси для example.com. ( Ви можете спробувати це самостійно за допомогою "dig @ b.gtld-servers.net example.com", щоб побачити, що кореневі сервери імен для вашого TLD знають про ваш домен - якщо ваш домен належить до звичайних TLD-файлів com / net / etc. Інше TLD повинні будуть запитувати відповідні кореневі сервери. )
- Кореневі сервери імен для TLD завжди повертають сервери імен у тому порядку, у якому вони були вказані вами; жодна рандомізація не триває. Вони також повертають IP-адреси для кожного сервера імен; це відомо як "GLUE", і це те, що дозволяє Інтернету вирішити проблему "курка і яйце", як вирішити ім'я хоста на сервері імен до IP, перш ніж взагалі нічого знати про домен. Більше того, більшість із них (як-от реєстри com / net / etc., які є найбільшими) використовують кеш-пам’ять у 2 дні, щоб вони не забивались постійно "яким є список серверів імен для домену X?" запити. Це джерело загальних знань про те, що ВИ ПОТРІБНО зачекати 2 дні, поки ви сміливо можете сказати, що ваші нові сервери імен відомі у всьому світі після того, як ви '
- Коли Інтернет-провайдер знає сервери імен example.com та їхні IP-адреси, такі як ns1.example.com, ns2.example.com, ns3.example.com, тепер Інтернет-провайдер вибирає з цього списку випадковий сервер і відправляє запит. ( Це приємно для них, вони не потребують забивати всі DNS-сервери відповідного веб-сайту, і вони допомагають додатково врівноважувати навантаження, не завжди запитуючи перший перелічений сервер імен. )
- Якщо провайдер не отримає відповіді від цього сервера імен протягом визначеного періоду очікування, він запитує ще одного у списку.
- Коли він отримав відповідь, тепер провайдер зберігає його у власному локальному кеші. Щодо того, як довго він буде зберігатися в кешеному режимі; кожен запис, повернутий будь-яким сервером DNS, також має з ним пов'язаний час "м'якого закінчення терміну дії" (у секундах), який означає, як довго клієнту запиту (наприклад, DNS-серверу провайдера ISP) дозволено кешувати цей запис, перш ніж його розглядати " як і раніше можна використовувати, але можливо застарілий, тепер новий запит повинен відбуватися ЯКЩО МОЖЛИВО, щоб переконатися, що він не змінився. " Існує також "термін придатності", який вказаний у записі "SOA" (Початок повноважень) кожного окремого сервера імен (ви можете бачити своє за допомогою "dig @ ns1.example.com example.com -t soa"), який визначає глобальний "жорсткий ліміт" для всіх записів, повернених цим сервером, після цього будь-який кеш ДОЛЖНЕ ЗАБЕЗПЕЧИТИ кешовану запис НАДІЛЬКО, якщо сервери імен не працюють, і неможливо переглянути записи знову. Зазвичай м'який термін дії становить від 30 хвилин до 5 годин, а термін придатності зазвичай становить від 1 до 3 тижнів.
- Після цієї вичерпної роботи ISP, нарешті, має останню запис DNS і може повернути її перед запитувачем широкосмугового абонента, який не є наймудрішим, яка величезна робота відбулася за лаштунками!
Цей процес повторюється для КОЖНОГО пошуку записів. Однак лише перший запит виконує всю роботу; IP-адреси сервера імен будуть кешовані після цього, і наступні запити на кешування DNS-сервера провайдера швидко зможуть перейти до кроку 8.
Тепер, що стосується рандомізації кроку 8, він працює на рекордному рівні. Скажімо, абонент широкосмугового зв’язку цього провайдера запитав про такі записи:
- A foo.example.com
- Приклад.com
- Www.example.com
- MX example.com (клієнт ISP не повинен просити цю запис, але це лише приклад)
Кожен запис буде оброблятися як його окрема "сутність", незалежно кешований та піднятий. Скажімо, абонент і провайдер ніколи раніше не стикалися з доменом, і обидва мають повністю нульові кешовані записи. Шукання може бути наступним:
- A foo.example.com через ns1.example.com, потім зберігається в кеші провайдера
- Example.com через ns3.example.com, потім зберігається в кеші провайдера
- Www.example.com через ns2.example.com, потім зберігається в кеші провайдера
- MX example.com через ns3.example.com, потім зберігається в кеші провайдера
Кожного разу, коли кешовані записи з простроченим терміном закінчуються, процес повторюється, тому ви навіть не знаєте, що наступні запити для цієї записи знову використовуватимуть той же сервер.
Тому ваша абсолютна найбільша мета - переконатися, що всі ваші DNS-сервери повністю синхронізовані між собою, ідеально відображаючи всі записи DNS на кожному сервері. Ви ніколи не знаєте, на який сервер буде потрапляти клієнт DNS, і ви не можете розраховувати ні на яке замовлення. Немає такого.
Крім того, як зазначав Адам С, сервери DNS на рівні сервера (example.com) DNS-сервери могли самі повертати NS-записи і рандомізувати порядок їх. Для звичайних серверів DNS дуже часто рандомізувати свої записи NS з невеликим шансом на те, що погана реалізація DNS завжди вибирає перший повернутий намсервер. Однак сервери імен ROOT TLD (згадані раніше) ніколи не рандомізують цей список, а їх перелік - це те, що дійсно має значення при вирішенні домену. Ось чому більшість реалізацій вибирають випадковий сервер зі списків серверів імен, щоб уникнути того, щоб завжди потрапляти на один і той же сервер і не перевантажувати його.
Гаразд, це ваш праймер в тому, як працює DNS і що вам слід пам’ятати.
- Коротше кажучи: поводьтеся з усіма своїми серверами DNS так, ніби вони є лише одним сервером, зробивши це найвищою метою у житті - переконатися, що вони всі однаково здатні відповісти на будь-який запит, який може бути кинутий на них.
Відмова: Вищі цілі в житті, ніж управління DNS, можуть бути доступні, але продаються окремо, використовуйте свою фантазію. ;-)