ドメイン認証の普及率に対する測定方法

ドメイン認証の導入は、送信側と受信側に大別できる。 この内、あるサイトが受信側としてドメイン認証を導入しているか、 外部から知る方法はない。 一方、送信側は DNS で認証情報を公開するので、 認証情報の有無を調べることにより、 送信側の導入を判断できる。

WIDE プロジェクトは、JPRS と共同研究契約を結び、 2005年4月からドメイン認証の普及率を毎月測定している。 JPRS からは、.jp 以下のドメインの一覧を提供して頂き、 それらのドメインに対して認証情報の有無を検査している。

たとえば、JPRS から提供されたドメイン名の1つが example.jp だとする。 このサイトが、メール用のドメインとして example.jp を使っているのか、 サブドメインを設定しているのかは分からない。 しかしながら、最近では大学などを除くとサブドメインを設けないのが一般的である。 事実、JPRS から提供されたドメインを検査したところ、 約8割に MX リソースレコード(以下 RR)が設定されていた。 すなわち、全体の約8割は、サブドメインを設けずにメール用のドメインとして利用されている可能性が高い。 このため、サブドメインを推測せずに、JPRS から提供されたドメイン名のまま、 ドメイン認証の普及率を測定しても、 全体の傾向を掴むには十分であると考えられる。

調査対象とするドメイン認証は以下の通りである。

• SPF, Sender ID
• DomainKeys, DKIM

調査は、JPRS から提供して頂いたマシン上で実施している。 リゾルバとして、ローカルの bind を用い、 bind に再帰処理をさせて各ドメインの権威サーバからデータを得ている。

SPF, Sender ID

SPF も Sender ID も、ドメイン名に対して SPF RR (type 99)を宣言する。 ただし、現時点では SPF RR が普及していないため、TXT RR で代用するのが一般的である。 (BIND 9.4 から SPF RR が利用可能となる予定。) 以下に、SPF と Sender ID の宣言の特徴を示す。

• SPF は、SPF RR のデータとして "v=spf1" を持つ
• Sender ID は、SPF RR のデータとして "spf2" を持つ (v= がないことに注意)

Sender ID の受信側では、"v=spf1" という SPF RR を "spf2.0/mfrom,pra" として取り扱うことが決まっている。 そのため、SPF と Sender ID を厳密に分けることにはあまり意味がない。 そこで、我々の調査では両者を同一視している。

測定方法は、ドメイン・リストの各要素に対し以下を繰り返す。

• 「ドメイン名」に対し、SPF RR を引く
  • SPF RR が応答セクション(answer section)に含まれていれば、導入している
  • そうでなければ、導入していない
• 「ドメイン名」に対し、TXT RR を引く
  • TXT RR が応答セクションに含まれており、かつそのデータが文字列 "spf" を含んでいれば、導入している
  • それ以外なら、導入していない

DomainKeys, DKIM

DomainKeys の送信側では、公開鍵を DNS で公開する。 たとえば、example.jp に対する公開鍵の名前は、 <selector>._domainkey.example.jp となる。 <selector> の部分は、 受け取ったメールの署名を見なければ分からない。 <selector> は推測できないので、 公開鍵の有無から DomainKeys の導入を判断することはできない。

古い測定方法

DomainKeys では、ポリシーも DNS で宣言できる。 このポリシーの名前は、_domainkey.example.jp であり、推測する部分はない。 そこで、2005年4月の調査開始時点では、 ポリシーの有無で導入を調べることにした。 ただし、ポリシーの宣言はオプションであるため、 ポリシーを宣言せずに DomainKeys を導入しているサイトは落としてしまう。

新しい測定方法

2005年10月からは、測定方法を改良し、 サブドメイン "_domainkey" が存在するか否かで、 導入を判断することにした。 この方法では、ポリシーを宣言せずに DomainKeys を導入しているサイトも拾える可能性がある。

ところで、サブドメインの設定には、以下の方法がある。

1. _domainkey.example.jp という個別のゾーンを設定する
2. example.jp ゾーンに _domainkey.example.jp を書く

_domainkey.example.jp という名前の SOA RR が存在すれば、 1. であると判断できる。 一方、_domainkey.example.jp の SOA RR を引いて "name error" となれば、 1. でも 2. でもないと判断できる。

それ以外の場合、_domainkey.example.jp の TXT RR を引いて、 "no error" となれば、2. である可能性がある。 ただし、実際には _domainkey.example.jp が存在しないのにも関わらず、 *.example.jp に何らかの RR が定義されているために "no error" となった可能性もある。 そこで次に、*.example.jp の TXT RR を引く。 これが "name error" となれば、 *.example.jp は定義されていないので、 _domainkey.example.jp が存在していると分かる。

_domainkey.example.jp と *.example.jp が共に "no error" となった場合は、以下の可能性がある。

• _domainkey.example.jp が存在し、*.example.jp も存在する。
• _domainkey.example.jp が存在せず、*.example.jp が存在する。

これらを区別するためには、これら2つの名前に対し、 いくつかの RR (たとえば TXT RR)を引いてみて、それぞれに対し両者の返答内容が完全に一致するか判定すればよい。 なんらかの不一致が見つかれば前者である。 完全に一致するなら、後者の可能性が高い。

新しい測定方法のまとめ

以上をまとめ、新しい測定方法では、 ドメイン・リストの各要素に対し以下を繰り返す。

• 「_domainkey.ドメイン名」の SOA RR を引く
  • "no error" で、SOA RR が応答セクションに含まれていれば、導入している。次のドメイン候補へ。
  • "no error" で、応答セクションが空であれば、以下へ。
  • "name error" なら、次のドメイン候補へ。
• 「_domainkey.ドメイン名」の TXT RR を引く
  • "no error" なら、応答セクション(a と呼ぶ)を保存して、以下へ。
• 「*.ドメイン名」の TXT RR を引く
  • "name error" なら、導入している。次のドメイン候補へ。
  • "no error" なら、応答セクション(b と呼ぶ)を保存して、以下へ。
• (a)と(b)を比較し、一致すれば導入してない。一致していなければ導入している。

現実問題として、おかしな振る舞いをする DNS サーバも存在するため、 実際の測定方法はもう少し複雑である。 また、古い測定方法との継続を考慮して、 新しい測定方法でもポリシーの有無も調べている。

DKIM

DKIM では、 ポリシーの名前が _policy._domainkey.example.jp であること以外は、 DomainKeys と同じである。 サブドメイン _domainkey の存在の有無では、 DomainKeys と DKIM を区別することはできない。 よって、我々の調査では両者を区別していない。

---

Copyright © 2005 WIDE Project