在我的应用程序中，我必须不时发送通知电子邮件。为了发送邮件（通过 SMTP），我必须获取该特定域的 MX 服务器（电子邮件地址的域部分）。这不是 Unix 应用程序，而是嵌入式应用程序。
我做的事情是这样的::
1 - 向当前 DNS 发送包含域的 DNS 查询（MX 类型）
2 - 如果响应包含 MX 答案，则从此函数返回成功
3 - 读取第一个 NS 记录并将其 IP 地址复制到当前 DNS，转到 1
这可能会循环几次，这是意料之中的，但我没想到的是响应包含名为 ns1.blahblah.com 的服务器的 NS 记录，但不包含它们的 IP 地址。在这种情况下，我必须发送另一个查询来查找此 NS 的 IP。我只看到了 1 个电子邮件地址（1 个域），其他地址没有任何问题。
这是正常行为吗？恕我直言，这是 DNS 记录上的错误配置。有什么想法吗 ？
提前致谢...
消息中的权限部分以及附加部分是可选的。即，名称服务器及其 IP 不必在对 MX 查询的响应中。即使服务器已经拥有数据，也由 DNS 服务器决定是否发送该额外信息。
您必须先查询 MX，然后再查询邮件服务器的 IP
简短回答您的问题：RFC 1035说，
NS 记录会导致通常的附加部分处理来定位 A 类记录，并且当在引用中使用时，会对它们所在的区域进行特殊搜索以查找粘合信息。
...附加记录部分包含与查询相关的 RR，但不是该问题的严格答案。
...在撰写回复时，要插入附加部分的 RR，但在答案或权威部分中重复的 RR，可以从附加部分中省略。
所以我认为的底线是，是的，如果响应不包含与 NS 记录它的某个部分匹配的 A 记录，则某处可能配置错误。但是，正如老话所说，“对你接受的东西要自由；” 如果您要进行查询，您将需要处理这样的情况。DNS 充斥着这类问题。
更长的答案需要一个问题：您如何获得开始 MX 查找的原始 DNS 服务器？
您正在做的是一个非递归查询：如果您查询的第一台服务器不知道答案，它会将您指向另一台服务器，该服务器在 DNS 层次结构中“更接近”您正在寻找的域，您必须进行后续查询以查找 MX 记录。如果您在其中一台根服务器上开始查询，我认为您将不得不像您一样自己遵循 NS 指针。
但是，如果在您的应用程序中配置了起始 DNS 服务器（即手动配置项或通过 DHCP），那么您应该能够使用 Recusion Desired 标志发出递归请求，这会将重复查找推送到已配置的DNS 服务器。在这种情况下，您只会在第一个响应中获得 MX 记录值。另一方面，递归查询是可选的，您的本地 DNS 服务器可能不支持它们（这很奇怪，因为从历史上看，许多客户端库依赖于递归查找）。
无论如何，我个人要感谢您查看 MX 记录。我不得不处理想要发送邮件但无法进行 DNS 查找的系统，而且他们使用的各种奇怪和令人不快的黑客攻击给我留下了情感上的伤疤。
可能是该域根本没有 MX 记录。我完全删除了我未使用/停放的域的 MX 条目，它为我的邮件服务器节省了很多痛苦（SPAM）。
确实没有必要跳过第 2 步。如果系统（或 ISP）解析器没有返回 MX 条目，那是因为它已经执行了额外的步骤但什么也没找到。或者，可能是系统主机解析器太慢（即来自 ISP）。
不过，我认为如果发生任何一种情况，就直接退出是合适的，因为它显然是 DNS 或 ISP 问题，而不是功能问题。只需告诉用户您无法解析域的 MX 记录，然后让他们自行调查。
此外，是否可以在应用程序本身中配置解析器，以便用户可以绕过笨拙的 NS？