4

Я не вижу точного ответа на это в другом месте, поэтому я собираюсь быть смелым и спрашивать здесь. У меня есть линода и я установил запись DNS A для своего хоста, которую я назову A.wc.net. Когда я смотрю его с помощью nslookup на A.wc.net, я получаю такой ответ:

#  running on A.wc.net:  
root@linode (etc ): nslookup A.wc.net
Server:         173.255.243.5
Address:        173.255.243.5#53

** server can't find A.wc.net: NXDOMAIN

Однако с любой другой машины nslookup дает правильный результат:

@HomeMac (~ (BARE:master)): nslookup A.wc.net
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   A.wc.net
Address: 173.255.111.911  (number changed for my protection ;-) 

Кроме того, если я запускаю dig на хосте A.wc.net:

root@linode (etc ): dig @ns1.linode.com A.wc.net

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @ns1.linode.com A.wc.net
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55398
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 10
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;A.wc.net.                IN      A

;; ANSWER SECTION:
A.wc.net. 86400   IN      A       173.255.111.911  (number changed for my protection ;-) 

Мой вопрос, почему

nslookup A.wc.net

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

dig @ ns1.linode.com A.wc.net

на хосте A.wc.net сам выходит из строя?

1 ответ1

5

В этом ответе я делаю предположение: вы создали новую запись A для домена и сразу начали делать запросы из других систем.

Давайте посмотрим на то, что вы действительно спрашивали в каждом из трех примеров.

Пример 1: Вы попросили nslookup найти A-запись для A.wc.net , но вы не сказали nslookup, какой сервер имен использовать для поиска этой записи. По умолчанию ОС имеет некоторые значения по умолчанию. Nslookup сообщает, что для поиска используется сервер имен 173.255.243.5. Этот поиск не удается.

Пример 2: вы попросили nslookup на другом компьютере снова выполнить поиск A.wc.net не сообщая nslookup, какой сервер имен использовать. Это соединение использует Google DNS по умолчанию на 8.8.8.8. (личная рассылка} Google DNS работает быстро, но я отказываюсь предоставлять Google больше информации обо мне, чем им нужно знать. {/personal rant } Google ответила вам и сказала, что она также не является официальным DNS для этого домен - это, по сути, ~ простыми словами ~ говорит: этот сервер имен не является полномочием для этого домена, вот ответ для вас, однако моя запись может быть кэширована, может быть более свежая запись на официальном DNS для этого домена. (Полное объяснение авторитетных / неавторизованных ответов и т. д. действительно выходит за рамки вашего вопроса, но быстрый ответ таков: авторитетные серверы имен - это серверы имен, которые вы задали для использования доменом. В случае с wc.net в то время Я выкладываю этот ответ. Серверы имен wc.net - это UDNS2.ULTRADNS.NET и UDNS1.ULTRADNS.NET и они предоставят достоверные ответы, если вы скажете dig или nslookup использовать любой из этих серверов для запроса).

Пример 3: вы попросили dig использовать @ns1.linode.com для поиска A.wc.net и он нашел A-запись и передал ее вам. На этот раз мы получили одну дополнительную информацию TTL или Time-To-Live, которая установлена на 86400 секунд или 24 часа.

Значение этого заключается в том, что неавторизованные серверы имен, которые обрабатывают запросы (и во всех трех примерах, которые вы использовали неавторизованные серверы имен для wc.net), сначала будут искать в своем собственном кэше, чтобы узнать, знает ли он уже ответ с истекшим сроком действия. на вопрос, если это произойдет по соображениям скорости и пропускной способности, он вернет ответ, который он кэшировал. TTL 24 часа говорит ~ если эта кэшированная запись менее 24 часов, то это ответ, в противном случае сделайте запрос к вышестоящему DNS-серверу для более новой записи.~ В наше время этот исходный запрос часто направляется непосредственно к авторитетному серверу имен, но может закончиться кэшированным ответом некоторых других серверов имен - опять же, это выходит за рамки вашего вопроса, но сложность заключается в том, что он может расширить время кэширования, если сервер имен не настроен должным образом для принятия оставшегося TTL в вышестоящем кэше, который ответил.)

Выводы: внесение изменений в существующую A-запись, как правило, станет доступным со всех DNS-серверов по всему миру в течение следующих 86400 секунд (24 часа), если требуется более прямой ответ, найдите авторитетные серверы для домена и сделайте nslookup или копайте запрос с использованием одного из них. (в продвинутых случаях субдомены могут на самом деле иметь свои собственные авторитетные серверы имен «отличающийся от основного домена», опять же за рамками.)

whatsmydns.net - это инструмент, который вы можете использовать для наблюдения за распространением или скоростью ваших изменений DNS по всему миру. Зеленые чеки и красные X показывают ответ различных DNS-серверов по сравнению с официальным ответом. Помните, что whatsmydns.net не имеет всех имен в мире на своей карте, поэтому даже все зеленые проверки могут означать, что все еще есть серверы с кэшированной записью. Используя этот инструмент, вы обнаружите, что НОВЫЕ записи распространяются по Интернету или более быстро, измененная запись может занять TTL-секунды, чтобы быть удаленным. Мы должны сказать "может", потому что на самом деле это может быть больше или меньше, но, вероятно, меньше.

Итог: не внося дополнительных изменений в A-запись для A.wc.net дождитесь TTL в течение 24 часов и повторите ваши запросы, к тому времени большинство ответов должны быть правильными.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .