うちのXPがいつの間にかAAAAレコードを問い合わせるようになった

その時は WireShark を起動したままFireFoxでネットを見ていた、よくある話です。
 

ふとwiresharkをDNSの通信だけ表示するようにしたら、FireFoxでWEBサイトを見るときに、
「AAAAリソースレコード問い合わせ→「Server Fail」(またはCNAME)」
というプロセスをいちいち踏んでから、改めてAを問い合わせて目的のWEBサーバにアクセスしている事に気付いた。
これではDNSサーバに負担がかかる（下記資料リンクを参照）じゃないの。

参考資料：IPv6/IPv4 TCP フォールバックと IPv6 DNS クエリ 現状と今後
http://www.nttv6.net/200512-fallback.pdf

 

あれ？何で？と思いNICのプロパティでIPv6プロトコルの状態を見てみると、インストールはされているが無効になってる。
そういえばちょっと用があってインストールして、用が済んだので無効にした、という覚えがある。
 

じゃあ何でFireFoxはAAAAを問い合わせるんだろうと思い、「どういうことよFireFox」という気分で、何をトチ狂ったかFireFoxのソースを取りに行った。
後から思うと調べる順番がおかしいが、ちょっとソースも見てみたかったので仕方ない。
 
 

さて、プログラムも読めないのにソースを展開、調査してみる。
きっとIPv6の有効状況を調査して、AAAAトライ → A なロジックがあるに違いない。無効にしているのに何故かそっちに行っているに違いない、と思った。（冤罪ですよ念のため）
 
ふむ…
"mozilla\netwerk\dns\src\nsHostResolver.cpp"ファイルの
"nsHostResolver::ResolveHost" あたりが怪しい…
 
……
(ノ-Д-)ノΞ┻┻ ＜ 読めんわー！
 
 
 
 

気を取り直してIE6を立ち上げると、こいつもAAAAから聞く。
ああ、もうOSのリゾルバがそうなってるんだな。。。とやっと気づく。
 

Microsoftで情報を探すと、"The Cable guy"に気になる記事。

1. The Cable Guy – 2006 年 5 月 Windows Vista で IPv6 を構成する
   http://www.microsoft.com/japan/technet/community/columns/cableguy/cg0506.mspx

 

関連の箇所を引用する。

Windows XP とは異なり、Windows Vista の IPv6 はアンストールできません。しかし、次の操作の 1 つを行うことにより、Windows Vista の IPv6 を無効にすることができます。
 
●[Connections and Adapters] フォルダで、すべての接続およびアダプタのプロパティを取得し、[この接続は次の項目を使用します] の下の [Internet Protocol version 6 (TCP/IPv6) component] のとなりのチェックボックスを外します。この方法は LAN インターフェースの IPv6 を無効にしますが、トンネル インターフェースまたは IPv6 ループバック インターフェースの IPv6 は無効にしません。
(略)
●次の 0xFF に設定されたレジストリ値 (DWORD タイプ) を追加します。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\DisabledComponents
この方法はすべての LAN インターフェース、接続およびトンネル インターフェースの IPv6 を無効にしますが、IPv6 ループバック インターフェースは無効にしません。このレジストリ値を有効にするためには、コンピュータを再起動する必要があります。

 

あー…
IPv6はインストールしてしまったらNICのバインドを外しても、ループバックが有効だからIPv6のアドレスもまだ持ってるのか、これは迂闊。
何のことはなく、IPv6が有効だからDNSの問い合わせでまずAAAAをとろうとしていたことが判明。
 
 

冒頭の資料(3年前!)ではないけど、この一連の 一人相撲 調査でIPv6対応を推進していかなくてはいかんと思った。
がんばれ「IPv6普及・高度化推進協議会!」共存でいいから。

DNSSECのサーバ対応の状況

一つ前の投稿でIPv6について書いたのけど、インターネットのインフラ関連としては DNS → DNSSEC のほうが優先してやらないといけないともっぱらの評判。
 

普段使っているDNSサーバ（コンテンツサーバ）がDNSSEC に対応しているか見た。というかMicrosoftDNSのヘルプを見ていたらDNSSECの実装について記述があったから驚いて並べてみただけなんですが。
 

表：DNSSEC実装方式と対応の状況_2008年8月

