DNS ツール
キャッシュ階層としてのDNSの捉え方、レコード種別、TTLと切り替え・切り戻しの段取り、委任、SPF/DKIM/DMARCのTXTレコードを実務目線で整理し、名前が引けないときにどのツールで何をどこまで確認できるかをまとめたリファレンスです。
1 ツール
DNSはデータベースではなくキャッシュの階層
「レコードを変更する」とは権威ネームサーバー上のゾーン1つを書き換えることですが、そのゾーンを直接読む利用者はいません。答えを返すのは再帰リゾルバ(ISP、8.8.8.8、社内リゾルバ、ブラウザ自身のDoH)で、各々が独立した期限でコピーを持ちます。権威の答えは1つ、キャッシュされた近似はN個、さらに手元のOSキャッシュと/etc/hostsが最優先されます。
名前解決はルートから.com、そしてレジストラが公開したNSへと委任をたどり、各段もTTLを持つキャッシュ対象です。TLD側のNSは通常1〜2日キャッシュされるため、DNS事業者の移行はAレコード変更とは別物で、旧事業者にも長く問い合わせが届きます。「伝播」は不正確で、古い答えが期限切れになるだけです。NXDOMAINもSOA由来の時間(多くは300〜3600秒)キャッシュされ、作成後も数分「存在しない」と見えます。
実務で触るレコード種別
| 種別 | 内容・用途 | 注意点 |
|---|---|---|
A | IPv4アドレス1つ | 複数指定はラウンドロビンでフェイルオーバー不可 |
AAAA | IPv6アドレス1つ | 壊れたAAAAはIPv6優先クライアントを壊す |
CNAME | 別名(CDN/SaaS) | apex不可。他レコードと共存不可 |
MX | メールホスト+優先度 | 小さい数値が優先。IPではなくホスト名 |
TXT | 自由文字列(SPF/DKIM/DMARC/所有確認) | 1文字列255文字。長い鍵は分割される |
NS | 委任先ネームサーバー | 効くのは親(TLD)側の内容 |
SOA | タイマーとシリアル | MINIMUMがNXDOMAINの保持時間 |
PTR | アドレス→名前(逆引き) | IPv4はin-addr.arpa、IPv6はip6.arpa配下。IP保有者の領域 |
CAA | 発行を許可するCA | 参照は証明書発行時のみ |
DS / DNSKEY | DNSSECの信頼点 | 鍵更新後の不整合で解決が全滅 |
TTL・切り替え・切り戻しの窓
数分で向き先を変えうるレコードは60、移行中は300〜900、平常運用は3600、触らないNS/MXは86400。短いTTLは問い合わせ量が増え、権威サーバー不通時の猶予も減ります。キャッシュされたTTLは復旧時間の下限でもあり、TTL 300秒なら公開後5分は一部リゾルバが停止先へ送り続け、月2回で約10分のダウンタイム。許容範囲かはSLA稼働率計算で確認できます(99.99%は30日で4.3分)。SRE向けツールも参照。
SPF・DKIM・DMARCがそれぞれ示すもの
| 方式 | 公開場所 | passが示すこと | 示さないこと |
|---|---|---|---|
| SPF | ドメインのTXT(v=spf1 …) | 接続元IPがエンベロープMAIL FROMのドメインで送信してよいこと | 表示From:については何も示さない。単純転送で壊れる |
| DKIM | selector._domainkey.domainのTXT(v=DKIM1; p=…) | d=が署名して以降、対象ヘッダーと本文が改変されていないこと | d=が自ドメインである保証。未署名ヘッダーは後から追加できる |
| DMARC | _dmarc.domainのTXT(v=DMARC1; p=…) | SPFかDKIMのpass、かつそのドメインがFrom:とアラインメントしていること | 強制力。p=noneはレポートを求めるだけ |
3つのうちツールで直接引けるのはapexのSPFだけです。DNS LookupのTXTタブには公開中のv=spf1が出ますが、受理されるのはホスト名ラベルのみで、_dmarc.example.comやselector._domainkey.example.comのようなアンダースコア名はInvalid domain formatとして弾かれます。これらはdig TXT _dmarc.example.comかDNS事業者のゾーン編集画面で確認してください。受信側がどう判定したかは別問題で、メールヘッダー解析が配信済みメールのAuthentication-Results・Received-SPF・DKIM-Signature・ARCヘッダーから読み取ります。ip4:を足す前にIPアドレス確認で実際の送出元を確認し、組み直したp=はBase64に貼ればパディング破損や不正文字を検出できます。詳細はメールハブ。
どの場面でどのツールを使うか
ドメイン名があるならDNS Lookup。A・AAAA・CNAME・MX・TXT・NSを1回で解決し、TYPE / NAME / VALUE / TTLにMX優先度を添えて表示します。種別タブは取得済みの行をクライアント側で絞り込むだけなので、MXとTXTを行き来しても再照会は起きません。CNAME専用のタブはないため、その名前が別名か実アドレスかを示すCNAME行はALL表示で確認します。ステータスバーは表示どおりに読んでください。SERVERは常にapi.sitekits.dev、LATENCYはブラウザ→APIの往復時間であり、実際に応答した再帰リゾルバでも名前解決自体の所要時間でもありません。解決はサーバー側からCloudflare DoH経由で走るので、手元のキャッシュでは得られない外部視点にはなりますが、どのリゾルバが答えたかを特定したいときはdig @8.8.8.8 example.comのように直接問い合わせます。URLしかなければURLパーサーでポートを含むhostとhostnameを分離(通信なし)。
レコードは正しいのに配信内容が違うなら、問題はDNSではありません。HTTPヘッダー確認はサーバー側から取得してステータス・リダイレクトチェーン・全ヘッダーを返し、「まだ旧IP」か「IPは正しくCDNのキャッシュが古い」かを切り分けます(本文は取得せず、プライベートアドレスは拒否)。非ASCIIの名前はIDN / Punycode変換で実際に問い合わされるxn--形を確認でき、homograph判別にも使えます。AAAAはIPv6アドレス圧縮で表記を揃えてから比較し、移行前後のレコード一覧はテキスト差分で突き合わせます。
時間を溶かす落とし穴
apexのCNAME
example.comはSOAとNSを持つ必要があり、CNAMEは同名で他レコードと共存できません。管理画面が通してもapexのCNAMEは仕様違反で、ALIAS/ANAMEやフラット化は事業者独自の機能です。
SPFレコードを2つ置く
同じ名前にv=spf1のTXTが2つあるとpermerrorになります。全メカニズムを1レコードに統合し、参照回数を数えます。include:・a・mx・ptr・exists・redirect=がそれぞれDNS参照を1回消費し、評価1回あたり合計10回が上限です(RFC 7208 §4.6.4)。ベンダーのinclude:を重ねると気づかず超過します。
相対名と末尾ドットの欠落
ゾーンファイル記法では末尾ドットのない値は相対名で、www.example.comはwww.example.com.example.com.になります。自動補完するUIにFQDNを貼ると起こります。
放置レコードによるサブドメイン乗っ取り
削除したバケットやPaaS、CDNのホスト名へCNAMEが向いたままだと、その名前を取得した第三者にサブドメインを使われます。撤収時はレコードも消すこと(セキュリティ向けツール)。