☰

BIND 9 查詢日誌中的客戶端物件標識符

tag-icon • tag-icon bind
BIND 9 查詢日誌中的客戶端物件標識符

BIND 9 管理員參考手冊例如版本2011年9月14日或者9.17.1各州

  • 5.2.設定檔語法
    • category詞組
      • queries

查詢日誌條目首先以@0x<hexadecimal-number>格式報告客戶端物件識別碼。

該術語在 ARM 中的其他任何地方都沒有被提及，並且這是唯一提及的物件標識符根本不。

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

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

  • 例如@0x123456789abc

    • 上半場123456似乎總是保持不變
    • 下半場789abc時常發生變化。

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

  • 艾倫·克萊格在這綁定日誌記錄2019 年 10 月的簡報僅透過其不真實之處進行了描述：

    A@0x後面是客戶端物件識別碼（與客戶端位址無關）

它是什麼以及如何計算？
我們可以從中得到什麼資訊？為什麼它仍然被記錄？

答案1

根據東尼芬奇的說法回覆2019 年 8 月綁定使用者郵件清單：

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

我很驚訝這似乎是唯一真正解釋的地方。這個命名似乎相當具有誤導性，因為基於此，它與客戶也不物件標識符OID（每ITU-T X.660| ISO/IEC 9834-1)。

這個解釋似乎是可信的，因為它與值的格式和行為都是一致的。此日誌記錄來自 ISClib/ns/client.c即客戶對象（謝謝，派崔克梅夫澤克！）：

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>。

嗯，整個段落也可以是格式化為列表而不是一個故事...

相關內容