『dhcp-v6で配信される検索ドメインが壊れている』のクチコミ掲示板

[peroxy]

東日本でドコモ光を契約し、ONUに当ルータを接続しています。
- https://diary.sshida.com/20170616-4-NTT%E6%9D%B1%E3%81%8B%E3%82%89%E3%81%AEDHCPv6+Advertise%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6
- https://www.tsanvr.com/2023/09/dns.html
- https://pure2z.com/terayama/
等を見るに、フレッツ光系列の光回線の下では検索ドメインとしてiptvf.jpとflets-east.jpが降ってくるはずです。
しかし当ルータの下で/etc/resolv.confを確認すると

search flets-east.jp. iptvf.jp flets-east.jp.iptvf.jp # mac
search flets-east.jp.\032iptvf.jp flets-east.jp.iptvf.jp # linux

のような異常な検索ドメインが登録されており、このために一部のツールがドメイン解決に失敗する状況となっています。

wiresharkでdhcp-v6のパケットを確認したところ、画像の通り2ドメインが半角スペースで結合されたものが配布されており、実装のバグの線が濃厚ですが、単なる故障の可能性も考えられますし、プロバイダや回線業者側の問題の可能性もあります。

このルータの使用者で、同様の症状が出ている方はいませんか?

書込番号：25976863

[えがおいっぱい]

＞peroxyさん
当方はMac所有者ではないので、

https://pure2z.com/terayama/

の記事の事を参考にした回答ですが、この記事によればDNSサーバーには2つの数値があり、通常は、

