Это ожидаемое поведение, которое уменьшает количество необходимых обменов и характерно для записи 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 будут возвращены в ответе на типЗапрос, в то время как тип 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.