DNS 响应的 NAME 字段是否始终压缩?

Question

在阅读rfc1035的过程中，我遇到了这些问题。

这是资源记录格式部分。

这是消息压缩部分。

4.1.3. Resource record format
The answer, authority, and additional sections all share the same
format: a variable number of resource records, where the number of
records is specified in the corresponding count field in the header.
Each resource record has the following format:
1  1  1  1  1  1
0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                                               |
/                                               /
/                      NAME                     /
|                                               |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                      TYPE                     |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                     CLASS                     |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                      TTL                      |
|                                               |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                   RDLENGTH                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/                     RDATA                     /
/                                               /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
NAME            a domain name to which this resource record pertains.

问题：

0. 为什么NAME字段显示为至少 2 个字节的字段，但实际上，它可以是 1 个字节的ROOT。
1. 是否存在NAME不使用压缩的情况？如果是，您能否提供转储。
2. 是否存在NAME字段混合的情况 - 例如标签和指针的顺序。

相关 1. 和 2. 问题 我认为答案是肯定的。 例如，消息压缩部分提供了一个示例，其中域名显示为标签序列和指针的混合。但是，我找不到带有真实示例的 pcap 转储。

---

UPD.0：将资源记录格式图像替换为 RFC 中的引用

Answer 1

我找到了混合大小写的例子 - 请参阅评论。它帮助我解决了1. 和2.问题。

关于0.问题：

我仍然困惑为什么NAME是这样说明的，因为对于 ROOT 情况，它只占用 1 个字节。(顺便说一句，这是关于这个的StackOverflow主题)

但是，它不再阻止我了。如果标签长度具有最高位1,1- 则它是一个指针。如果0,0- 它是长度(最大值为 63)。 保留1,0和0,1。

UPD.0： 请参阅评论。Patrick Mevzek为解决这些问题提供了很好的答案。