192.168.11.1(Buffaloは確か11.1だったような）
240b:xxxx

の2つが割り振られていて、右側に検索ドメイン名が逆引きされているようです。

通常は、

flets-east.jp
iptvf.jp

の2つになっていると思いますが、それが違う文字列になっているという事なのですか？

また、もう1つわからないのは、一部のツールだけが繋がらないというのもよくわからない症状です。

DNSの名前逆引きはOSやルーターレベルで行う事なので、ブラウザでちゃんと名前解決が出来ているのにアプリだけが駄目という事であれば、むしろそのアプリに問題があるように思います。

そのアプリがどういう状態かが分かりませんが、MAP/Eで割り当てられている利用可能以外のポート番号を使うようなアプリだとか、そもそもDS-Lite方式でポート開放が出来ない環境だとか、UPnP開放をするようなアプリでそれに失敗しているとか、PPPoE接続にした上で任意ポートを開放しないと使えないアプリだとか、そちらが問題なきがしますがいかがですか。

書込番号：25977103

[Gee580]

なんか、おかしいよね。

＞一部のツールがドメイン解決に失敗する状況

そのツールはなんですかね？　FQDN指定ではダメで　iptvf.jpとflets-east.jp　じゃないとダメな理由はなんですかね？

＞プロバイダや回線業者側の問題

を切り分けるために、ルーターの上流側で　Wireshark　でトレースできますかね。

いづれにしても、ワークアラウンドではなく、ちゃんと全部正確に機能しないといけないよね。

わたくしは、Windows　Playerなので　写真のリストはLINUXかMACかツール　での結果ですかね？

なんか、柳生ルーターが悪さしてる感じだよね。　ファームウェアを最新にして工場リセット／再設定でどうなるかだよね。　大事なところは”拡張設定 「表示する」を選択すると、DHCPサーバーの拡張設定項目が表示されます。”、”ドメイン名の通知 DHCPサーバー機能で通知するドメイン名を設定します。”　をちゃんと指定することだよね。

あとは先述したように上流でWireshark　でトレースして切り分けだよね。
柳生の対応が悪い場合、買い替えか、　または、　柳生ルーターのDHCPサーバー機能をOFFにして　自分で、　/etc/resolv.conf　を書き換えだよね。

書込番号：25977172

[次世代スーパーハイビジョン]

フレッツテレビを契約していないからでしょう。

iptvf.jpを正引きしてみたらどうですか。？

書込番号：25977205

[peroxy]

回答ありがとうございます。

> ＞プロバイダや回線業者側の問題
> を切り分けるために、ルーターの上流側で　Wireshark　でトレースできますかね。

linux機を直挿ししてキャプチャした所、検索ドメインとして画像の通り 'flets-east.jp.' と 'iptvf.jp.' がきちんと列挙されて降ってきていて、/etc/resolv.confは

search flets-east.jp iptvf.jp

となっていたので、やはりルータ自体のdhcp-v6の実装の問題とわかりました。

> この記事によればDNSサーバーには2つの数値があり、通常は、
>
> flets-east.jp
> iptvf.jp
>
> の2つになっていると思いますが、それが違う文字列になっているという事なのですか？

はい、dhcp-v6のレベルでは 'flets-east.jp. iptvf.jp.' という(半角スペース入りの)単一のドメインが降ってきています。
複数回書き込まれているのは、半角スペースは本来ドメイン名に入ってはいけないので、それぞれのOSで適当な変換処理が挟まった結果だと思います。

手元にwindows機もあるので合わせて確認したところ、それぞれ次のような振る舞いをしていると推測されました:

dhcp-v6: 'flets-east','jp',' iptvf','jp' の4ラベル
-> windows: ピリオドで結合した後半角スペースで分割 -> "flets-east.jp." と "iptvf.jp"
-> mac : ピリオドで結合したものと、そこからダメ文字を消去したもの -> "flets-east.jp. iptvf.jp" と "flets-east.jp.iptvf.jp"
-> linux : ピリオドで結合してダメ文字をエスケープしたものと、ダメ文字を消去したもの -> "flets-east.jp.\032iptvf.jp" と "flets-east.jp.iptvf.jp"

おそらくwindows機でしかテストしておらず、見逃されたバグではないでしょうか。

> DNSの名前逆引きはOSやルーターレベルで行う事なので、ブラウザでちゃんと名前解決が出来ているのにアプリだけが駄目という事であれば、むしろそのアプリに問題があるように思います。
> そのアプリがどういう状態かが分かりませんが、MAP/Eで割り当てられている利用可能以外のポート番号を使うようなアプリだとか、そもそもDS-Lite方式でポート開放が出来ない環境だとか、UPnP開放をするようなアプリでそれに失敗しているとか、PPPoE接続にした上で任意ポートを開放しないと使えないアプリだとか、そちらが問題なきがしますがいかがですか。

> ＞一部のツールがドメイン解決に失敗する状況
> そのツールはなんですかね？　FQDN指定ではダメで　iptvf.jpとflets-east.jp　じゃないとダメな理由はなんですかね？

問題が起きているのはcargo-binstallというツールで、rust製バイナリをレポジトリから落とせるようにするツールです。ファイルのダウンロードにはhttp(s)を使っているので、特殊な処理は行われていません。
実装を見たところhickory-dnsという独自実装のDNSソルバを使っていて、これが名前解決において(OSのAPIを使わず)/etc/resolv.confを自前でパースしていました。パース部分を見るとドメイン名のバリデーションをかなり厳しく行なっており、不正な文字を含むドメインは弾かれる仕様になっていて、これがエラーの原因でした。
hickory-dnsの実装自体あまり行儀が良くないとは思いますが、DNSの仕様に従っている方に文句をつけるわけにはいかないでしょう。
また、同様に/etc/resolv.confを自前でパースするソルバを使っていると同じ問題を起こしうると思われます。

> なんか、柳生ルーターが悪さしてる感じだよね。　ファームウェアを最新にして工場リセット／再設定でどうなるかだよね。　大事なところは”拡張設定 「表示する」を選択すると、DHCPサーバーの拡張設定項目が表示されます。”、”ドメイン名の通知 DHCPサーバー機能で通知するドメイン名を設定します。”　をちゃんと指定することだよね。

ファームウェアは最新のv1.46のものなのを確認し、初期化してみましたが、リセット直後の状態でも同じ症状が見られました。
また拡張設定からドメイン名を設定してみたところ、dhcp(v4)に追加のオプションとして Option 15のDomain Nameが生えただけで、dhcp-v6に影響はありませんでした。

> フレッツテレビを契約していないからでしょう。
> iptvf.jpを正引きしてみたらどうですか。？

これは関係ないと思います。検索ドメインは省略されたドメインに対してサフィックスを加えてFQDNを得るための仕組みなので、フレッツ内部のサービスに省略されたドメインでアクセスしない限りは実際に機能することはないはずです。


以上のことから、buffalo側に問い合わせを行おうと思うのですが、このようにほぼバグであることを確信しているものはサポートに送るのと脆弱性報告に送るのと、どちらが良いのでしょうか?

書込番号：25978001

[Gee580]

脆弱性に送る、　と思った理由は？

まず、小手調べで、LINEとかチャットでコンタクトしてミレバ？

柳生はサポートに問題があるので、タフだから注意だよね。　さらにこの商品は販売終了なのでね。

書込番号：25978073

[Gee580]

＞このために一部のツールがドメイン解決に失敗する状況となっています。

あれから、ちょっと調べたんだけれども、/etc/resolv.conf がおかしくなってるのは、おかしいけれども、それはそれで機能するみたいよ。

半角スペースの隙間がなくても、/032 (スペースの意味）が入っていても、　自動的に補正して解釈してくれるみたいだけれども。

その一部のツールって何？　今度はそのツールが臭いよね。　実装がプアかもね。　そもそも、その他は普通に動くんでしょ？　

書込番号：25978250

[次世代スーパーハイビジョン]

そもそも、「flets-east.jp」、「iptvf.jp」のドメインはフレッツ閉域網に中継するためのもので

「flets-east.jp」はユーザーサービスページのドメイン。「iptvf.jp」はフレッツテレビのドメイン。

ユーザーサービスページに接続できないのですか。？
以前、バッファローのルーター使っていましたが
何ら使用に問題なかったですが。

インターネット使用上、問題があるドメインがあるんですか。？
Linuxからフレッツユーザーページにアクセスできないのですか。？

書込番号：25978420

[Gee580]

＞その一部のツールって何？　今度はそのツールが臭いよね。　実装がプアかもね。　そもそも、その他は普通に動くんでしょ？　

よく、お返事を読んでなかったよね。　失礼したよね。

さらに調べたら、パージングにて不正確なものを生成しちゃうケースもあるし、厳しくそのチェックをして、無視してしまうのがあるみたいね。　hickory-dns　は後者のほうだよね。　セキュリティを重視している実装だよね。

なので、どっちが悪いということではなく、この場合は使いやすい、とか、使いにくいとかだよね。
柳生にコンタクトしても、理解できないだろうし、労力が無駄になるところだったよね。

最終的には、その環境を続けるなら、FQDNでのアクセスになるんだろうね。

書込番号：25979450

[peroxy]

> 脆弱性に送る、　と思った理由は？
> まず、小手調べで、LINEとかチャットでコンタクトしてミレバ？

一般的な製品のサポートが想定しているのは操作がわからないだとか故障だとかで、バグ情報を送っても対応できる部署に回されるとは思えなかったからです。とはいえ、とりあえずメールサポートに送ってみようと思います。

> 柳生はサポートに問題があるので、タフだから注意だよね。　さらにこの商品は販売終了なのでね。

管理画面から見えるログのフォーマットを調べると、DHCPのサーバ・クライアントともにISC-DHCPを使っているようなので、当機種だけのバグではないと予想されます。なのでしかるべき所に伝われば修正が降ってくるんじゃないかなぁ……と期待しています。

> dhcp-v6: 'flets-east','jp',' iptvf','jp' の4ラベル
> -> windows: ピリオドで結合した後半角スペースで分割 -> "flets-east.jp." と "iptvf.jp"
> -> mac : ピリオドで結合したものと、そこからダメ文字を消去したもの -> "flets-east.jp. iptvf.jp" と "flets-east.jp.iptvf.jp"
> -> linux : ピリオドで結合してダメ文字をエスケープしたものと、ダメ文字を消去したもの -> "flets-east.jp.\032iptvf.jp" と "flets-east.jp.iptvf.jp"

ここに関して若干訂正があります。パケットキャプチャの結果を見直していた所、IPv6のNeighbor Discoveryでもdhcpv6と同様の付帯情報を配るシステムがあって、そこについていた検索ドメインは画像の通り 'flets-east','jp','iptvf','jp'の4ラベル (スペースなし)となっていました。
linuxでデバッグログを睨んだ結果、"flets-east.jp. iptvf.jp"はdhcp-v6由来、"flets-east.jp.iptvf.jp"はicmp6由来で登録されていて、2ドメインが異なっていたために二重に登録されているという形でした。macもおそらく同様の機構で2個生成されていて、windowsはdhcpv6のもので上書きする仕様なのだと思います。

ここから内部の挙動を推定するに、NGNから受け取った検索ドメインを内部で雑なテキストで保持(おそらくルータ内部の/etc/resolv.conf?)し、それを改めてパースする際にNDプロキシ・DHCPv6サーバの双方が間違ったパースをしているのでしょう。

書込番号：25981006

[kabada]

そもそもこの機種はLinuxに対応しているとはメーカーページのどこにも書かれてません。
対応していないOSの一部アプリが動作しないからといってメーカーに苦情を入れるのはいかがなものかと思います。
メーカーサポートに問い合わせても「Linuxには対応していません」としか回答されないのでは。

書込番号：25981495

[peroxy]

多忙につき遅くなりましたが、結果報告です。
buffaloに問い合わせをしたところ、向こうでも再現したということで、時期は未定ですがファームウェア改修が入るそうです。

またこの際実装の異なる機種との交換を提案されたので、全buffaloルータに共通する不具合というわけでもないようです。
一方でこの製品は販売終了しているので、例えば同クラスの最新版など(WSR-3000AX4P?)で共通の実装なのかな、と予想しています。

いずれにせよ、今はbuffaloの対応待ちといったところです。

書込番号：26062431