GoogleがPublic DNS用の標準規格を提案

2010/1/29-1

先月発表されたGoogle Public DNSですが、課題であったCDNとの相性問題を解決すべくGoogleが、IETFでDNSに関連する標準規格提案を開始しました。「DNS問い合わせメッセージの中にユーザ(クライアント)のIPアドレスを埋め込めるような追加を行おう！」という内容のものです。先月サービスを発表してから次の月にはもう標準化を開始するという、このスピード感は凄いと思います。

「Google code blog : A proposal to extend the DNS protocol」

Google Public DNSそのものに関して「Google Public DNS解説と個人的妄想」を記事として書きましたが、その中でも「DNSを活用した他者CDNとの相性」という部分でGoogle Public DNSが抱えている課題を解説しています。今回のInternet Draftによって解決しようとしているのは、たとえばAkamaiとの相性問題です。 Akamaiは、DNSキャッシュサーバの位置情報に応じて最適なWebキャッシュを応えるので、ISPのDNSキャッシュサーバではなく、Google Public DNSを使うと最適ではないWebキャッシュに繋がってしまう可能性があります。

このような問題を解決するために、たとえばGoogle Public DNSからAkamaiへのDNSキュエリーに、ユーザのIPアドレスを埋め込もうというものです。図にすると次のような感じです。まず、今回の提案がない状態だと、次のようにユーザに近いWebキャッシュではなく、Google Public DNSに近いWebキャッシュが返ってしまいます。

次に、今回の提案を利用するとユーザに近いWebキャッシュが返るようになります。

ここで注意が必要なのは、Google Public DNSは新たにユーザのプライバシ情報を得ているわけではありません。 Google Public DNSは、Akamaiが運営する権威DNSにユーザのIPアドレスを教えられるようになる形です。（ただし、この仕組みが普及するとGoogle権威DNSは、ISPなどによるキャッシュDNSからのキュエリーからクライアントIPアドレスを得られるようになります。）

提案されたのは、以下のInternet Draftです。

「Client IP information in DNS requests draft-vandergaast-edns-client-ip-00」

IETFメーリングリストで早速議論開始

この提案は、DNS Extensions (dnsext)ワーキンググループにメールで送信されたようです。 Google code blogでは、以下のように「数ヶ月で公式なインターネット標準として認められることを望む」と述べています。

The Internet-Draft was posted to the dnsext mailing list today, and over the next few months our group hopes to see this proposal accepted as an official Internet standard.

でも、これって揉める予感がします。結構インパクトがある提案だと思うのですが、こういう系統の提案は数ヶ月で収まらない気がします。なので、個人的な感想だと「数ヶ月」はツライのではないかと思いました。

というか、既に議論が開始してました。早速重鎮Paul Vixie氏が意見を述べています。

Re: [dnsext] Re: I-D ACTION:draft-vandergaast-edns-client-ip-00.txt

if we're going to add client identity to the query, can we do so in a more general way? i'd like to know lat-long, country, isp, language, and adult/child. and the ip address should be multiprotocol, covering ipv6.

(一部意訳)「クライアント情報を含みたいならIPアドレスだけではなく、もっと一般化できない？緯度経度、国、ISP、言語、大人/子供など。アドレスはIPv6対応でマルチプロトコルじゃなきゃね。」

この系統の議論が開始されると「じゃあ、どういう要素があるのか考えようよ」というのが開始され、色々と仕様が巨大化したり、「で、これ必要なんだっけ？」という根本的な議論が勃発して、そもそも最初に入れたかった「クライアントのIPアドレス」という目的とは違うところに議論が吹っ飛んで延々揉めるパターンっぽい気がします。 (まだ、もうちょっと見てみないと、今後どういう風に議論が展開されるかは不明ですが。。。)

で、さらに問題なのが、この議論が色々な方向に吹っ飛んだ結果、仕様の中に「ユーザの個人情報」といった雰囲気を醸し出すフィールドが大量に定義され、プライバシー問題に発展したときにGoogleとしては非常に使いにくい標準が出来上がりそうな予感がします。当初提案したのは「IPアドレスだけ」という仕様だったのに、気がついてみたら根掘り葉掘り定義出来るフォーマットでしたという笑えない方向に行き兼ねません。

それに続くTony Finch氏の「実装名とバージョン番号もどう？」というメールもビミョーです。

Re: [dnsext] Re: I-D ACTION:draft-vandergaast-edns-client-ip-00.txt

> if we're going to add client identity to the query, can we do so in a more
> general way? i'd like to know lat-long, country, isp, language, and
> adult/child. and the ip address should be multiprotocol, covering ipv6.

And implementation name and version number?

Tony.

Paul Vixie氏はIPv6ができないと言っているように聞こえますが、I-Dを読む限りはIPv6も考慮されています。その点は指摘されてPaul Vixie氏が納得していました。ただし、その後こんな発言も出てるので、すんなりとは進みそうにない気がします。

議論の方向性はさておき、以下がI-Dに含まれるフォーマットですが、I-DによるとFAMILYの部分に1だとIPv4で、2だとIPv6だそうです（1と2なんですね）。


                 +0 (MSB)                            +1 (LSB)
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 0: |                          OPTION-CODE                          |
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 2: |                         OPTION-LENGTH                         |
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 4: |                            FAMILY                             |
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 6: |            NETMASK            |          ADDRESS...           /
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

4バイト単位(32ビット単位)のフォーマット図が見慣れているせいもあり、2バイト単位で改行されている図に最初は惑わされかけましたが、FAMILYがあることと、NETMASKが8ビット表現なのでIPv6も行けると思います。ただ、気になるのがADDRESSの部分が32ビットの25ビット目からという中途半端な場所から開始している点ですかね。。。

ここら辺以外にも、NATは「edns-client-ipは絶対に変更してはならない」と書いてあるのも、気になります。

The client's network address MUST NOT be added, and existing edns-client-ip options, if present, MUST NOT be modified by NAT devices.

あとは、Security ConsiderationsのPrivacyのところで、ユーザプライバシのために「IPv4アドレスは24ビットで切れ」とか、「いまのところはIPv6考慮してないよ」とかが、個人的にはビミョーと思いました。なぜ「24ビット」とビット長を指定してるのでしょう、とかですかね。

To protect users' privacy, Recursive Resolvers are strongly encouraged to conceal part of the IP address of the user by truncating IPv4 addresses to 24 bits. No recommendation is provided for IPv6 at this time, but IPv6 addresses should be similarly truncated in order to not allow to uniquely identify the client.

ざっとしか読んでないのですが、もっと真面目に読むともうちょっと色々発見できるのかも知れません。「8.2. Attack scenarios」あたりも地雷原かも知れません。

IETFでの今後の議論がどうなるか、ですね。 RFCになる頃にはIPv4アドレス枯渇関連で世界がLSN(Large Scale NAT)だらけになっていたりして。。。と言ってみるテスト。

過去記事

過去記事一覧

超凄いIPv6解説書(488ページ)を無料配布します！

GoogleがPublic DNS用の標準規格を提案

IETFメーリングリストで早速議論開始

最近のエントリ

過去記事

YouTubeチャンネルやってます！