dns - 这些 DNS 记录中哪一个具有优先权？

Question

假设我定义了这两条记录:

*.example.com CNAME <some name>
foo.example.com TXT <some text>

如果我运行这样的 DNS 查询，预计会发生什么？

dig TXT foo.example.com

我希望获得上面答案部分中定义的 TXT 记录，因为它的定义更明确。但是，我从 DNS 提供商处获得的是为通配符定义的 CNAME。

我已经向他们提出了这个问题，他们说他们遵循了正确的行为。这是他们给我的解释:

Refer section 2.4 in RFC1912 about "Common DNS errors". http://www.rfc-editor.org/rfc/rfc1912.txt "A CNAME record is not allowed to coexist with any other data. In other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you can't also have an MX record for suzy.podunk.edu, or an A record, or even a TXT record."

Basically, this means that, if you add a CNAME record for *.example.com, it will always take priority over any other record, even if those records are added for a specific subdomain, they're still ignored. There is nothing we can do in this case. It's how DNS is supposed to work, according to the DNS-standard.

这是正确的吗？引用的 RFC 中的部分是否涵盖通配符的情况？谁能给我一个权威的答案并提供来源链接？

Answer 1

Wikipedia page on DNS wildcard示例非常清楚(请参阅有关 host1.example 的示例)。

简而言之，仅当未找到“直接”全名时才使用通配符。

所有解释可以在 https://www.rfc-editor.org/rfc/rfc1034 的 4.3.2 节中找到特别是第 3.a 点和第 3.c 点:

     a. If the whole of QNAME is matched, we have found the
        node.

        If the data at the node is a CNAME, and QTYPE doesn't
        match CNAME, copy the CNAME RR into the answer section
        of the response, change QNAME to the canonical name in
        the CNAME RR, and go back to step 1.

        Otherwise, copy all RRs which match QTYPE into the
        answer section and go to step 6.

[..]

     c. If at some label, a match is impossible (i.e., the
        corresponding label does not exist), look to see if a
        the "*" label exists.

了解它如何具体首先搜索全名，如果是 CNAME，则需要额外的条件，但如果您查询 TXT，则情况并非如此。

在您的情况下，如果您专门查询 TXT 记录，那么无论是否有任何通配符，都应该返回该记录。 事实上，foo.example.com 上的 TXT 将隐藏任何其他类型，对其进行 CNAME 请求，不应返回通配符，但以 NOERROR NODATA 结尾，表示该名称存在，但不适用于此类型。 这正是上述维基百科页面中的 host1.example 情况。

事实上，这很容易尝试。 使用此区域文件:

$TTL 1
@ IN SOA localhost. root.localhost. (1 604800 86400 419200 604800)
  IN NS a.example.org.
  IN NS b.example.org.
  IN NS c.example.org.

*.example.com. IN CNAME foobar.example.net.
foobar.example.com. IN TXT "I am here." 

(开头只是让绑定(bind)真正加载区域的样板)

如果你dig @127.0.0.1 foobar.example.com TXT你会得到预期的结果:

;; ANSWER SECTION:
foobar.example.com. 1 IN TXT "I am here."

如果您查询相同名称的任何其他记录类型(包括 CNAME)，您将得到 NOERROR，而没有任何 CNAME 回复(通配符被区域文件中的显式名称隐藏) ，并且您得到 NOERROR，但此名称上除了 TXT 之外没有任何其他记录类型的数据，因为这是区域文件中唯一的记录类型)并且通配符适用于任何其他名称，例如 dig @127.0.0.1 not-foobar.example.com TXT 给出:

;; ANSWER SECTION:
not-foobar.example.com. 1 IN CNAME foobar.example.net.

您得到的解释不正确，并且不适用于您的用例。该引用仅适用于这种(无效)配置:

*.example.com. CNAME <some name>
*.example.com. TXT <some text>

但这与通配符无关，以下配置也会出现同样的问题，任何合规的名称服务器都会拒绝该问题:

foobar.example.com. CNAME <some name>
foobar.example.com. TXT <some text>