au光のホームゲートウェイ(BL1500HM)のRDNSSが壊れていてDNS解決もIPv6疎通もおかしくなっていた話

この記事はClaude Sonnet 5で生成されています。

要約

au光のホームゲートウェイ(BL1500HM)の配下で、WSL上のresolvectl queryはもちろん、Windows側のnslookupもIPv6のリンクローカルDNSサーバー宛の問い合わせだけタイムアウトする現象に遭遇した。ルーター再起動、PC再起動、二重ルーター構成にしていたBuffalo WNR-5400XE6を疑っての設定変更など、遠回りの切り分けを重ねた末、結局原因はHGW自体の「RDNSS設定」だった。これをOFFにしたところ、DNS解決だけでなく副次的にIPv6のグローバル疎通自体も直るというオマケ付きの決着になった。この記事ではその切り分けの過程と、最終的な対処、そして原理の推測をまとめる。

事象

Arch Linux (WSL) でnslookupが入っていなかったのでbindパッケージを入れつつ、resolvectl queryで名前解決を試みたところ、こうなった。

$ resolvectl query platform.claude.com
platform.claude.com: resolve call failed: All attempts to contact name servers or networks failed

resolvectl statusを見ると、DNSサーバーとして172.17.0.1が設定されている。

Global
           Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: foreign
  Current DNS Server: 172.17.0.1
         DNS Servers: 172.17.0.1
Fallback DNS Servers: ...
          DNS Domain: mshome.net

DNS Domain: mshome.netから分かる通り、これはWSL2(Hyper-V Default Switch)環境である。172.17.0.1はDockerのブリッジではなく、Default SwitchのNAT側(ICS共有)アドレスであり、pingは普通に通る。つまりICMPは生きているのにDNSクエリだけ死んでいる状態だった。

ホストのWindows側で確認すると、こちらもおかしい。

> nslookup platform.claude.com
DNS request timed out.
    timeout was 2 seconds.
サーバー:  UnKnown
Address:  fe80::7693:daff:fe8e:8f56
...
*** UnKnown への要求がタイムアウトしました

Resolve-DnsNameだと成功するのに、nslookupだけIPv6のリンクローカルアドレス(fe80::7693:daff:fe8e:8f56)への問い合わせでタイムアウトしている。ipconfig /allで見ると、このアドレスがDNSサーバーとして2回優先的に登録されていた。

   DNS サーバー. . . . . . . . . . . . .: fe80::7693:daff:fe8e:8f56%7
                                          192.168.0.1
                                          fe80::7693:daff:fe8e:8f56%7

一方、IPv4のDNSサーバー(192.168.0.1)を明示的に指定すれば普通に解決できる。

> nslookup platform.claude.com 192.168.0.1
サーバー:  router.askey.net
Address:  192.168.0.1

権限のない回答:
名前:    platform.claude.com
Addresses:  2607:6bc0::10
          160.79.104.10

つまりIPv4のDNSフォワーディングは生きているのに、ルーターが広告しているIPv6のリンクローカルDNSサーバーだけが応答しない。

構成

物理構成はこうなっている。

事象が出ていたのはBuffalo機経由でWi-Fi接続していたデスクトップPC。au光はIPoE(IPv6ネイティブ)接続で、HGWがRA(ルーター広告)でグローバルプレフィックスとDNSサーバー情報(RDNSS)を配布する構成になっている。

切り分け1: ルーター・PCの再起動

まず定番の「再起動して直るか」を試した。

• HGWを再起動 → 変化なし
• PCを再起動 → 変化なし

ルーターのログを見ると、確かに再起動自体は行われていた(タイムスタンプが2021年の初期値から2026年の現在時刻に飛んでいる)ので、再起動が効いていないこと自体は確実だった。

切り分け2: HGWの設定を疑う

HGWの管理画面(192.168.0.1)の「LAN側設定」→「IPv6設定」を見ると、以下の設定になっていた。

項目	値
配布する情報	設定1 [RA:プレフィックス配布 DHCPv6:配布しない]
RDNSS設定	ON

RDNSSは、ルーター自身のリンクローカルアドレスをDNSサーバーとしてRA経由で配布する機能だ。ここがONになっていて、かつそのアドレス(fe80::7693:daff:fe8e:8f56)への応答がない、というのが症状と一致する。

ここでいったん「ルーターのIPv6 DNSプロキシ機能が壊れているだけでは」と当たりをつけたが、話はここで終わらなかった。

切り分け3: 二重ルーター構成を疑う(遠回りの始まり)

netsh interface ipv6 show routeを確認すると、意外な結果が出た。

発行     種類      Met  プレフィックス            Idx ゲートウェイ/インターフェイス名
-------  --------  ---  ------------------------  ---  ------------------------
いいえ      Manual    256  ::/0                        7  fe80::6ae1:dcff:fe6a:8bb0

デフォルトルートのゲートウェイが、HGWのアドレス(...8f:56)ではなく別のアドレス(...8bb0)になっていた。netsh interface ipv6 show neighborsでMACアドレスを確認し、OUI(68:E1:DC)を調べると、これはBuffalo製品のものだった。