サーバ	RFC2535方式	DS方式
MicrosoftDNS (WindowsServer2003)	○	×
MicrosoftDNS (WindowsServer2008)	○	×
BIND9	○	○

※ほかは今のところ使った事がないので載せない。
 
 

実はDNSSECちゃんとを調べるまで方式2つあるという認識ではなかった、記事では何度か読んでるはずなのに。必要に迫られてない事は忘れるということか。
 
で、RFC2535方式は面倒なのでDS方式が考えられて、そのまま採用の見込みと。Windowsアカンやないの。
実装しないわけにいかないでしょうから、WindowsServer2008のSPとかに期待でしょうかね。
 
 

リゾルバはどうするんだろう。。。

IPv6インターネット、ISP以外はとりあえず公開サーバまで対応させておいたら いい？

日経NETWORK2008年9月号を読んでいる。
特集1は何も対策しなければIPv4が枯渇するということを前提に、延命として キャリアグレードNAT 、 移行期間（ただしとても長くなるだろう）のIPv4/IPv6のデュアルスタック を経て、、その先はなるようになるんじゃないの。
という記事だった。
 


fujisan.co.jpから定期購読
 

インターネットでのIPv6利用については不勉強だったのだが、ISPが苦労しそうな内容についてまとめて理解することができた。閉域のASPを含むマルチプレフィックスの扱い(参考リンク：IPv6普及・高度化推進協議会)など色々問題があるのだなぁ。
 
 

IPv6対応は

しかし個人的にIPv6インターネットへの対応を考えると、ネットワークは回線業者から払いだしてもらうのが前提の今の環境では特に腰を据えて取り組むようなものでもないのだろうなと思う。普及するならしたころに乗っかれば十分。
 
一応ルートDNSサーバがもうIPv6でレコードを返すようになっているので、使いたいところは使ってOKだと思う。
 
ただ、今グローバルIP（v4）を引いて公開しているサーバは、割と早目にIPv6を引きこんで対応させておくべきなのかとも思う。理由も一応挙げておくけど、そのうち見解は変わるかもしれない。
 
 

デュアルスタックのPCはAAAAレコードをDNSに問い合わせるのか？

以降の内容は多分に想像含むので注意。
さて、しばらくしてIPv6インターネット普及がもっと本格化、移行期間としてデュアルスタックをやりだすことになるとします。
 
IPv6、IPv4の両方を持つ端末は、まずIPv6でDNSサーバに問い合わせを行うでしょう。
このときはAAAAレコードを問い合わせるのか？と思ったので少し考えてみる。
 
手元のIPv4環境の FireFox と オプションなしDig の名前解決をキャプチャしてみたら、Aレコードの問い合わせだった。(DNSクエリのフラグが "0x00 0x01"、ついでにAAAAは "0x00 0x1c")
確かデュアルスタック環境では "AAAAが見つからなかったら次はA" という挙動をするらしい。(これは近く実際に試してみたい。)
なので公開サーバにIPv6を振っておかないと、毎回 AAAA → A のオーバーヘッドが発生ってことになるのかしら。ネガティブキャッシュがあるといってもちょっとカッコ悪いし無駄なトラフィックが増える。
 
ということから外部向けのDNS（コンテンツ）、WEBサーバあたりは IPv6 振ってあげたいなーと思う次第なのですよね。
 
 

NSは込み込みANSWER

ついでにNS（フラグ 0x00 0x02）も考えてみると、digで見る限りは結構前から「ADDITIONAL SECTION」でAとAAAAを両方返してくれる、クライアント側の実装によるけど妙なオーバーヘッドはなさそう。
IPv6含むレコードのリストをもらったらIPv6で、IPv4だけのレコードをもらってもすぐにIPv4のスタックで目的のDNSサーバに再帰問い合わせを行うのでしょう。
なのでDNSサーバ自体はIPv6対応でなくてよいけど、SOAを持つゾーンのAAAA は返してあげたい。ということは一応ローカルもそうかな。
 
 
 
 

途中から色々興味が湧いて調査しつつ書いたので締まりのない記事になったがとりあえずこのへんで。。。
 
