☰

CNAME 域名到没有 MX 记录的子域名

tag-icon • tag-icon domain-name-system email mx-record cname-record
CNAME 域名到没有 MX 记录的子域名

应发送电子邮件至[电子邮件保护]工作？

test.com CNAME something.else.com
else.com MX 1 <google mx>

我认为有些参考资料需要 RFC1912不是拥有 CNAME 记录以及同一域上的其他记录，但这应该是可接受的用法吗？

something.else.com 没有 MX 记录，但 else.com 有 MX 记录。我多次运行 dig 时得到的结果不同：

$ dig +short @8.8.8.8 test.com. mx
something.else.com
$ dig +short @8.8.8.8 test.com. mx
1 aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
5 alt2.aspmx.l.google.com.
10 alt3.aspmx.l.google.com.
10 alt4.aspmx.l.google.com.

有问题的域名是维戈网站，尝试向该域中的地址发送电子邮件。

答案1

看起来，该域名（dns1.p01.nsone.net等）的权威名称服务器根据 qtype 提供相冲突的响应。

问题类型A：

$ dig @dns1.p01.nsone.net wego.com A +norec

; <<>> DiG 9.11.14-RedHat-9.11.14-2.fc31 <<>> @dns1.p01.nsone.net wego.com A +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24735
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
wego.com.               3600    IN      CNAME   enigma.wego.com.cdn.cloudflare.net.

;; Query time: 0 msec
;; SERVER: 198.51.44.1#53(198.51.44.1)
;; WHEN: Wed Feb 12 07:40:14 UTC 2020
;; MSG SIZE  rcvd: 85

$

问题类型MX：

$ dig @dns1.p01.nsone.net wego.com MX +norec

; <<>> DiG 9.11.14-RedHat-9.11.14-2.fc31 <<>> @dns1.p01.nsone.net wego.com MX +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51501
;; flags: qr aa; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
wego.com.               3600    IN      MX      1 aspmx.l.google.com.
wego.com.               3600    IN      MX      5 alt1.aspmx.l.google.com.
wego.com.               3600    IN      MX      5 alt2.aspmx.l.google.com.
wego.com.               3600    IN      MX      10 alt3.aspmx.l.google.com.
wego.com.               3600    IN      MX      10 alt4.aspmx.l.google.com.

;; Query time: 0 msec
;; SERVER: 198.51.44.1#53(198.51.44.1)
;; WHEN: Wed Feb 12 07:40:25 UTC 2020
;; MSG SIZE  rcvd: 152

$

这与问题中列出的场景不同。
并不是MX您看到的 是来自不同的名称（如问题中所示），MX和CNAME显然与其名称服务器并列，根据您要求的内容提供不同的“视图”，即使这些视图显然直接冲突且无法合并。

至于客户端将获得什么结果，这可能是一个取决于缓存状态和实现细节的问题。如果您已经CNAME在缓存中拥有，您已经知道该名称是一个别名，并且这是该名称本身的一个属性，该名称不能是某些记录类型的别名，而不能是其他记录类型的别名（因此CNAME记录不能与其他数据共存）。

此名称服务器实现的行为不符合标准，我并不期望它能可靠地工作。无法确定客户端是否真的会得到他们针对给定情况想要的响应，或者是否会产生基于已缓存的混淆CNAME。

答案2

有一些参考资料要求 RFC1912 不能将 CNAME 记录与同一域上的其他记录一起使用

确实如此，一旦您拥有 CNAME，您就不能拥有同一域 (FQDN) 的其他类型记录。在您的示例中，您正在传递此“要求”。为了更好的方法，请假设示例.com和例子.net域。

example.com. CNAME sub.example.net.

example.net. MX 10 192.0.2.10
example.net. A 192.0.2.15

sub.example.net. A 192.0.2.20

MX 和 A 记录都与example.netCNAME 无关，因为 CNAME 与example.com重定向到sub.example.net的子域有关example.net。一般来说，一旦有了 CNAME，就会有以下请求sub.example.net。首先是墨西哥记录，如果不存在，则需要进行另一个查询A或者高级。

在此用例中，电子邮件将被发送到192.0.2.20就像它A缺少“目标”域上的记录墨西哥记录。

注意：要解释您返回的答案，您应该提供更多相关信息或正确的域以供检查。经过“匿名化”过程和详细程度后，无法详细回答...

相关内容