つまりデスクトップPCは、HGW配下のBuffalo WNR-5400XE6(WNR-5400XE6)を、実質的なIPv6ルーターとして認識していたことになる。二重ルーター構成が悪さをしている可能性を疑い、しばらくこちらを追いかけることにした。

• Buffalo機の管理画面を確認 → 動作モードはすでに「アクセスポイントモード」で、ルーターモードではなかった
• IGMP/MLDスヌーピングをOFFにしてみる → 今度はRAそのものが届かなくなり、グローバルIPv6アドレス自体が消滅(悪化)
• Buffalo機のログを解析すると、DHCPC XMT: Info-Request on eth1というDHCPv6のInfo-Requestが5日間、一度も応答を受け取らないまま延々と送信され続けていた

これらから「Buffalo機がAPモードなのに裏でIPv6ホストとして振る舞っていて、中継処理にバグがあるのでは」という仮説を立てたが、正直この段階の推測はほぼ外れだった。

切り分け4: Buffalo機を完全にバイパスする

一番確実な切り分けとして、別のノートPCをHGWに直接有線で繋いでみた。Buffalo機を一切経由しない構成である。

結果、こちらでも同じ症状が再現した。

発行     種類      Met  プレフィックス            Idx ゲートウェイ/インターフェイス名
-------  --------  ---  ------------------------  ---  ------------------------
(デフォルトルートの::/0が存在しない)

netsh interface ipv6 show neighborsでも、HGWのリンクローカルアドレスへの到達性が「到達不可」のままだった。

fe80::7693:daff:fe8e:8f56    00-00-00-00-00-00  到達不可

これでBuffalo機は完全に無罪と確定した。二重ルーター構成を疑ってあれこれ弄っていた時間は、結果的にすべて遠回りだったことになる。

解決: RDNSS設定をOFFにする

振り出しに戻り、最初に見つけていたRDNSS設定をOFFにしてみた。

IPv6設定 > RDNSS設定: ON → OFF

デスクトップPC側で確認すると、劇的に改善していた。

> ipconfig /all
(抜粋)
   デフォルト ゲートウェイ . . . . . . .: fe80::7693:daff:fe8e:8f56%7
                                          192.168.0.1

> nslookup platform.claude.com
サーバー:  router.askey.net
Address:  fe80::7693:daff:fe8e:8f56

権限のない回答:
名前:    platform.claude.com
Addresses:  2607:6bc0::10
          160.79.104.10

> ping -6 platform.claude.com
2607:6bc0::10 からの応答: 時間 =9ms
...
パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)

DNS解決だけでなく、それまで100%packet lossだったIPv6のグローバル疎通自体も直った。netsh interface ipv6 show neighborsでもHGWのアドレスが「到達可能(ルーター)」に変わっていた。

念のため、以前は症状が出ていなかったノートPC(HGW直結)でも確認したところ、こちらもRDNSSをOFFにする前は実はグローバルIPv6アドレスが振られない状態になっていたことが判明した。RDNSSをOFFにした後は、こちらも正常にグローバルアドレス・デフォルトルート・DNS解決すべてが機能するようになった。結局、Buffalo機の有無に関わらず、HGW配下の全端末がRDNSSの不具合の影響を受けていたことになる。

なぜRDNSSをOFFにすると直るのか(推測)

以下はHGWのファームウェアの中身が見えない以上、あくまで推測である。

観測された事実を並べると次のようになる。

状態	DNS解決	IPv6グローバルアドレス	デフォルトルート	HGWへのNDP
RDNSS ON	fe80宛クエリのみタイムアウト	端末により来る/来ない	不完全/来ない	到達不可
RDNSS OFF	正常	正常	正常	到達可能

不自然なのは、RDNSSは本来DNSサーバー情報の有無だけを左右する設定のはずなのに、OFFにしたらNeighbor Discovery(NDP)やデフォルトルートの認識といった、本来DNSとは無関係のはずの挙動まで正常化した点だ。

もっとも筋が通りそうな説明は、「RDNSSオプションを含むRAパケットの生成処理自体にファームウェア側のバグがあり、それがDNSプロキシ機能だけでなくIPv6スタック全体(RA配布・NDP応答)の安定性にまで波及していた」というものだ。安価な組み込みルーターでは、IPv6周りの処理(RA送信・DNSプロキシ・NDP応答など)が単一のユーザー空間デーモンに同居していることが珍しくない。このデーモンがRDNSSオプションを含むRAの組み立てで例外やクラッシュを起こしていたとすれば、DNSだけでなくRA・NDPまで巻き込まれて不安定になるのは自然に説明がつく。

まとめ

• au光のホームゲートウェイ(BL1500HM)で、DNS解決とIPv6グローバル疎通が同時におかしくなった
• 原因はHGWの「RDNSS設定」で、OFFにしたら両方直った
• 途中で疑った二重ルーター構成(Buffalo WNR-5400XE6)は完全に無関係だった。デフォルトゲートウェイがBuffalo機のアドレスになっていたのも、RDNSS不具合の副作用の一種だったと考えられる
• 同じ症状に遭遇したら、まずHGWのRDNSS設定を疑うのが早道