331.4 DNSと暗号化
課題 331: 暗号化
331.4 DNSと暗号化
LPIC303の試験範囲である主題331～335まであるうちの「331 暗号化」から「331.4 DNSと暗号化」についてのまとめ
総重量：5
説明：
BINDを利用した際の、DNSの背景と実装について、暗号化の知識と経験がある。BINDのバージョンは9.7とそれ以上を対象としている。主要な知識範囲：
DNS・ゾーン・リソースレコードの概念を理解している。
鍵署名鍵、ゾーン署名鍵、DS, DNSKEY, RRSIG, NSEC, NSEC3, NSEC3PARAMなどの関連するDNSレコードを含み、DNSSECを理解している。
DNSSECセキュアゾーンを提供している権威のあるネームサーバとしての、BINDの設定をトラブルシューティング。
DNSSECの署名されたゾーンを管理する。これには、キー生成・キーのロールオーバー・ゾーンの再署名が含まれます。
クライアントの振る舞いがDNSSECバリデーションとして機能する、再帰ネームサーバとしてBINDを設定する。
CAAやTLSAのようなDNSレコードに関連する、CAAとDANEの理解。
DNSで、X.509証明書と認証局/CAの情報を発行する、CAAとDANEを利用する。
BINDでセキュアな接続を行うため、TSIGを利用する。
DNS over TLSとDNS over HTTPSの知識。
マルチキャストDNSの知識。
重要なファイル、用語、ユーティリティ：
named.conf
dnssec-keygen
dnssec-signzone
dnssec-settime
dnssec-dsfromkey
rndc (関連するサブコマンドを含む)
dig
delv
openssl (関連するサブコマンドを含む)
DNS・ゾーン・リソースレコードの概念
DNS
Domain Name Service の略
ホスト名とIPアドレスの対応についてのデータベースを保持している
ゾーン
ゾーン=ドメインに相当する
ゾーンは権威サーバーで管理されている
リソースレコード(RR)
ゾーンで管理されているレコードで、SOA、NS、MX、A、CNAME などがある。
DNSSECではこのリソースレコードについて公開鍵暗号とデジタル署名の技術を使って正当性を確保している。
DNSSECを理解
DNSSECとは
DNSキャッシュサーバーがDNS権威サーバーに問い合わせた際の応答について、正当な権威サーバーであることや、権威サーバーが応答した内容が改ざんされていないことを検証する
- 出自の認証：DNS応答が正当なドメイン管理者が発行したものである
- 完全性の保証：DNS応答が改ざんされていないDNSキャッシュポイズニング攻撃への対策となる
公開鍵暗号とデジタル署名の技術によてDNS応答が正当であるかを検証する
権威サーバーでは、リソースレコードに対して秘密鍵でデジタル署名をする
キャッシュサーバーでは、受け取ったリソースレコードを公開鍵で復号し正当なものであるかを確認する
「信頼の連鎖」という仕組みで実現している
キーワード
ZSK(Zone Signing Key)
ゾーンを署名する鍵KSK(Key Signing Key)
ZSKの公開鍵を署名する鍵DS(Delegation Signer)
上位の権威DNSサーバーに登録する情報
コマンド
dnssec-keygen
ZSKの公開鍵と秘密鍵を作成する
KSKの公開鍵と秘密鍵を作成する(-f KSK)dnssec-signzone
ゾーンファイルに署名をする
手順
DNSサーバーを名前解決できる状態に構築する
`dnssec-keygen` コマンドでZSKを作成する
dnssec-keygen -K /var/named/DNSSECkeys -a RSASHA256 -b 1024 -P now -A now -I +1mo -D +2mo example.co.jp`dnssec-keygen` コマンドでKSKを作成する
dnssec-keygen -K /var/named/DNSSECkeys -a RSASHA256 -b 2048 -f KSK -P now -A now -I +1mo -D +2mo example.co.jp`dnssec-signzone` コマンドでゾーンファイルに署名をする
dnssec-signzone -S -K /var/named/DNSSECkeys -d /var/named/DNSSECkeys -H 3 -3 'd0ec' -N unixtime -P -o exa
mple.co.jp /var/named/example.net.zone
各RRに対してRRSIG、DNSKEYなどのレコードが追加される`dnssec-dsfromkey` コマンドでDSレコードを生成する
dnssec-dsfromkey <KSK公開鍵>`dig`コマンドで検証する
dig @127.0.0.1 example.co.jp +dnssec
dig @127.0.0.1 example.co.jp +nodnssec
DNSSECのリソースレコード
DNSKEY
KSKとZKSの公開鍵DS
子ゾーンのKSKを親ゾーンに承認されていることを示すRRSIG
各RRへの署名NSEC
存在しないドメイン名を偽装されたときのために「存在しないこと」を示すためのレコードNSEC3
ドメイン名をハッシュ化したもの
NSECレコードをたどるとゾーンデータが入手できてしまうことへの対策NSEC3PARAM
権威DNSサーバー側がNSEC3の生成に必要なレコード
参考
権威のあるネームサーバとしての、BINDの設定をトラブルシューティング
rndcコマンド
validation [ on | off | status ] [view]
DNSSEC関連サブコマンド
dnssec -checkds [-key id [-alg algorithm]] [-when time] (published|withdrawn) zone [class [view]]
dnssec -rollover -key id [-alg algorithm] [-when time] zone [class [view]]
dnssec -status zone [class [view]]
署名関連サブコマンド
sign zone [class [view]]
signing -clear all zone [class [view]]
signing -clear <keyid>/<algorithm> zone [class [view]]
signing -list zone [class [view]]
signing -nsec3param hash flags iterations salt zone [class [view]]
signing -nsec3param none zone [class [view]]
signing -serial <value> zone [class [view]]
TSIG関連サブコマンド
tsig-delete keyname [view]
tsig-list
トラストアンカー関連サブコマンド
nta -dump
nta [-lifetime duration] [-force] domain [view]
nta -remove domain [view]
digコマンド
DNS lookup utility
Ubuntu22.04：bind9-dnsutils
RockyLinux9：bind-utils
delvコマンド
DNS lookup and validation utility
digコマンドの後継
Ubuntu22.04：bind9-dnsutils
RockyLinux9：bind-utils
参考
DNSSECの署名されたゾーンを管理
＜・・・調査中・・・＞
再帰ネームサーバとしてBINDを設定する
再帰ネームサーバ：recursive name server
再帰DNSの利点とは？
一般に、再帰DNSクエリは、反復クエリよりも速く解決する傾向があります。これはキャッシュによるものです。再帰DNSサーバーは、実行するすべてのクエリに対する最終回答をキャッシュし、その最終回答を一定時間（ Time-To-Liveとして知られる）保存します。
再帰リゾルバーは、既にキャッシュにあるIPアドレス向けのクエリを受信すると、他のDNSサーバーと通信することなく、キャッシュされた回答をクライアントにすばやく提供できます。a）DNSサーバーが多くのクライアントにサービスを提供している場合、および/またはb）要求されたWebサイトが非常に人気がある場合、キャッシュから応答を迅速に提供する可能性が非常に高くなります。
再帰DNSの欠点とは？
残念ながら、オープンDNSサーバーで再帰DNSクエリを許可すると、攻撃者がDNSアンプ攻撃および DNSキャッシュポイズニングを実行できるため、セキュリティ上の脆弱性が発生します。
※DNSアンプ攻撃＝DNSリフレクション攻撃
named.confの設定例
例1) 再帰検索要求は受け付けない設定
//一部抜粋
options {
version "unknown"; //BINDのバージョン情報を公開しない
recursion no;
allow-query { any; };
};例2) 再帰検索要求を受けるクライアントを制限する設定
192.168.1.0/24からのみ再帰検索要求を受け付ける
//一部抜粋
options {
version "unknown"; //BINDのバージョン情報を公開しない
recursion yes;
allow-query { 192.168.1.0/24; };
};参考
CAAとDANEの理解
CAA
Certification Authority Authorization
ドメイン名の登録者が、登録されたドメイン名に対応する証明書の発行を許可する認証局（Certification Authority：CA）を指定するリソースレコードです。CAAは、Certification Authority Authorizationを意味します。
ドメイン名登録者は、CAAリソースレコードを設定することで
・証明書の誤発行を防止
・不正な証明書発行要求の検知
が期待できます。
DANE
DNS-Based Authentication of Named Entities
TLSにおける機能の1つである「通信先の認証」をDNSで行うという仕組みです。
一般的なTLSの通信の例を挙げると、あるドメインを指定してWebページにアクセスした際、クライアントがサーバからサーバ証明書を受け取り、接続したドメインの所有者が正しい所有者であるかということを検証します。DANEはこの「接続したドメインの所有者が正しい所有者であるか」をDNSを利用して検証する仕組みです。
参考：CAA
参考：DANE
CAAとDANEを利用する
CAAレコード
ドメイン名 IN CAA <flags> <tag> <value>
flags
tag
- issue：サーバー証明書を発行するCA認証局
- issuewild：ワイルドカード証明書を発行するCA認証局
- iodef：連絡先value
タグに対応する値
example.com. IN CAA 0 issue "letsencrypt.org"DANE
＜・・・調査中・・・＞
参考：CCA
TSIGを利用する
ゾーン転送で改ざんを回避する仕組み
共有する秘密鍵とDNSメッセージから生成されるMAC(Message Authentication Code)をマスター/スレーブ双方で比較
手順
`dnssec-keygen`コマンドで共有鍵の生成
dnssec-keygen -a HMAC-SHA512 -b 512 -K /var/named/keys -n HOST example.co.jp.key共有鍵の設定
マスター："named.conf" に "key" を登録する
スレーブ："named.conf" に "key" とマスターサーバーを登録する`dig`コマンドで確認
dig @<マスターのIP> -y hmac-sha512:example.co.jp.key:<秘密鍵>
DNS over TLSとDNS over HTTPSの知識
いずれもDNSクエリを暗号化する手段で、それぞれがRFCで規定されている。
DNS over TLS(DoT)
ポート番号：853/tcp
RFC7858
PC用の主要ブラウザでは対応していない
Android9～ 対応しているが実用的ではない
DNS over HTTPS(DoH)
ポート番号：443/tcp
RFC8484
Firefox、GoogleChrome、Microsoft Edgeが対応
iOS、macOS、Androidでも利用可能
参考
マルチキャストDNSの知識
マルチキャストDNS(mDNS)
コンピュータネットワークにおいて、マルチキャストDNS(mDNS) はローカルネームサーバーの存在しない小さなネットワーク内でホスト名からIPアドレスを解決するプロトコルである。
DNSが存在しないLAN内での名前解決で使われる
Appleが開発しRFC6762で規定
ポート番号：5353/udp
IPマルチキャストグループ：224.0.0.251/IPv4, ff02::fb/IPv6
TLDは .local
Linux(Ubuntu22.04、RockyLinux9)：avahi-browse コマンド
Windows：dns-dsコマンド
スマートスピーカーなどコマンド操作ができない端末の探索ができる
この記事が気に入ったらサポートをしてみませんか？