Навіщо надсилати авторитетний сервер імен у DNS?

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

Однак якщо додатково перевірити запит, ви побачите, що сервер також надсилає NS (авторитетний сервер імен). Моє запитання: чому?

Як хост, я дбаю лише про IP. Це головний момент DNS , щоб вирішити ім'я в IP-адресу .

Чому мені, як хосту, потрібна інформація про NS?

— АхмедВас
джерело

@downvoter, будь ласка, прокоментуйте. І якщо ви вважаєте, що моє питання таке просте, то принаймні відповідь на нього тоді зворотне.

— Ахмед був

За філософією та дизайном голоси є анонімними, і ні голосування , ні голосування не вимагають обов'язкових пояснень . Підказка, яка з’являється, коли курсор миші клацає на кнопку вниз, вказує: "це питання не показує жодних зусиль для дослідження; воно незрозуміле чи не корисне" . Також питання можуть залучати голосування проти тих, коли вони недостатньо написані , не надто тематичні або відсутні деталі.

— HBruijn

Відповіді:

Традиційно сервери імен не надсилають коротку відповідь на запит, але повну відповідь, сумісну з RFC 1034 - 1035, яка включає розділ повноважень, що містить записи ресурсів, які спрямовані на авторитетні сервери імен.

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

Редагувати: До речі: надсилання розділу авторитету відповідає стандарту RFC, але не є обов'язковим для всіх відповідей на запити.

У BIND така поведінка може бути налаштована за minimal-responses yes | no;директивою, де за замовчуванням є noрозділи повноважень та додаткові відповіді на запити завжди повністю заповнені.
Інші сервери імен CloudFlare, AWS Route 53, Infoblocks і, ймовірно, інші, вже завжди надсилатимуть такі мінімальні відповіді за замовчуванням. Громадські розпорядники Google повернуть розділ Правління, коли буде доступний, Cloudflare.

Я думаю, що початок цієї традиції включати як розділ повноважень, так і власне відповідь на запит знаходить свій корінь у (псевдо) коді з застарілого RFC882 сторінки 15-16

If the name server is not authoritative, the code copies 
the RRs for a closer name server into the response.  

The last section of the code copies all relevant RRs into the response.

— HBruijn
джерело

дякую за редагування та додаткову інформацію. Я хотів би, щоб я міг дати вам більше, ніж один голос "за" :)

— AhmedWas

Це насправді не відповідає на питання. Ми вже знаємо, що отримана повна відповідь. Питання полягало в тому, яка користь від цього? Чому стандарт розроблений таким чином? Яке значення "додаткової" інформації у цій формі відповіді?

— Гонки легкості по орбіті

@LightnessRacesinOrbit для мене відповідь очевидна: сервер DNS не просто говорить мені, що example.com abcd; це говорить мені, хто так сказав. Це гносеологічно добре, тому що я не можу точно сказати вам, що я знаю, що це факт, коли я фактично знаю лише те, що третя сторона стверджує, що це факт. Мені складніше вирішувати проблеми, коли люди представляють з чужих даних, як ніби це спостереження, або їхні висновки, як ніби первинні докази і т. Д. Різниця між твердженням X, що є правдою, і кажучи мені, Y сказав, що це правда величезна.

— Monty Harder

@MontyHarder Так, це має сенс, але те, що я говорю, - це повинно бути у відповіді.

— Гонки легкості по орбіті

@LightnessRacesinOrbit RFC не завжди включає мотиви дизайну. Для уточнення "це здавалося гарною ідеєю в той час" - я думаю, що це причина, чому традиційно включати розділ повноважень на додаток до реальної відповіді на запит, навіть незважаючи на те, що нинішній RFC не мандат, який знаходить своє походження в (псевдо ) код із застарілого RFC882 на сторінці 15-16 "... Якщо сервер імен не є авторитетним, код копіює RR для більш близького сервера імен у відповідь. Останній розділ коду копіює всі відповідні RR у відповідь. ... "

— HBruijn

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

Я вважаю, що це було оригінальним обґрунтуванням у протоколі, але це має наслідки для безпеки. Відповідь може включати розділ органу, в якому перераховані фальшиві сервери імен, і це було використано при атаках з отруєнням кеша. Таким чином, сервери імен, як правило, не кешують записи NS, якщо вони не делегують записи для субдомену домену, який ви запитуєте.

— Вармар
джерело

Сервер може фактично визначити різницю між такими запитами. У прапорах є трохи, щоб попросити рекурсії.

— kasperd

Сервери можуть надсилати рекурсивні запити, наприклад, коли використовується forwardersфункція.

— Бармар

Але якщо ви це зробите, це все одно не піклується про авторитетні сервери.

— kasperd