HEADLINE

HEADLINE


【digでTXTレコードを確認する方法】DNS設定後に反映確認

digでTXTレコードを確認

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

whisper.cpp を Visual Studio 2022 でビルドする方法

remoted で問題が起きました。 | macOS Tahoe 26.2

monitoring timed out for service: remoted

MacBook (Intel 版) 起動時、「remoted で問題が起きました。」ダイアログが表示される。

remoted はユーザーが入れたアプリではなく、macOS 標準のシステムデーモンということらしい。
エラーは「Mac起動時に remoted が一時的に応答しなかった」ものでした。


remoted って何?

remotedApple純正のバックグラウンド常駐プロセスで、下記の機能を担当しているようです。

  • 🎮 Bluetooth / 外部デバイス連携
  • 📱 Sidecar(iPadをサブディスプレイにする機能)
  • 🖱 Universal Control(MacとiPadを1つのマウス・キーボードで操作)
  • 🎧 AirPlay / 外部入力系の仲介

つまり
👉 「周辺機器・リモート系の橋渡し役」という立ち位置のシステムサービスです。


今回のエラー内容を噛み砕くと

WATCHDOG timeout
monitoring timed out for service: remoted
device not responsive

  • macOS 起動直後
  • remoted が 60秒間 応答しなかった
  • 監視役(watchdog)が「固まってる」と判断して記録

💡 **クラッシュというより「起動時のもたつき」**に近いです。

特に今回は

  • ディスプレイ OFF
  • 起動から約80分後にログ採取
  • 熱状態も正常

なので、深刻度は低めです 名称未設定


よくある原因

これは珍しくないパターンで、だいたい次のどれかです。

  • 🔌 起動時に Bluetooth / USB 機器が大量につながっている
  • 🖥 外部ディスプレイ・ドック・ハブ
  • 📱 iPad / iPhone が近くにあって Universal Control 初期化
  • 💤 スリープ復帰直後のタイミング被り
  • 🧪 macOSの軽い不具合(特にメジャーアップデート直後)

アップデート待つしかなさそうかな

【Git】git branch -a に残る削除済みリモートブランチの正体と解消方法

git branch -a に残る削除済みリモートブランチ

Git を使って開発していると、
GitHub 上では消えているはずのブランチが、ローカルでは残って見える
という現象に遭遇することがあります。

error: unable to delete 'feat/base': remote ref does not exist
error: failed to push some refs

発生した状況

以下のような流れで問題が起きました。

  1. git branch -a を実行
  2. remotes/origin/feat/base が表示される
  3. GitHub の Web サイトを見ると、そのブランチはすでに削除済み
  4. 削除しようとして以下を実行
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 fetch
  • git pull

を実行するたびに、
不要なリモート追跡ブランチを自動で削除 してくれます。


よくある勘違いポイント

  • git branch -a に出ている = GitHub に存在する
  • ⭕ 実際は「ローカルに残っている情報」なだけ

Git は「安全側」に倒れる設計のため、
勝手にブランチを消さない のが仕様です。


まとめ

  • GitHub で消したブランチが git branch -a に残ることがある
  • 原因はローカルのリモート追跡情報のズレ
  • 解決方法はこれだけ👇
git fetch --prune
  • 定期的にズレを防ぐなら fetch.prune = true を設定