DNS 解析与主机不相同

DNS 解析与主机不相同

我们有一个 OSX 主机和一个在 virtualbox 上运行的 ubuntu 10.04 vagrant 实例。在尝试向 emailtests.com 发送电子邮件(用于电子邮件测试目的)时,我们注意到 DNS 解析不正确。

因此,我们尝试在 OSX 和 Vagrant 实例上执行以下命令:dig -tMX emailtests.com

OSX

; <<>> DiG 9.8.3-P1 <<>> -tMX emailtests.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39364
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 3

;; QUESTION SECTION:
;emailtests.com.            IN  MX

;; ANSWER SECTION:
emailtests.com.     300 IN  MX  10 litmus-smtp-in-392690123.us-east-1.elb.amazonaws.com.

;; AUTHORITY SECTION:
emailtests.com.     172711  IN  NS  ns-1596.awsdns-07.co.uk.
emailtests.com.     172711  IN  NS  ns-215.awsdns-26.com.
emailtests.com.     172711  IN  NS  ns-1288.awsdns-33.org.
emailtests.com.     172711  IN  NS  ns-964.awsdns-56.net.

;; ADDITIONAL SECTION:
ns-964.awsdns-56.net.   158810  IN  A   205.251.195.196
ns-1288.awsdns-33.org.  158499  IN  A   205.251.197.8
ns-1596.awsdns-07.co.uk. 72461  IN  A   205.251.198.60

;; Query time: 74 msec
;; SERVER: 184.73.189.33#53(184.73.189.33)
;; WHEN: Mon Sep  9 13:15:02 2013
;; MSG SIZE  rcvd: 282

流浪汉

; <<>> DiG 9.7.0-P1 <<>> -tMX emailtests.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2227
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;emailtests.com.            IN  MX

;; Query time: 104 msec
;; SERVER: 10.0.2.3#53(10.0.2.3)
;; WHEN: Mon Sep  9 13:09:42 2013
;; MSG SIZE  rcvd: 32

如您所见,MX 记录的解析方式不同。我在网上查找了一下,发现答案告诉我们在 vagrant 文件中添加以下内容:

  config.vm.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
  config.vm.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
  config.vm.customize ["modifyvm", :id, "--natdnspassdomain1", "on"]

我们已经有了。我们仍然无法正确解析该地址以及可能许多其他地址。关于如何解决这个问题或缩小问题范围,您有什么想法吗?

注意:我们能够向 gmail 发送电子邮件并可以 ping/挖掘一些域。

更新,来自 vagrant 的 ifconfig

eth0      Link encap:Ethernet  HWaddr 08:00:27:36:71:5f  
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe36:715f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:38137 errors:0 dropped:0 overruns:0 frame:0
          TX packets:26845 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:18987844 (18.9 MB)  TX bytes:6605246 (6.6 MB)

eth1      Link encap:Ethernet  HWaddr 08:00:27:80:07:aa  
          inet addr:192.168.42.3  Bcast:192.168.42.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe80:7aa/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8294812 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4509692 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1871276346 (1.8 GB)  TX bytes:1268188839 (1.2 GB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:815216 errors:0 dropped:0 overruns:0 frame:0
          TX packets:815216 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:371105283 (371.1 MB)  TX bytes:371105283 (371.1 MB)

答案1

似乎配置的 DNS 服务器 10.0.2.3 没有配置为执行递归查找。您根本得不到答案。请使用可以执行递归查找的 DNS 服务器,或将您的 DNS 服务器配置为可以执行此操作。

答案2

今天早上我在查看同样的问题时偶然发现了这一点,经过大量的谷歌搜索/绞尽脑汁后,我想出了以下解决方案,我会将其发布给将来遇到此问题并陷入困境的任何人。

对我们有用的 natdns Vagrantfile 设置(Vagrant 1.6.3,在 OSX(使用 VirtualBox 4.3.14)和 Windows8(使用 Virtual Box 4.3.15 r95286 - 我的同事在使用 4.3.14 与 windows8 时遇到了不同的不相关问题,因此使用了似乎可以与 vagrant 正常工作的测试版)

config.vm.customize ["modifyvm", :id, "--natdnsproxy1", "off"]
config.vm.customize ["modifyvm", :id, "--natdnshostresolver1", "off"]
config.vm.customize ["modifyvm", :id, "--natdnspassdomain1", "off"]

(绝对是第一行,你可能不需要下面两行,我把它们包括进去只是为了以防你在实验时将它们打开 - 我刚刚--natdnsproxy1--natdnshostresolver1我的 Vagrantfile 中将它们都设置为关闭)。

原因似乎是 Vagrant 默认--natdnsproxy1处于开启状态,而 virtualboxs 用于 mx 查找的代理 DNS 似乎有缺陷/损坏/不稳定 - 如果将其设置为关闭,则 vm 将使用主机用于 DNS 的 IP 地址,而不是尝试通过 10.0.2.3 代理它们 - 这样您就可以从 DNS 获得完整的 mx 记录(或者至少我们可以这样做)。

(借助一点谷歌搜索,我了解到这些的原因是运行 Centos 6.5 的 vagrant 无法向某些域名发送电子邮件 - 我们可以看到 sendmail 响应了错误:503“此邮件服务器在尝试发送到非本地电子邮件地址时需要身份验证...”,然后我们发现执行操作dig mydomain.com mx返回了域名的 A 记录而不是预期的 MX 邮件记录,这表明 Vagrant / VirtualBox 存在 DNS 查找问题)。

相关内容