dig возвращает неправильный тип записи

Question

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

$ dig -t A -q polestar.databaseguy.com.

; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> -t A polestar.databaseguy.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33130
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;polestar.databaseguy.com.      IN      A

;; ANSWER SECTION:
polestar.databaseguy.com. 3600  IN      CNAME   databaseguy.ddns.net.
databaseguy.ddns.net.   60      IN      A       173.19.127.251

;; Query time: 30 msec
;; SERVER: 10.0.10.1#53(10.0.10.1)
;; WHEN: Mon Dec 10 14:41:50 STD 2018
;; MSG SIZE  rcvd: 103

CNAME а также A записи, перечисленные в ANSWER SECTION верны. Тем не менее CNAME для polestar.databaseguy.com. и A для databaseguy.ddns.net., Здесь нет A запись дляpolestar.databaseguy.com., что я и просил, поэтому я ожидал, что не будет никаких результатов.

Я довольно уверен, что это правильное поведение, но я не понимаю его и не вижу никакого объяснения в man dig страницы. Я также не мог найти другие обсуждения в Интернете, ни на этом сайте, ни где-либо еще. Может кто-нибудь помочь мне понять это?

Answer 1

Это ожидаемое поведение, которое уменьшает количество необходимых обменов, и является специфическим для CNAME запись.

Он охватывается основными документами по DNS: RFC1034, раздел 3.6.2.

Видеть это:

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

С наглядным примером, который полностью соответствует вашему случаю:

Например, предположим, что сервер имен обрабатывал запрос для USC-ISIC.ARPA, запрашивал информацию типа A и имел следующие записи ресурсов:

USC-ISIC.ARPA   IN      CNAME   C.ISI.EDU

C.ISI.EDU       IN      A       10.0.0.52

Оба этих RR будут возвращены в ответе на запрос типа A, в то время как запрос типа CNAME или * должен возвращать только CNAME.

Смотрите раздел 5.2.2 для других вопросов. В разделах 6.2.7 и 6.2.8 также приведены примеры.

Это также зависит от того, запрашиваете ли вы рекурсивный или авторитетный сервер имен.

databaseguy.com имеет для серверов имен:

pdns01.domaincontrol.com.
pdns02.domaincontrol.com.

Если вы запросите один из них:

$ dig A polestar.databaseguy.com. @pdns01.domaincontrol.com.

; <<>> DiG 9.12.0 <<>> A polestar.databaseguy.com. @pdns01.domaincontrol.com.
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64115
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: e45ebc418c94c90a
;; QUESTION SECTION:
;polestar.databaseguy.com. IN A

;; QUERY SIZE: 65

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64115
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;polestar.databaseguy.com. IN A

;; ANSWER SECTION:
polestar.databaseguy.com. 1h IN CNAME databaseguy.ddns.net.

Вы получаете только значение CNAME, потому что этот авторитетный сервер имен знает только это и не является полномочным для ddns.net,

Но если вы спросите любого рекурсивного сервера имен, он выполнит работу рекурсии и даст вам "полный" ответ:

$ for ns in 1.1.1.1 8.8.8.8 9.9.9.9 80.80.80.80 ; do dig A polestar.databaseguy.com. @$ns +noall +ans ; done

; <<>> DiG 9.12.0 <<>> A polestar.databaseguy.com. @1.1.1.1 +noall +ans
;; global options: +cmd
;; connection timed out; no servers could be reached

; <<>> DiG 9.12.0 <<>> A polestar.databaseguy.com. @8.8.8.8 +noall +ans
;; global options: +cmd
polestar.databaseguy.com. 59m59s IN CNAME databaseguy.ddns.net.
databaseguy.ddns.net.   59s IN A 173.19.127.251

; <<>> DiG 9.12.0 <<>> A polestar.databaseguy.com. @9.9.9.9 +noall +ans
;; global options: +cmd
polestar.databaseguy.com. 1h IN CNAME databaseguy.ddns.net.
databaseguy.ddns.net.   1m IN A 173.19.127.251

; <<>> DiG 9.12.0 <<>> A polestar.databaseguy.com. @80.80.80.80 +noall +ans
;; global options: +cmd
polestar.databaseguy.com. 1h IN CNAME databaseguy.ddns.net.
databaseguy.ddns.net.   1m IN A 173.19.127.251

(1.1.1.1 не ответил на мой запрос, но это не имеет значения здесь для этого вопроса)

Так что насчет "Нет записи A forpolestar.databaseguy.com., О которой я и просил, поэтому я ожидал, что результатов не будет". это наполовину неправильно, потому что это имя имеет CNAME, что означает другое каноническое имя, и это каноническое имя имеет A запись, так что в конце дня это точно так, как если бы начальное имя имело A запись. Любое приложение, локально запрашивающее у ОС IP-адрес этого хоста, получит запись A, поскольку ОС позаботится о полном рекурсивном разрешении и "разыменовании" CNAME.