Давайте трохи розбимо його.
Записи NS в зоні TLD (наприклад, example.com NS ...в com) - це записи делегації .
Записи A і AAAA в зоні TLD (наприклад, ns1.example.com A ...в com) - це записи клею .
Записи NS в самій зоні (тобто example.com NS ...в example.com) є повноважними записами.
Записи A і AAAA в самій зоні ( ns1.example.com A ...в example.com) є адресними записами, прості і прості.
Коли (рекурсивний) резолютор запускається без кешу даних вашої зони та лише кешу кореневої зони (який використовується для завантаження процесу вирішення імені), він спочатку перейде до ., потім com.. Ці comсервери будуть реагувати з відповіддю влади розділу , який в основному говорить : «Я не знаю, але подивіться тут для кого - то , хто знає», так само як сервери для .справ про com. Ця відповідь на запит не є авторитетною і не включає заповнений розділ відповідей. Він може також включати так званий додатковийрозділ, який дає відображення адрес для будь-яких імен хостів, про які конкретний сервер знає (або з записів клею, або, у випадку рекурсивних розділювачів, з раніше кешованих даних). Резолютор візьме на це відповідь делегування, при необхідності вирішить ім'я хоста запису NS та перейде до запиту сервера DNS, якому було передано повноваження. Цей процес може повторитися кілька разів, якщо ви маєте глибоку ієрархію делегування, але врешті-решт призводить до відповіді на запит із встановленим прапором "авторитетна відповідь" .
Важливо зауважити, що резолютор (як правило, сподіваємось) не намагатиметься розбити вирішене ім'я хоста, щоб запитати про нього детально, а просто відправить його в повному обсязі на "найкращий" сервер, про який він знає. Оскільки середній авторитетний сервер імен в Інтернеті не є авторитетним для переважної більшості дійсних імен DNS, відповідь буде неавторитетним відповіддю делегації, що спрямоване на якийсь інший сервер DNS.
Тепер сервер не повинен бути названий в делегуванні або повноваженнях, де він був авторитетним для зони. Розглянемо для прикладу приватний головний сервер; у цьому випадку існує авторитетний DNS-сервер, про який знають лише адміністратор (-ів) підлеглого DNS-серверів для зони. Сервер DNS є авторитетним для зони, якщо через якийсь механізм, на його думку, він має повне та точне знання про зону, про яку йдеться. Як правило, авторитетний DNS-сервер може, наприклад, стати неавторитетним, якщо налаштовані майстер-сервери не можуть бути досягнуті протягом часу, визначеного як час закінчення в записі SOA.
Лише авторитетні відповіді слід вважати правильними відповідями на запити; все інше - або делегація, або якась помилка. Делегування на неавторитетний сервер називається "кульгавою" делегацією, і означає, що резолютор повинен відхилити один крок і спробувати інший DNS-сервер. Якщо в делегації не існує авторитетних доступних серверів імен, то дозвіл імен виходить з ладу (інакше це буде просто повільніше, ніж зазвичай).
Це все важливо, оскільки не авторитетні дані не повинні кешуватися . Як це могло бути, оскільки неавторитетний сервер не має повної картини? Тож авторитетний сервер повинен за власним бажанням мати можливість відповісти на питання "хто повинен бути авторитетним, а для чого?". Це інформація, надана в зоні записів NS.
Існує ряд крайових випадків, коли це насправді може серйозно змінитись, в першу чергу зосереджено на декількох мітках імен хостів всередині однієї зони (можливо, досить поширених, наприклад, із зворотними зонами DNS, особливо для великих динамічних діапазонів IP) або коли список серверів імен відрізняється між батьківська зона та зона, про яку йдеться (що, швидше за все, є помилкою, але це може бути зроблено також навмисно).
Ви можете побачити, як це працює трохи детальніше, використовуючи digйого функції +norec(не вимагаючи рекурсії) та @специфікаторів сервера. Далі йде ілюстрація про те, як працює фактичний сервер вирішення проблеми DNS. Запит для записів A для unix.stackexchange.comпочатку, наприклад a.root-servers.net:
$ dig unix.stackexchange.com. A @a.root-servers.net. +norec
Подивіться уважно на flagsпідрахунки, а також на кількість перерізів. qr- це відповідь на запит і aaє авторитетним відповіддю. Зауважте, що вас делегують лише comсервери. Вручну слідкуйте за цим делегуванням (у реальному житті рекурсивний вирішальник використовує IP-адресу з додаткового розділу, якщо це передбачено, або ініціює окреме дозвіл імені одного з названих серверів імен, якщо в відповіді на делегування не вказано IP-адреси, але ми пропустіть цю частину і просто поверніться до нормальної роздільної здатності операційної системи для стислості прикладу):
$ dig unix.stackexchange.com. A @a.gtld-servers.net. +norec
Тепер ви бачите, що stackexchange.comце делеговано (серед інших) ns1.serverfault.com, і ви все ще не отримуєте авторитетної відповіді. Знову слідкуйте за делегацією:
$ dig unix.stackexchange.com. A @ns1.serverfault.com. +norec
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35713
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
;unix.stackexchange.com. IN A
;; ANSWER SECTION:
unix.stackexchange.com. 300 IN A 198.252.206.16
Бінго! Ми отримали відповідь, оскільки aaпрапор встановлений, і він, можливо, містить IP-адресу, як ми сподівалися знайти. Як осторонь, варто зазначити, що принаймні під час написання цієї публікації списки серверів імен з делегованими та переліченими повноваженнями відрізняються, показуючи, що ці два не повинні бути однаковими. Те, що я наводив на прикладі вище, - це в основному робота будь-якого рішення, за винятком будь-якого практичного резолютора, також кешуватиме відповіді на цьому шляху, тому не потрібно щоразу потрапляти на кореневі сервери.
Як видно з вищенаведеного прикладу, записи делегування та склеювання служать цілі, відмінній від повноважень та адресних записів у самій зоні.
Сервер кешування, вирішення імен також, як правило, здійснює перевірку правильності повернених даних для захисту від отруєння кешем. Наприклад, він може відмовитись кешувати відповідь, іменуючи авторитетні сервери comвід джерела, відмінного від того, яке вже було названо батьківською зоною як видалене для com. Деталі залежать від сервера, але наміром є кешування якомога більше, не відкриваючи двері сараю, щоб дозволити будь-якому серверу випадкових імен в Інтернеті перекрити записи делегацій за все, що офіційно не перебуває під його "юрисдикцією".