PowerPoint プレゼンテーション

Size: px

Start display at page:

Download "PowerPoint プレゼンテーション"

たつぞうそや
5 years ago
Views:

1 SIer Developer から見た BIND からの移行 DNS Summer Day 年 6 月 27 日

2 発表者名前佐藤匠 ( さとうたくみ ) 所属三菱電機インフォメーションシステムズ株式会社 (MDIS) 仕事内容 SIer 通信キャリア向けネットワークインフラシステム構築 (RADIUS DHCP DNS)

3 発表者名前矢島崇史 ( やじまたかし ) 所属株式会社 XACK 仕事内容通信キャリア向けのソフトウェア開発 (RADIUS DHCP DNS)

4 XACK DNS 100% 自社開発の DNS サーバー UNIX 系 OS で動作するソフトウェアアプライアンス権威サーバーフルリゾルバーフォワーダー etc... モジュール化による機能の足し引きが可能

5 BIND を XACK DNS にしてみよう! お客様から DNS サーバ更新の提案機会をいただきました Master キャッシュ共用パターンもアリ! 1 自社ドメイン権威 DNS Slave Slave 2 セカンダリ用権威 DNS 3 フルリゾルバ更新対象ユーザ運営 Master - 現在はBINDだが次回はOSS 以外がよい - 権威キャッシュ共用を現 IPで継続したい - 123パターンができるDNSソフトウェアそうだ! XACK DNSなら全部できる!

6 結果 BINDは懐が深くてやさしくて適当で学ぶことが多くありました!

7 事例 1: ゾーン転送よくあるシーケンススレーブマスター Notify 要求 Notify 応答 SOA 要求 SOA 応答 IXFR 要求 IXFR 応答

8 事例 1: ゾーン転送ケース 1: 色々応答してくれないスレーブマスタータイムアウト Notify 要求 Notify 応答 SOA 要求 SOA 応答 AXFR 要求 AXFR 応答 SOA だめ UDP だめ EDNS0 だめスレーブに対しても Hidden Primary?

9 事例 1: ゾーン転送ケース 2: RR 毎に DNS パケットを分割する ID 違いでスレーブマスター DNS パケットの最大サイズは 64KB 64KB 超のゾーンはパケット分割して送信する IXFR 応答 (ID=aaaaa, ANCOUNT=1) ( 中略 ) IXFR 要求 IXFR 応答 (ID=bbbbb, ANCOUNT=1) IXFR 応答 (ID=ccccc, ANCOUNT=1) IXFR 応答 (ID=zzzzz, ANCOUNT=1) 何も全部分割しなくても

10 事例 1: ゾーン転送ケース 3: AXFR 応答の最初と最後の SOA が違うスレーブマスター分割されたパケットの先頭終端は SOA レコードで判別する一度のゾーン転送に 2 つの SOA レコードがある AXFR 要求 AXFR 応答 SOA( シリアル = ) SOA( シリアル = ) シリアルは差分ゾーン転送時に重要な情報値が異なると出来上がるゾーンが異なってしまうかもどっちのシリアル使えばいいんです?

不正な応答または無応答 IXFR 要求 (TCP/EDNS0 無し ) 不正な応答または無応答 AXFR 要求 (TCP/EDNS0 無し ) AXFR 応答

11 事例 1: ゾーン転送対処 : 色々失敗してもフォールバック応答のチェックを許容的にスレーブ SOA 要求 (UDP/EDNS0 有り ) 不正な応答または無応答 SOA 要求 (UDP/EDNS0 無し ) 不正な応答または無応答 SOA 要求 (TCP/EDNS0 無し ) 不正な応答または無応答 IXFR 要求 (TCP/EDNS0 無し ) 不正な応答または無応答 AXFR 要求 (TCP/EDNS0 無し ) AXFR 応答 (TCP/EDNS0 無し ) マスター結果として BIND よりもゾーン転送に対応できるようになりました (BIND は IXFR から AXFR にはフォールバックしないパターンあり )

