У меня есть выделенный сервер на поддомене. Я хочу настроить поддомены как DNS. В основном я использую example.com в качестве основного домена моей компании. Я, вероятно, буду иметь более одного выделенного сервера и хочу, чтобы они были s1, s2 и т.п.
Я перенаправил server.example.com к другому провайдеру DNS через записи NS
server.example.com NS ns1.hostingcompany.example.com
server.example.com NS ns2.hostingcompany.example.com
И там я установил следующие записи:
servers.example.com NS ns1.hostingcompany.example.com.
servers.example.com NS ns2.hostingcompany.example.com.
s1.servers.example.com NS ns1s1.servers.example.com.
s1.servers.example.com NS ns2s1.servers.example.com.
ns1s1.servers.example.com A 192.0.2.1
ns2s1.servers.example.com A 192.0.2.2
s1.servers.example.com A 192.0.2.1
Но, servers.example.com нет записи А. Я пропустил его, так как хотел использовать его только как группировка Запись DNS.
Кажется, все работает, кроме моего локального сервера привязки в компании. Не распознает s1.servers.example.com и любой из поддоменов. Когда я переключаюсь на Google DNS, похоже, все работает нормально.
Вопрос в том, правильная ли эта настройка и будет ли она работать?
Примечание. Возможно, я не понимаю, как работают записи NS, насколько я понимаю, это когда NS-сервер существует в записи домена, указывая на другой DNS-сервер, который считается «Не спрашивайте меня, спрашивайте другой сервер», а записи A не являются необходимо в этой цепочке.
Ваша конфигурация верна, за исключением:
s1.servers.example.com A 192.0.2.1
Поскольку вы делегировали домен s1.servers.example.com другим серверам имен, их задача - определить эту запись. Исключение составляют приклеивать пластинки, который должен находиться в родительской зоне. Вы можете использовать их, чтобы дать более рациональное имя делегированным серверам имен:
s1.servers.example.com NS ns1.s1.servers.example.com.
s1.servers.example.com NS ns2.s1.servers.example.com.
ns1.s1.servers.example.com A 192.0.2.1
ns2.s1.servers.example.com A 192.0.2.2
Запись в общем случае не является обязательной, но хорошо, если она есть, по крайней мере, чтобы держать подсказку, как к ней добраться в случае поддомена (вам нужно знать, где находится ns1.sub.example.com который обрабатывает example.com - знаете, что было первым курица или яйцо? / вы не можете запросить ns1.sub.example.com, если вы еще не знаете о example.com :-)).
Должна быть SOA (Sпирог Озона f Аuthority) записи, и довольно часто, по крайней мере, NS (Nаме Server) запись. Технически NS необходим для делегирования, связанного с другим subdoamain, поскольку «важная» NS-запись для зоны расположена в верхней зоне (если вы запрашиваете NS, вы в конце запрашиваете непосредственно в зоне, но для ее достижения вы используете NS из верхней зоны).
Для воображения предположим, что эта структура (example.com, example.net и 192.0.2.0/24 предназначена для целей документации, а все остальное реально в системе DNS - конечно, сведено к одной из многих записей ...):
. (e.g. a.root-servers.net. - 198.41.0.4 ):
. IN SOA ...
. IN NS a.root-servers.net.
a.root-servers.net. IN A 198.41.0.4 ( <= this is HINT - how to reach it)
...
com. IN NS a.gtld-servers.net.
a.gtld-servers.net. IN A 192.5.6.30 ( <= this is HINT - how to reach it)
a.gtld-servers.net. IN AAAA 2001:503:a83e::2:30 ( <= this is HINT - how to reach it)
...
com. (e.g. a.gtld-servers.net. - 192.5.6.30 ) :
com. IN SOA ...
com. IN NS a.gtld-servers.net.
...
example.com. IN NS ns1.example.com.
ns1.example.com. IN A 192.0.2.10 ( <= this is HINT)
...
example.com ( ns1.example.com. - 192.0.2.10 ) :
example.com. IN SOA ...
example.com. IN NS ns1.example.com.
ns1.example.com. IN A 192.0.2.10
...
www.example.com. IN A 192.0.2.20
sub.example.com. IN NS ns1.sub.example.com.
ns1.sub.example.com. IN A 192.0.2.30 ( <= HINT to where to find NS server)
...
sub2.example.com. IN NS ns1.example.net. ( no HINT needed as it point out to other zone)
...
В этом примере есть согласованная информация для делегирования NS для example.com непосредственно в зоне и в верхней зоне.
example.com. IN NS ns1.example.com.
ns1.example.com. IN A 192.0.2.10
В случае, если он будет другим, это не проблема, но для поиска авторитетного сервера будет использоваться сервер из верхней зоны (com.), Но в случае регулярной рекурсии будет возвращена запись из зоны напрямую ... Так что что-то еще, кроме можно показать то, что используется технически. Это может быть проблемой, если вы переносите зону на другой DNS-сервер - пока прежний DNS-сервер не заработал, все в порядке и выглядит хорошо, но после выключения зона становится недоступной ...
«Верхняя» зона поддерживается через регистратора (обычно это какая-то веб-форма), но зона напрямую (ваша зона) поддерживается везде, где вы указываете NS-запись (сервер регистратора, сторонний сервер или ваш собственный DNS-сервер).
Чтобы увидеть запись в верхней зоне, вы можете использовать эту команду (в случае DNS-сервера example.com и com.):
dig +norec NS example.com @a.gtld-servers.net.
Чтобы получить содержимое зоны example.com, вы можете использовать (например, запрос общедоступного DNS-сервера Google):
dig NS example.com @8.8.8.8
В случае, если делегирование работает в целом, но не локально, я предполагаю, что вы локально определили зону DNS для example.com (например, чтобы получить внутренний IP-адрес вместо общедоступного), поэтому даже вы сделали делегирование NS для поддомена вашим локальным экземпляром зоны DNS example.com понятия не имеет об этом - вам также нужно добавить его туда.
Рядом с ним вам не нужно дополнительное делегирование NS для каждого поддомена. Если вам не нужен дополнительный DNS-сервер поддомена, даже «главный» DNS-сервер может его обработать.
Это действительное содержимое зоны для example.com
example.com IN SOA ...
example.com. IN NS ns1.example.com.
ns1.example.com. IN A 192.0.2.10
...
www.example.com. IN A 192.0.2.20
s1.servers.example.com. IN A 192.0.2.30
s2.servers.example.com. IN A 192.0.2.40
s3.servers.example.com. IN A 192.0.2.50
...
В случае необходимости делегирования достаточно "уровня" серверов:
example.com :
example.com IN SOA ...
example.com. IN NS ns1.example.com.
ns1.example.com. IN A 192.0.2.10
...
www.example.com. IN A 192.0.2.20
servers.example.com. IN NS ns1.servers.example.com.
ns1.servers.example.com. IN A 192.0.2.15
...
servers.example.com ( ns1.servers.example.com. - 192.0.2.15 ) :
servers.example.com. IN SOA ...
servers.example.com. IN NS ns1.servers.example.com.
ns1.servers.example.com. IN A 192.0.2.15
...
s1.servers.example.com. IN A 192.0.2.30
s2.servers.example.com. IN A 192.0.2.40
s3.servers.example.com. IN A 192.0.2.50
...
Так что, если вам не нужен дополнительный DNS-сервер для каких-то специальных целей непосредственно на s1.servers.example.com, эта запись из вопроса на самом деле не нужна:
s1.servers.example.com NS ns1s1.servers.example.com.
Если я серьезно не ошибаюсь, я вижу здесь две проблемы.
Первый тривиальный. Я пишу этот ответ через несколько часов после того, как вы разместили вопрос. Это означает, что новая конфигурация DNS, возможно, еще не распространилась по всей системе DNS. В зависимости от различных записей TTL в конфигурации домена это может занять день. Типичным этапом этого процесса является то, что одни DNS-серверы уже обслуживают новую информацию, а другие - старую.
Второй - ваша конфигурация. Я не понимаю, почему у вас есть следующие записи:
s1.servers.example.com NS ns1s1.servers.example.com.
s1.servers.example.com NS ns2s1.servers.example.com.
ns1s1.servers.example.com A 192.0.2.1
ns2s1.servers.example.com A 192.0.2.2
Насколько я понял ваш вопрос, s1.servers.example.com является не поддомен, а просто хост. Но вы относитесь к нему как к субдомену, поскольку вы явно делегируете его серверу имен. Это очень необычно, и вам, вероятно, следует пропустить эти четыре строки. Базовая структура должна быть такой:
Сообщите миру, какие серверы имен отвечают / уполномочены разрешать все имена, которые находятся в servers.example.com пространство имен. Вы сделали это с помощью первых двух строк, которые вы разместили в поле кода.
Затем просто добавьте записи (записи A) для всех ваших хостов в конфигурацию этих серверов имен. Если эти серверы имен не копируют друг друга, вам следует добавить соответствующие записи в обе из них. Вы сделали это для s1 последней строкой, которую вы разместили во втором поле кода.
Делать больше нечего. Лично я бы добавил дополнительную запись для servers.example.com сам, возможно, просто указывая на s1.servers.example.com, потому что опыт показывает, что люди воля попробуйте это имя хоста, и вы будете беспокоиться, если его не удастся разрешить.