Якщо припустити, що у налаштованого сервера імен у вашому розпорядженні немає жодних кешованих результатів, скільки серверів імен повинен запитувати ваш сервер імен, щоб вирішити maps.google.com? Яку команду (и) ви використали для пошуку всіх цих серверів імен? Перерахуйте по одному з кожного рівня та поясніть, для чого потрібен цей рівень.
Що ж, давайте виберемо цей.
"Припустимо, що у вашого налаштованого сервера імен немає в своєму розпорядженні жодних кешованих результатів", - спочатку, якщо він взагалі не має кешованих даних, то він нічого не може вирішити. Для того, щоб прокласти кеш-пам'ять роздільної здатності, вам потрібно мати записи NS та адреси (A, AAAA) для зони .(кореня AKA). Це сервери кореневих імен, які знаходяться в root-servers.net.зоні. Немає нічого магічного в цій зоні або тих DNS-серверах. Однак, ці дані часто надаються "поза діапазоном" до DNS-резолюції, саме для того, щоб прогрунтувати кеш-пам'ять резолюції. Ці дані не потребують лише авторитетних серверів імен, але сервери імен вирішують.
Також "вирішувати" до чого? Будь-який тип RR під цим ім'ям? ARR? Або щось інше? Який клас ( CH/ Chaosnet, IN/ Internet, ...)? Точний процес буде різним, але загальна ідея залишається тією ж.
Якщо ми можемо припустити, що ми знаємо, як знайти сервери кореневих імен, але нічого більше, і під "вирішенням" ми маємо на увазі отримання вмісту будь-яких IN ARR, пов'язаних з ім'ям, це стає набагато більш практичним.
Щоб вирішити ім'я DNS, ви в основному розділите ім'я на мітки, а потім працюєте вправо-вліво. Не забувайте .в кінці; ти дійсно вирішив би, maps.google.com.а не maps.google.com. Це залишає нам потребу в вирішенні (ми це знаємо, але реалізація DNS-резолюції, ймовірно, не буде):
.com.google.com.maps.google.com.
Почніть з з'ясування, де запитувати вміст .. Це легко; ми вже маємо цю інформацію: імена кореневих імен серверів та IP-адреси . Отже, у нас є сервер кореневих імен. Скажімо, ми вирішили використовувати 198.41.0.4 ( a.root-servers.net, також 2001: 503: ba3e :: 2: 30) для продовження дозволу назви. На практиці однією з перших речей, яку зробив вирішальник, швидше за все, буде використовувати надані дані кореневого сервера, щоб запитати у одного з серверів кореневої зони точний список серверів імен для кореневої зони, таким чином гарантуючи, що якщо хтось із імена та IP-адреси є дійсними та доступними, вони матимуть повний і повний набір даних для кореневої зони, коли розпочнеться роздільна здатність.
Зніміть DNS-запит maps.google.com. IN Aна 198.41.0.4. Це скаже вам у відповідь "ні, не збираюсь це робити, але ось хтось, хто може знати"; це направлення. Він містить NSзаписи про найближчу зону, про яку знає відповідний сервер, а також записи про клей, які сервер має. Якщо даних про клей немає, спочатку потрібно вирішити той хост, який названий у вибраній вами записі NS, і породити окрему роздільну здатність імені, щоб отримати IP-адресу; якщо дані клею доступні, у вас буде IP-адреса сервера імен, яка принаймні "ближче" до відповіді. У цьому випадку це буде набір серверів для com.зони, а також надаються дані клею.
Повторіть процес, задавши одному із com.серверів імен те саме питання. Вони також не знають, але перейдуть на авторитетні сервери імен Google. На даний момент у загальному випадку буде потрапляти чи буде пропущено, чи надано дані про клей чи ні; ніщо не заважає comдомену мати лише сервери імен nl, наприклад, у цьому випадку дані клею навряд чи будуть доступні на серверах gTLD. Надані дані про клей також можуть бути неповними, або якщо вам справді не пощастило, це може бути навіть неправильно! Ви завжди повинні бути готовими до нерестування тієї окремої роздільної здатності імені, про яку я згадував вище.
В основному, ви продовжуєте продовжувати, поки не отримаєте відповідь із aaвстановленим прапором (авторитетна відповідь). Ця відповідь підкаже вам, що ви просите, або що RR, про який ви просили, не існує ( NXDOMAINабо NOERRORз записами даних про відповіді з нулем). Продовжуйте шукати відповіді на кшталт SERVFAIL(і відступіться від одного кроку та спробуйте інший сервер, якщо ви отримаєте його; якщо всі названі сервери повертаються SERVFAIL, проваліть процес вирішення імені та поверніться SERVFAILдо клієнта).
Альтернативою запиту повного імені RR від кожного сервера (що може вважатися поганою практикою) є використання розбитого списку міток, який ми визначили раніше, запитуйте імена, подані сервером далі до кореня для IN NSта IN A/ IN AAAARR для цієї мітки та використовуйте їх для подальшого процесу вирішення імені. Це практично незначно на практиці, і той самий процес все ще застосовується.
Ви можете імітувати весь цей процес, скориставшись +traceопцією для digутиліти, яка входить до BIND або set debugв nslookup.
Варто також пам’ятати, що деякі RRtypes (зокрема NS, MXі деякі інші; також A6протягом певного часу були досить добре використані, але були застарілими) можуть і посилатися на інші RR. У такому випадку вам може знадобитися створити ще один процес вирішення імені, щоб дати повну та корисну відповідь своєму клієнту.
dig +trace, але не впевнений, що розуміють під рівнями. Це може бути питання про помилку сервера.