В чем разница между `dig` и` host` при запросе определенного сервера имен?

Я использовал эту команду, чтобы проверить, правильно ли я все настроил с поставщиком DNS:

host hostname.example.com ns1.example-nameserver.com

Насколько я могу сказать, это просит ns1.example-nameserver.comпосмотреть hostname.example.comи сообщает ответ. Я получал ответ "не найден хозяин", поэтому подумал, что сделал это неправильно. Однако, без указания их имя-сервера (что позволяет имя-сервера моего провайдера , чтобы посмотреть его) , я получил правильный ответ ( hostnameявляется CNAMEли это имеет значение). Я не мог понять это, поэтому я искал вокруг и нашел digкоманду:

dig @ns1.example-nameserver.com hostname.example.com

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

Мой вывод либо правильный, либо неправильный, если он правильный:

В чем разница между этими двумя методами поиска?

Если это не так:

Каковы мои недоразумения о DNS и hostи digкоманды , которые привели меня к такому выводу?

Пример вывода:

$ host cardiff.tzmchapters.org ns1.livedns.co.uk
Using domain server:
Name: ns1.livedns.co.uk
Address: 213.171.192.250#53
Aliases: 

Host cardiff.tzmchapters.org not found: 3(NXDOMAIN)

$ dig @ns1.livedns.co.uk cardiff.tzmchapters.org

; <<>> DiG 9.8.3-P1 <<>> @ns1.livedns.co.uk cardiff.tzmchapters.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23620
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;cardiff.tzmchapters.org.   IN  A

;; ANSWER SECTION:
cardiff.tzmchapters.org. 3600   IN  CNAME   ghs.google.com.

;; AUTHORITY SECTION:
google.com.     3600    IN  SOA ns1.livedns.co.uk. admin.google.com. 1354213742 10800 3600 604800 3600

;; Query time: 27 msec
;; SERVER: 213.171.192.250#53(213.171.192.250)
;; WHEN: Mon Apr 22 23:47:05 2013
;; MSG SIZE  rcvd: 128

— jhabbott
источник

в этом случае обе команды должны работать одинаково. Можете ли вы показать полный вывод каждой команды?

— Ренан

Обратите внимание, как digи hostотчет NXDOMAIN. С помощью digвы можете увидеть это в заголовке (5-я непустая строка вывода), и с hostэтим это более очевидно. NXDOMAINозначает, что домен не существует. И все же CNAMEвозвращается в разделе ответов! Я верю, что это ошибка в DNS-сервере!

— Селада

Таким образом, в этом случае отправляют ли оба пакета один digи hostтот же запрос, получают ли тот же самый ответный пакет (не считая отметок времени), но интерпретируют ли они его по-разному? Есть ли hostпод залог, как только он видит NXDOMAIN?

— Джабботт

У меня есть совершенно противоположная проблема на конкретном поддомене. Использование хоста на этом конкретном поддомене обеспечивает ожидаемую запись, показывающую, что этот конкретный поддомен преобразуется в ожидаемое каноническое имя хоста. Однако при использовании dig на этом конкретном поддомене - я получаю ответ, что запись не существует. Кроме того, переход на этот поддомен с помощью браузера не работает. Я пробовал несколько раз, проверяя ошибки орфографии и т. Д. Команды явно НЕ работают одинаково.

— user12345

Ответы:

host, digИ nslookupвсе разделяют большинство той же функциональности. В случае, о котором вы спрашиваете (задаете конкретный вопрос DNS конкретному серверу имен), digи host(и действительно nslookup) ведете себя точно так же.

Для устранения неполадок DNS digпредпочтительнее, потому что его выходной формат является более «сырым»: в его выводе он непосредственно показывает содержимое всех 4 полей в ответе DNS: вопрос, ответ, полномочия и дополнительные разделы (плюс флаги в заголовке) , а также у него есть больше вариантов. hostс другой стороны, имеет более удобный для пользователя формат вывода.

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

— Celada
источник

Если они делают то же самое на стороне сети (фактический запрос), как я могу получить хост не найден при использовании, hostно правильный ответ при использовании dig? Даже если сервер настроен с использованием определенного параметра (по выбору или случайно), чтобы вызвать это, он должен иметь возможность дифференцировать запросы.

— Джабботт

Нет! Две команды, которые вы даете в своем вопросе, эквивалентны, и они должны давать один и тот же ответ! Вы уверены, что digдали вам реальный ответ, а не запись в дополнительном или авторитетном разделе? Как предполагает Ренан , это может помочь показать результат.

— Селада

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

— Джабботт

Просто рассмотрев это - провайдер в конечном итоге сказал мне, что их сервер настроен так, чтобы он не отвечал на прямые клиентские запросы, а только на другие серверы имен, запрашивающие передачу информации - выполняет ли digзапрос другой способ, как сервер имен?

— Джабботт

dig может выполнять как обычные вопросы (все типы, кроме AXFR), так и переносы зон (тип AXFR), но операторы DNS обычно ограничивают перенос зон авторизованным ведомым, поэтому вы, скорее всего, захотите использовать обычные вопросы

— Celada

Если вы используете имя хоста, не являющееся полным доменным именем, результаты могут отличаться, потому что hostбудут использовать поисковые домены resolv.conf, а digне по умолчанию.

Вы должны использовать +searchопцию, если вы хотите digиспользовать resolv.conf(или добавить его ~/.digrc).

Например:

$ host foo
foo.myfqdn.com has address 10.1.2.3

$ dig +short foo
# (no result)

$ dig +short +search foo
10.1.2.3

— wisbucky
источник