dig (и другие инструменты) возвращают только записи A

Я ' Мы пытались выяснить, почему методы PHP getmxrr () и checkdnsrr () не возвращаются успешно для рабочих доменов в ряде бродячих виртуальных машин, которые я использую.

Когда Изучая это дальше, я попытался использовать простые команды dig и получил ОТВЕТ только для записей A . Все остальное ничего не возвращает.

В качестве примера вот «правильный» раздел ОТВЕТА на ЛЮБОЙ запрос, показывающий все записи для этого домена для примера (с сервера, размещенного на AWS) . Вы можете видеть, что это как минимум NS , TXT , A и MX записи:

Debian AWS VM:

$ dig reiss.com ANY 

; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> reiss.com ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65366
;; flags: qr rd ra; QUERY: 1, ANSWER: 20, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;reiss.com.         IN  ANY

;; ANSWER SECTION:
reiss.com.      55  IN  NS  ns2.dnsmadeeasy.com.
reiss.com.      55  IN  NS  ns3.dnsmadeeasy.com.
reiss.com.      55  IN  NS  ns4.dnsmadeeasy.com.
reiss.com.      55  IN  NS  ns0.dnsmadeeasy.com.
reiss.com.      55  IN  NS  ns1.dnsmadeeasy.com.
reiss.com.      55  IN  MX  1 reiss-com.mail.protection.outlook.com.
reiss.com.      55  IN  TXT "v=spf1 ip4:212.49.201.210 ip4:80.168.187.225 ip4:109.68.12.42 ip4:79.125.20.120 ip4:46.51.172.2 ip4:46.51.172.4 include:spf.protection.outlook.com include:spf.mandrillapp.com -all"
reiss.com.      55  IN  TXT "loaderio=44b80a8be72962eccbd8ad01b6bfcac7"
reiss.com.      55  IN  TXT "google-site-verification=vrc2bvxpw2quwligK1dYuIFG6SLPp6PsOj3FlbNKmmo"
reiss.com.      55  IN  TXT "globalsign-domain-verification=DxtJ51OaIp87_OgmKu-iPxmFMN4i0CvhJtymIzHDyK"
reiss.com.      55  IN  TXT "vzjt+g3yB76l1eAihRfinxKPdAJvcxO5AAXUVdOlnqDRjHA8l+fHdBKsUp+mrKeCB2GTaX4GCUpFo5PoYNvTgw=="
reiss.com.      55  IN  SOA ns0.dnsmadeeasy.com. dns.dnsmadeeasy.com. 2008025750 43200 3600 1209600 180
reiss.com.      55  IN  A   52.85.142.187
reiss.com.      55  IN  A   52.85.142.218
reiss.com.      55  IN  A   52.85.142.227
reiss.com.      55  IN  A   52.85.142.253
reiss.com.      55  IN  A   52.85.142.33
reiss.com.      55  IN  A   52.85.142.79
reiss.com.      55  IN  A   52.85.142.108
reiss.com.      55  IN  A   52.85.142.145

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Feb 18 12:48:12 UTC 2017
;; MSG SIZE  rcvd: 872

Виртуальная машина (Centos 7):

Однако, глядя на отдельные запросы на моей Vagrant VM, я получаю:

$ dig reiss.com A 

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.2 <<>> reiss.com ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32964
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;reiss.com.         IN  ANY

;; ANSWER SECTION:
reiss.com.      3600    IN  A   52.85.142.79
reiss.com.      3600    IN  A   52.85.142.218
reiss.com.      3600    IN  A   52.85.142.227
reiss.com.      3600    IN  A   52.85.142.253
reiss.com.      3600    IN  A   52.85.142.145
reiss.com.      3600    IN  A   52.85.142.33
reiss.com.      3600    IN  A   52.85.142.108
reiss.com.      3600    IN  A   52.85.142.187

;; Query time: 1 msec
;; SERVER: 10.0.2.3#53(10.0.2.3)
;; WHEN: Sat Feb 18 12:48:24 GMT 2017
;; MSG SIZE  rcvd: 155

Но любой другой тип записи ничего не возвращает:

$ dig reiss.com MX

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.2 <<>> reiss.com MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 2267
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;reiss.com.         IN  MX

;; Query time: 0 msec
;; SERVER: 10.0.2.3#53(10.0.2.3)
;; WHEN: Sat Feb 18 14:52:15 GMT 2017
;; MSG SIZE  rcvd: 38


$ dig reiss.com TXT

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.2 <<>> reiss.com TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 24668
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;reiss.com.         IN  TXT

;; Query time: 0 msec
;; SERVER: 10.0.2.3#53(10.0.2.3)
;; WHEN: Sat Feb 18 14:53:36 GMT 2017
;; MSG SIZE  rcvd: 38

Эти команды отлично работают на сервере AWS, а также на моем хост-компьютере Mac OSX локально, просто кажется, что они не работают внутри моей виртуальной машины Vagrant / Virtualbox.

проблема также влияет на PHP, поэтому я не думаю, что это как-то связано с командой dig.

Есть идеи?

0
задан 18 February 2017 в 16:58
2 ответа

Способ ANY заключается в том, что сервер, который получает запрос, должен возвращать записи, которые он имеет для этого имени (независимо от типа).

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

Т.е., ЛЮБОЙ имеет ограниченное использование для реального производственного использования, но может иметь значение в устранение неполадок и т. д.

5
ответ дан 4 December 2019 в 11:15

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

В этом сообщении есть дополнительная информация: Vagrant / VirtualBox DNS 10.0.2.3 не работает .

Однако , предложения здесь не сработали для меня, я уже применил следующее:

vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]

Я попытался удалить это или альтернативу:

vb.customize ["modifyvm", :id, "--natdnsproxy1", "on"]

Ни то, ни другое не помогло. Я бы все равно получил resolv.conf следующим образом, и dig не будет работать для MX , TXT или Записи SOA :

# Generated by NetworkManager
search local
nameserver 10.0.2.3

Моим (вероятно, грязным) решением было отключить обновление resolv.conf в NetworkManager и жестко запрограммировать Google для DNS.

/etc/NetworkManager/NetworkManager.conf:

[main]
dns=none 

/ etc /resolv.conf:[1217 impressionЕсли вы меняете сетевые адаптеры, то 10.0.2.3 больше не является динамическим, поэтому вам нужно быть осторожным, но этот обходной путь помог мне.

Я конечно, есть способ получше, может, мне лучше использовать мостовой адаптер ...

1
ответ дан 4 December 2019 в 11:15

Теги

Похожие вопросы