“绑定9管理员参考手册”(例如用于版本9.14.11或9.17.1 )在
category短语queries查询日志条目首先以
@0x<hexadecimal-number>格式报告客户端对象标识符。
这个术语在ARM中没有提到过,它是唯一提到任何对象标识符的。
@0x123456789abc 123456似乎总是保持不变789abc不时发生变化。@0xffffffff或48位@0xffffffffffff。@0x,后面跟着客户机对象标识符(与客户机地址无关)。它是什么,它是如何计算的?
我们能从中得到什么信息?为什么会被记录下来?
发布于 2020-05-17 13:23:00
根据托尼芬奇的回复绑定用户邮件列表在2019年8月:
它是BIND用于保存查询的工作状态的数据结构的内存地址。
我很惊讶这里似乎是唯一一个真正被解释的地方。命名似乎相当误导,因为基于这一点,它不是关于客户端或对象标识符OID (根据国际电联-T十.660 /IEC9834-1)。
这一解释似乎是可信的,因为它与价值的形式和行为都是一致的。此日志记录来自ISC的L/ns/Client.c,即客户机对象(谢谢,Patrick!):
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格式字符串,%占位符有:
格式占位符的语法是%参数宽度长度type 类型字段。
s:空终止字符串.p:实现定义格式中的void * (指向空的指针)。相反,BIND 9管理员参考手册可以简单地这样说:
查询日志条目首先以
@0x<hexadecimal-number>格式报告用于保存查询工作状态的数据scructure的内存地址。
整个段落也可以是格式化为列表,而不是一个故事.
https://serverfault.com/questions/1017496
复制相似问题