具有权威位集（或用于响应的其他位）的 DNS 查询是否被视为有效？
Is a DNS query with the authoritative bit set (or other bits used for responses) considered valid?
来自RFC 1035：
Authoritative Answer - this bit is valid in responses,
and specifies that the responding name server is an
authority for the domain name in question section.
那么，如果在 DNS 查询 (QD=0) 中设置该位会怎样？大多数 DNS 实现是否将数据包视为无效，或者该位是否会被忽略？
同样的问题适用于特定于查询或响应的其他位，例如在响应中设置 RD 位。
我的猜测是，如果这些位不适用于有问题的数据包，它们将被简单地忽略，但我不确定或如何找到答案。
我问是因为我正在编写自己的 DNS 数据包处理程序，想知道是否仍应解析此类数据包或将其视为无效数据包。
您要么应用 Postel 定律 ("Be conservative in what you do, be liberal in what you accept from others") - 这通常被吹捧为 reason/condition 互联网上如此多不同事物互操作性成功的其中之一 - 或者如果您严格应用您认为无效的 RFC，您可以立即使用 FORMERR 进行回复。
在第二种情况下，因为您会得到不同的客户端（不一定针对您的特定情况，在 DNS 世界中，它们在各个方面都有很多不符合要求的实现），您需要定义是否创建特定的规则（如 ACL）接受其中一些，因为您认为它们是 "important".
请注意，在这个阶段，您的问题实际上与编程无关（没有代码），所以这里有点离题。但答案还取决于您要构建的 "packet handler" 类型。如果是为了某种IDS/monitoring/etc。您需要解析 "as much as possible" 的 DNS 流量来报告它。如果要模仿真实世界的 DNS 解析器并确保它的行为像解析器，那么您可能不需要处理每一个奇怪的异常情况。
还要记住，所有这些都可以在传输过程中更改，所以如果您收到一些错误的东西，显然并不总是来自发件人的错误，可能是因为某些中介，有意或无意。
最后，不可能预测您将获得的所有内容，并且在任何足够广泛的实验中，您会惊讶于您无法理解它是如何存在的流量数量。因此，与其在开始之前尝试定义所有内容，不如迭代版本，清楚地了解您的目标（为某种监控系统尽可能多地解析，或者作为 lean/simple/secure/close 解析 DNS 解析的真实世界功能尽可能）。
至于 "how I would find out."，您可以研究各种现有解析器（bind、nsd、unbound 等）的来源，看看它们如何反应。或者只是启动它们并像您想象的那样向它们扔一些错误的数据包并查看它们的回复。有些案例可能以 unit/regression 测试的形式存在，并且可能会扩展一些工具（如 ZoneMaster）（如果还没有进行这些特定测试）以涵盖您的案例。
来自RFC 1035：
Authoritative Answer - this bit is valid in responses, and specifies that the responding name server is an authority for the domain name in question section.
那么，如果在 DNS 查询 (QD=0) 中设置该位会怎样？大多数 DNS 实现是否将数据包视为无效，或者该位是否会被忽略？
同样的问题适用于特定于查询或响应的其他位，例如在响应中设置 RD 位。
我的猜测是，如果这些位不适用于有问题的数据包，它们将被简单地忽略，但我不确定或如何找到答案。
我问是因为我正在编写自己的 DNS 数据包处理程序，想知道是否仍应解析此类数据包或将其视为无效数据包。
您要么应用 Postel 定律 ("Be conservative in what you do, be liberal in what you accept from others") - 这通常被吹捧为 reason/condition 互联网上如此多不同事物互操作性成功的其中之一 - 或者如果您严格应用您认为无效的 RFC，您可以立即使用 FORMERR 进行回复。
在第二种情况下，因为您会得到不同的客户端（不一定针对您的特定情况，在 DNS 世界中，它们在各个方面都有很多不符合要求的实现），您需要定义是否创建特定的规则（如 ACL）接受其中一些，因为您认为它们是 "important".
请注意，在这个阶段，您的问题实际上与编程无关（没有代码），所以这里有点离题。但答案还取决于您要构建的 "packet handler" 类型。如果是为了某种IDS/monitoring/etc。您需要解析 "as much as possible" 的 DNS 流量来报告它。如果要模仿真实世界的 DNS 解析器并确保它的行为像解析器，那么您可能不需要处理每一个奇怪的异常情况。
还要记住，所有这些都可以在传输过程中更改，所以如果您收到一些错误的东西，显然并不总是来自发件人的错误，可能是因为某些中介，有意或无意。
最后，不可能预测您将获得的所有内容，并且在任何足够广泛的实验中，您会惊讶于您无法理解它是如何存在的流量数量。因此，与其在开始之前尝试定义所有内容，不如迭代版本，清楚地了解您的目标（为某种监控系统尽可能多地解析，或者作为 lean/simple/secure/close 解析 DNS 解析的真实世界功能尽可能）。
至于 "how I would find out."，您可以研究各种现有解析器（bind、nsd、unbound 等）的来源，看看它们如何反应。或者只是启动它们并像您想象的那样向它们扔一些错误的数据包并查看它们的回复。有些案例可能以 unit/regression 测试的形式存在，并且可能会扩展一些工具（如 ZoneMaster）（如果还没有进行这些特定测试）以涵盖您的案例。