DNS 应答返回没有 IP 地址的 NS 记录，这正常吗？
在我的应用程序中，我必须不时发送通知电子邮件。为了发送邮件（通过 SMTP），我必须获取该特定域（电子邮件地址的域部分）的 MX 服务器。这不是 Unix 应用程序，而是嵌入式应用程序。
我所做的是这样的 ::
1 - 发送包含域的 DNS 查询（MX 类型）到当前 DNS
2 - 如果响应包含 MX 答案，则从此函数返回成功
3 - 读取第一个 NS 记录并将其 IP 地址复制到当前 DNS ，转到 1
这可能会循环几次，这是预期的，但我没想到的是响应包含名为 ns1.blahblah 的服务器的 NS 记录。 com 但不是他们的 IP 地址。在这种情况下，我必须发送另一个查询来查找该 NS 的 IP。我只看到 1 个电子邮件地址（1 个域）出现此情况，其他地址工作没有任何问题。
这是正常行为吗？恕我直言，这是 DNS 记录的配置错误。有什么想法吗？
提前致谢...
In my application, I have to send notification e-mails from time to time. In order to send mail (over SMTP), I have to get the MX server of that particular domain (domain part of e-mail address). This is not a Unix application but an Embedded one.
What I do goes like this ::
1 - Send a DNS query (MX type) containing the domain to the current DNS
2 - If the response contains the MX answer , return success from this function
3 - Read the first NS record and copy its IP address to the current DNS , goto 1
This may loop a few times and this is expected but what I do not expect is that the response contains NS records of servers named like ns1.blahblah.com but not their IP addresses. In this case, I have to send another query to find the IP of this NS. I have seen this for only 1 e-mail address (1 domain), the other addresses worked without any problem.
Is this normal behaviour ? IMHO, it is a misconfig on the DNS records. Any thoughts ?
Thanks in advance...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
消息中的权限部分以及附加部分是可选的。即，名称服务器及其 IP 不必出现在对 MX 查询的响应中。即使服务器已经拥有数据，也由 DNS 服务器决定发送该额外信息。
您必须查询 MX，然后查询邮件服务器的 IP
The authority section in the message, as well as the additional section are optional. Ie, the name servers and their IPs don't have to be in the response to the MX query. It is up to the DNS server to decide to send that extra information even when the server already has the data.
You are stuck having to query for the MX and then query for the IP of the mail server
对您问题的简短回答：RFC 1035 说，
所以我认为底线是，是的，如果响应不包含与 NS record it some 部分匹配的 A 记录，则某些地方可能配置错误。但是，正如那句老话所说，“对你所接受的东西要宽容；”如果你要进行查询，你将需要处理这样的情况。 DNS 充斥着此类问题。
较长的答案需要一个问题：如何获取开始 MX 查找的原始 DNS 服务器？
您所做的是非递归查询：如果您查询的第一台服务器不知道答案，它会将您指向 DNS 层次结构中与您正在查找的域“更接近”的另一台服务器，并且您必须进行后续查询以查找 MX 记录。如果您在其中一台根服务器上开始查询，我认为您必须像现在一样遵循 NS 指针。
但是，如果在您的应用程序中配置了起始 DNS 服务器（即手动配置项或通过 DHCP），那么您应该能够使用 Recusion Desired 标志发出递归请求，这会将重复查找推到配置的 DNS 服务器上。 DNS 服务器。在这种情况下，您只会在第一个响应中获得 MX 记录值。另一方面，递归查询是可选的，并且您的本地 DNS 服务器可能不支持它们（这很奇怪，因为从历史上看，许多客户端库都依赖于递归查找）。
无论如何，我个人要感谢您查看 MX 记录。我不得不处理那些想要发送邮件但无法进行 DNS 查找的系统，他们使用的奇异和令人不快的黑客攻击的数量和种类给我留下了情感上的伤痕。
Short answer to your question: RFC 1035 says,
So the bottom line in my opinion is that, yes, if the response does not contain the A record matching the NS record it some section, something is likely misconfigured somewhere. But, as the old dodge goes, "be liberal in what you accept;" if you are going to make the queries, you will need to handle situations like this. DNS is awash in these kinds of problems.
The longer answer requires a question: how are you getting the original DNS server where you are starting the MX lookup?
What you are doing is a non-recursive query: if the first server you query does not know the answer, it points you at another server that is "closer" in the DNS hierarchy to the domain you are looking for, and you have to make the subsequent queries to find the MX record. If you are starting your query at one of the root servers, I think you will have to follow the NS pointers yourself like you are.
However, if the starting DNS server is configured in your application (i.e. a manual configuration item or via DHCP), then you should be able to make a recursive request, using the Recusion Desired flag, which will push the repeated lookup off onto the configured DNS server. In that case you would just get the MX record value in your first response. On the other hand, recursive queries are optional, and your local DNS server may not support them (which would be bizarre since, historically, many client libraries relied on recursive lookups).
In any case, I would personally like to thank you for looking MX records. I have had to deal with systems that wanted to send mail but could not do the DNS lookups, and the number and variety of bizarre and unpleasant hacks they have used has left me with emotional scars.
可能是该域根本没有 MX 记录。我完全删除了我未使用/停放的域的 MX 条目，它为我的邮件服务器节省了很多麻烦（垃圾邮件）。
实际上没有必要执行第 2 步。如果系统（或 ISP）解析器未返回 MX 条目，那是因为它已经执行了额外的步骤，但什么也没找到。或者，系统主机解析器可能太慢（即来自 ISP）。
不过，我认为如果发生任何一种情况，就应该立即解决，因为这显然是 DNS 或 ISP 问题，而不是功能问题。只需告诉用户您无法解析该域的 MX 记录，然后让他们自行调查即可。
另外，是否可以在应用程序本身中配置解析器，以便用户可以绕过笨重的 NS？
It could be that the domain simply does not have a MX record. I completely take out the MX entry for my unused / parked domains, it saves my mail server a lot of grief (SPAM).
There really is no need to go past step 2. If the system (or ISP) resolver returned no MX entry, its because it already did the extra steps and found nothing. Or, possibly, the system host resolver is too slow (i.e. from an ISP).
Still, I think its appropriate to just bail out if either happened, as its clearly a DNS or ISP issue, not a problem with the function. Just tell the user that you could not resolve a MX record for the domain, and let them investigate it on their end.
Also, is it feasible to make the resolvers configurable in the application itself, so users could get around a bunky NS?