■DNS温泉#4

2017/09/16(Sat.) 13:00 - 2017/09/17(Sun.) 12:00
@加賀温泉 山下屋 7F 宴会場

13:30 - DNS基礎のおさらい

アプリ( スタブリゾルバ)からフルリゾルバ(DNSキャッシュサーバ)へ名前解決要求。
root hintを参照(13系列のルートサーバのリスト)し、その中の1つに問い合わせる。

※「.」と表記されるが、実態はnull

root(.)→jp→example.jp(権威サーバ・ゾーンサーバ)→www.example.jpの順でフルリゾルバは参照する。
一度名前解決した名前はキャッシュされる(セントラルキャッシュ)。

委任（移譲)delegation →名前空間の管理を任せること

DNSコンテンツサーバ … rootや権威サーバのこと
DNSキャッシュサーバ … 名前解決要求をコンテンツサーバに行うサーバ

+ 反復(Iterative)問い合わせ …
キャッシュサーバからみたroot(.)→jp→example.jp(権威サーバ・ゾーンサーバ)→www.example.jpの名前解決の流れ

+ 再帰(recursive) … スタブリゾルバからみたキャッシュサーバへの名前解決要求の流れ

再帰終了の条件 … ANSWERが帰ってくること

Recursion Desireフラグ(RD)=1 : 再帰処理であることを表す
RD=0: 反復処理であることを表す

DNSプロキシもフルリゾルバもフォワーダーと呼称される
どちらかというとフルリゾルバをフォワーダーと呼称するほうが正しい。

IN (Internet class)

資料
http://www.e-ontap.com/misc/virtualtomocha/#(1)
http://sim.internot.jp/

●VITOCHAの説明
ツール説明のため省略

unboundのqname-minimizationを有効化すると、各権威サーバにNSを聞きに行くという従来では間違っているとされていた動作になる

●RFC2308
・QNAME
従来:クエリの名前(シンプル)
RFC2308: CNAMEの連鎖の先にある名前

そもそもRFC2308はキャッシュのことを言っているのか権威サーバのことをいっているのかわからない。

世の中のキャッシュサーバと権威サーバの実装のほぼすべてがRFC2308に従っている。

・否定応答
RefferalはStatusがNO ERRORになる
NXDOMAIN……　QNAMEが存在しない

Header:

RDCODE=NOERROR
Query:
AN.EXAMPLE. A
Answer:
AN.EXAMPLE. CNAME TRIPPLE.XX.
Authority:
XX. NS NS1.XX.
XX. NS NS2.XX.
Additional:
NS1.XX. A 127.0.0.2
NS2.XX. A 127.0.0.3

NODATA は RCODE が NOERROR で Answer Section に妥当な Answer がないことで示される。

http://www.e-ontap.com/dns/onsen4/

キャッシュの TTL は SOA の MINIMUM フィールドと SOA 自身の TTL の小さい方にセットされ、否定回答をどれくらいキャッシュしていてよいかを示す。

権威サーバは、SOAレコード自身のTTLもしくはMinimum TTLどちらか小さい方を否定応答のTTLとして採用する。

●夜の部
・co.jp TXTレコード追加の謎
https://www.slideshare.net/goto_ipv6/cojptxt

・DNSリクエストが中国を経由するとどうなるか？
SI案件でVPN接続しようとしたら、先方からは正しく引けるのに、自社から正しい結果が帰ってこない。

root→*.dns.jp→clala.net.cn（中国？）

openvpn.*を含むと無条件に変なIPアドレスを返してくるらしい。
そもそも中国のroot DNSサーバの挙動もあやしい。
→検閲のためにでたらめなIPアドレスを返している？


●DNSSECとKSKロールオーバー
http://www.e-ontap.com/dns/DNSSEC-seminar2017.pdf
ゾーンデータを署名し、ゾーンデータが改ざんされていないことを保証する。
ZSK(Zone Signing Key)という秘密鍵で暗号化し、公開鍵で復号できれば正当性が保証される。
その公開鍵自体の正当性の保証のためにKSK(Key Sharing Key)という別の秘密鍵で暗号化し、その公開鍵をハッシュ化する。そのハッシュ値を上位ゾーンへ登録。

・なぜKSKが必要なのか？
当初はKSKなんてものはなかった。（ZSKのみ）

安全性の高い鍵(ZSK)を使おうとすると、鍵長も署名も(=応答)が大きくなる。
DNSの思想としては、応答をなるべく小さくしたい。
鍵長の小さな鍵(ZSK)を使おうとすると、安全性が低くなるのでセキュリティ上頻繁に鍵を交換する必要が出てくる。
→どっちにしろめんどくさい。

・KSKの導入
ZSKを暗号化するKSKは安全な鍵長にし、取り替える頻度を減らす。
ZSKは鍵長を短くする代わりに高い頻度で取り替える。

RRSET … データ
RRSIG … 署名

・信頼の連鎖
バリデーター(リゾルバ）が予めルートサーバの公開鍵ないしハッシュ値を信頼している（ルートKSK）

※HTTPSでブラウザがルート証明書を信頼しているのと同様

・KSKロールオーバー

9/19 古いKSK+新しい+KSK+新しいZSK（KSKとZSKの更新タイミングが被る）
→DNSKEYレスポンスが増大する（準備期間）

10/11 新しいKSKでルートゾーンの署名開始(実際に署名が始まる日）
なので、どちらかというと10/11を心配するべき。
うまく行くかは祈るしかない。

KSK鍵更新自体はRFC5011に定義されているが、準拠しているといっても実際の実装がどうなっているかは正直わからない。


応答サイズ増大によってIPv6やVPNなどでMTUオーバーして通信に問題が発生する可能性がある

・対策
・DNSサーバを最新版にする（BINDとか、Unbound等では最新版には新KSKが内蔵済み）
・キャッシュDNSサーバにおいて、DNSSECのトラストアンカーの自動更新の設定を行う。（必ず新DNSKEYが取り込まれたことを確認する。）

データ量増大に対応するために、
①「キャッシュDNS サーバー」において、UDP 受信サイズを4096 バイト
の検索結果が受信できる設定（RFC6891 による推奨設定）を行うことが言われているが、実際には4096に設定することで問題が起きる可能性の方が高い。

DNSSEC が有効かどうかを確認する方法：
・確認したいキャッシュDNSサーバーに対して問い合わせる
→有効なら RRSIG が入って返ってくる

フラグメントすることそのものが問題なのではない。
ICMP Unreachableがドロップされたことにより、通信できなくなるケースもある。

Firewallでフラグメントしたパケットの通過を禁止している運用の場合などで、フラグメントした後続のパケットがDropされる

様々なネットワークに起因するトラブルは UDP サイズを大きくすることにより発現しやすく、むしろ安全な UDP サイズを越えないよう TCP フォールバックしたほうが無難
MTU は 1500 より 1280 (IPv6 最小 MTU) とみたほうが安全

さっさとTCPフォールバックさせる。ただし、TCP 53ポートが空いていることが条件だが、現在ではTCP 53が空いていることはBIND等では必須とされている。

●Exampleから読み解くRFC5155
資料:http://www.e-ontap.com/dns/onsen4/rfc5155.html#(1)


1. 最近接名 (closest closer) にマッチする NSEC3
a.c.x.w.example の 最近接名 (最長一致の実在する名前) は x.w.example である。


NSECは前後のドメイン名を示すことで不在証明で
NSEC3はドメイン名のハッシュ値をソートしたもの前後を示すことでの不在証明