Наша компания с нетерпением ждет возможности развернуть и поддерживать собственный публичный DNS. Я обрисовал деятельность по развертыванию, но немного запутался, где зарегистрировать доменное имя моей компании и как сопоставить мой публичный DNS. Пожалуйста, кто-нибудь объясните поток трафика.
решение1
Раньше я работал в реестре доменов и входил в рабочие группы IETF DNS, поэтому я дам вам основные сведения.
Система доменных имен разработана в иерархическом порядке. Когда вы ищете данные для доменного имени, вы обычно идете на самый верх и спускаетесь вниз.
На самом верху находится корень. Корневые серверы имен — это ряд серверов, разбросанных по всему миру, с которых всегда будет начинаться любой вопрос — если только данные не кэшированы, мы вернемся к этому позже. Как обычный пользователь, вы не увидите их в доменном имени, но они там есть.
Далее следуют домены верхнего уровня. Они делятся на общие домены верхнего уровня (такие как .com, .net или .movie) и домены верхнего уровня с кодом страны (такие как .us для США, .no для Норвегии или .cn для Китая).
После этого идут домены второго уровня. Это те, которые вы обычно покупаете как конечный покупатель. Например, если вы хотите владеть example.com, вы идете к регистратору, проверяете, доступен ли example.com, и если да, то добавляете его в корзину и нажимаете оформить заказ. Затем вы либо попросите регистратора или другую хостинговую компанию запустить ваш DNS для вас, либо вы настроите свои собственные DNS-серверы и попросите регистратора делегировать вам домен. Делегирование означает, что они зарегистрируют данные, которые будут говорить, что ваши DNS-серверы отвечают за этот домен.
После того, как вы станете владельцем домена, вы также сможете настроить домены третьего уровня или поддомены. Это добавит еще одну иерархию к DNS-серверам. Вы также можете настроить имена хостов, что для обычного пользователя будет выглядеть как одно и то же.
Итак, давайте рассмотрим средний DNS-поиск.
Допустим, вы хотите пойти вwww.example.com. Первое, что сделает ваш DNS-сервер, это обратится к корневым серверам, чтобы узнать, кто отвечает за .com. На вашем DNS-сервере уже есть встроенные адреса для корневых серверов, поэтому обычно нет необходимости их искать. Вместо этого мы ищем информацию для .com.
Я воспользуюсь программой «dig» здесь, но буду признателен за удобочитаемость вывода.
Сначала мы запрашиваем Name Servers (ns) для com. Мы запрашиваем это напрямую с сервера a.root-servers.net, который является одним из корневых серверов для системы DNS.
$ dig ns com. @a.root-servers.net.
Вывод выглядит следующим образом (опять же, сокращенно):
;; QUESTION SECTION:
;com. IN NS
;; AUTHORITY SECTION:
com. 172800 IN NS a.gtld-servers.net.
;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800 IN A 192.5.6.30
a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
РАЗДЕЛ ВОПРОСОВ показывает нам то, что мы запрашиваем, в данном случае записи NS для com.
РАЗДЕЛ AUTHORITY показывает нам, что root-server не несет ответственности за .com, но он сообщает нам, кто несет. В этом случае он сообщает нам, что a.gtld-servers.net несет ответственность.
Он также дает нам ДОПОЛНИТЕЛЬНЫЙ РАЗДЕЛ, содержащий записи адресов (A для IPv4 и AAAA для IPv6) для a.gtld-servers.net. Этот адрес называется Glue и не считается авторитетным ответом, но это подсказка, сообщающая нам, что это адрес, который был указан в системе. Glue-записи нужны, когда вам нужен IP-адрес сервера, к которому вы иначе можете получить доступ только с помощью поиска DNS, для чего вам нужен IP-адрес сервера имен. Все это немного рекурсивно.
В любом случае, давайте продолжим и найдем серверы имен для example.com. Теперь это будет немного отличаться от того, что вам скажет реальный DNS, но это пример, поэтому мы будем использовать пример данных.
$ dig ns example.com. @192.5.6.30
Мы запрашиваем IP-адрес a.gtld-servers.net, который мы получили выше. Они являются авторизованными для домена .com и, следовательно, должны быть в состоянии сообщить нам, какие серверы имен есть у example.com.
;; QUESTION SECTION:
;example.com. IN NS
;; AUTHORITY SECTION:
example.com. 172800 IN NS ns2.example.com.
example.com. 172800 IN NS ns1.example.com.
;; ADDITIONAL SECTION:
ns2.example.com. 172800 IN A 192.0.2.4
ns1.example.com. 172800 IN A 192.0.2.5
Теперь, вот почему этот клей важен. Поскольку серверы имен example.com находятся под example.com, они управляются серверами имен под example.com. По сути, вам говорят позвонить Бобу, чтобы узнать номер Боба, потому что только Боб знает номер телефона Боба. Склеивание — это подсказка. Боб мог изменить номер, но это то, что знают серверы имен для .com.
Теперь, когда мы знаем адрес серверов имен example.com, мы наконец можем запросить имя хоста.
$ dig a www.example.com. @192.0.2.4
;; QUESTION SECTION:
;www.example.com. IN A
;; ANSWER SECTION:
www.example.com. 300 IN A 192.0.2.10
Наконец-то у нас есть адресная запись дляwww.example.comhostname. Обратите внимание, что здесь нет ДОПОЛНИТЕЛЬНОГО РАЗДЕЛА, поскольку для этого запроса такой раздел не нужен. Мы задаем прямой вопрос и получаем точный ответ от сервера, который является полномочным для домена.
Теперь, делать все эти поиски постоянно - пустая трата времени и ресурсов, поэтому обычно ваш локальный DNS-сервер работает как кэш. Вы заметили, как выглядят все записи DNS? Поля в записи DNS следующие: Домен, Время жизни (TTL), Класс (в нашем случае IN для Интернета), Тип (A для адреса, NS для сервера имен и т. д.) и Данные (например, IP-адрес для записи A).
TTL в записи DNS — это то, как долго кэшу разрешено хранить данные. Записи, которые, как ожидается, не изменятся или изменятся очень редко, имеют большие TTL. Например, TTL в 172800 секунд в первых нескольких записях, которые мы рассматривали. Записи, которые могут обновляться в короткие сроки, имеют низкие TTL, например, TTL в 300 секунд дляwww.example.com.
Всякий раз, когда мы делаем поиск DNS, нам не нужно проходить весь путь до корневых серверов, если данные, которые мы уже ищем, кэшированы. Обычно мы постоянно обращаемся к доменам .com, поэтому данные почти всегда кэшируются на нашем локальном сервере DNS. Однако это означает, что всякий раз, когда вы меняете данные DNS, может потребоваться время для распространения изменений. На практике это означает, что вам нужно будет либо изменить TTL заранее, либо сказать своему боссу, что потребуется время, чтобы любые изменения полностью вступили в силу.
Чтобы зарегистрировать домен, вам обычно нужно обратиться к регистратору домена верхнего уровня, под которым вы хотите зарегистрироваться. Большинство хостинговых компаний и регистраторов доменов смогут регистрировать домены под несколькими различными доменами верхнего уровня, поэтому вы можете выбрать любой из них.
Регистраторы являются реселлерами Реестра. Реестр — это компания или организация, которая фактически управляет рассматриваемым доменом верхнего уровня, но как конечный пользователь, вам придется иметь дело только с Регистратором или даже просто с вашей хостинговой компанией.
У большинства регистраторов есть веб-интерфейсы, которые обрабатывают множество технических деталей делегирования и записей DNS, но даже в этом случае понимание основ DNS значительно облегчит вам жизнь, даже если вы полагаетесь на веб-интерфейс своего регистратора.
Если вы хотите узнать больше о DNS, и если вы работаете в сфере IT, вам действительно следует знать, как работает DNS, потому что это источник многих потенциальных проблем, я бы рекомендовал книгу DNS and Bind от O'Reilly. Она очень всеобъемлющая и сделает вас экспертом по DNS. Если вы хотите запустить свои собственные DNS-серверы, я настоятельно рекомендую вам прочитать эту книгу. Она охватывает программное обеспечение сервера Bind DNS, но те же принципы применимы к любому программному обеспечению DNS-сервера.