Наша компания надеется развернуть и поддерживать собственный общедоступный DNS. Я описываю действия по развертыванию, но немного не понимаю, где зарегистрировать доменное имя моей компании и как сопоставить мой общедоступный DNS. Пожалуйста, объясните поток трафика.
Раньше я работал в реестре доменов и входил в рабочие группы IETF DNS, поэтому я дам вам учебник.
Система доменных имен построена по иерархии. Когда вы ищете данные для доменного имени, вы обычно идете на самый верх и продвигаетесь вниз.
В самом верху находится корень. Корневые серверы имен - это несколько серверов, разбросанных по всему миру, с которых всегда начинается любой вопрос - если данные не кэшированы, мы вернемся к этому позже. Как обычный пользователь, вы не увидите их в доменном имени, но они там есть.
Далее идут домены верхнего уровня. Они делятся на общие домены верхнего уровня (например, .com, .net или .movie) и домены верхнего уровня с кодом страны (например, .us для США, .no для Норвегии или .cn для Китая).
После этого идут домены второго уровня. Это те, которые вы обычно покупаете как конечный покупатель. Например, если вы хотите владеть example.com, вы переходите к регистратору, проверяете, доступен ли example.com, и если да, то добавляете его в корзину и нажимаете «оформить заказ». Затем ваш DNS-сервер будет запускать регистратор или другая хостинговая компания, либо вы настроите свои собственные DNS-серверы, и регистратор делегирует вам домен. Делегирование означает, что они будут регистрировать данные, которые будут говорить, что ваши DNS-серверы отвечают за этот домен.
После того, как вы станете владельцем своего домена, вы также можете настроить домены третьего уровня или субдомены. Это добавляет еще одну иерархию к DNS-серверам. Вы также можете настроить имена хостов, которые для обычного пользователя будут выглядеть одинаково.
Итак, давайте посмотрим на средний поиск DNS.
Допустим, вы хотите пойти в www.example.com. Первое, что сделает ваш DNS-сервер, - это перейдет к корневым серверам, чтобы выяснить, кто отвечает за .com. На вашем DNS-сервере уже есть встроенные адреса корневых серверов, поэтому, как правило, нет необходимости их искать. Вместо этого мы ищем информацию для .com.
Я воспользуюсь программой "копать", но оцениваю вывод для удобства чтения.
Сначала мы запрашиваем серверы имен (нс) для 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.
РАЗДЕЛ АВТОРИТЕТА показывает нам, что корневой сервер не отвечает за .com, но он сообщает нам, кто именно. В этом случае он сообщает нам, что ответственность несет a.gtld-servers.net.
Он также дает нам ДОПОЛНИТЕЛЬНЫЙ РАЗДЕЛ, содержащий записи адресов (A для IPv4 и AAAA для IPv6) для a.gtld-servers.net. Этот адрес называется связующим и не считается авторитетным ответом, но это подсказка, говорящая нам, что это адрес, который был указан в системе. Связующие записи необходимы, когда вам нужен 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.com имя хоста. Обратите внимание, что здесь нет ДОПОЛНИТЕЛЬНОГО РАЗДЕЛА, потому что он не нужен для этого запроса. Мы задаем простой вопрос и получаем точный ответ от сервера, который является авторизованным для домена.
Теперь выполнение всего этого поиска постоянно - это небольшая трата времени и ресурсов, поэтому обычно локальный DNS-сервер действует как кеш. Вы заметили, как выглядят все записи DNS? Поля в записи DNS выглядят следующим образом: домен, время жизни (TTL), класс (в нашем случае IN для Интернета), тип (A для адреса, NS для сервера имен и т. Д.) И данные (например, IP-адрес для Запись).
TTL в записи DNS определяет, как долго кэш может хранить данные. Записи, которые, как ожидается, не изменятся или изменятся очень редко, имеют длительный TTL. Например, TTL 172800 секунд в первых нескольких записях, которые мы рассмотрели. Записи, которые могут быть обновлены в короткие сроки, имеют низкие значения TTL, например 300 секунд TTL для www.example.com.
Всякий раз, когда мы выполняем поиск в DNS, нам не нужно полностью обращаться к корневым серверам, если данные, которые мы уже ищем, кэшированы. Обычно мы постоянно обращаемся к доменам .com, поэтому данные почти всегда кэшируются на нашем локальном DNS-сервере. Однако это означает, что всякий раз, когда вы изменяете данные DNS, для распространения изменений может потребоваться время. На практике это означает, что вам нужно либо изменить TTL заранее, либо сообщить своему боссу, что потребуется время, чтобы любые изменения полностью вступили в силу.
Чтобы зарегистрировать свой домен, вы, как правило, захотите обратиться к регистратору домена верхнего уровня, под которым вы хотите зарегистрироваться. Большинство хостинговых компаний и регистраторов доменов смогут регистрировать домены под несколькими разными доменами верхнего уровня, поэтому вы можете выбрать любой из них.
Регистраторы являются торговыми посредниками для Реестра. Реестр - это компания или организация, которая фактически управляет доменом верхнего уровня, о котором идет речь, но как конечный пользователь, все, с чем вам нужно иметь дело, это Регистратор или даже просто ваша хостинговая компания.
У большинства регистраторов есть веб-интерфейсы, которые обрабатывают множество технических деталей делегирования и записей DNS, но даже в этом случае понимание основ DNS значительно облегчит вашу жизнь, даже если вы полагаетесь на веб-интерфейс своего регистратора.
Если вы хотите узнать больше о DNS, и если вы работаете в сфере ИТ, вам действительно следует знать, как работает DNS, поскольку он является источником множества потенциальных проблем, я бы порекомендовал книгу «DNS и привязка» от O'Reilly. Он очень всеобъемлющий и сделает вас экспертом в области DNS. Если вы хотите использовать свои собственные DNS-серверы, я настоятельно рекомендую вам прочитать эту книгу. Он распространяется на программное обеспечение Bind DNS-сервера, но те же принципы применимы к любому программному обеспечению DNS-сервера.