koie blog : いってきた: DNS温泉番外編(2019年2月)

日時: 2019-02-16 12:00〜17:00
場所: 株式会社ラック本社 (平河町森タワー2F)
イベント告知: https://atnd.org/events/102699
予習資料:
- DNS 温泉 4 教材: http://www.e-ontap.com/dns/onsen4/
  - RFC 2308 要約メモ: http://www.e-ontap.com/dns/onsen4/rfc2308.html
  - RFC 8020 要約メモ: http://www.e-ontap.com/dns/onsen4/rfc8020.html
  - DNSSECの仕組みとKSKロールオーバへの対応: http://www.e-ontap.com/dns/DNSSEC-seminar2017.pdf
  - Example から読み解く RFC 5155: http://www.e-ontap.com/dns/onsen4/rfc5155.html
- DNSSECの仕組みとKSKロールオーバへの対応: http://www.e-ontap.com/dns/DNSSEC-seminar2017.pdf
- DNS第一フラグメント便乗攻撃: http://www.e-ontap.com/dns/ngk2018
#dnsonsen: https://twitter.com/hashtag/dnsonsen
まとめ: https://togetter.com/li/1320001

前日に予習資料に目をとおしておこうとしたのだが、まにあわず。

DNS温泉とは

DNS温泉: 鈴木先生主催呑むついでに話す
DNS補講: 温泉参加者限定
DNS番外編: だれでも

[2019-02-16 12:01]

基礎講座 / 鈴木常彦

DNS温泉5の資料にもとづいて

http://www.e-ontap.com/dns/onsen5
DNSの学び方
- JPRSの本がいちばん正確だが、それでも首をかしげるところも..
- RFC違反の実装もある
- RFCもあやしい
- 自分で考えるしかない
RFC1034,1035,2181,2308,8020(3308の訂正),1912(よくあるまちがい集)
自律分散といいつつICANNを頂点とする階層構造
DNSにいろんなものをつめこめる → DNS camel
ラベルは any binary string (rfc2181) ホスト名は英数とか限定だがドメイン名はなんでもよい
ドメイン名は内部表現上で255オクテットまで。
RRs=Resource Record set (複数のsじゃなくてsetのs)
TTL: how long a RR can be cached. should be discarded.
RDATA: owner,type,class
QNAME minimizationない伝統的なやりかたならroot zone serverにFQDNで問合せる。
stub resolverからfull resolverのあいだは多段になる可能性がある。
誤解するので再帰問い合わせ→再帰検索要求と大学の授業ではいっている (RD flag=1)
full resolver: iterative searchをする。個々の問い合わせは非再帰問い合わせ.(RD=0)
最終回答にはAA bitがたっている。ただし自称AAでしかない。委任されているかどうかが重要。
アプリがDNS RRをキャッシュするのはTTLがわからないので危険。でも攻撃を避けるのにdns rebinding攻撃を避けるためにキャッシュすることもある。
zoneとはなにか？むつかしい。
サブドメインとゾーンのちがい。
- chukyo-u.ac.jpゾーンの親としてのac.jpゾーンはない(昔はあった)。ac.jpがあってもjと管理者が同じなので意味がない。
グルーのはなしは難しいので後半でやるかも。
ゾーンの構成物
- 自分が権威をもつRR
- 頂点 SOA NS
- サブゾーン NS
- サブゾーンNSのA
内部名=下部名 in-bailwick
sibling glue
recursiveはもともとサーバーのモードのことだった昔はcache serverとcontents serverが混在してた
DNS応答5種類 (djbの分類)
- CNAME (別名)
- NXDOMAIN (名前がない)
- NOERROR (成功)
- referral (委任)
- NODATA=(NOERROR+SOA) (名前はあるけどそのタイプはない)

[2019-02-16 13:00]

sibling glueとは
- zone jp.
- zone example.ne.jp.
  - NS ns.example.ad.jp
- zone example.ad.jp.
  - NS ns.example.ad.jp
  - ns A 192.0.2.1
jpサーバに xx.example.ne.jp の問い合わせがあったときにns.example.ad.jp Aを返すことができる=sibling glue。(jpからみたら内部名。sibling domain)
sibling glue <-> strict glue
BINDとNSDはsibling glueを返す実装になっている。
sibling glue: エセグルーとよんでいる。
例:
- www.ctc.co.jp. NS ns1.hs.ctc.jp. 外部名 (a.dns.jpが知らない)
- www.ctc.co.jp. NS ns2.dc.ctc.ad.jp. sibling