12 事例 2: ゾーンファイル読み込みケース 4: 委任先のグルーがない委任先内部名のグルーがないと委任先の権威サーバーの IP アドレスが分からずその先の問い合わせができない設定でそのようなゾーンファイルを許容できる機能を追加 ( 推奨しません ) $ORIGIN example.com. $TTL IN SOA (SOA RDATA 略 ) NS ns1 ns1 A sub NS no-glue ;no-glueのaレコードはなし

13 事例 2: ゾーンファイル読み込みケース 5: TTL が 10 進数でない RFC 項では以下のように書かれています The RR begins with optional TTL and class fields, followed by a type and RDATA field appropriate to the type and class. Class and type use the standard mnemonics, TTL is a decimal integer. しかし色々なゾーンファイルを見てみると $TTL 1w3d12h59m1s $TTL 1m1m1m1m1m $TTL 39m421S899s981M1h4M9H s TTL は 10 進数の整数である SOA の RDATA でこんなの見たことある! TTL でも許容するようにしました

14 事例 3: この応答の違い分かりますか? ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com IN A ;; Query time: 3 msec ;; SERVER: #53( ) ;; WHEN: Fri Jun 15 11:35: ;; MSG SIZE rcvd: 45 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com IN A ;; Query time: 3 msec ;; SERVER: #53( ) ;; WHEN: Fri Jun 15 11:35: ;; MSG SIZE rcvd: 56

15 事例 3: メッセージサイズが違う! ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com IN A ;; Query time: 3 msec ;; SERVER: #53( ) ;; WHEN: Fri Jun 15 11:35: ;; MSG SIZE rcvd: 45 ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com IN A ;; Query time: 3 msec ;; SERVER: #53( ) ;; WHEN: Fri Jun 15 11:35: ;; MSG SIZE rcvd: 56

16 事例 3: メッセージ圧縮同一の名前が存在する場合他方を参照するポインターを設定することで圧縮することが出来ます ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com IN A ;; Query time: 3 msec ;; SERVER: #53( ) ;; WHEN: Fri Jun 15 11:35: ;; MSG SIZE rcvd: 45

17 事例 3: メッセージ圧縮ケース 6: 後方参照圧縮 $ORIGIN example.jp. $TTL IN SOA ns1.test.jp. a.test.jp. ( ; serial 3000 ; refresh 3000 ; retry 100 ; expire 3000 ; minimum ) PTR foo.bar. NS a.foo.bar. NS b.foo.bar. example.jp. の PTR レコードを問い合わせると

18 事例 3: メッセージ圧縮ケース 6: 後方参照圧縮 drill の場合 ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: ;; flags: qr aa ; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;; example.jp. IN PTR ;; ANSWER SECTION: example.jp IN PTR foo.bar. ;; AUTHORITY SECTION: example.jp IN NS a.foo.bar. example.jp IN NS b.foo.bar. ;; ADDITIONAL SECTION: ;; Query time: 0 msec ;; SERVER: ;; WHEN: Wed Dec 20 17:17: ;; MSG SIZE rcvd: 81

19 事例 3: メッセージ圧縮ケース 6: 後方参照圧縮 dig の場合 ;; Got bad packet: bad compression pointer 81 bytes 2a d c *...exa 6d 70 6c a c0 0c 00 0c mple.jp e c0 3a c0 0c b.: e b f 6f a.foo.b c0 0c e c0 ar (

20 事例 3: メッセージ圧縮ケース 6: 後方参照圧縮 ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: ;; flags: qr aa ; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;; example.jp. IN PTR ;; ANSWER SECTION: example.jp IN PTR foo.bar. (2)PTRは後方にある1 番目のNSを参照後方参照 ;; AUTHORITY SECTION: example.jp IN NS a.foo.bar. example.jp IN NS b.foo.bar. ;; ADDITIONAL SECTION: (1)2 番目の NS は前方にある PTR を参照 BIND は (2) の解釈に失敗しますが Unbound は対応しているようです

21 事例 4: 誰も守っていない RFC ケース 7: 応答の EDNS0 のサイズ RFC 項では以下のように記載されています The fixed part of an OPT RR is structured as follows: Field Name Field Type Description NAME domain name MUST be 0 (root domain) TYPE u_int16_t OPT (41) CLASS u_int16_t requestor's UDP payload size TTL u_int32_t extended RCODE and flags RDLEN u_int16_t length of all RDATA RDATA octet stream {attribute,value} pairs OPT RR の CLASS フィールドには要求者つまるところクエリを送信した側の UDP ペイロードサイズを設定するように定められているようです ( 昔は sender's UDP payload size でした )

