導入
セキスペの問題でDNSの知識を問われる問題があり、これはまずいと思ったので使えそうな情報をまとめる。
ちなみにまずいと思ったのは令和3年春午後1問2。6割はギリ取れたけど自信なかった。
DNSSEC
DNSSEC は、DNSサーバから返されるリソースレコード（Aレコード、MXレコードなど）に対して、デジタル署名を付与し、
・そのデータが改ざんされていないか（完全性）
・そして正当なDNSサーバから送られてきたか（送信者の正当性）
を検証する技術。
DNS over TLS(Dot)
スタブリゾルバ（PC）とフルサービスリゾルバの間の通信をTLSで暗号化する。
ポート883を使うが、たいていのFWはポート883の通信を許可していないため、許可し忘れると通信が通らない。
なお、宛先IPアドレスは暗号化されないので、問い合わせ先DNSのIPアドレスは盗聴できる。
DNS over HTTPS（DoH）
DoT同様、スタブリゾルバ（PC）とフルサービスリゾルバの間の通信をTLSで暗号化する。
ただし、こちらはポート443を使うため、HTTPS通信を許可しているFWであれば、通信が通る。
一方、通常のHTTPS通信と混在するのでブロッキングが難しくなるともいえる。
DoT VS DoH
| 観点 | DoT（DNS over TLS） | DoH（DNS over HTTPS） |
|---|---|---|
| プロトコル | TCP + TLS（専用） | HTTPS（HTTP/2 or 3） |
| ポート番号 | 853（専用） | 443（Webと共通） |
| 主な利用場所 | ルーター、OSレベル、DNSリゾルバ | ブラウザ、アプリ（Chrome, Firefoxなど） |
| 監視・フィルタ | 比較的しやすい（DNSとして扱える） | 難しい（Web通信にしか見えない） |
| ファイアウォールとの相性 | 専用ポートゆえにブロックされやすい | Webと同じなので検閲回避に強い |
| 速度や軽さ | 軽い（HTTPヘッダなし） | 重い（HTTPヘッダ付き） |
| 標準化 | RFC 7858（IETF標準） | RFC 8484（IETF標準） |
| プライバシー強度 | 高い（内容は暗号化） | 同等以上（HTTPSにカモフラージュ） |
正引きゾーンファイル
「このドメイン名はこのIPアドレスだよ」とかの情報を管理するファイル。
たとえば example.com というドメインがあったとき、次のような情報がゾーンファイルに書かれる。
$TTL 3600
@ IN SOA ns1.example.com. admin.example.com. (
2025072901 ; シリアル番号
3600 ; リフレッシュ間隔
1800 ; リトライ間隔
604800 ; 有効期限
86400 ; 最低TTL
)
IN NS ns1.example.com.
IN NS ns2.example.com.
www IN A 192.0.2.1
mail IN A 192.0.2.2
@ IN MX 10 mail.example.com.
| コード | 意味 |
|---|---|
| ns1.example.com. | ゾーンを管理しているプライマリDNSサーバー |
| ns2.example.com. | ゾーンを管理しているセカンダリDNSサーバー |
| admin.example.com. | 管理者のメールアドレス（@ はドットに変える） |
| 2025072901 | シリアル番号（変更時に更新） |
| 3600 | セカンダリが情報を確認する間隔（秒） |
| 1800 | セカンダリが失敗したときの再試行間隔 |
| 604800 | ゾーン情報の有効期限 |
| 86400 | 最低TTL（キャッシュの生存時間） |
| IN NS ns1.example.com. | example.comの情報はns1.example.com.が持っているよ |
| IN NS ns2.example.com. | example.comの情報はns2.example.com.も持っているよ |
| www IN A 192.0.2.1 | www.example.com →192.0.2.1 |
| mail IN A 192.0.2.2 | mail.example.com → 192.0.2.2 |
| @ IN MX 10 mail.example.com. | example.com宛のメールはmail.example.comへ |
ゾーン転送（Zone Transfer）
DNSには複数の権威DNSサーバ（Primary／Secondary）が存在し、それらが同じゾーン情報（ドメイン名とIPの対応情報など）を持つ必要がある。
このとき、プライマリDNS（マスター）からセカンダリDNS（スレーブ）にゾーン情報を同期させる仕組みを「ゾーン転送」と言う。
ゾーン転送の種類
| 転送方式 | 説明 |
|---|---|
| AXFR（全転送） | ゾーン全体のデータを一括で送信。初回同期や手動更新時に使う。 |
| IXFR（差分転送） | 差分だけを転送する。効率的な同期。 |
ゾーン転送のリスク
DNS側で制御していない場合、外部からDNSへゾーン転送を依頼し、情報を得ることができてしまう。
転送依頼はPCのコマンドラインとかで簡単に可能。
dig @ns.example.com example.com AXFR
転送できると、サブドメイン含めた各ドメインのIPアドレス一覧（開発用ドメインなどの非公開含む）といった情報が流出してしまい、攻撃の足掛かりとなってしまう。
対策
allow-transferで転送先を制限。
zone "example.com" {
type master;
file "db.example.com";
allow-transfer { 192.0.2.10; }; // ← ここで転送許可先を制限
};
備考
他に覚えるべき情報が見つかれば随時追記。