v6も色々言われますが、v4なくならないとかv6普及するとかしないとかはインフラ使うだけの私あたりのレイヤではどうでもよいんですよね、技術にはとても興味あるけれど。
ただ人気のサイトとかを持つサーバは義務としてIPv6への対応をしておくべきだと思いました。

MicrosoftDNSサーバのイベントID4515を解消する

WindowsServer2003で構成されたActiveDirectoryのドメインコントローラで、DNSが起動する際にイベントID4515を記録するときがあります。
関連して色々と調査したので情報エントリ、関連リンク先を一通り理解すればイベントID4515が発生する原因は全部潰せるとおもいます。
 
ActiveDirectoryのスキーマに精通してLDAPの理解があれば苦労しなかったのでしょうがなかなかそうもいかない…

イベント ID : 4515
ソース : DNS
種類 : 警告
説明 : ゾーン example.local はディレクトリ パーティション MicrosoftDNS から既に読み込まれましたが、ディレクトリ パーティション DomainDnsZones.example.local でこのゾーンの別のコピーが見つかりました。DNS サーバーはこのゾーンの新しいコピーを無視します。この競合をできるだけ早く解決してください。
※サーバイベントログより引用

 

あるお客さんの環境で発生したので、これを下記マイクロソフトのKBをを参考に解消しようとするとどうも細部が違う。

Windows Server 2003 の DNS サーバー ログにイベント ID 4515 が記録される
http://support.microsoft.com/kb/867464/ja

 

ADSIEDITを使用して ForestDnsZones と DomainDnsZones を参照したが、重複する情報は特にない。イベントログの文言も今回のケースとは少し違った。
 

表：この環境で確認できた状況

確認先	状況
ForestDnsZones	サブドメイン「_msdcs.example.local」のゾーン情報が入っている
DomainDnsZones	example.localのゾーン情報が入っているが情報が古い

 
結局、MicrosoftKBの解説はあくまで2003仕様のActiveDirectoryの話で、今回のケースでは過去にWindows2000Serverで構築されていたドメインとWindowsServer2003の”新ドメイン”があり、それらを統合する為に色々と相互接続設定をを試した名残があったのだろうということに落ち着いた。
 
 

以下調べたことをつらつらと記述。
 

DNSのActiveDirectory統合ゾーンがカギ

