BIND 9 管理员参考手册(例如版本9.14.11或者9.17.1州
- 5.2. 配置文件语法
- 词组
category
queries
- 词组
查询日志条目首先以
@0x<hexadecimal-number>
格式报告客户端对象标识符。
这个术语在 ARM 的其他地方没有被提及,而且这是唯一一次提到对象标识符一点儿也不。
它似乎与发送查询的客户端无关:
- 对于来自许多不相关 IP 地址的查询,情况可能相同,但
- 来自同一 IP 地址的两个查询可能会有所不同。
例如
@0x123456789abc
- 前半部分
123456
似乎总是一样的 - 下半场
789abc
时有变化。
- 前半部分
在查询日志示例中,它可以是 32 位
@0xffffffff
或 48 位@0xffffffffffff
。艾伦·克莱格BIND 日志2019 年 10 月的演示文稿仅通过以下方式描述它:
A
@0x
后跟客户端对象标识符(与客户端地址无关)
它是什么以及如何计算?
我们能从中得到什么信息?它到底为什么要被记录下来?
答案1
根据托尼·芬奇的回复2019 年 8 月绑定用户邮件列表:
它是 BIND 用于保存查询工作状态的数据结构在内存中的地址。
我很惊讶这似乎是唯一真正解释这一点的地方。命名似乎相当具有误导性,因为基于这一点,它与客户也不对象标识符OID(每国际电信联盟T X.660| ISO/IEC 9834-1)。
这个解释似乎可信,因为它与值的格式和行为都一致。此日志来自 ISC 的lib/ns/client.c
即客户端对象(谢谢,Patrick Mevzek!):
2715 isc_log_write(ns_lctx, category, module, level,
2716 "client @%p %s%s%s%s%s%s%s%s: %s", client, peerbuf, sep1,
2717 signer, sep2, qname, sep3, sep4, viewname, msgbuf);
这里,%p
确实是client
,因为它是用 C 语言编写的,并且"client @%p %s%s%s%s%s%s%s%s: %s"
是printf 格式字符串,其中%
占位符有:
格式占位符的语法是
%[parameter][flags][width][.precision][length]type
s
:以空字符结尾的字符串。p
:(void *
指向 void 的指针)采用实现定义的格式。
相反,BIND 9 管理员参考手册可以简单地说:
查询日志条目首先以下列格式报告用于保存查询工作状态的数据结构的内存地址
@0x<hexadecimal-number>
。
那么整个段落也可以是格式化为列表而不是一个故事……