Як можна для серверів імен Root обробляти всі запити DNS?

18

Я читав про DNS кілька днів тому і дізнався, як обробляються запити. Якщо ви переходите на сторінку www.example.com, тоді запит перейде до серверів імен Root, щоб побачити, кому належить ця .com-адреса, тоді ще один запит перейде на інший, більш локальний, DNS-сервер, щоб побачити, хто є власником example.com адреса тощо.

Наскільки технічно можливо, що 13 серверів імен коренів можуть одночасно обробляти всі запити, зроблені мільйонами мільйонів користувачів Інтернету, не маючи на увазі ddos: ed?

domain-name-system nameserver ddos

— Рокс
джерело

11

До речі, ваше резюме того, як працює DNS, є неправильним. Питання, задане серверу кореневих імен, - це не "кому належить .com?" але "що таке IP-адреса www.example.com?" (сервер імені кореня відповідає на це посиланням на власника .com). Сервер кореневих імен бачить весь запит (що корисно для статистики, пошуку даних тощо).

— борцмейєр

@bortzmeyer Основна причина, що все ім'я надсилається на кореневі сервери, полягає в тому, що не кожна крапка в імені обов'язково є межею повноважень. На практиці я вважаю, що завжди існує межа повноважень трохи нижче TLD, але в принципі це не гарантується. Отже, в якийсь момент у майбутньому може бути прийнято рішення запровадити спеціальний TLD, де другим шаром обробляються кореневі сервери, так що при запиті кореневих серверів a.b.c.exampleвам скажуть, хто відповідає, c.exampleа не за кого відповідає example.

— kasperd

51

У них 13 високо доступних кластерів серверів, а не просто 13 серверів.

Крім усього іншого, оператори сервера імен root повинні мати достатню потужність, щоб тричі перевищувати їх нормальне завантаження ( RFC 2870 ). Це призводить до досить великих скупчень.

Тим НЕ менше, кореневі сервери імена служать тільки для відповідей доменів верхнього рівня, тобто сам com., net., uk., ae., і т.д., і сервера імен , які запитують корінь може кешувати цю інформацію до 48 годин , що значно знижує навантаження на кореневих серверах імен. Це призводить до менших кластерів.

Сервери кореневих імен знаходяться у понад 130 фізичних місцях у 53 країнах; з лише 13 іменами серверів, це робиться через магію IPv4 anycast.

У кореневих серверів імен також є власний веб-сайт , який вам може бути цікавим для читання.

— Майкл Хемптон
джерело

48 год - TTL записів NS в корені. Але це може бути замінено серверами імен самого TLD. Наприклад, для .jp це лише 24 год.

— борцмейєр

Ну, ми тут говоримо про кореневі сервери імен. :)

— Майкл Хемптон

RFC 2870 сьогодні досить застарілий. Через атаки dDoS сервер кореневих імен повинен бути готовий відповісти набагато більше, ніж утричі, ніж його звичайний трафік.

— борцмейєр

8

53 країни? це збіг випадків, або вони вибрали його так само, як порт запиту DNS ?? : D

— amyassin

10

Вони цього не роблять. Кореневі сервери імен просто повинні повідомити вам, з якими серверами імен обробляються com. З цього моменту вам не потрібно звертатися до них, щоб обробляти будь-який домен всередині com. Користувачі кореневих імен не мають уявлення, кому належить example.com. Вони - кореневі сервери імен, а не сервери імен ком .

Те, що сказав slimsuperhero, також є правдою. Багато серверів імен з високою гучністю використовують anycast, щоб мати єдину IP-адресу, яка обслуговується багатьма серверами по всьому світу.

— Девід Шварц
джерело

Але якби 1 мільярд користувачів відвідували різні адреси .com за одну і ту ж секунду, чи могли б сервери кореневих імен обробляти всі запити?

— Rox

3

Ні. З одного боку, користувачі спілкуються лише з рекурсивними серверами імен (тими, які підключаються до інших серверів імен, щоб отримати відповіді), а кореневі сервери імен не є рекурсивними (вони обслуговують лише локальну інформацію, яку вони вже знають). Користувачі спілкуються зі своїми власними серверами імен (зазвичай надаються їх провайдером), яким потрібно лише один раз запитати кореневих серверів імен для серверів, які обробляють com.

— Девід Шварц

1

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

— Шадур

@Shadur: Тепер сервери імен, comз іншого боку, повинні мати набагато більш масштабні побиття.

— Девід Шварц

1

І я впевнений, що вони масштабуються та кластеруються належним чином.

— Шадур

6

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

— Гевіал
джерело

3

Зауважте, що ви не використовуєте кореневі сервери. Зазвичай ви використовуєте сервер DNS, наданий постачальником послуг Інтернету, який зазвичай може негайно відповісти, якщо потрібна інформація знаходиться у їх локальному кеші. Тільки якщо вони не кешовані, запитується їхній сервер DNS вище, і лише в кінцевому підсумку запитується кореневий сервер (і ця відповідь потім кешується)

— Торбьорн Равн Андерсен
джерело

0

Насправді його IP-адреса 13 Anycast, яка вирішує багато серверів по всьому світу. Ви можете переглянути Посилання, щоб знайти ці сервери, якщо це потрібно. Усіма цими серверами керується відповідний орган.

Той факт, що ми все ще використовуємо лише 13 IP-адрес (І кластер серверів, що мають однакову IP-адресу), полягає в тому, щоб забезпечити, щоб розмір пакету не перевищував 512 байт. Тоді чому? у нас є TCP, який може перевищувати цей розмір пакета, чому ми не можемо його використовувати ?. Вся справа в тому, що TCP передбачає дуже високі накладні витрати, оскільки включає в себе кілька кроків і процедур для встановлення TCP-з'єднання. Через це весь процес запиту DNS буде йти повільно.

Такі речі, як DNS, ніколи не можуть бути повільними, і тому ми все ще використовуємо ту саму стару систему.

— Джейсон
джерело

Відповідь на запит .більше не відповідає 512 байтам. Оскільки IPv6 зараз є необхідністю, відповідь зросла до 811 байт. З EDNS, який можна повернути в одній відповіді. Однак запити .не потрібні настільки часто, що пара туди і назад - це стоп-шоу. Рекурсорам в першу чергу потрібно дізнатися останні зміни в IP-адресах коренів, які рідко змінюються.

— kasperd

@kasperd Я не впевнений. Я перевірив dig + trace на нормальний запис A або AAAA запис, і всі відповіді (з серверів Root level, серверів верхнього рівня або в серверах імен) мають менше 508 до 509 байт. Чи можете ви пояснити трохи більше про це.

— Джейсон

Щоб отримати повну відповідь, потрібно використовувати EDNS або TCP. Запити UDP без EDNS ніколи не можуть отримати відповідь довше 512 байт.

— kasperd