Почему корней DNS тринадцать, хотя в 512 байт влезало пятнадцать

Корневых серверов DNS тринадцать, и обычно это объясняют одной фразой: четырнадцатый не влезал в 512 байт UDP-ответа. Так написано и в недавней статье на Хабре, как общеизвестный факт. Сам предел появился в RFC 883 1983 года, перешёл в RFC 1035 без объяснения, а FAQ комитета RSSAC при ICANN выводит из него тринадцать расчётом на бумаге.

Я проверил этот расчёт на живом сервере. Поднял в контейнере BIND 8.1.2 из Debian 1998 года, загрузил в него список корневых серверов от 22 августа 1997-го, восстановил по документам, кто тогда держал .com, и задавал ему вопросы, как резолвер того времени. При обычных именах ни один ответ этой конфигурации в 512 байт не упирался. Корневому серверу хватало места на пятнадцать серверов, а за пределом он молча выкидывал адреса, не ставя флаг усечения. Тринадцать получаются из расчёта FAQ с запасом под имя в вопросе. Стены на тринадцати в пакетах нет.

Как FAQ насчитал тринадцать

К 1993 году корневых серверов было восемь, с длинными именами вроде NS.INTERNIC.NET, KAVA.NISC.SRI.COM, AOS.BRL.MIL. В хронологии Шона Донелана на 21 апреля 1993 года стоит запись «Root server list UDP packet size limit exceeded». Тогда предел действительно мешал. В 1995-м серверы переименовали в a…i.root-servers.net: общий хвост пишется в пакет один раз, дальше на него ссылается двухбайтный указатель. В 1997 году добавили J, K, L и M, и серверов стало тринадцать.

FAQ считает так: заголовок 12 байт, первая NS-запись 31, двенадцать сжатых NS по 15, тринадцать A-записей по 16, тип и класс вопроса 4. Итого 435 байт, и 77 остаётся на имя в вопросе. Под имя FAQ откладывает 64 байта и пишет, что «adding another server would require 25 bytes, and since 435 + 64 + 25 > 512» серверов больше не добавляли. Запас под имя нужен, по FAQ, потому что те же серверы отвечали за .COM, .NET и .ORG, а в ответе про example.com в пакет попадает и само имя из запроса.

По таблице самого FAQ сервер стоит 15 + 16 = 31 байт, хотя в тексте сказано 25. На вывод это не влияет. Важнее другое: это расчёт модели, и как вёл себя настоящий сервер, FAQ не пишет.

Корневой сервер 1997 года в контейнере

Серверное ПО того времени нашлось в архиве Debian: пакет BIND 8.1.2 из Debian 2.0 «hamm» вместе с libc 1998 года. В том же пакете лежит named.root с пометкой «last update Aug 22, 1997, related version of root zone 1997082200»: все тринадцать серверов A–M с адресами того лета. Контрольные суммы пакетов — в конце статьи.

Корни 1997 года в основном работали на BIND 4.9.x. Его я тоже скачал (Debian 1.3 «bo», BIND 4.9.7), но этот бинарник под libc5 в моём контейнере не запустился. Поэтому сервер в проверке на год моложе событий.

Вторую половину конфигурации пришлось восстанавливать по документам. Снимка корневой зоны до 1999 года я не нашёл: Wayback Machine хранит с rs.internic.net только страницы и named.root, архив DNS-OARC начинается с июня 1999-го. Кто держал .COM, видно из двух независимых записей. В RSSAC023 сказано, что J–M обслуживали «the root zone exclusively». У Донелана: «root only root name servers J and K added» 22 января 1997 года, L и M — 28 февраля, а H и I в том же году несколько раз «теряют зону COM», то есть держали её. Отсюда моё допущение: .COM, .NET и .ORG обслуживали девять серверов, A–I. Полного списка ни один документ не даёт, но так я и настроил зону.

Запросы шли без EDNS и без рекурсии, как от резолвера тех лет. Чтобы найти предел, я добавлял в зону лишние корневые серверы с адресами из документационной сети 198.51.100.0/24.

Что отдал сервер

ответ                               серверов  имя в вопросе  байт  адресов   TC
priming '. NS'                          13          1         436   13 из 13  нет
priming                                 15          1         498   15 из 15  нет
priming                                 16          1         497   14 из 16  нет
priming                                 17          1         496   13 из 17  нет
J–M: реферал на имя в .com (A–I)         9         64         387    9 из 9   нет
то же                                    9        128         451    9 из 9   нет
то же                                    9        255         498    4 из 9   нет

Priming-ответ тринадцати корней занял 436 байт, ровно как в таблице FAQ. Пятнадцать серверов влезли целиком. На шестнадцатом BIND не отказался отвечать и не поставил TC: он отдал все шестнадцать NS-записей и выкинул два адреса из раздела Additional. Это не баг: RFC 2181 того же 1997 года прямо говорит, что TC не ставят, если не влезла только дополнительная информация.

Реферал от J–M на имя внутри .com несёт NS-набор зоны com и имя из запроса. С девятью серверами A–I он влезает целиком до имени в 128 байт. При имени в 200 байт адресов остаётся семь из девяти, при 255 — четыре, и TC сервер не ставит и тут.

Где модель FAQ расходится с сервером

Чтобы проверить саму модель, я раздал .COM всем тринадцати серверам, как подразумевает FAQ, и спросил имя длиной 64 байта. По FAQ должно выйти 499 байт со всеми адресами. Сервер отдал 499 байт, но адресов в нём двенадцать.

Разница в мелочи, которую модель не учитывает. FAQ считает владельцем каждой NS-записи корень, а это один байт. У реферала про .com владелец — com. Даже с двухбайтным указателем каждая запись дороже на байт, и в моей офлайн-сборке на dnspython такой пакет выходит ровно в 512. BIND 8.1.2 к тому же пишет первое COM целиком (03 43 4f 4d 00), хотя мог сослаться на хвост имени из запроса. Это ещё три байта, тринадцатый адрес уже не помещается. В пакетах реального сервера полный реферал с 64-байтным именем выдерживает двенадцать серверов.

Так откуда тринадцать

В пакетах сервера той эпохи число тринадцать не совпадает ни с одной границей. Priming-ответ держал пятнадцать серверов. Реферал .com с запасом FAQ держал двенадцать. С восстановленным набором .com из девяти серверов реферал влезал целиком до имени в 128 байт, а при 200 байтах уже терял адреса. За пределом сервер всё равно отвечал, без TC и без части адресов.

Стена в 512 байт была в 1993 году, со старыми длинными именами. RSSAC023 пишет, что к апрелю 1993-го ответ «was approaching the limit», у Донелана предел уже «exceeded». По RSSAC023, переименование оставило место ещё для четырёх серверов. Priming-ответ на сервере 1998 года оставлял его для шести. Четыре совпадают с моделью FAQ, где место откладывают под имя в вопросе. Мотивов решения в пакетах не видно, но по ним тринадцать похоже на запас, который взяли люди, помнившие 1993 год. Объяснение «четырнадцатый не влезал» пакеты сервера той эпохи не подтверждают.

Оговорки. BIND 8.1.2 собран в 1998 году, корни работали на 4.9.x. Какие адреса выкинуть, решает именно эта версия. Состав .COM восстановлен по двум документам, снимка зоны у меня нет.

Проверка 22 октября 2026 года в одноразовом контейнере: python:3.15-slim, BIND 8.1.2 и libc6 2.0.7 из Debian hamm, клиент dnspython 2.9.0. SHA-256: e65fc870c8f7aeab… (bind_8.1.2-3.deb), 8f97a359678ad21b… (libc6_2.0.7t-1.deb).