IPv6の普及に欠かせないのが，DNS（domain name system）のIPv6対応である。jpドメインを管理するDNSサーバーでは，IPv6対応が進んでいる。しかし，その上位に位置するルート・ドメインを管理するサーバー（ルート・サーバー）では，IPv6への対応が遅れている。その理由は「512バイト問題」と呼ばれる問題点があるから。そこで今回は，DNSのIPv6対応のハードル「512バイト問題」について見ていこう。

　DNSはドメイン名からIPアドレスを割り出すしくみのこと。DNSの仕様では，やりとりするデータを512バイト以下に収めて，一つのUDPパケットで運ぶ決まりになっている。

　現状，DNSでルート・サーバーのアドレスを問い合わせると，全世界で動く13台のルート・サーバーのドメイン名とIPv4アドレスが返信されてくる。この13台という数は，DNSでやりとりできる512バイトのデータ量の制限を受けている。つまり，13台分のドメイン名とIPv4アドレスまでなら，512バイト以内でぎりぎり収まるようになっているのである。

　DNSでは512バイトを超えるデータをUDPで転送できない。これが「512バイト問題」と呼ばれるものである。

　DNSをIPv6に対応させると，問い合わせに対する返答には，IPv6のアドレスと従来のIPv4のアドレスをいっしょに運ぶことになる。ルート・サーバーのアドレスを問い合わせた場合も，13台分のドメイン名とIPv4アドレスに加えて，13台分のIPv6アドレスも運ぶ必要がでてくる。すると当然，返信用のデータは512バイトを超えてしまう。

　DNSサーバーが512バイトを超えるデータをやりとりするときは，UDPの代わりにTCPを使う。ところが，TCPを使うとDNSサーバーの負荷が増大する。TCPコネクションの確立や切断といった処理が発生するからだ。仮に，ドメイン名の上位に位置するルート・サーバーがすべてTCP処理の高い負荷でダウンしたら，DNS全体がストップしてしまう。そこで，TCPを使うのはどうしても避けたい。

　では，jpドメインを管理するDNSサーバーではなぜIPv6に対応できたのだろうか。それは，上位のルート・サーバーに登録する情報を工夫して，応答パケットが確実に512バイト以内に収まるようにしたから。ルート・サーバーにjpドメインを登録する際，登録するサーバーが6台とルート・サーバーに比べて少ないうえ，それらのドメイン名をa.dns.jpやb.dns.jpのように短く統一したのである。

　ただ，512バイト問題の根本的な解決策も見えつつある。DNSで512バイトを超えるデータをUDPでやりとりするための「EDNS0」（extension mechanisms for DNS version 0）という拡張仕様の利用が始まった。EDNS0を使うと，DNSサーバーへの要求時に，自分が受け取れるUDPパケットの最大データ・サイズを通知できる。それを使えば，512バイトを超えるデータを1個のUDPパケットでやりとりできる。最も利用されているDNSサーバー・ソフト「BIND」は，すでに最新版のバージョン9でEDNS0に対応している。