BIND 9 查詢日誌中的客戶端對象標識符

BIND 9 管理員參考手冊（例如9.14.11或9.17.1版）在

• 5.2. 配置文件語法

  • category片語 _
    • queries

查詢日誌條目首先以@0x<hexadecimal-number>格式報告客戶端對象標識符。

在 ARM 的其他任何地方都沒有提到這個術語，而且它是唯一提到任何對象標識符的地方。

• 它似乎與發送查詢的客戶端無關：

  • 對於來自許多不相關 IP 地址的查詢可能是相同的，但
  • 來自同一 IP 地址的兩個查詢可能會有所不同。

• 例如@0x123456789abc

  • 上半場123456似乎總是一樣
  • 下半場789abc不時變化。

• 在查詢日誌範例中，它可以是 32-bit@0xffffffff或 48-bit @0xffffffffffff。

• Alan Clegg 在 2019 年 10 月的這個BIND Logging展示文稿中，僅通過它不是什麼來描述它：

A@0x後跟客戶端對象標識符（與客戶端地址無關）

它是什麼以及如何計算？

我們能從中得到什麼資訊？為什麼它仍然被記錄？

根據 Tony Finch在 2019 年 8 月對 bind-users 郵件列表的回复：

它是 BIND 用於保存查詢工作狀態的資料結構在記憶體中的地址。

我很驚訝這似乎是唯一可以解釋的地方。該命名似乎頗具誤導性，因為基於此，它與客戶端或對象標識符OID 無關（根據ITU-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>。

好吧，整個段落也可以格式化為列表而不是故事……

引用自：https://serverfault.com/questions/1017496