Мне всегда было интересно, как спроектирована инфраструктура DNS для (скажем, .com) TLD. Она должна не только поддерживать высокий уровень надежности, но и поддерживать большое количество обновлений записей в реальном времени.
Я бы предположил, что на этом уровне используется BIND от ISC. У меня есть довольно четкое представление о том, как кто-то может построить масштабируемую инфраструктуру с использованием BIND. Часть, которая мне не ясна, заключается в том, как кто-то может спроектировать систему, которая может обрабатывать добавление, удаление и изменение сотен зон DNS каждые несколько секунд. В мире бесчисленное множество регистраторов доменов, и только .com, вероятно, видит огромный объем активности. Как система, построенная на файлах зон BIND, масштабируется до такого большого количества изменений?
Прав ли я, сомневаясь, что оператор TLD использует текстовые файлы и постоянно заставляет BIND перезагружать изменения каждый раз при регистрации нового .com? Если да, то что они делают? Это база данных SQL или LDAP? Это вообще масштабируется?
решение1
Во-первых, вы действительно думаете, что в мире больше обновлений, чем, скажем, транзакций по кредитным картам в секунду, и что в конечном итоге это делают всего 2 или 3 компании? Они работают, так что это решаемая проблема :-)
Во-вторых, вы можете быть сбиты с толку относительно того, как происходят обновления, поскольку это не часто понимаемая часть, где пересекаются две плоскости: плоскость регистрации и плоскость публикации. Вы также можете быть сбиты с толку относительно того, что именно происходит на серверах имен реестра (только поддержание записей NSдля делегирования доменов, а НЕ полного содержимого этих зон).
Но прежде чем углубляться в это, вы также, кажется, предполагаете, что обновления должны быть в режиме реального времени, когда они оба не нужны и часто не являются таковыми. В любом случае, в DNS нет ничего в режиме реального времени из-за TTL.
Итак, вернемся к вашим двум самолетам:
- Регистраторы отправляют обновления в реестры при изменении серверов имен и других операциях, которые имеют побочные эффекты DNS (например, настройка
clientHoldстатуса EPP); это плоскость регистрации, она совершенно НЕ СВЯЗАНА с публикацией DNS и обычно использует протокол EPP; когда реестр отвечает «обновление принято», это совершенно не означает, что оно уже опубликовано в их инфраструктуре DNS, это просто гарантия того, что «это будет в какой-то момент». - Реестры поддерживают плоскость публикации DNS, гарантируя, что их серверы имен публикуют правильные
NSзаписи для всех делегирований, т. е. всех доменов, зарегистрированных в управляемых ими TLD.
Таким образом, количество изменений, вероятно, гораздо меньше, чем вы себе представляете: если владелец .comизменяет содержимое своей зоны, добавляя новые записи, в большинстве случаев регистратору ничего делать не нужно, и на авторитетных серверах имен реестра ничего не меняется.
И эти изменения НЕ происходят через механизм обновления DNS. Изменения вносятся регистраторами с использованием специального протокола EPP, изменения каким-то образом сохраняются в какой-то базе данных реестра, после чего новые данные публикуются реестром на его авторитетных серверах имен.
Вы, кажется, также считаете, что "в реальном времени" является обязательным. Это не так, по крайней мере, технически, и может быть даже неэффективным дизайном (подумайте, хотите ли вы провести тесты, чтобы новые изменения имели смысл, как это делают некоторые реестры, проверяя, что серверы имен имен правильно настроены для разрешения имени, для которого они вскоре будут указаны как авторитетные, или тесты DNSSEC, например...).
Типичный способ настройки, используемый многими реестрами, предоставляющими такие возможности, как «задержка обновлений в 10 минут» или «задержка в 1 час», заключается в сохранении в некотором внутреннем буфере всех изменений, запрошенных за данный период времени, а затем в раз и навсегда создании новой зоны и ее публикации с одновременным запуском нового буфера для сбора всех изменений, которые поступят в следующий период.
Я предполагаю, что на этом уровне используется BIND от ISC.
Вовсе нет. Verisign использует собственное программное обеспечение для серверов имен, называемое Atlas. См. напримерhttps://www.enterpriseappstoday.com/news/verisign-accelerates-dns.html Обратите внимание, что в этой статье 2004 года уже говорилось:
VeriSign Naming and Directory Services (VNDS) обещает обновить основные 13 .com и .net авторитарных серверов имен менее чем за пять минут. Текущая скорость составляет около двух раз в день.
Конечно, с тех пор стало лучше. Но я считаю, что даже раз в 5 минут будет вполне достаточно для любого реального практического использования DNS.
Также могут быть договорные обязательства, и в частности для реестров gTLD и регистраторов, которые все находятся в рамках контракта с ICANN. Текущий контракт Verisign-ICANN находится наhttps://www.icann.org/en/registry-agreements/details/com Вы можете найти в §6.6 приложения по адресуhttps://www.icann.org/en/registry-agreements/com/com-registry-agreement-appendix-7-1-12-2012-enПодробная информация об ограничениях обновления:
6.6 Частота обновления. Оператор реестра своевременно обновляет данные на серверах имен DNS и Whois. Регистраторы, аккредитованные ICANN, регистрируют эти обновления через SRS. Затем SRS обновляет сервер имен DNS и Whois. Оператор реестра обрабатывает эти обновления практически в режиме реального времени.
Обязательная спецификация производительности в отношении частоты обновления как для DNS Name Server, так и для Whois составляет 3 минуты для 95% транзакций в течение ежемесячного периода. То есть, 95% обновлений DNS Name Servers и Whois в течение ежемесячного периода будут завершены в течение 3 минут. Частота обновления измеряется с момента, когда оператор реестра подтверждает обновление, до момента, когда обновление появляется в DNS Name Server и Whois. Показатели частоты обновления будут ежемесячно сообщаться ICANN в соответствии с Приложением 4.
Обратите внимание на обычную отметку в "95%", используемую для многих SLA. Так что это близко к реальному времени, когда это осуществимо, но на практике обычно 3 минуты (отсюда и типичная настройка буфера, описанная выше).
У меня есть довольно ясная картина того, как кто-то может построить масштабируемую инфраструктуру с использованием BIND. Часть, которая мне не ясна, заключается в том, как кто-то может спроектировать систему, которая может обрабатывать добавление, удаление и изменение сотен DNS-зон каждые несколько секунд.
У Verisign всего пара зон: .com, .net, несколько IDN и т. д. Они не управляют "сотнями зон". И уж точно не сотнями из них с множеством изменений каждую секунду.
Вы можете/хотите быть более заинтересованы в DNS-провайдерах, которые размещают миллионы зон с возможной высокой частотой обновлений. Вот одна статья от CloudFlare, где они объясняют, что они делают с точки зрения производительности относительно их авторитетного DNS-сервиса:https://blog.cloudflare.com/how-we-made-our-dns-stack-3x-faster/
В мире существует бесчисленное множество регистраторов доменов.
Нет, не все. Далеко не бесчисленное множество. Менее 2000 на самом деле, и, вероятно, только около 500 действительно активны с большими объемами изменений. Все регистраторы gTLD должны быть аккредитованы ICANN. Вы можете найти их полный список наhttps://www.icann.org/en/accredited-registrars
Прав ли я, сомневаясь, что оператор TLD использует текстовые файлы и постоянно заставляет BIND перезагружать изменения каждый раз при регистрации нового .com?
Никакое разумное программное обеспечение сервера имен транзакций высокого уровня не будет поддерживаться текстовыми файлами. Даже Bind не поддерживает: когда включены динамические обновления, у вас есть файл "журнала" (который является двоичным), и вам определенно не следует редактировать текстовую версию файла зоны (без предварительной заморозки обновлений и последующего их повторного разрешения после редактирования).
Если да, то что они делают? Это база данных SQL или LDAP? Это вообще масштабируется?
Я сомневаюсь, что SQL или LDAP являются хорошими движками хранения для DNS. Помните, что DNS иерархичен по своей природе, что накладывает различные ограничения.
решение2
Прежде всего, в некоторых случаях вам не нужно немедленно перезаряжаться.
Если у вас есть SLA, в котором говорится: «заплатите нам, и ваш домен будет зарегистрирован в течение X часов», вы даже можете периодически перезагружать его с помощью какой-нибудь cron-задачи или чего-то подобного. Поэтому некоторые регистраторы могут использовать плоские файлы и периодически перезагружать его.
Имейте в виду, что у вас может быть несколько DNS-серверов, связанных с одним и тем же IP-адресом (например, с помощью anycast), поэтому вы даже можете настроить механизм «последовательного развертывания», который изменяет плоский файл везде и перезагружает один DNS-сервер за раз.
При этом Bind >9 поддерживает DLZ (динамически загружаемые зоны), что по сути позволяет Bind использовать базу данных в качестве бэкэнда данных зоны. Базы данных (и соединения с базами данных) затем можно масштабировать в соответствии с классическими стратегиями масштабирования баз данных, если у вас есть действительный драйвер DLZ для вашей базы данных.
Наконец, как было сказано в одном из комментариев, помогает вертикальное масштабирование (т. е. наличие большого количества ЦП, ОЗУ и IOPS для каждого сервера).
Есть 2009 годСАНОГслайд может показаться вам интересным, хотя он, очевидно, немного устарел:https://www.sanog.org/resources/sanog14/sanog14-devdas-dns-scalability.pdf