EDNS0
○ DNSトラブルシューティング
IPv6,DNSSECなどで、DNSサーバの要件が大きくかわっていました。
ISP運用なら不可避な内容なのでメモを。
□ DNSの512byteの壁 元来、DNS問い合わせ・応答は(ヘッダを除く)データサイズが512byte以下でないといけませんでした。*RFC1035 当時のインターネットの信頼性を考慮した時、1パケットでうけとれるサイズ=576byteに入るようにしていたのでした。*RFC791 ＊Aレコードのラウンドロビンで8レコード以上を見ないのはこのサイズが限界になるからのようで IPv6の登場、DNSSEC対応、spam対応のTXTレコード、DomainKeysなどなどDNSデータを使ったやりとりが ふえてきたことにより、DNS応答のデータサイズが512byteというのは現実的ではなくなってきました。 で、512byteの壁をこえるための手法が ・TCP Fallback ・EDNS0 となります。 □ TCP Fallback 実際にdigコマンドで確認してみます。 512byteより大きいデータで応答が帰ってくるgTLD(.gov)を公開DNSに聞いてみます。$ dig @4.2.2.1 +dnssec +bufsize=512 gov ;; Truncated, retrying in TCP mode. *1) ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.2 <<>> @4.2.2.1 +dnssec +bufsize=512 gov ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37290 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;gov. IN A ;; AUTHORITY SECTION: gov. 71114 IN SOA a.usadotgov.net. nstld.verisign-grs.com. 1353927601 3600 900 1814400 86400 gov. 71114 IN RRSIG SOA 7 1 86400 20121201100021 20121126100021 11596 gov. CzGbjEQvgj14d2nXlK5kyZtBTGSf46AKU5Kv1f+yw7Ez7JHOv++88Mih 4nMf/vIB04/zycK2Cv4qmnQZ5cJBuQ5gR3v5Pi0xEDefEjuIZHLFf61F wFkdpamKn/fNA0SRMFZzvvYCJI451ONyGoT/+V6GJr4bkHPvFwPgw1ok gr08mH2hp1Q6h+bfcZkmNrm3LGrDzqpfUsb2Yc+WhO7MV6jTksMPe/0A Wil9cmBZq1dUJYyaxstSvG6Ete53cxGJQBXJ5PONvj0CcVovKITY/CBE Ep5aCP6uaVYjT2H10QXqUSWnbVNF6M+n9n3YzH1xUOu2H1ttUVeEJKDh e+iiuw== 578et16s7ltnsq1t0amm21gl20oj5g76.gov. 71114 IN NSEC3 1 0 8 4C44934802D3 578H5NT2EIQH2T6CETLNEBNTL52T0ET8 NS SOA RRSIG DNSKEY NSEC3PARAM 578et16s7ltnsq1t0amm21gl20oj5g76.gov. 71114 IN RRSIG NSEC3 7 2 86400 20121201100021 20121126100021 11596 gov. oToOjRlj4fMiPWTlbKbPdg0nPhorEAVy319tot3LnbckP/nfBD7G+Fvm yuPUVCTSRcpdKPb+Y8kqJsQVfUz2SyHjiIGVHq0hOIDFPzp/0giWjwfI h/wJ2wqr7TsJqgITsNrFaSBvVjSY3ILZVn5tbeBmHM/JlG0x7CbQ6kHI apokRROyvEB4o3i3OxKWhSGn3scoUyT3lQCIQ6Km/r6vSmQ+GYsNJzTP eo0q1TmCvuxY1bY5euoFqrByoy5k1O1v+9hpn1cHADuHjFDJh8rWNFiz /3Bk1wwXfVIyfdp/HXq0SiNj+WvNhKN8ZfeCyBdctDMBQIhzQI46npJm aqCJ7w== ;; Query time: 111 msec ;; SERVER: 4.2.2.1#53(4.2.2.1) ;; WHEN: Tue Nov 27 00:22:45 2012 ;; MSG SIZE rcvd: 773 *2) *1) TruncatedしたのでTCPでリトライしましたといってます。 *2) MSG SIZEが773(512byte)以上です。
これもRFCの仕様ですが、DNS Request QueryはかならずUDPで問い合わせしなければなりませんので、 １．UDPで問いあわせ ２．Resposeのデータサイズが512byteをこえるとき、権限サーバは、TCbit=1(Truncated) をつけて返す ３．Truncatedを受け取った問い合わせサーバは、TCPで問いあわせしなおす これがTCP FallBackです。 □ EDNS0 TCP Fallbackで512byteの壁を越えることができましたが、 そもそもDNSの応答速度はユーザアプリケーションのRTTに直結するので、 返すだけならUDPのほうがはやくてよいです。 ネットワークの信頼性、データを処理するCPUの処理能力向上より、 UDPで大きいサイズも扱いましょうとしたのが、EDNS0です。$ dig @4.2.2.1 +dnssec gov ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.2 <<>> @4.2.2.1 +dnssec gov ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49273 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 *1) ;; QUESTION SECTION: ;gov. IN A ;; AUTHORITY SECTION: gov. 70843 IN SOA a.usadotgov.net. nstld.verisign-grs.com. 1353927601 3600 900 1814400 86400 gov. 70843 IN RRSIG SOA 7 1 86400 20121201100021 20121126100021 11596 gov. CzGbjEQvgj14d2nXlK5kyZtBTGSf46AKU5Kv1f+yw7Ez7JHOv++88Mih 4nMf/vIB04/zycK2Cv4qmnQZ5cJBuQ5gR3v5Pi0xEDefEjuIZHLFf61F wFkdpamKn/fNA0SRMFZzvvYCJI451ONyGoT/+V6GJr4bkHPvFwPgw1ok gr08mH2hp1Q6h+bfcZkmNrm3LGrDzqpfUsb2Yc+WhO7MV6jTksMPe/0A Wil9cmBZq1dUJYyaxstSvG6Ete53cxGJQBXJ5PONvj0CcVovKITY/CBE Ep5aCP6uaVYjT2H10QXqUSWnbVNF6M+n9n3YzH1xUOu2H1ttUVeEJKDh e+iiuw== 578et16s7ltnsq1t0amm21gl20oj5g76.gov. 70843 IN NSEC3 1 0 8 4C44934802D3 578H5NT2EIQH2T6CETLNEBNTL52T0ET8 NS SOA RRSIG DNSKEY NSEC3PARAM 578et16s7ltnsq1t0amm21gl20oj5g76.gov. 70843 IN RRSIG NSEC3 7 2 86400 20121201100021 20121126100021 11596 gov. oToOjRlj4fMiPWTlbKbPdg0nPhorEAVy319tot3LnbckP/nfBD7G+Fvm yuPUVCTSRcpdKPb+Y8kqJsQVfUz2SyHjiIGVHq0hOIDFPzp/0giWjwfI h/wJ2wqr7TsJqgITsNrFaSBvVjSY3ILZVn5tbeBmHM/JlG0x7CbQ6kHI apokRROyvEB4o3i3OxKWhSGn3scoUyT3lQCIQ6Km/r6vSmQ+GYsNJzTP eo0q1TmCvuxY1bY5euoFqrByoy5k1O1v+9hpn1cHADuHjFDJh8rWNFiz /3Bk1wwXfVIyfdp/HXq0SiNj+WvNhKN8ZfeCyBdctDMBQIhzQI46npJm aqCJ7w== ;; Query time: 141 msec ;; SERVER: 4.2.2.1#53(4.2.2.1) ;; WHEN: Tue Nov 27 00:25:30 2012 ;; MSG SIZE rcvd: 773 *1) EDNSversionが0,udp 4096byteまで拡張されているといってます。
＊ digのoptionで +dnssecとすれば自動的にEDNS0が有効になります。 １．はじめの問い合わせでOPTレコードを使用して、EDNSに対応していることを伝えます。 ２．正しい応答がかえってくれば、キャッシュして、次回より、RequestにEDS0を使用します。 ちなみにBind9からdefaultで EDNS0が有効なのでdisableにするには、named.confにoptions { edns no; } or server 192.168.0.1 { edns no; }
とする必要があります。 □ ネットワークインフラ側のEDNS0対応 DNSの要件がかわっているので、途中にレガシーなF/WやLSBがあればDropする危険性があるので注意が必要です。 F/W → 512byte以上は不正なDNSパケットとしてしまう SLB → UDPのセッションtableの飽和を防ぐため、DNSのflagmentpacketが通らない １．UDPはFINがないので、セッションをある程度保持しておかなくてはならない ２．DNSクエリはセッションが多くなる性質のぱけっとなので、セッションtableの飽和はパフォーマンスに直結する ３．DNSは512byte以下→1packetなのでレスポンスパケットがきたら、即セッションtableを削除してしまおう BIND9以降、EDNS0がデフォルト有効なので、キャッシュサーバであっても 上記のような仕様で動作されると思わぬところでdropされる場合があります。 DNSSECチェックリストが公開されているので、チェックしてみてください。 (追記) ISPにいるならばDNSはMUSTなのはずですが、はまりました。 参考になった、解説リンクを紹介しておきます。 JPRS解説 DNSOPS解説 これを機にDNSOPSのMLに登録しようかと思います。
Categorised as: ISP