[2019-02-16 13:16]

休憩

わざわざ外部名をつかうのはレンタルサーバのIPアドレスが変更になってもだいじょうぶだから、というのがきこえてきた。

[2019-02-16 13:26]

DNS温泉4教材

http://www.e-ontap.com/dns/onsen4/
否定応答
RFC2308は古い問題を引き起している
QNAMEがCNAMEの指す先まで含むことになっている。BINDの実装を追認するRFCになっている?
FORWARDER: もともとfull resolverのこと。proxyのことだけだとおもいがちだが。
NXDOMAINなのにanswerにCNAMEがはいっているのはなぜか？ contentsとcacheが混在しているか2つのゾーンをもっているか。
このRFCにはそもそも正しい(典型的な)NXDOMAINの例が載ってない。
NODATA:疑似応答コード. RCODE=NOERRORでanswerに適切なレコードがないことで示す。
SOAのMINIMUMフィールドとSOA自身のTTLの小さい方がネガティブキャッシュのTTLになる。
dig soa iij.ad.jp.
- iij.ad.jp. 86500 SOA ... 3600
dig wwwwwww.iij.ad.jp @dns0.iij.ad.jp +norec
否定応答ではSOAのTTLはSOAのTTLとminttlの小さい方にセットされるべき。
もし小さい値にセットしない実装があった場合、クライアント側が小さい方を選ばないといけない。
古い実装でNXDOMAINのときに上位のNSを返してくるものがある。example.jp.がjp. NSを返してくるとか。そんなものは信用でいない。簡単に毒入れできてしまう。
server failure: 設定がおかしいときはだまりこむのがいいとおもう(鈴木)。
server failureはTTLが提供されないにもかかわらずネガティブキャッシュしてよいと書いてある。このRFCおかしい。
キャッシュサーバはSOAをちゃんと返す。

RFC2308のおかしいところがRFC8020でやっと訂正された。
タイトル: NXDOMAIN: There Really Is Nothing Underneath
nom.のしたにsub.example.nom.があるけどexample.nom.がない、という場合がある(最近はかなり減った)
pseudoの発音は「スド」
NXDOMAINがかえってきたら、その下はすべて存在しないと扱ってよい。RFC2308を訂正して、もともとRFC1034にもどった。
利益: QNAME minimizationのときに役だつ。
dig ns aws.amazon.com
dig aws.amazon.com @...amazon.com +norec
CNAMEがかえってくる
キャッシュサーバにきくとCNAMEチェインをたどってAまでかえしてくれる。
RFC的にはかえすのはおかしい。
dig com.cdn.amazon.com は権威サーバにといあわせるとNXDOMAINがかえってくるけど、その下にドメインはある。amazonはがんばって撲滅しようとしていらしいが... お客さん向けのはなおしたが、自分達用のはまだ残っている。
unboundでqname-minimisation: yes + qname-minimisation-strict:yes にしてみると、ひけなくなる。
www.chuko-u.ac.jpのNSがxxx.elb.amazonawx.com.になっているのでこまった。
elb.amazonawx.com. TXT を置くようにした。実装はいじらずに。

[2019-02-16 14:30]

cache-min-ttl おおきくしすぎると浸透しなくなる
cache-max-ttl メモリ使用量とのかねあいか？
TTL 0はキャッシュするなという意味。
TTLみじかすぎるとcache poisoningによわい。
TTLの推奨値はRFCにはない。
kantei.go.jp. はTTL 300 にしている(たぶんDoSくらったときに逃げられるように)がjpのサーバは86400をかえしてくる。
DNS温泉番外編2016でくわしくやった。
cache serverはcontents serverのTTLを減算していった値をSOAでstubに返すが、maxできりつめた値を返すかどうかは実装しだい。RFCにはそこまでかいてない。
BINDで孫ゾーンをつくれば子ゾーンをNXDOMAINにできるかも。ゾーン共存サーバの場合。

[2019-02-16 14:51]

休憩

[2019-02-16 15:05]

RFC5155補足資料 / こやね @xkoyane

http://www.convivial.ne.jp/dns/extra2019/rfc5155.pdf
鈴木研究室 B4
VITOCHAアプライアンス(2GBくらいある)をつかうと理解がふかまる。