事例 4: 誰も守っていない RFC ケース 7: 応答の EDNS0 のサイズ尚実際の所誰も守っていません皆さん自身のサーバーの設定を返すようです $ dig +norec

A; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY,

22 事例 4: 誰も守っていない RFC ケース 7: 応答の EDNS0 のサイズ尚実際の所誰も守っていません皆さん自身のサーバーの設定を返すようです $ dig +bufsize=1024 a.root-servers.net. A; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5940 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 26 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1472

23 これらの事例を受けて RFC に書かれていること書かれていないこと含めて様々な想定外の動作差分があることが判明差分を洗い出したい! どうやって? 全通り試せばいい ( 白目 )

24 対象となる通信マスター権威サーバー Notify 要求ゾーン転送応答リゾルバークエリー XACK DNS 反復問い合わせの応答権威サーバー Notify 応答ゾーン転送要求スレーブ権威サーバー

25 やったことヘッダーについては概ね全通り試せる ID QR Opcode AA TC RD RA Z RCODE QDCOUNT ANCOUNT NSCOUNT ARCOUNT *COUNT は RR の数に依存するので気にしなければならないのは先頭 32 ビットだけしかもうち 16 ビットは ID

26 やったこと質問部の数については 0 個 1 個 2 個で試す (2 個以上の質問部をサポートしていないことを想定 ) / QNAME / / / QTYPE QCLASS 要求の場合 QTYPE QCLASS は 32 ビットなので全通り試せる応答の場合 QNAME QTYPE QCLASS は要求との一致不一致の 2 通りに畳み込む

27 やったこと資源レコード ( 回答部権威部追加部 ) はパターン分けするポジティブ応答ネガティブ応答委任 etc これらから回答部権威部追加部のパターンを作成して組み合わせるざっくり 10 億通りくらい現実的!!

28 やりたいこと DNSパケットのビットレベルでの比較思い付き + 提供いただけたものについては実施様々なゾーンファイルの読み込み思い付き + 提供いただけたものについては実施資源レコード個々のリソースレコードタイプ毎に深堀したい

29 おわりに今回の経験を得てXACK DNSもよりやさしく懐深くなりました今後も安心安定してご使用いただけるソフトウェアシステムを目指して参ります ( 新設更改のお声掛けお待ちしております!) ご注意本書の内容の一部又は全部を三菱電機インフォメーションシステムズ株式会社および株式会社 XACK に断りなくいかなる形でも転載又は複製することは固くお断りします本文記載の社名製品名ロゴは各社の商標または登録商標です

2 注意事項教材として会場を提供していただいている ConoHa さんのドメイン名とその権威ネームサーバを使用しています conoha.jp ns1.gmointernet.jp

2 注意事項教材として会場を提供していただいている ConoHa さんのドメイン名とその権威ネームサーバを使用しています conoha.jp ns1.gmointernet.jp 夏の DNS 祭り 2014 ハンズオン - dig 編株式会社ハートビーツ滝澤隆史 2 注意事項教材として会場を提供していただいている ConoHa さんのドメイン名とその権威ネームサーバを使用しています www.conoha.jp conoha.jp ns1.gmointernet.jp 3 権威ネームサーバへの問い合わせ @ 権威サーバと +norec を付ける例例 ) www.conoha.jp