ハクソク

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

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

2026年3月20日原文(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は昔よりも比較的保守的になった。

Hacker Newsで議論の続きを見る