WSL2でDNS解決がうまくいかない問題と解決方法

WSL2でDNS解決がうまくいかない問題と解決方法

こんにちは!

Windows Subsystem for Linux (WSL2)は、Windows上でLinux環境を利用できる素晴らしい機能ですが、中にはDNS解決に関する問題が発生することがあります。この記事では、その症状と効果的な解決方法を紹介します。

検証環境

この記事で紹介する方法は、以下のバージョンで検証しています

WSL バージョン: 2.4.13.0
カーネル バージョン: 5.15.167.4-1
WSLg バージョン: 1.0.65
MSRDC バージョン: 1.2.5716
Direct3D バージョン: 1.611.1-81528511
DXCore バージョン: 10.0.26100.1-240331-1435.ge-release
Windows バージョン: 10.0.22631.3880

症状

以下のようなエラーメッセージが表示される場合、WSL2でのDNS解決に問題が発生している可能性が高いです:

  • コマンドラインから接続時: Could not resolve hostname ...
  • Pythonコードから接続時: [Errno -2] Name or service not known

これらのエラーは、WSL2内でDNSサーバーの設定が正しく行われていないことを示しています。

原因

WSL2は起動時に自動的に /etc/resolv.conf ファイルを生成し、Windows側のDNS設定を使用しようとします。しかし、この自動生成されるDNS設定が正しく機能しないケースがあります。上記のバージョン情報にあるように、2025年3月時点の最新WSL2(バージョン2.4.13.0)でもこの問題は完全には解決されていません。

解決方法

以下の3ステップで問題を解決できます

STEP1: WSL2が自動生成するDNS設定を無効化

WSL bashで以下のワンライナーを実行して、resolv.confが自動生成されるのを防ぎます。

注意:既存のwsl.conf があるばあいはvim等で編集してください。

sudo sh -c 'cat > /etc/wsl.conf << EOF
[network]
generateResolvConf = false
EOF'

このコマンドは、WSL2の設定ファイル /etc/wsl.conf を作成し、DNS設定の自動生成を無効にします。

STEP2: Windows側でWSLを再起動

Windows PowerShellまたはコマンドプロンプトで以下のコマンドを実行し、WSLを完全に再起動します

wsl --shutdown

STEP3: DNSサーバーを手動で設定

WSLを再度起動し、シェルで以下のコマンドを実行して、GoogleのパブリックDNSサーバーを手動で設定します

sudo sh -c 'cat > /etc/resolv.conf << EOF
nameserver 8.8.8.8
EOF'

これにより、GoogleのDNSサーバー(8.8.8.8と8.8.4.4)を使用するように設定されます。

確認方法

設定が正しく適用されたかを確認するには、以下のコマンドを実行してみてください

ping google.com

または、以下のPythonコードでの接続テスト

import socket
socket.gethostbyname('google.com')

WSLのカーネルバージョンを確認するには、以下のコマンドが使用できます

# カーネルバージョンの簡易表示
uname -r

# カーネルバージョンの詳細表示
cat /proc/version

# システム情報全体の確認(systemdが利用可能な場合)
hostnamectl

また、WindowsコマンドプロンプトまたはPowerShellからWSLのバージョン情報を確認するには

wsl --version

これらが正常に動作すれば、DNS解決の問題は解決されています。

注意点

  • この設定はWSLを再起動するたびにリセットされる可能性があります。その場合は、STEP3を再度実行する必要があります。
  • WSLのバージョンによっては動作が異なる場合があります。最新の情報については、Microsoftの公式ドキュメントを参照することをお勧めします。

まとめ

WSL2でのDNS解決問題は、自動生成されるDNS設定を無効化し、手動でDNSサーバーを設定することで解決できます。この方法は、最新のWSL2バージョンでも有効です。

Read more

楽観的ロック vs 悲観的ロック:実際のトラブルから学ぶ排他制御

楽観的ロック vs 悲観的ロック:実際のトラブルから学ぶ排他制御

