ことなかれblog 備忘録

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に登録しようかと思います。