Як визначається порядок пошуку DNS?

Наприклад: ми зареєстрували доменне ім’я domain.com та додали записи сервера імен на сервері реєстраторів:
ns1.domain.com.
ns2.domain.com.
ns3.domain.com.

Чим ми шукаємо домен.com . Ми отримуємо всі 3 адреси сервера імен.
1. На який з цих серверів буде подано запит і чому?
2. Чи має значення порядок записів NS у файлі зон?
3. Чи визначено це в будь-якому RFC ?

На жаль, відповідь тут "це залежить". Фактори, від яких залежить, залежать від домену та того, як налаштовані сервери володіння, а також від того, як налаштовано ваш власний локальний DNS.

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

Далі, деякі реалізації DNS будуть паралельно запитувати кожну НС та використовувати будь-який із них. Інші вдарять кожного, визначають найшвидший за деяку кількість запитів і використовують цей. Або це міг просто круглобільний.

Існує кілька RFC для DNS, два з найбільш корисних, які я знайшов:

http://www.faqs.org/rfcs/rfc1912.html

http://www.faqs.org/rfcs/rfc1033.html

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

Найпоширеніша реалізація, яку я бачив на рівні клієнтів, наприклад, Інтернет-провайдери у всьому світі, полягає в наступному:

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