こんにちは! Qualitegプロダクト開発部です! 「楽観的ロックを実装したのに、まだ競合エラーが出るんですけど...」 これは私たちが実際に経験したことです。 本記事では、楽観的ロックと悲観的ロックの違いを、実際に発生したトラブルを通じて解説します。 抽象的な説明ではなく、 「なぜそれが必要なのか」「どんな問題を解決できるのか」 を実感できる内容を目指します。 目次 1. 問題の背景:並列処理で謎のエラー 2. ロックなしの世界:なぜ競合が起きるのか 3. 楽観的ロックの導入:期待と現実 4. 楽観的ロックの限界:解決できなかった問題 5. 悲観的ロックによる解決 6. 実装時のハマりポイント 7. どちらを選ぶべきか:判断基準 8. まとめ 1. 問題の背景:並列処理で謎のエラー 1.1 システムの概要 私たちが開発していたのは、 複数のワークスペースを切り替えて使用するAPIサーバー でした。 当社AI関係のプロダクトの一部だったのですが、結合テスト兼負荷テストを実行すると、まれに発生してしまっていました。 ユーザーは複数のワーキン

By Qualiteg プロダクト開発部
企業セキュリティはなぜ複雑になったのか? 〜AD+Proxyの時代から現代のクラウド対応まで〜

企業セキュリティはなぜ複雑になったのか? 〜AD+Proxyの時代から現代のクラウド対応まで〜

こんにちは! ChatGPTやClaudeといった生成AIサービスが業務に浸透し始めた今、 「AIに機密情報を送ってしまうリスク」 が新たなセキュリティ課題として浮上しています。 この課題に向き合う中で、私たちは改めて「企業のセキュリティアーキテクチャはどう変遷してきたのか」を振り返る機会がありました。 すると、ある疑問が浮かんできます。 「なんでこんなに複雑になってるんだっけ?」 企業のセキュリティ担当者なら、一度は思ったことがあるのではないでしょうか。 アルファベット3〜4文字の製品が乱立し、それぞれが微妙に重複した機能を持ち、設定は複雑化し、コストは膨らみ続けています。 当社ではAIセキュリティ関連プロダクトをご提供しておりますが、AI時代のセキュリティを考える上でも、この歴史を理解することは重要ではないかと考えました。 本記事では、企業ネットワークセキュリティの変遷を振り返りながら、「なぜこうなったのか」を整理してみたいと思います。 第1章:観測点を集約できた時代 ― オンプレAD + Proxy(〜2010年代前半) 統制しやすかったモデル かつ

By Qualiteg コンサルティング, Qualiteg AIセキュリティチーム
【IT温故知新】WS-* の栄光と黄昏:エンタープライズITはいかにして「実装」に敗北したか

【IT温故知新】WS-* の栄光と黄昏:エンタープライズITはいかにして「実装」に敗北したか

こんにちは。 —— 2003年のSOAから、2026年のAIへ —— この記事は、過去の技術動向を振り返り、そこから学べる教訓について考察してみたものです。 歴史は常に、後から見れば明らかなことが、当時は見えなかったという教訓を与えてくれます。 そして、今私たちが「正しい」と信じていることもまた、20年後には違う評価を受けているかもしれません。 だからこそ、振り返ることには意味があるとおもいます。同じ轍を踏まないために。 はじめに:20年前の熱狂を覚えていますか 2000年代初頭。 私はSOA(サービス指向アーキテクチャ)に本気で取り組んでいました。 当時、SOAは「次世代のエンタープライズアーキテクチャ」として、業界全体が熱狂していました。 カンファレンスに行けば満員御礼、ベンダーのブースには人だかり、書店にも関連の書籍がちらほらと。 SOAP、SOAP with attachments、JAX-RPC、WS-Security、WS-ReliableMessaging、WS-AtomicTransaction... 仕様書の山と格闘する日々でした。 あれから

By Qualiteg コンサルティング
DockerビルドでPythonをソースからビルドするとGCCがSegmentation faultする話

DockerビルドでPythonをソースからビルドするとGCCがSegmentation faultする話

こんにちは!Qualitegプロダクト開発部です! 本日は Docker環境でPythonをソースからビルドした際に発生した、GCCの内部コンパイラエラー(Segmentation fault) について共有します。 一見すると「リソース不足」や「Docker特有の問題」に見えますが、実際には PGO(Profile Guided Optimization)とLTO(Link Time Optimization)を同時に有効にした場合に、GCC自身がクラッシュするケースでした。 ただ、今回はDockerによって問題が隠れやすいという点もきづいたので、あえてDockerを織り交ぜた構成でのPythonソースビルドとGCCクラッシュについて実際に発生した題材をもとに共有させていただこうとおもいます 同様の構成でビルドしている方の参考になれば幸いです TL;DR * Docker内でPythonを --enable-optimizations --with-lto 付きでソースビルドすると GCCが internal compiler error(Segmentati

By Qualiteg プロダクト開発部