bind9/Memo_Of_Answer_ACL

Ａ．ＢＩＮＤ９のＡＣＬ（Access Controll Lists）の癖となります。詳しくは参考文献をお読みください。 というのは不親切なので、解説すると、

1. ＡＣＬの処理はリストの左から右へ評価されます。これはＡＮＤ結合であるということを意味しません。
2. よってブール論理で解釈するのではなく、ファーストマッチ・ファーストアウトで解釈する必要があります。
3. 接続元ＩＰアドレスに対して、以下の３つが判断されます。
   • match and accept（一致かつ受諾）
   • match and reject（一致かつ拒絶）
   • no match（一致しない、なので次のリストに委ねる）
4. これは「!」（reject）と「 」（accept、「!」が指定されてない）のニュアンスが直感的に違うことを意味します（今まで一致・不一致に見えませんでしたか？）。
5. ネスト（{･･･}）されていた場合、その内容について下記の２つの評価を行い（ここでは一致・不一致の直感とマッチする）、その結果に対して上記３つの判断が実施されます。
   • match（一致）
   • no match（不一致）
6. 当然ネストの中に更にネストできるので、それは上記２評価（match または no match）の繰り返しとなる。

上記ルールを踏まえ、問題のルールを解析すると･･･。

• 大枠は２つのリストに分かれる（「!」の意味に注意）。
  1. !{ !ＩＰｖ４アドレス; !ＩＰｖ６アドレス; any; } → match and reject
  2. key "ＴＳＩＧキー名." → accept or reject
• 最初のネストを分解すると、３つのリストに分かれる。
  1. !ＩＰｖ４アドレス → 一致した場合「no match」という評価で完了
  2. !ＩＰｖ６アドレス → 一致した場合「no match」という評価で完了
  3. any → 一致（常に一致する）した場合「match」という評価で完了

上記をまとめて解釈すると、

• 最初のネスト内では以下の評価を行う（「!」の評価に注意）。
  1. 「ＩＰｖ４アドレス『ではない』」の評価をする。
     • 指定された「ＩＰｖ４アドレス」であれば「no match」として評価完了。
     • そうでないなら「match」として次の評価。
  2. 「ＩＰｖ６アドレス『ではない』」の評価をする。
     • 指定された「ＩＰｖ６アドレス」であれば「no match」として評価完了。
     • そうでないなら「match」として次の評価。
  3. 「any」（任意の全てのアドレス）に･･･とここまで来ると常に match と解釈され、評価が終了する。
  4. また any の時点で既に、「match」評価されてるので、この場合の「any」の指定のあり／無しに意味はない
     • ※人間の直感には反するから入れておいた方がいい。
• このネストでの結果を全体「!」＝match and reject で評価することから、「no match」（つまり次のリストの評価）の時は、次のリスト key が評価される。