症状: Wi-FiのDNS設定を空にしても、VPN(Tunnelblick)に接続していないとネットに繋がらない。VPN接続を試みる（失敗しても）と何故か直る。
原因: 過去のVPNセッションが正常終了せず、VPN用のDNS設定が macOS の SystemConfiguration の Setup（恒久設定）層 に残留していた。Wi-FiパネルのGUIから削除してもこの層までは反映されなかった。
対処法: scutil コマンドで残留したDNS設定を直接削除する。

環境

macOS
VPNクライアント: Tunnelblick（OpenVPN）
Wi-Fi接続（en0）

症状

ある日、Wi-FiのDNS設定（システム設定 → Wi-Fi → 詳細 → TCP/IP・DNS）を手動でいじった後から、以下の現象が発生した。

VPNに接続していない状態だと、名前解決ができずネットに繋がらない（ping 8.8.8.8 のようなIP直打ちは通るが、ping google.com のようなドメイン名は通らない）
VPN(Tunnelblick)の接続ボタンを押すと、たとえ接続が失敗（タイムアウトなど）してもネットが復旧する
Wi-FiのDNSサーバー欄を手動設定から空欄に戻しても症状は変わらなかった
一見するとWi-Fi側のDNS手動設定が悪さをしているように見えるが、実際にはその設定を消しても直らない、というのがポイントだった。

切り分けの手順

1. DHCPが正しく機能しているか確認

ipconfig getpacket en0

domain_name_server にルーターのIP（例: 192.168.x.x）が正しく入っており、DHCP自体は正常だった。

2. IP直打ちと名前解決の切り分け

ping 192.168.x.x   # ローカルゲートウェイ
ping 8.8.8.8       # 外部IP直打ち
ping google.com    # 外部ドメイン名

前者2つは通るが、ping google.com だけが通らない → 経路の問題ではなく、DNS(名前解決)だけの問題 と判明。

3. 実際に使われているDNS設定を確認

scutil --dns

出力の resolver #1 に、見覚えのない設定が残っていた。

resolver #1
  search domain[0] : openvpn
  nameserver[0] : 10.x.x.x      # ← VPN内部専用DNS(例)
  nameserver[1] : 10.x.x.x       # ← VPN内部専用DNS(例)
  if_index : 11 (en0)

search domain: openvpn という検索ドメインと、VPN内部でしか到達できないプライベートIPのDNSサーバーが、Wi-Fi(en0)のDNSとして直接設定されていた。

これがVPN未接続時に名前解決が全滅する原因。VPN接続を試みるとTunnelblickがルートを一時的に張るため、たまたまこの内部DNSに到達できるようになり「直ったように見えていた」だけだった。

4. Wi-Fiパネルから該当DNSを削除しても直らない理由を特定

Wi-Fiパネルの DNSサーバー欄から該当IPを削除しても、scutil --dns の出力からこの設定が消えなかった。

これは、GUIが参照・書き込みする層とは別に、SystemConfigurationの Setup: 階層（恒久設定）に同じ設定が別途残っていたため。おそらく過去にTunnelblickでのVPN接続が正常終了せず（接続不安定でクラッシュ的に切断されたなど）、down（切断）スクリプトによるクリーンアップが正しく走らず、この設定だけが取り残されてしまったと考えられる。

原因の特定（scutil対話モードで直接確認）

sudo scutil

対話モードに入り、まず全体のキー一覧を確認する。

> list

Wi-Fi(en0)に対応するService IDを探し（Setup:/Network/Service/<UUID>/Interface などから特定できる）、DNSキーの中身を確認する。

> show State:/Network/Service/<UUID>/DNS

<dictionary> {
  ServerAddresses : <array> {
    0 : 192.168.x.x
  }
}

State（実行時の実体）側は正常だった。しかし、恒久設定側を見ると：

> show Setup:/Network/Service/<UUID>/DNS

<dictionary> {
  DomainName : openvpn
  SearchDomains : <array> {
    0 : openvpn
  }
  ServerAddresses : <array> {
    0 : 10.x.x.x
    1 : 10.x.x.x
  }
}

ここにopenvpn関連の設定がそのまま残留していた。 これがOS起動時やネットワーク再構成のたびに読み込まれ、Wi-FiのDNSとして適用されていたため、GUIから消してもすぐに（あるいは実際には最初から）反映されていなかった。

対処法

scutilの対話モードのまま、該当キーを削除する。

> remove Setup:/Network/Service/<UUID>/DNS

念のため確認：

> show Setup:/Network/Service/<UUID>/DNS
  No such key

quitで抜けて、最終確認。

scutil --dns

resolver #1
  nameserver[0] : 192.168.x.x
  if_index : 11 (en0)

openvpn関連の設定が消え、DHCPで配布された正常なDNSのみになっていることを確認。この状態でVPN未接続でもping google.comが正常に通るようになった。

まとめ

項目	内容
症状	VPN未接続時に名前解決できずネットに繋がらない。VPN接続を試みると（失敗しても）直る
見た目の疑わしい原因	Wi-FiパネルのDNS手動設定
真の原因	Tunnelblickが書き込んだVPN内部DNS設定が、SystemConfigurationの`Setup:`階層に残留し、Wi-FiパネルのGUI操作では消えなかった
対処法	`sudo scutil` の対話モードで `Setup:/Network/Service/<UUID>/DNS` を直接 `remove` する

補足：なぜGUIから消せなかったのか

Wi-FiのTCP/IP・DNSパネルはSystemConfigurationの設定を読み書きしているが、Tunnelblick（OpenVPN）がVPN接続確立時に直接この階層へ書き込みを行うため、VPN切断が正常に完了しなかった場合、GUI操作だけでは完全にロールバックされないケースがある。今回のように接続が不安定（AEAD Decryptエラーが頻発するなど）だと、正常な切断シーケンスが走らずこの現象が起きやすいと考えられる。

同じ症状に遭遇した場合は、Wi-Fiパネルだけでなく scutil --dns で実際に使われているDNS設定を確認し、怪しい残留があれば scutil の対話モードで直接削除するのが確実。

なお、根本的な再発防止のためには、VPN接続自体が不安定な原因（AEAD Decryptエラーなど）を合わせて調査するのが望ましい。