Networking DNS应答返回没有IP地址的NS记录，这正常吗？

在我的应用程序中，我必须不时发送通知电子邮件。为了发送邮件（通过SMTP），我必须获得该特定域的MX服务器（电子邮件地址的域部分）。这不是Unix应用程序，而是嵌入式应用程序

我是这样做的：：

1-向当前DNS发送包含域的DNS查询（MX类型） 2-如果响应包含MX答案，则从该函数返回成功 3-读取第一条NS记录并将其IP地址复制到当前DNS，转到1

这可能会循环几次，这是意料之中的，但我不希望响应包含名为ns1.blahblah.com的服务器的NS记录，但不包含它们的IP地址。在这种情况下，我必须发送另一个查询来查找此NS的IP。我只在1个电子邮件地址（1个域）中看到了这一点，其他地址没有任何问题

这是正常的行为吗？嗯，这是对DNS记录的错误配置。有什么想法吗

---

提前感谢…

可能是域没有MX记录。我完全删除了我未使用/存放的域的MX条目，这为我的邮件服务器节省了很多麻烦（垃圾邮件）

真的没有必要超过步骤2。如果系统（或ISP）解析程序没有返回MX条目，这是因为它已经执行了额外的步骤，但没有找到任何内容。或者，可能是系统主机解析程序太慢（即来自ISP）

尽管如此，我认为，如果发生了任何一种情况，就应该进行纾困，因为这显然是DNS或ISP的问题，而不是功能上的问题。只需告诉用户您无法解析域的MX记录，并让他们自己调查即可

---

此外，是否可以在应用程序本身中配置解析器，以便用户可以绕过bunky NS？

消息中的authority部分以及附加部分是可选的。也就是说，名称服务器及其IP不必出现在对MX查询的响应中。由DNS服务器决定是否发送该额外信息，即使该服务器已经拥有该数据

---

您必须先查询MX，然后再查询邮件服务器的IP

NS记录导致通常的附加节处理定位 a类记录，以及在转介中使用时，对 它们为获取粘合信息而驻留的区域

…附加记录部分包含RRs 与查询相关，但严格来说不是 问题

…在编写响应时，将插入到 附加部分，但答案或权限中有重复的RRs 章节，可从附加章节中省略

因此，我认为底线是，是的，如果响应中不包含与NS record it some部分匹配的A记录，则可能在某个地方配置错误。但是，正如老掉牙的道奇所说，“在你接受的东西上要自由”；如果你要提出疑问，你需要处理这样的情况。DNS充斥着这类问题

较长的答案需要一个问题：如何获得开始MX查找的原始DNS服务器

您正在执行的是非递归查询：如果您查询的第一台服务器不知道答案，它会将您指向DNS层次结构中与您要查找的域“更近”的另一台服务器，并且您必须进行后续查询以查找MX记录。如果您是在某个根服务器上启动查询，我认为您必须像现在这样遵循NS指针

但是，如果在您的应用程序中配置了启动DNS服务器（即手动配置项或通过DHCP），则您应该能够使用Recursion Desired标志发出递归请求，这将在配置的DNS服务器上取消重复查找。在这种情况下，您只需在第一个响应中获得MX记录值。另一方面，递归查询是可选的，您的本地DNS服务器可能不支持它们（这很奇怪，因为历史上许多客户端库都依赖于递归查找）

---

无论如何，我个人要感谢您查找MX记录。我不得不处理那些想发送邮件但无法进行DNS查找的系统，他们使用的奇怪和令人不快的黑客数量和种类给我留下了情感创伤。

我认为你所寻求的术语叫做“胶水记录”。我已经很久没有使用DNS了，但这会在我模糊的记忆中浮现出来。如果这就是我们所讨论的，有两种思路：（1）胶水记录是必要的和标准的实践，（2）因为胶水记录永远不能被删除（？），它们应该一直避免。@ Heath：谢谢这个信息……你可以考虑只添加一个“传出邮件SMTP服务器”。嵌入式设备的配置选项-毕竟，大多数正确配置的网络都会有一个，许多网络要求您使用它，而不是直接去目的地。@caf:谢谢，我将添加此选项。如果客户知道SMTP，他们将按照自己的意愿设置此选项。否则，我会表现得相反。我修复了这个MX-DNS问题，但需要几（5-6）轮才能获得所需的信息……好吧，但我可以在循环3次后找到一个有效/工作的MX。事实上，我很少能在第一次尝试时得到MX的答案。不要考虑hotmail/gmail电子邮件地址。想想像这样的电子邮件somebody@somesmallcompany.com.md（摩尔多瓦）例如…能否将系统解析程序分别设置为4.2.2.1、4.2.2.2和4.2.2.3，然后重试？它可能是您的本地解析器problematic@tinkertim：我将DNS查询发送到4.2.2.1，它在第一个循环中返回MX记录（不是IP，但这不是问题）。我想不是