Как проверить, распространяется ли информация DNS?

16

Я установил новую запись DNS для одного из моих поддоменов (я еще не настроил виртуальные хосты Apache или что-то подобное). Как я могу проверить, что информация DNS распространилась?

Я предположил, что мог бы просто ping my.subdomain.comи предположить, что, если бы это могло разрешить, это показало бы IP-адрес, который я указал в записи A. Тем не менее, я не знаю, правильно ли я предполагаю. Каков наилучший способ проверить эту информацию?

domain-name-system 
— Андрей
источник
3
Не глупый вопрос. Это не так просто, чтобы узнать такого рода вещи.
— 2012 г.
1
Я согласен с @aseq, что это не глупый вопрос, но «попробуй и посмотри» тоже дал бы тебе ответ. Это также то, на что Google мог бы ответить так же легко с минимальными усилиями (поиск How to test if DNS information has propagated- кровавое название вопроса дает хорошие результаты Google).
— voretaq7
4
Я не думаю, что вы потратили время людей. Ваш вопрос вызвал некоторые ценные ответы. Вы никогда не знаете, как может получиться, казалось бы, простой вопрос, который можно «просто погуглить». Одна из ценностей этого форума заключается в том, что ответы и вопросы могут быть расширены очень легко.
— Aseq
1
@ и ничего плохого не спросил, что многие из нас считают простыми вопросами - это, вероятно, будет лучшим результатом Google для этой строки за несколько дней из-за того, как сайт будет проиндексирован / оценен. В целом, хотя Google - лучшее (более быстрое) место для поиска: если Google не знает, спросите здесь (и Google узнает) :-)
— voretaq7
1
Я понял, почему ничего, что я пробовал, не работало. По-видимому, наша сеть настроена таким образом, что новый поддомен должен быть добавлен и в наш локальный DNS. Таким образом, поддомен был доступен из внешнего мира, только не в нашей сети, где я тестировал. = [Но используя nslookupи digуказав внешний сервер, я смог проверить информацию внешнего DNS.
— Андрей

Ответы:

15

Вы можете использовать dig или nslookup, например, ваш (или ваш провайдер, если вы не запускаете свой собственный) сервер имен ns1.example.com.

Используя nslookup:

nslookup - ns1.example.com

По приглашению введите:

my.example.com

Если это решает то, что вы ожидали, то это работает. Это должно дать вам что-то вроде:

Name:   example.com
Address: 192.0.43.10

Это может все еще занять некоторое время, чтобы распространиться на остальную часть Интернета, это вне вашего контроля.

Используя dig:

dig@ns1.example.com my.example.com

Вы должны увидеть что-то вроде:

;; ANSWER SECTION:
example.com.        172800  IN  A   192.0.43.10

Простое использование ping может дать вам идею, но только тогда, когда она распространится (кэширование удаленными серверами имен может быть лучшим способом описать это), и ваш локальный DNS-кэш может нуждаться в очистке. Хотя в вашем случае это не относится, потому что это новая запись. В этом случае он должен быть доступен немедленно. Вышеупомянутый способ более точен в том, чтобы дать вам идею, а не просто проверить ее.

Если вы используете окна, то команды и синтаксис могут немного отличаться, но довольно похожи.

— aseq
источник
3
+1 Если вы что-то делаете с DNS, получите копию dig(* у систем nix она уже есть, есть разные версии для Windows).
— Крис С
3
-1. Мне жаль. Да, это так, но этот ответ «распространяет» миф о том, что DNS-записи распространяются, что они, безусловно, НЕ делают. Вы ищете термин «кеширование», что и происходит с записями DNS, основываясь на TTL записи. Поскольку OP ссылается на новую DNS-запись, кэширование не может произойти, поэтому любой DNS-клиент, пытающийся разрешить данную запись, получит ответ ... немедленно ..., поскольку он не мог быть кэширован этим клиентом. ... или этот DNS-сервер клиентов ... или любой другой DNS-сервер. Записи DNS не распространяются на «остальную часть Интернета».
— Joeqwerty
1
ДжоКверти абсолютно прав. DNS-серверы будут кэшировать положительное или отрицательное попадание в течение заданного времени. Тем не менее, в дополнение к исходному сообщению, есть несколько публичных серверов имен, с которыми вы можете проверить, включая старый GTE (4.2.2.1, 4.2.2.2, 4.2.2.3 и 4.2.2.4) и google (8.8.8.8, 8.8. 4.4). Простое эмпирическое правило, новые изменения могут занимать длительность ttl для положительного или отрицательного удара. Однако в некоторых случаях приложения реализуют неверную логику и кэшируют ответы в течение более длительного периода времени.
— Bangdang
2
Я не думаю, что вам действительно нужно придерживаться точного определения, чтобы понять смысл. Кроме того, я думаю, что распространение не плохое слово для использования. Он охватывает эту тему в том смысле, что кэширование записи DNS распространяется на более широкий круг серверов. Это распространение - это то, к чему относится распространение. Я обновил свой ответ, чтобы отразить тот факт, что новая запись доступна немедленно.
— Aseq
1
@aseq, это вводящий в заблуждение термин. И в основном получается, что люди, которые думают / говорят о DNS как о «распространении», не знают, как работает DNS. Как правило, они заявляют, что «распространение вашей информации DNS занимает 2–3 дня через Интернет / Землю» и так далее.
— Пой
7

Вы не можете проверить распространение DNS-записи, потому что распространение DNS не происходит. То, что вы можете проверить, является ли DNS-клиент или сервер кешируется конкретной записи DNS.

Поскольку это новая запись DNS, кэширование не может произойти. Предполагая, что ваши серверы имен правильно зарегистрированы на родительских серверах и что ваши серверы имен работают правильно, эта запись DNS должна быть немедленно доступна любому клиенту или серверу DNS.

— joeqwerty
источник
Рад помочь ...
— Joeqwerty
Можно ли проверить, что я ввел действительный IP-адрес? Я просто хотел убедиться, что IP-адрес, который я использовал, был правильным. Кто-то, с кем я говорил, казалось, думал, что ping потерпит неудачу, если у меня еще не настроен Apache VHost.
— Андрей
Пинг не является инструментом тестирования DNS. Dig и Nslookup являются инструментами тестирования DNS. Используйте Dig или Nslookup для проверки новой записи DNS. Запросите запись для вашего сервера имен, а затем запросите запись для других серверов имен, чтобы убедиться, что они находят ваш сервер имен и что ваш сервер имен отвечает правильным ответом.
— Joeqwerty
1
«Распространение» - это понятие, составленное в том случае, если люди не могут понять фактическую ситуацию, а именно старение и истечение срока действия кэша. DNS-провайдеры должны были сказать, что «ваши данные могут быть просмотрены только после XX часов». Объяснение, почему было необходимо, чтобы не было похоже, что провайдер DNS был задержкой. Слишком много людей "не могут справиться с истиной". Придуманная «пропаганда» - эффективная история прикрытия. Настоящие фанаты DNS знают, что на самом деле происходит, потому что они читают технические детали.
— Skaperen
Достаточно верно ... Я просто ненавижу использовать термин, который "распространяет" неправильное представление о том, как работает DNS.
— Joeqwerty
5

В то время как другие ответы довольно хороши, помните, что то, что передается вам, может не передаваться мне. Вместо того чтобы использовать DIG или NSlookup и тратить целый час на проверку DNS-серверов по всему миру, я обычно использую http://www.whatsmydns.net/, чтобы посмотреть, как идет распространение.

— Джим Б
источник
В DNS нет распространения, этот термин довольно вводит в заблуждение всех ламеров, которые не будут читать RFC, поэтому не используйте <strike> пропаганду </ strike>, пожалуйста. ;-D
— Пойдж
1
Конечно, в DNS есть распространение. RFC предполагают, что читатель понимает, что информация может распространяться, когда серверы выполняют поиск и кеширование. это особенно очевидно, когда ламеры читают RFC, а затем задаются вопросом, почему запись на их сервере не соответствует результатам поиска с другого сервера. Они обнаруживают, что распространение имеет определение «распространять широко» (что именно нужно проверять - распространение обновленных записей)
— Джим Б.
Ни распространение, ни распространение (кроме как от ведущего к подчиненному).
— Poige
Вероятно, это пережиток того времени, когда иногда потребовалось около суток, чтобы изменения, внесенные в домены .com, загружались на корневые серверы имен (еще тогда, когда .com был на корнях!)
— Cakemox
@ poige - спасибо за подтверждение вашего непонимания того, как работает DNS-кэширование. Я бы посоветовал прочитать RFC о том, как работает DNS, и, возможно, проверить сайт, на который я ссылался, на реальные примеры.
— Джим Б.
3

Самый простой способ убедиться, что ваши авторитетные DNS-серверы в пути делегирования отвечают правильно, это использовать dig +trace:

; <<>> DiG 9.7.3 <<>> +trace www.google.com a
;; global options: +cmd
.           80050   IN  NS  m.root-servers.net.
.           80050   IN  NS  f.root-servers.net.
.           80050   IN  NS  i.root-servers.net.
.           80050   IN  NS  h.root-servers.net.
.           80050   IN  NS  c.root-servers.net.
.           80050   IN  NS  k.root-servers.net.
.           80050   IN  NS  d.root-servers.net.
.           80050   IN  NS  g.root-servers.net.
.           80050   IN  NS  a.root-servers.net.
.           80050   IN  NS  b.root-servers.net.
.           80050   IN  NS  e.root-servers.net.
.           80050   IN  NS  l.root-servers.net.
.           80050   IN  NS  j.root-servers.net.
;; Received 509 bytes from 192.168.1.1#53(192.168.1.1) in 0 ms

com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  k.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
com.            172800  IN  NS  d.gtld-servers.net.
com.            172800  IN  NS  j.gtld-servers.net.
com.            172800  IN  NS  f.gtld-servers.net.
com.            172800  IN  NS  i.gtld-servers.net.
com.            172800  IN  NS  m.gtld-servers.net.
com.            172800  IN  NS  e.gtld-servers.net.
com.            172800  IN  NS  a.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
com.            172800  IN  NS  h.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
;; Received 504 bytes from 198.41.0.4#53(a.root-servers.net) in 127 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.43.172.30#53(i.gtld-servers.net) in 20 ms

www.google.com.     604800  IN  CNAME   www.l.google.com.
www.l.google.com.   300 IN  A   173.194.35.180
www.l.google.com.   300 IN  A   173.194.35.178
www.l.google.com.   300 IN  A   173.194.35.176
www.l.google.com.   300 IN  A   173.194.35.177
www.l.google.com.   300 IN  A   173.194.35.179
;; Received 132 bytes from 216.239.34.10#53(ns2.google.com) in 27 ms

Это будет следовать делегированиям на серверах имен, уполномоченных для вашего запроса. Последний ответ обычно является тем, который вас больше всего беспокоит, но трассировка полезна тем, что показывает, кто отвечает за каждую делегацию. Если вы меняете серверы имен, это может быть очень полезно.

Имейте в виду, что трассировка будет запрашивать авторитетные серверы напрямую, поэтому кэширование отсутствует. Это лучший показатель того, что ответы возвращаются, как и ожидалось, но это не является хорошим показателем того, что могут испытать конечные пользователи. Однако, поскольку вы все равно не всегда можете контролировать кэширующие серверы имен других людей (помимо предвидения понизить ваш TTL, дождаться исходного TTL, внести изменения, а затем восстановить TTL), обычно не стоит проверять этот факт.

— Cakemox
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.