DNSSEC: RFC4033,4034,4035で規定、キャッシュポイズニング対策
レコード: RRSIG(RRのsign),DNSKEY(pubkey),DS(KSK pubkey hash;上位ゾーンに登録する),NSEC3(ゾーンに存在するレコードをしめすもの)
ZSK: zone signing key, RRを署名するもの
KSK: key signning key, ZSKを署名するもの
ZSKだけで構築すると、鍵長を長くすると応答が大きくなってよくない。鍵を更新するときの手間がかかる。
KSKは鍵長をながくして、ZSKは小さくする。
ルートの公開鍵はcache serverからもってくるか、公開されているものをもってくる。
(KSKロールオーバのはなしは省略)
rfc5155: ゾーン列挙をむつかしくする。
NSECレコードをつかった場合はNSECチェーンをたどってゾーンの名前を列挙できてしまう。
NSEC3レコード: 名前をハッシュ化する
secure delegation: NSのほかにDSもある移譲
insecure delegation: NSだけ。
ENT: empty non-terminal. レコードがないけどサブドメインがあるもの.
.example. IN NSEC3 1 MX RRSIG
flag=1はOpt-Outを意味する。
hash = base32_rfc4648((sha1**iterations)(domain_nameの内部表現 + salt))
ハッシュをもとめるツール: nsec3hash(ISC), ldns-nsec3-hash(NLnet Labs)
ハッシュ整列順: ハッシュ値でソート
不存在証明
dig a.c.x.wexample. @example.koyane.net +norec
closerXXXX name
dig a.c.x.w.example. @example.koyane.net +norec
next closerXXXX name
ワイルドカード
最近接名 closest encloser
Q: dns cookieとかqnameのhashをつかわずにnsec3のようなふくざつなものをつかうりゆうは？
A: 動的に署名するのを避けた(パフォーマンス)。キャッシュサーバの容量節約(範囲でネガティブキャッシュできるとうれしい)。 CDNで肯定応答を動的に署名しているものがあるらしい。
Q: ラベルはany binaryということだったが、正規化はどうしてる?
A: たぶんそのまま。英字は小文字にするとおもう。
Q: cloud flareでrfc4470 NSECをかえしてきたが、なにかわかる？
A: わからん。
opt-out: insecure delegationのやつはNSEC3の生成を省略する。
opt-out=1だとNSEC3で署名されてないかもしれないことを示す。
ENTは省略
Q: sha1なのはなぜ？
A: rfc5155に書いてあるから。長いのはいやだ。NSEC3のフィールドにアルゴリズムは書いてある。あまり強くする必要もない。saltもiterationsも公開されてるし。辞書をつくりにくくするだけ。djbが辞書ツールを公開している。

[2019-02-16 15:56]

第一フラグメント便乗攻撃(アイコラ攻撃) / こやね @xkoyane

http://www.convivial.ne.jp/dns/extra2019/aikora.pdf
IPフラグメントのリアセンブル処理を悪用したもの。
IDがでた。藤原さん https://tools.ietf.org/html/draft-fujiwara-dnsop-fragment-attack-00
権威サーバに偽装した2ndフラグメントをリゾルバおくりつけておく。
EDNSでメッセージサイズが大きくできるようになった。
EDNSはDNSSECとIPv6では必須
unboundはDOビットをつねにセットして要求してくる。(RRSIGかえってきても検証しないならむだになるのに)
フラグメントされると: source port random, ID random,が無効になる
UDPチェックサム
- チェックサムは毎回変化するが、応答内容とフラグメントする位置が固定なら事前に偽造2ndフラグメントをつくっておける。
- 2バイトあればチェックサムは調整できる。4バイトのTTLがつかいやすい。パディングオプションもつかえる。
あんがいフラグメントするほどメッセージを大きくするのはむつかしい。
権威サーバに対して Path MTU discoveryをつっこむのが簡単。ICMP echoをおくりつけたあとICMPをおくる。
PMTUDのキャッシュ時間はlinuxだと10分。
2ndフラグメントのチェックサムがあわないようにして権威サーバをつかえなくさせる攻撃もありえる。
RRSIGをNSに差し替える攻撃: 否定応答を差し替える攻撃になる。
オープンレゾルバ 9.9.9.9 はこの攻撃に脆弱
(ついてくのつらい)
record rankkingが高いのを偽装できるとよりよい。