【digでTXTレコードを確認する方法】DNS設定後に反映確認
DNSにTXTレコード(Google認証やSPFなど)を追加したのに、
「ちゃんと設定できているか分からない…」ということはありませんか?
dig コマンドを使ってTXTレコードを確認する方法まとめ
TXTレコードとは?
TXTレコードは、ドメインに任意のテキスト情報を登録できるDNSレコードです。
主に次の用途で使われます:
- Google Search Console のサイト所有権確認
- SPF(送信ドメイン認証)
- DKIM / DMARC設定
- AWS / HubSpot / 各種サービス認証
digでTXTレコードを確認する方法
基本コマンド
dig example.com TXT
シンプル表示する場合
dig example.com TXT +short
成功すると、以下のように表示されます。
"google-site-verification=xxxxxxxxxxxx"
"v=spf1 include:_spf.google.com include:amazonses.com ~all"
TXTレコードが複数あっても問題ない?
はい、問題ありません。
1つのドメインに複数のTXTレコードを持つのは通常の構成です。
例:
re-tool.co.jp TXT "google-site-verification=..."
re-tool.co.jp TXT "v=spf1 include:_spf.google.com ..."
ただし注意
⚠ SPF(v=spf1)は1つだけにまとめる必要があります。
複数のSPFレコードがあるとメールが正常に送信できなくなる可能性があります。
TXTレコードが表示されないときのチェックポイント
1. ネームサーバーが正しいか確認
dig example.com NS +short
2. DNS反映待ちの可能性
DNSは反映に数分〜最大48時間かかることがあります。
Google DNSで確認:
dig example.com TXT @8.8.8.8 +short
Windowsで確認する方法
PowerShellを使う場合:
Resolve-DnsName example.com -Type TXT
Resolve-DnsName example.com -Type TXT -Server 8.8.8.8
remoted で問題が起きました。 | macOS Tahoe 26.2
MacBook (Intel 版) 起動時、「remoted で問題が起きました。」ダイアログが表示される。
remoted はユーザーが入れたアプリではなく、macOS 標準のシステムデーモンということらしい。
エラーは「Mac起動時に remoted が一時的に応答しなかった」ものでした。
remoted って何?
remoted は Apple純正のバックグラウンド常駐プロセスで、下記の機能を担当しているようです。
- 🎮 Bluetooth / 外部デバイス連携
- 📱 Sidecar(iPadをサブディスプレイにする機能)
- 🖱 Universal Control(MacとiPadを1つのマウス・キーボードで操作)
- 🎧 AirPlay / 外部入力系の仲介
つまり
👉 「周辺機器・リモート系の橋渡し役」という立ち位置のシステムサービスです。
今回のエラー内容を噛み砕くと
WATCHDOG timeoutmonitoring timed out for service: remoteddevice not responsive
- macOS 起動直後
- remoted が 60秒間 応答しなかった
- 監視役(watchdog)が「固まってる」と判断して記録
💡 **クラッシュというより「起動時のもたつき」**に近いです。
特に今回は
- ディスプレイ OFF
- 起動から約80分後にログ採取
- 熱状態も正常
なので、深刻度は低めです 名称未設定
よくある原因
これは珍しくないパターンで、だいたい次のどれかです。
- 🔌 起動時に Bluetooth / USB 機器が大量につながっている
- 🖥 外部ディスプレイ・ドック・ハブ
- 📱 iPad / iPhone が近くにあって Universal Control 初期化
- 💤 スリープ復帰直後のタイミング被り
- 🧪 macOSの軽い不具合(特にメジャーアップデート直後)
アップデート待つしかなさそうかな
【Git】git branch -a に残る削除済みリモートブランチの正体と解消方法
Git を使って開発していると、
GitHub 上では消えているはずのブランチが、ローカルでは残って見える
という現象に遭遇することがあります。
error: unable to delete 'feat/base': remote ref does not exist error: failed to push some refs
発生した状況
以下のような流れで問題が起きました。
git branch -aを実行remotes/origin/feat/baseが表示される- GitHub の Web サイトを見ると、そのブランチはすでに削除済み
- 削除しようとして以下を実行
git push origin :feat/base
エラーが出る
結論:原因は「ローカルのリモート追跡情報が古い」
この問題の原因はとてもシンプルです。
GitHub 上の状態と、ローカルに保存されている
origin/*情報がズレている
git branch -a で表示されるremotes/origin/* は 実体ではなくキャッシュ情報 です。
つまり、
- GitHub:すでに削除済み
- ローカル:まだ「あることになっている」
という状態になっていました。
正しい解決方法(これだけでOK)
✅ git fetch --prune を実行する
git fetch --prune
このコマンドを実行すると、
- リモート(GitHub)に存在しないブランチを
- ローカルの
remotes/origin/*から自動削除
してくれます。
実行後に確認:
git branch -a
remotes/origin/feat/base が消えていれば解消完了です
なぜ git push origin :branch は失敗したのか?
git push origin :feat/base
このコマンドは、
「リモートに存在する
feat/baseを削除せよ」
という意味です。
しかし今回は、
- すでに GitHub 側にブランチが存在しない
- 削除対象が見つからない
ため、
remote ref does not exist
というエラーになりました。
操作自体は間違っていません。
単に「もう消えていた」だけです。
今後ズレを防ぐおすすめ設定
毎回 --prune を付けるのが面倒な場合は、
以下を設定しておくと便利です。
git config --global fetch.prune true
これにより、
git fetchgit pull
を実行するたびに、
不要なリモート追跡ブランチを自動で削除 してくれます。
よくある勘違いポイント
- ❌
git branch -aに出ている = GitHub に存在する - ⭕ 実際は「ローカルに残っている情報」なだけ
Git は「安全側」に倒れる設計のため、
勝手にブランチを消さない のが仕様です。
まとめ
- GitHub で消したブランチが
git branch -aに残ることがある - 原因はローカルのリモート追跡情報のズレ
- 解決方法はこれだけ👇
git fetch --prune
- 定期的にズレを防ぐなら
fetch.prune = trueを設定
