ハクソク

世界を動かす技術を、日本語で。

macOS 26が「.internal」を含むカスタムDNS設定を破損する

45日前原文(gist.github.com)

概要

  • macOS 26.3.1アップデート後、**/etc/resolver/**によるカスタムDNS解決が一部TLDで機能しなくなった問題
  • mDNSResponderがIANA未登録TLDを全てmDNSとして扱い、unicast nameserverを参照しない不具合
  • 開発用途やDocker、Kubernetesなど、ローカルDNSワークフローが大きく影響
  • /etc/hostsによる手動回避策はあるが、動的運用には非現実的
  • Appleへのバグ報告済み、影響を受ける場合はアップデートを控える推奨

macOS 26で発生したカスタムTLDのDNS解決障害

  • macOS 26.3.1（Darwin 25.3.0, Build 25D771280a）へのアップデート後、**/etc/resolver/**を使ったTLD単位のDNSリゾルバ設定が一部TLDで機能停止
  • IANAルートゾーンに存在しないTLD（例：.internal, .test, .lan, .home.arpa など）で障害発生
  • mDNSResponderが該当TLDを全て**mDNS（マルチキャストDNS）**として内部処理し、unicast nameserverを参照しない仕様変更
  • これにより、dnsmasqやbindなどローカルDNSサーバを使った開発・検証環境のドメイン解決が全滅
  • 公式ドキュメント（man 5 resolver）で推奨されていた運用が突然破綻

再現手順と検証結果

  • dnsmasqをHomebrew経由で導入し、/etc/resolver/example-privateにnameserver 127.0.0.1を記載
  • dig @127.0.0.1 probe.example-private Aは正常応答（127.0.0.1返却）
  • ping probe.example-privateやpython3 socket.getaddrinfo()ではUnknown hostエラー
  • scutil --dnsではresolver設定が正しく登録されていると表示されるが、実際には動作しない
  • tcpdumpで確認しても、dnsmasqへのクエリ自体が発生していない（mDNSResponderが内部で即座に応答）

影響範囲

  • .internal, .test, .home.arpa, .lanなど、IANA未登録もしくは特別用途TLD全般
    • .testはRFC 6761で明確に「ローカルDNSテスト用」として予約されているが、macOS 26ではmDNS専用扱い
  • google.com, bbc.co.uk等、IANA登録済みTLDは従来通り正常動作
  • 影響を受ける主なケース
    • **dnsmasq + /etc/resolver/**でローカル開発環境構築している全ての開発者
    • Docker Desktopや**Kubernetes（minikube, kind, k3d）**のローカルクラスタ名解決
    • Vagrant, Tailscale, VPNクライアント等が自動生成するresolver設定
  • scutil --dns上は設定が正常に見えるため、原因特定が困難

回避策と問題点

  • 唯一の確実な回避策は**/etc/hosts**への手動エントリ追加
    • ただし、動的なホスト名変化（Dockerコンテナ等）には非現実的
    • 追加・削除のたびにsudo権限が必要
  • 恒久的な解決にはApple側の修正が必要

参考情報・関連資料

  • man 5 resolver（macOS公式ドキュメント）
  • RFC 6761（.testなどの特別用途TLDの扱い規定）
  • RFC 8375（.home.arpaの用途規定）
  • IETF draft（.internalの特別用途TLD提案）
  • Apple Feedback Assistantへのバグ報告（https://feedbackassistant.apple.com/feedback/22280434）

総括・推奨

  • macOS 26.xへアップデート予定の開発者は、カスタムTLDを利用している場合はアップデートを控えることを推奨
  • 既にアップデート済みの場合は、/etc/hosts手動運用で一時的に対応
  • Appleの対応・修正が出るまで、開発・検証環境のDNS設計見直しも検討

追記：Docker・ローカル開発者への注意喚起

  • DockerやローカルDNSを多用する開発者は、macOS自動アップデートによる環境破壊リスクに注意
  • Appleへのフィードバックを積極的に送り、修正を促すことが重要

Hackerたちの意見