ActiveDirectory（以下AD…）で使うDNSはゾーン情報をAD内に持っています。
DNS(Domain）用のアプリケーションディレクトリパーティションがあって、それが「ForestDnsZones」と「DomainDnsZones」、Domain～ のほうは2003用ADにドメイン構築した際の「名前そのままゾーン」の保管先として、 "example.local" のリソースレコードが並んでいる。
Forest～ のほうは"example.local"ドメイン作成時に自動的に作られる委任サブドメイン"_msdcs.”ゾーンが、これにはSRVレコードが含まれる。
"_msdcs.”はアイランド問題の解消のため設置、フォレスト内のドメインコントローラに一意な識別子を設定する。
 

しかしこれらはWindows2000のADスキーマにはいない、もともと2000のADが抱えていた問題解消＋いろいろ拡張性を考慮して改良したから。
 

関連用語のMS公式解説 （※解釈おかしい箇所があるかも知れないので要確認）
■アプリケーションディレクトリパーティション(リンク：TechNet)
■Windows2000ADのアイランド問題（リンク先の中段くらい）
■ゾーン レプリケーション スコープ(リンク：TechNet)
では2000のADでゾーンはどこにいたのか探す。
WindowsでDNSの管理コンソールを立ち上げて、ActiveDirectory統合ゾーンのプロパティを見たらゾーンレプリケーションスコープの選択がある、選択肢は下記のリンク。
 

• Active Directory の DNS ゾーンのレプリケーション
  http://technet2.microsoft.com/WindowsServer/ja/library/6c0515cf-1719-4bf4-a3c0-7e3514cef6581041.mspx

 

これがADの保管先と対応しているので表にしてみた。

表：ADスキーマとAD統合ゾーンDNSとの関係

ADエントリ	ゾーン情報のあるDN /対応するゾーン レプリケーション スコープ
ForestDnsZones	CN=MicrosoftDNS, DC=ForestDNSZones, DC=example, DC=local / Active Directory フォレスト内のすべての DNS サーバー
DomainDnsZones	CN=MicrosoftDNS, DC=DomainDNSZones, DC=example, DC=local / Active Directory ドメイン内のすべての DNS サーバー
System	CN=MicrosoftDNS, CN=System, DC=example, DC=local / Active Directory ドメイン内のすべてのドメイン コントローラ

 

統合ゾーンDNSの3つ目の保管先、"CN=MicrosoftDNS, CN=System"

SystemのMicrosoftDNSを調べると、ちゃんと "example.local"ゾーンが最新の状態で保管されている。
ちなみに "CN=System" の中身は DNを"DC=example, DC=local" として開く＝ADSIEDITのデフォルトで開いているDNから簡単にたどれる。
さらにちょっと寄り道すると、実際のADのレプリケーションでレプリカされるのはこの情報で、ADのDNSはゾーン転送とかするわけでなく、ADのアプリケーションディレクトリパーティションを読み込む・更新を適用する、という動作をしている。
 

ということで上記ディレクトリパーティションはWindowsのDNSサーバが起動する際にゾーン情報を「System」→（「ForestDNSZones」→「DomainDNSZones」※カッコ内は未確認）という順番で読み込んでいるんだろうなと。
 

ほか今回確認した時点ではSystemには「逆引きDNSゾーン」、と「RootDNSサーバ達」のゾーンが格納されていた。
 

DNS管理コンソールで確認すると、正引き、逆引きともに ゾーン レプリケーション スコープ は「Active Directory ドメイン内のすべてのドメイン コントローラ」となっていた、上記対応表どおりだ。
 

なおRootDNSサーバゾーンは各DNSサーバサービス固有のものなのでSystemでいい。
 
 

実際どれを消したらいいのか

ここまでわかれば後は簡単だった。
「DomainDNSZones」の"CN=MicrosoftDNS"から"example.local"ディレクトリを削除してDNSを再起動、DNSイベントログにID:4515の警告はもう出ない。
 

結局はイベントログの "説明：" セクションを読み返してみると、ログ様の仰せのとおりだったと事後になって理解。警告・エラーを調査すると結局はいつもこうなりますね。
 
 

すでに2000Serverを使ったドメインコントローラなくなっていたので、そのあと正引き、逆引きゾーンの ゾーン レプリケーション スコープ を「Active Directory ドメイン内のすべてのドメイン コントローラ」から「Active Directory ドメイン内のすべての DNS サーバー」 に変更した。
※2000Serverが残っている場合もADスキーマ更新で行けるようです。
 

作業後のディレクトリパーティションとゾーン情報は下記になった。

表：作業後のゾーン格納パーティション

ADエントリ	保持しているゾーン情報
ForestDnsZones	"_msdcs.example.local"
DomainDnsZones	"example.local" その他逆引きゾーン
System	. (ルートDNSサーバの一覧)

 
 

まるまる当てはまる事例は少ないかも知れませんが、ID：4515で「ForestDNSZones」、「DomainDNSZones」、「MicrosftDNS（※このイベントログで出てくる際にはSystemを指す）」のキーワードに迷った人にこのエントリを参考にしてもらえると。

WindowsDNSサーバが大量のUDPポートを待ち受けるように実装変更

Windows付属のDNSサーバを使っているサーバに、2008年7月のMicrosoftセキュリティ更新プログラム、MS08-37：DNS の脆弱性により、なりすましが行われる(KB953230)を適用すると、UDPポートの待ち受け状況がすごいことになる。
 
[caption id="attachment_533" align="alignnone" width="450" caption="画像：「netstat -na」の実行結果、笑えるくらい待ち受けている"][/caption]
何気なく"netstat -na"を実行したらUDPの待ち受けがずらずら出てくる、すごく多いのでどうしたことかと思ったら、しっかり公式に解説があったので一安心。
なんとその数2500ポート、DNSの更新情報は重要なのでしっかり読んでおくべきでした。
 
[caption id="attachment_534" align="alignnone" width="450" caption="画像：ついでに「netstat -nba」で待ち受けているプロセスを表示、たしかにDNS"][/caption]
WindowsServer2003で確認したが、更新対象に2000と2008も入っているので同様でしょう。
 
※パッチ一覧ではDNS サーバー (KB951746) のほう、クライアントは(KB951748)
 
 
以下関連情報へのリンクとちょっと解説など