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


20

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

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

Відповіді:


20

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

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

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

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

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

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

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


Я схвалив вашу відповідь. Я збирався сказати те саме, але ти мене побив.
Тонні

Також клієнти, які використовують гетадрінфо, закінчують сортуванням результатів, тоді як дзвінки gethostbyname, здавалося б, були випадковими. Клієнти, які не сподіваються, що така поведінка, в деяких аспектах, порушить кругові рублі
Метт

5

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

  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, можуть бути доступні, але продаються окремо, використовуйте свою фантазію. ;-)

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.