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

執筆:WIDE antispam WG
編集:山本和彦
作成:2006年1月6日

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

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

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

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

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

SPF, Sender ID

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

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

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

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" となった場合は、以下の可能性がある。

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

新しい測定方法のまとめ

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

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

DKIM

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


Copyright © 2005 WIDE Project