DNSレコードの種類（A, CNAME, TXT）とDoH（DNS over HTTPS）の仕組み

DNS（Domain Name System）は、人間が理解しやすいドメイン名（devutils.run）を、マシンが通信可能なIPアドレスへ変換する全世界規模の階層型分散データベースです。ユーザーがブラウザにURLを入力すると、以下の4階層を経て目的のIPアドレスが特定されます：

1. 再帰リゾルバー（Recursive Resolver）: ISPやCloudflare（1.1.1.1）、Google（8.8.8.8）が運用し、クライアントに代わって世界中のネームサーバーを再帰的に巡回します。
2. ルートネームサーバー（Root Nameserver）: 世界中に配置された論理的に13組の最上位サーバーで、トップレベルドメイン（.runや.com）に応じたTLDネームサーバーの場所を案内します。
3. TLDネームサーバー: 対象ドメインのレジストリが管理し、そのドメインの権威ネームサーバー情報を返します。
4. 権威ネームサーバー（Authoritative Nameserver）: ドメイン所有者が設定した実際のDNSレコード（AレコードやCNAMEレコード）が保持されている最終到達点です。

• Aレコード: ドメイン名をIPv4アドレス（例: 192.0.2.1）にマッピングします。
• AAAAレコード: ドメイン名を128ビットの次世代IPv6アドレス（例: 2001:db8::1）にマッピングします。
• CNAME（Canonical Name）: あるドメインを別の正規ドメイン名のエイリアス（別名）として関連付けます。RFC仕様上、Zone Apex（サブドメインのないルートドメイン）にはCNAMEを直接設定できないため、CNAME Flattening技術が利用されます。
• MX（Mail Exchange）: そのドメイン宛てのメールを受信するメールサーバーのホスト名と優先度（Priority）を指定します。
• TXT（Text）: 任意の文字列データを登録でき、ドメイン所有権の証明やメール偽装防止ポリシーの宣言に広く活用されています。
• CAA（Certificate Authority Authorization）: 自ドメインに対してSSL/TLS証明書を発行できる認証局（Let's Encryptなど）を限定し、不正発行を防止します。

標準のメールプロトコル（SMTP）は、送信元アドレス（From:）を容易に偽装できる構造的弱点を抱えています。このなりすまし被害を根絶するために、3大DNSセキュリティレコードが不可欠となっています：

1. SPF（Sender Policy Framework）: 自ドメインに代わってメールを送信することを許可された正規のサーバーIPや外部サービス一覧をTXTレコードで宣言します。
2. DKIM（DomainKeys Identified Mail）: 送信側メールサーバーがメール本文とヘッダーに秘密鍵で電子署名を付与し、受信側サーバーはDNSのTXTレコードに公開された公開鍵で署名を検証して改ざんを検知します。
3. DMARC: SPFやDKIMの検証に失敗した不正メールを受信側がどう処理すべきか（none無視、quarantine隔離、reject受信拒否）を指定し、集計レポートを受信します。

// SPFレコードの設定例 (TXT @)
v=spf1 include:_spf.google.com ~all

// DMARCポリシーの設定例 (TXT _dmarc)
v=DMARC1; p=reject; rua=mailto:dmarc-reports@devutils.run; pct=100; adkim=s; aspf=s

歴史的なDNS問い合わせは、暗号化されていないUDP 53番ポートを使用して平文で伝送されてきました。このため、公共Wi-Fiの管理者や中継ISPがユーザーの閲覧ドメインを容易に盗聴（スヌーピング）できたり、偽のIPアドレスを応答するDNSスプーフィング攻撃に晒される危険がありました。

• DoT（DNS over TLS）: 専用のポート853番を使用して、DNS通信全体をTLSトンネル内で暗号化します。
• DoH（DNS over HTTPS）: 標準のWebトラフィックと同じポート443番を使い、通常のHTTPS通信の中にDNSクエリをカプセル化して伝送します。一般的なHTTPSトラフィックとポートが同一であるため、中間ネットワークによるパケットの盗聴や不正な改ざんを非常に困難にします。

DNSのパフォーマンスと可用性は、TTL（Time to Live）の戦略的なチューニングによって大きく左右されます：

• 短いTTL（60〜300秒）: データセンターの移行、ブルーグリーンデプロイ、動的フェイルオーバーを行う際に推奨されます。変更が数分で全世界に行き渡る反面、権威ネームサーバーへの問い合わせクエリ数は増加します。
• 長いTTL（86400秒 / 24時間）: 変更頻度が極めて低いMXレコードやSPF、安定した基幹インフラに適しています。リカーシブリゾルバーのキャッシュヒット率を高め、クライアントのDNS問い合わせ遅延を極小化します。
• ネガティブキャッシュ（SOA MINIMUM）: ドメインが存在しないことを示すNXDOMAIN応答をリゾルバーがキャッシュする期間です。レコード追加前にクライアントが先行してアクセスすると、失敗がキャッシュされて反映が遅延する原因となります。
• Digによる名前解決の追跡: OSキャッシュをバイパスしてdig +trace devutils.runを実行したり、DevUtilsのDNS Lookupツールを活用することで、ルートサーバーから権威サーバーまでの委任経路を完全にトレースできます。

# ルートサーバーから権威サーバーまでの完全な委任ルートを追跡
dig +trace devutils.run A

# ローカルキャッシュを無視してCloudflare（1.1.1.1）へ直接問い合わせ
dig @1.1.1.1 devutils.run A +short