☰

BIND 9 クエリ ログ内のクライアント オブジェクト識別子

tag-icon • tag-icon bind
BIND 9 クエリ ログ内のクライアント オブジェクト識別子

BIND 9 管理者リファレンスマニュアル (例: バージョン9.14.11または9.17.1州

  • 5.2. 設定ファイルの文法
    • フレーズcategory​
      • queries

クエリ ログ エントリは、まず、クライアント オブジェクト識別子を@0x<hexadecimal-number>形式で報告します。

この用語はARMの他のどこにも言及されておらず、オブジェクト識別子全然。

  • クエリを送信していたクライアントとは関係ないようです。

    • 多くの無関係なIPアドレスからのクエリでも同じかもしれませんが、
    • 同じ IP アドレスからの 2 つのクエリでは結果が異なる場合があります。

  • 例えば@0x123456789abc

    • 前半は123456いつも同じようだ
    • 後半は789abc随時変更します。

  • クエリ ログの例では、32 ビット@0xffffffffまたは 48 ビットになります@0xffffffffffff。

  • アラン・クレッグは、BIND ログ2019 年 10 月のプレゼンテーションでは、それが何ではないかということだけが説明されています。

    A@0xの後にクライアント オブジェクト識別子が続く (クライアント アドレスとは関係ありません)

それは何であり、どのように計算されるのでしょうか?
そこからどのような情報を取得できますか? そもそもなぜログに記録されるのですか?

答え1

トニー・フィンチの返事2019年8月のbind-usersメーリングリストへ:

これは、クエリの動作状態を保持するために BIND が使用するデータ構造のメモリ内のアドレスです。

これが実際に説明されている唯一の場所だというのは驚きです。この名前は誤解を招くようです。これに基づくと、これはクライアントまたはオブジェクト識別子OID（あたりITU-T X.660| ISO/IEC 9834-1)。

この説明は、値の形式と動作の両方に一貫しているため、信憑性があるようです。このログはISCのlib/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>形式で報告します。

まあ、この段落全体もリストとしてフォーマットされる物語の代わりに...

関連情報