Назад | Перейти на главную страницу

DNS NS Redirect

Я наткнулся на кое-что интересное, чего никогда раньше не видел, и надеялся, что кто-нибудь сможет объяснить то, что я вижу.

Вот сценарий: у меня есть домены testdomain.com файл зоны, размещенный у поставщика DNS с именем SummitNetworks. Со своей стороны, у меня есть домен, размещенный на GoDaddy, который называется mycustomdomain.com. В пределах mycustomdomain.com У меня есть клей для ns2.mycustomdomain.com это указывает на сервер имен в summitnetwork.

Теперь я сказал summitnetworks что я хочу зону, которую они размещают для меня, testdomain.com указать на NS-сервер ns2.mycustomdomain.com. Причина этого в том, что в будущем, если я решу перенести эту зону на нового поставщика DNS и целую кучу других доменов, мне нужно будет только обновить связующую запись NS на mycustomdomain на новый IP-адрес сервера имен DNS-провайдера.

Теперь вопрос в том, когда я делаю раскопки и поиск по зонам testdomain.com серверы NS указывают на summitnetworks NS-серверы, но реферальный путь указывает на ns2.mycustomdomain.com. Как это возможно и как я могу увидеть полный путь разрешения с помощью dig? Что такое реферальный путь? Когда я копаюсь в домене, на него нет ссылки. Единственный способ проверить это - я использовал dnsstuff toolbox

На ваш вопрос трудно ответить без реальной информации, но ваши доводы в пользу использования серверов тщеславия не имеют для меня смысла, когда вы меняете NameServers, которые вы действительно хотите смени свои серверы имен, а не связующие записи, вы также хотите, чтобы ваша SOA была реальным сервером имен, а не связующей записью.

Я думаю, что происходит следующее: NS-запись регистратора для example.com отличается от NS-записей зоны.

dig example.com

Корневые серверы отправляют вас на серверы com, серверы com отправляют вас на серверы имен, указанные в вашем регистраторе (godaddy), но на этих серверах нет ваших тщеславных серверов имен, у них есть настоящие серверы имен, которые (хотя и те же IP-адреса) отсылает вас к A Record реальных серверов имен.

Итак, снова ns1.example.com, ns2.example.com ваш сервер имен с register.com.

но зона говорит что-то вроде

@ IN NS ns3.example.com
@ IN NS ns4.example.com

Даже если ns1.example.com и ns3.example.com - это одна и та же IP-запись, dns не знает об этом, он видит, что ns3 не ns1, поэтому он обращается к ns3 для получения достоверного ответа.

Мы можем подтвердить это реальной информацией.

Если вы хотите использовать тщеславные серверы имен, я бы посоветовал сохранить ваш DNS в Godady.

Спасибо, Джейкоб, за то, что нашел время и помог мне с этим; если бы мог, я бы дал вам +100 баллов за это :).

Я смог отследить свой ответ с помощью некоторых инструментов и логики DNS. Итак, первая проблема, с которой я столкнулся, заключалась в том, что когда я запускал dig www.example.com +trace на моем Mac абсолютно ничего не появлялось. Сначала я подумал, что это проблема с доменом, но попробовал другие домены и получил такие же пустые результаты. Итак, я сказал, позвольте мне попробовать другой компьютер, и вуаля, я смог пройти полную трассировку для разрешения DNS, которая показывает ответ.

По сути, произошло следующее ... Когда testdomain.com был зарегистрирован в DNS Registrar, люди, которые зарегистрировали домен, указали серверы имен для перехода на ns1 & ns2.mycustomdomain.com как им было сказано. Этот процесс происходил для пары сотен доменов. Люди, которые владеют mycustomdomain.com создали серверы тщеславия с связующими записями, указывающими на поставщика хостинга DNS.

След раскопок показал следующее

  1. Первый шаг - запросите корневые DNS-серверы, чтобы определить, с каким доменом верхнего уровня разговаривать.
  2. Второй шаг - запросите DNS-сервер домена верхнего уровня, чтобы узнать, кто уполномочен testdomain.com
  3. 1-й результат - найдены серверы имен, которые могут отвечать на запросы. ns1 & ns2.mycustomdomain.com
  4. 2-й результат - потому что эти клейкие записи фактически указывают на серверы NS @ summitnetworks.com получаем дополнительный ответ с серверами имен ns1 & ns2.summitnetworks.com - примечание на полях, если бы у нас не было этих клейких записей, раскопки закончились бы на пункте 3.

Теперь перенос этих доменов и всех будущих доменов будет на AWS Route 53. Файлы зоны, которые я получу от summitnetworks.com конечно будет включать их серверы SOA и NS. Когда вы импортируете свой домен в Route53, они удаляют SOA и серверы имен, поскольку теперь они владеют этой частью. Поскольку я выполняю большой переход на AWS, я собираюсь создать Набор делегаций чтобы у меня были одни и те же серверы имен для каждого домена, который я создаю в AWS. Это сделает так, что все, что нам нужно сделать, это обновить связующие записи для наших серверов тщеславия, чтобы они указывали на серверы AWS, и добавить еще 2 связующие записи для большей надежности.

Надеюсь, это поможет любому, кто столкнется с этим.

Образец dig www.google.com +trace так что вы можете следовать по пути разрешения:

;; global options: +cmd
.           518400  IN  NS  D.ROOT-SERVERS.NET.
.           518400  IN  NS  E.ROOT-SERVERS.NET.
.           518400  IN  NS  F.ROOT-SERVERS.NET.
.           518400  IN  NS  G.ROOT-SERVERS.NET.
.           518400  IN  NS  H.ROOT-SERVERS.NET.
.           518400  IN  NS  I.ROOT-SERVERS.NET.
.           518400  IN  NS  J.ROOT-SERVERS.NET.
.           518400  IN  NS  K.ROOT-SERVERS.NET.
.           518400  IN  NS  L.ROOT-SERVERS.NET.
.           518400  IN  NS  M.ROOT-SERVERS.NET.
.           518400  IN  NS  A.ROOT-SERVERS.NET.
.           518400  IN  NS  B.ROOT-SERVERS.NET.
.           518400  IN  NS  C.ROOT-SERVERS.NET.
;; Received 496 bytes from 172.16.0.2#53(172.16.0.2) in 8 ms

com.            172800  IN  NS  m.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
com.            172800  IN  NS  k.gtld-servers.net.
com.            172800  IN  NS  j.gtld-servers.net.
com.            172800  IN  NS  i.gtld-servers.net.
com.            172800  IN  NS  h.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
com.            172800  IN  NS  f.gtld-servers.net.
com.            172800  IN  NS  e.gtld-servers.net.
com.            172800  IN  NS  d.gtld-servers.net.
com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
com.            172800  IN  NS  a.gtld-servers.net.
;; Received 492 bytes from 198.41.0.4#53(198.41.0.4) in 100 ms

google.com.     172800  IN  NS  ns2.google.com.
google.com.     172800  IN  NS  ns1.google.com.
google.com.     172800  IN  NS  ns3.google.com.
google.com.     172800  IN  NS  ns4.google.com.
;; Received 168 bytes from 192.26.92.30#53(192.26.92.30) in 99 ms

www.google.com.     300 IN  A   216.58.192.4
;; Received 48 bytes from 216.239.38.10#53(216.239.38.10) in 13 ms

Вот несколько хороших ресурсов DNS для тех, кому нужно обновление. Конечно, обновил свой DNS за год :)