Почему в мире всего 13 групп корневых DNS-серверов?

1. Жёсткое ограничение протокола: 512 байт

1.1 MTU в IPv4 и UDP без фрагментации

Ранние сети ARPANET / IPv4 требовали минимальный MTU в 576 байт. Каждый хост был обязан принимать пакеты такого размера, иначе нельзя было гарантировать даже базовую достижимость (RFC 791).

Total Length is the length of the datagram, measured in octets,
including internet header and data.  This field allows the length of
a datagram to be up to 65,535 octets.  Such long datagrams are
impractical for most hosts and networks.  All hosts must be prepared
to accept datagrams of up to 576 octets (whether they arrive whole
or in fragments).  It is recommended that hosts only send datagrams
larger than 576 octets if they have assurance that the destination
is prepared to accept the larger datagrams.

• 576 байт общей длины − типичный IP-заголовок 20 байт − UDP-заголовок 8 байт ≈ 548 байт полезного места (с опциями IP-заголовок может достигать 60 байт, и остаётся меньше)
• RFC 1035 § 4.2.1 выбрал более консервативную степень двойки — 512 байт — как жёсткий предел для DNS поверх UDP: безопасно даже при IP-заголовке с полным набором опций
• Если UDP-ответ превышает 512 байт, его нужно обрезать и выставить флаг TC, вынуждая клиента перейти на TCP, — а тройное рукопожатие TCP в разы увеличивает задержку первого разрешения

Иными словами, «полный список корневых серверов должен помещаться в один UDP-пакет размером 512 байт» — иначе каждый корневой запрос в мире пришлось бы отправлять по TCP, а на оборудовании 1980-х это было бы близко к катастрофе.

1.2 Побайтовая структура DNS-сообщения

Полная структура ответа на запрос NS-записей для . (сервер возвращает все корневые NS-записи и связующие A-записи):

Header   (12 байт)

Формула общей длины:

Подставляем лимит в 512 байт:

Теоретически это позволяет до 15 групп, но нужен запас под подписи DNSSEC, псевдозапись EDNS0 OPT и выравнивание полей, поэтому остановились на 13 группах — RFC 2010 (1996) описал эксплуатационные требования к корневым серверам, и после запуска M-root в следующем году их число больше не менялось.

1.3 Проверьте сами — <code>dig +noedns -t ns .</code> возвращает примерно 490–510 байт

Это теория. Теперь действительно запросим корневой сервер через dig и посмотрим, какого размера реальный ответ:

$ dig +noedns -t ns .

; <<>> DiG 9.10.6 <<>> +noedns -t ns .
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35973
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15

;; QUESTION SECTION:
;.                                IN      NS

;; ANSWER SECTION:
.                       430502  IN      NS      a.root-servers.net.
.                       430502  IN      NS      b.root-servers.net.
…  (всего 13 NS, c–l опущены)
.                       430502  IN      NS      m.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.     516909  IN      A       198.41.0.4
b.root-servers.net.     562547  IN      A       170.247.170.2
…  (все 13 glue-записей A поместились)
m.root-servers.net.     516941  IN      A       202.12.27.33
a.root-servers.net.     516930  IN      AAAA    2001:503:ba3e::2:30
b.root-servers.net.     562547  IN      AAAA    2801:1b8:10::b
↑ поместились только 2 записи AAAA — пакет заполнен

;; Query time: 8 msec
;; SERVER: 192.168.1.1#53
;; MSG SIZE  rcvd: 492

Ключевая строка в конце — общий размер ответа примерно 490–510 байт, с запасом меньше 512 (точная цифра зависит от того, какой корневой сервер вы спрашиваете и сколько связующих IPv6-записей вернулось), — сходится с байтовым бюджетом выше. Обратите внимание на флаг +noedns: по умолчанию dig отправляет EDNS0, и тогда ответ занимает больше 800 байт. Именно поэтому 512 байт перестали быть жёстким пределом, когда EDNS0 стал повсеместным, — но число 13 к тому времени уже было зафиксировано.

2. Откуда взялось 13? Краткая история

Это число не было зафиксировано с самого начала. Количество корневых серверов несколько раз увеличивалось; после запуска M-root (WIDE, Япония) в 1997 году оно больше не менялось:

После фиксации на 13 буквенные имена от A до M больше не меняются — обновляется только оборудование и добавляются anycast-зеркала. Файл корневых подсказок интернета (named.root) давно встроен в код миллиардов рекурсивных резолверов и stub-клиентов; изменить хоть одно число значило бы обновить весь интернет.

3. Но действительно ли в мире всего 13 машин?

Нет. Это самое распространённое заблуждение. «13 групп корневых серверов» — это 13 NS-имён (a–m.root-servers.net), каждому из которых соответствует один адрес IPv4 и один IPv6, а не 13 физических машин.

За каждым IP стоит anycast-кластер: один и тот же IP-адрес одновременно анонсируется через BGP сотнями дата-центров по всему миру, и DNS-запрос пользователя маршрутизируется на ближайшее по RTT зеркало. Когда корневой сервер «падает», обычно это значит лишь, что на обслуживании зеркало в одном городе, — на глобальное разрешение имён это не влияет.

13 групп корневых серверов в 2024 году

В материковом Китае (Пекин, Шанхай, Шэньчжэнь, Гуанчжоу, Хэфэй и другие города) размещены anycast-зеркала нескольких корневых серверов, включая F / I / J / K / L; измеренный RTT до корневых серверов внутри Китая обычно меньше 20ms.

4. После EDNS0 512 байт перестали быть реальным ограничением

Вы можете спросить: DNS-пакеты размером 4KB и больше сегодня обычное дело — так почему бы не «выйти за пределы 13»?

• EDNS0 (RFC 2671 в 1999 году, сейчас RFC 6891) — согласует больший размер полезной нагрузки UDP (обычно 4096 байт), поддерживается всеми современными резолверами
• DNSSEC требует EDNS0, поскольку одни только подписи намного превышают 512 байт
• Переход на TCP — современное тройное рукопожатие TCP вместе с TLS / cookies уже обходится дёшево

Но список корневых серверов теперь — общесетевой консенсус: каждый рекурсивный резолвер на планете жёстко прописывает эти 13 групп в файле подсказок (named.root), а за этими резолверами стоят миллиарды устройств. Стимул что-то менять равен нулю, а риск — раскол глобального интернета, поэтому это число почти наверняка навсегда останется 13.

Коротко: «13 групп» физически давно устарели, но с инженерной точки зрения отменить их невозможно.

5. Главное

1. Историческая причина: лимит DNS поверх UDP в 512 байт → математический потолок в 15 групп → выбрано 13 с запасом, число зафиксировано после запуска M-root в 1997 году
2. Инерция протокола: обновить файлы подсказок на миллиардах устройств нереально, поэтому число не меняется
3. Реальная мощность: 1395+ anycast-зеркал, поэтому риск отказа единой точки близок к нулю
4. Доступность из Китая: у нескольких корневых серверов, включая F / I / J / K / L, есть зеркала в материковом Китае, измеренный RTT < 20ms