自分の（古い）Yosemiteマシンで、ローカルのデプロイや開発用に複数のプライベートTLDを提供するセットアップをやってるよ。これ、2014年くらいに設定したかな？その頃から、/etc/resolverのやり方はもう古いって言われてたし。ついにその機能は廃止されたのかな？もっとちゃんとした（でも面倒な）やり方は、scutilを直接使うことだと思うけど、設定はどこかのバイナリplistに保存されるんじゃないかな。これを試してみて、まだ動くか確認してみて！
└
scutilだけじゃ話の半分で、macOSの一部のルックアップはmDNSResponderを通って、設定を無視したり上書きしたりすることがあるから、ランダムなミスやバイナリplistのゴミをデバッグする羽目になるんだよね。今のところ、unboundやdnsmasqの方が簡単だよ。
Appleがハードウェアとソフトウェアの会社に分かれる日をずっと待ってる。彼らのシリコンは欲しいけど、（おそらくひどい）オペレーティングシステムは絶対に使いたくない。自分のカーネルやカーネルモジュールを動かせないなら、それは自分のデバイスじゃないよね。ファームウェアは場合によっては大丈夫だけど、隣にあるノートパソコンはポイントを証明するためにcore bootを動かしてる。
└
でも、Macで自分のカーネルを動かせるんじゃないの？ドライバーサポートが問題なんじゃない？
└
macOSは完璧じゃないけど、ひどいって真剣に主張できる人はいないと思う。
└
（ひどいと言われる）macOSは、いくつかデザイン選択が良くないと言われてるけど、全体がひどいって言う人を真剣に受け止めるのは難しいよね。
こういう小さな不具合があるから、macOSから離れたんだよね。LLMを使ってバグレポートを書くのはあんまり好きじゃないな。レビューされるならいいけど、「macOS 25で動いた」とか、明らかに存在しないことについてはちゃんとレビューしてほしいよね。それが見逃されたら、他のレポートも正確かどうか自信持てないし。みんなバグを直してほしいけど、明らかにLLMで書かれたレポートは、各主張を検証する必要があるから、捨てられちゃうかもね。
└
どんな文章にもLLMを使うのは倫理的じゃないと思う。翻訳だけは狭い例外として認めるけど。言葉を考えて書く時間を取らなかったなら、読まれる時間も与えられないよ。
└
そうだね、今のところ最終レポートは多分私たちから出すべきだけど、その過程で考えを明確にしたり、業界標準の用語を理解する機会は無限にあるよね。
└
どのOSでもちょっとしたストレスには慣れてるけど、Linuxなら戻せるのがいいよね。前のブートメニューのエントリーを選ぶだけで済むし（NixOSならシステム全体がその方法で戻る）。MacOSはノートパソコンにはまあまあ使えるけど、実際の作業はLinuxコンテナでやってるしね。
└
「以下のコンテンツは人工知能によって生成されました」と明示しない形でAIを使うのは、絶対に許されないと思ってる。ほとんどの状況で、AIに自分の名前を使わせるのは「私の時間はあなたのよりも価値があるから、自動化してあなたに書かせてる」という印象を与える。これは本当に恥ずかしいことだよ。もしあなたの使い方がAI生成コンテンツの開示によって実質的に害を受けるなら、自分が何をしているのかをよく考える必要があるよ（でも、もしかしたらもう考える気がないのかもしれないね、それが今のあなたの状況に繋がってるのかも）。
└
> こういう小さな問題があるから、macOSから離れたんだ。何十年もこんな感じだよ。Microsoftは後方互換性を保つことで知られていて、Appleは壊すことを厭わないことで知られていた。実際のところ、違いはそれほど極端ではないよ：Microsoftは以前よりも壊すことが多くなったし、Appleは昔よりも比較的保守的になった。
ちょっと話が逸れちゃったけど。自分は主にLinuxを使ってて、Windowsよりずっと良いと思ってるんだけど、なんでみんなMacOSが見た目悪いって言うのか全然わからない。今のTahoeの問題を無視すれば、MacOSは比較的洗練されてる感じがした。ここではUXの話をしてるだけで、OS自体は明らかにバグがあるけどね。最も人気のあるGnomeテーマはMacOSの再実装だし、俺だけじゃないと思う。
└
選択バイアスだね。文句を言ってる人が一番目立つのがオンラインだし。特にHNではね。
└
「タホの混乱」なんてないよ。26.0から使ってるけど、いい感じだよ。確かに違うけど、良いと思う。文句を言うのが好きな人が多いね。
└
同意だよ。タホ以前は、iOSの見た目に問題なんて感じたことなかったし、カスタマイズができないくらいかな。でも、Windows 98やああいうインターフェースを懐かしむトレンドは理解できなかったな。世代の違いかもしれないね。
└
すごく重いよね。OSにAIエンジンなんていらないし、Spotlightもいらない。ブート後に何のためかわからないけどCPUを10分間使わせるOSなんていらない。チェスアプリや他の関係ないソフトが入ってるOSなんていらないし、音楽アプリが入っててサブスクリプションのオファーでうるさくされるのも嫌だ。iCloudアプリが入ってるのもいらない。出荷されるソフトに関しても変な選択をしてるよね。例えば、古いbash 3を出荷してるのは、GPLv3が嫌いだかららしいけど、私はGPLv3が好きだから、この選択はmacOSユーザーにとって不親切だと思う。
*.localhostはそのままで動くよね？127.0.0.1に複数のホスト名をポイントさせるのにdnsmasqなんて必要ないよ。
└
内部のプライベートIPを、localhostじゃないものに解決したいことがよくあるよね。
└
*.example-privateのポイントは、192.168.0.100のAレコードでweb.example-privateを、192.168.0.101のAレコードでdb1.example-privateを使って、複数のマシンがプライベートアドレスを使えるようにすることだよ。127.0.0.1を解決したいだけなら、ホスト名「localhost」を解決するか、127.0.0.1を直接使えばいい。個人的にはカスタムプライベートDNSゾーンを設定するのは面倒だから、機械名（ホスト名）とDHCPアドレスを使って自動設定する予約済みのMDNS *.localを使ってるよ。例えば、somehostname.localのAレコードみたいな感じ。
数バージョン前、Appleが自己署名証明書を壊しちゃって…ローカルサーバーとのHTTPS通信を妨げてモバイル開発を困難にしたんだよね。今の時点で、なんでそんなことをやってたのか疑問に思うよ。
ちょっと違うけど、ローカルのウェブ開発作業にはすべて *.localhost を使うようにしてるよ。最近のブラウザは、内部的に *.localhost を 127.0.0.1 に解決してくれるから、DNSリゾルバーを設定したり、hostsファイルを編集したりする必要がないんだ。ただ、これはブラウザでウェブサイトを扱うときに役立つだけで、ローカルマシンに戻すアドレスが必要なときだけだよ。他のプログラム、例えば python や wget など、getaddrinfo() を使う場合には役に立たないけどね。
└
public DNS で dev.our-root-domain.com が 127.0.0.1 を指してるよ。
└
いいヒントだね！最近、ブラウザが localhost のサブドメインを自動的に 127.0.0.1/::1 に解決することに気づかなかったよ。Chromeで試したけど、Safariでも同じだと思う？
└
一番いいのは、*.*.localhostもサポートされてるから、prodドメインの*.comを*.localhostに置き換えられるようになったことだね。ArchiveBoxは最新バージョンでこの機能をデフォルトで使うようになって、ついにスナップショットごとのドメイン隔離を提供できるようになったから、アーカイブされたJSを安全に再生できるようになったんだ。素晴らしい機能で、これを実現するのは以前はかなりハードルが高かったけど、今は「ただ動く」って感じだね。
macOS 26は今までで一番壊れやすいバージョンだね。今年はアプリ開発が本当に大変だった。いくつか挙げると：- リファレンスプリセットが任意のSDRニットを設定できなくなって、MacBook Proの1600nitsやStudio Display XDRの2000nitsをネイティブに解除できなくなった。これが私のLunarアプリを壊してる [0]（これが意図的なのかは分からないけど、AppleがこれをSIPの下でブロックする理由が分からない） - オレンジのマイクロフォンの点滅インジケーターやそのカラフルな仲間たちの明るさを変更できなくなって、私のYellowDotアプリが無駄になった [1]（プライバシーのためだと思うけど、TouchIDの下で設定できるようにすればよかったのに） - タイトルのない浮遊ウィンドウがマウスイベントを受け付けない（幸い、これが修正された） [2] - ガンマテーブルの変更がMacBook NeoやM5 Pro/Maxでは機能せず、DDCをサポートしない外部モニターのサブゼロ調光が壊れてる（幸い、Appleが調査中） [3] - すごく丸みを帯びたウィンドウのリサイズエリアがみんなをイライラさせて、いくつかのウィンドウにカスタムリサイズハンドラーを追加しなきゃいけなかった - ドラッグ&ドロップハンドラーからドラッグされたファイルに対して生成される `com.apple.SwiftUI.Drag-` 一時ファイルパスが、Clop [4] やYoink、Dropoverなどのファイルシェルフアプリから画像をドラッグするときに元のファイルにアクセスできなくなる - NSImageが画像の実際のピクセル数とは異なるサイズを返して、画像のDPIを決定するために依存していたワークフローが壊れた [0] https://lunar.fyi/#xdr [1] https://github.com/FuzzyIdeas/YellowDot/issues/18 [2] https://developer.apple.com/forums//thread/814798 [3] https://developer.apple.com/forums/thread/819331 [4] https://lowtechguys.com/clop
└
ああ、M5で600ニットを超えられなかった理由が分かった。M1ではうまくいったのにね。今はそれなしでやっていくしかないかな。
└
常に接続されているインターフェースを持つ趣味の音楽プロデューサーとして、そのマイクのインジケーターがめっちゃウザいし、必要ないと思う。完全に無効にできないなんて信じられないよ。macOSは好きだけど、ちょっと意見が強すぎるし、その意見の中にはクソみたいなのもある。
> 唯一の信頼できる回避策は、/etc/hostsに手動でエントリを追加することだね。これでmDNSResponderを完全にバイパスできる。でも、動的なユースケース（例えば、ホストエントリが頻繁に変わるDockerコンテナのDNS）には実用的じゃないし、変更するたびにsudoが必要なんだ。俺は怠け者なのかも - ずっと/etc/hostsを使ってきたけど、リンク先のようなユースケースは経験したことがないんだよね。
もしAsahiがMacOSと同じバッテリー寿命とパフォーマンスを持ってたら、MacOSを使うことは絶対にないね。