algorithm - 为什么 QNAME 字段的内容不是 DNS 消息中的原始域？

Question

为什么 QNAME 字段的内容不是 DNS 消息中的原始域？

例如，如果我想获取域 www.mydomain.com 的 IP，我将向网络发送一个 DNS 查找包，包的问题部分包含域。

但实际上QNAME包中的内容是3www8mydomain3com0，而不是www.mydomain.com。

3www8mydomain3com0表示每个标签都以这部分的长度开始，然后是内容，以长度0结束。

那么，为什么我们使用长度+数据模式来描述域而不是原始域？

查看本节 4.1.2。问题部分格式描述了我们如何在 RFC1035 上定义域记录(请搜索以查看此部分)。

Answer 1

(更改域名以使 Stack Overflow 关闭无法命名的域。)

For example, if I want to get the IP of domain www.qqqqsovr.com, I will send a DNS lookup package to the network, and the package's question section contains this url.

那不是 URL，而是域名。域名是 URL 的部分，但 URL 类似于 http://www.qqqqsovr.com/homepage.html。

But actually the content of QNAME in the package is 3www8qqqqsovr3com0 instead of www.qqqqsovr.com.

是 www.qqqqsovr.com。正如 Calle Dybedahl 所说，这是因为名称的编码形式有些复杂。 RFC 1035 的第 3.1 节“ namespace 定义”说:

Domain names in messages are expressed in terms of a sequence of labels. Each label is represented as a one octet length field followed by that number of octets. Since every domain name ends with the null label of the root, a domain name is terminated by a length byte of zero. The high order two bits of every length octet must be zero, and the remaining six bits of the length field limit the label to 63 octets or less.

并且名称的那些单独位可以由其他名称指向，因此，例如，如果您同时拥有 www.qqqqsovr.com 和 www.abcdefgh.com 在DNS报文中，第二个域名可以指向第一个域名的.com；这在 RFC 1035 的第 4.1.4 节“消息压缩”中有描述。

简单地将域字符串作为文本字符串放入消息中是不允许压缩的；您需要一些 方式来表达指针。你可能不得不问 Paul Mockapetris为什么他(和 Jon Postel)选择使用那种特殊编码。

即使在那里，字符串长度也必须以某种方式以某种方式指示，无论是通过计数还是通过空终止。 1987 年，虽然 UNIX 机器在 Internet 上很常见，但据我所知，它们并不常见到 null 终止是一个“显而易见”的选择。