share facebook facebook2 twitter menu hatena pocket slack

2013.01.03 THU

“ELB”と”512バイト問題”と”EDNS0″と”Route 53”

鈴木 宏康

WRITTEN BY鈴木 宏康

ELB(スケールサイズ)とDNS(返されるIPアドレス)の関係(予想)の記事を書いたら、Facebookで次のようなコメントをいただきました。

ということで、再調査です

まずは最初のキーワードの「512byte問題」ですが、DNSのIPv6対応へのハードル「512バイト問題」とは?の最初の部分を読むと概要がわかると思います。

つまり、「DNSでは512バイトを超えるデータをUDPで転送できない」ということで、 ELBのDNS名を名前解決するときに返すIPアドレスの最大数8は、この512バイトを ギリギリ超えない数だと予想できます。

実際に下記のようなdigコマンドを実行してみると、最終行が次のように出力されており

MSG SIZE rcvd: 493

転送されたデータが512バイトにギリギリの493バイトであることがわかります。

$ dig suz-000000000.ap-northeast-1.elb.amazonaws.com +noall +answer +stats

; > DiG 9.8.3-P1 > suz-000000000.ap-northeast-1.elb.amazonaws.com +noall +answer +stats
;; global options: +cmd
suz-000000000.ap-northeast-1.elb.amazonaws.com. 60 IN A 176.34.61.xxx
suz-000000000.ap-northeast-1.elb.amazonaws.com. 60 IN A 176.34.62.xxx
suz-000000000.ap-northeast-1.elb.amazonaws.com. 60 IN A 46.51.249.xxx
suz-000000000.ap-northeast-1.elb.amazonaws.com. 60 IN A 54.248.76.xxx
suz-000000000.ap-northeast-1.elb.amazonaws.com. 60 IN A 54.248.111.xxx
suz-000000000.ap-northeast-1.elb.amazonaws.com. 60 IN A 54.248.120.xxx
suz-000000000.ap-northeast-1.elb.amazonaws.com. 60 IN A 176.34.29.xxx
suz-000000000.ap-northeast-1.elb.amazonaws.com. 60 IN A 176.34.60.xxx
;; Query time: 134 msec
;; SERVER: 192.168.11.1#53(192.168.11.1)
;; WHEN: Mon Nov 12 01:25:56 2012
;; MSG SIZE rcvd: 493

そして次のキーワードである「EDNS0」ですが、恥ずかしながらこの言葉、 この時、初めて知りました…

で、いろいろ調べてみると、DNS拡張EDNS0の解析を読むことで、ある程度理解することができました。

要は、上記の記事の言葉をかりると、

DNSの要求と応答に「転送可能バイト」を格納することで、512バイト以上のデータをUDPでも送信できるようにする拡張。

といった感じになると思います。

おそらく、上記の拡張に対応していないDNSサーバ/クライアントのことも考え、ELBのDNS名を名前解決したときに返ってくるIPアドレスは、512バイトを超えない8個までにしているのでは、と予想できます。

で話は終わるはずだったのですが、Route 53のドキュメントにて下記のような記述を見つけてしまいました

DNS Constraints and Behaviors

Maximum Response Size

To comply with DNS standards, responses sent over UDP are limited to 512 bytes in size. Responses exceeding 512 bytes are truncated and the resolver must re-issue the request over TCP. If the resolver supports EDNS0 (as defined in RFC 2671), and advertises the EDNS0 option to Route 53, Route 53 permits responses up to 4096 bytes over UDP, without truncation.

DNSの標準に従うためにUDPで送信される応答の大きさは512バイトに 限定される。応答が512バイトを超える場合は切り縮められて、クライアントは 名前解決のためにTCPにて再度リクエストしなければならない。もしクライアントが EDNS0をサポートしている場合、EDNS0オプションを”Route 53″に送信することで UDPでも切り縮められることなしに、4096バイトまで応答を送信することができる。

つまり、Route 53なら、EDNS0をサポートしているわけです。

ということで、Route 53上でtest.suz-lab.comのAレコードを 10.0.0.1 – 10.0.0.30まで作成して実験してみます。

まず普通に名前解決してみると、下記の通り、最後がMSG SIZE rcvd: 514と 512バイト以上になっていますが、先頭がTruncated, retrying in TCP mode.なので、 UDPではなくTCPで応答が(ドキュメント通り)送信されていることがわかります。

$ dig @8.8.8.8 test.suz-lab.com +noall +answer +stats +comments
;; Truncated, retrying in TCP mode.

; > DiG 9.8.3-P1 > @8.8.8.8 test.suz-lab.com +noall +answer +stats +comments
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER;; flags: qr rd ra; QUERY: 1, ANSWER: 30, AUTHORITY: 0, ADDITIONAL: 0

;; ANSWER SECTION:
test.suz-lab.com. 41 IN A 10.0.0.1
test.suz-lab.com. 41 IN A 10.0.0.22
test.suz-lab.com. 41 IN A 10.0.0.20
test.suz-lab.com. 41 IN A 10.0.0.12
test.suz-lab.com. 41 IN A 10.0.0.10
test.suz-lab.com. 41 IN A 10.0.0.19
test.suz-lab.com. 41 IN A 10.0.0.15
test.suz-lab.com. 41 IN A 10.0.0.23
test.suz-lab.com. 41 IN A 10.0.0.13
test.suz-lab.com. 41 IN A 10.0.0.6
test.suz-lab.com. 41 IN A 10.0.0.14
test.suz-lab.com. 41 IN A 10.0.0.26
test.suz-lab.com. 41 IN A 10.0.0.21
test.suz-lab.com. 41 IN A 10.0.0.2
test.suz-lab.com. 41 IN A 10.0.0.27
test.suz-lab.com. 41 IN A 10.0.0.24
test.suz-lab.com. 41 IN A 10.0.0.18
test.suz-lab.com. 41 IN A 10.0.0.8
test.suz-lab.com. 41 IN A 10.0.0.16
test.suz-lab.com. 41 IN A 10.0.0.3
test.suz-lab.com. 41 IN A 10.0.0.7
test.suz-lab.com. 41 IN A 10.0.0.9
test.suz-lab.com. 41 IN A 10.0.0.11
test.suz-lab.com. 41 IN A 10.0.0.29
test.suz-lab.com. 41 IN A 10.0.0.4
test.suz-lab.com. 41 IN A 10.0.0.25
test.suz-lab.com. 41 IN A 10.0.0.28
test.suz-lab.com. 41 IN A 10.0.0.5
test.suz-lab.com. 41 IN A 10.0.0.30
test.suz-lab.com. 41 IN A 10.0.0.17

;; Query time: 8 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Nov 12 02:42:02 2012
;; MSG SIZE rcvd: 514

そしてEDNS0で名前解決(+bufsize=4096を付与)してみると、 今度は下記のように、EDNS: version: 0, flags:; udp: 512とEDNS0を利用して UDPのまま応答を送信していることがわかります。

$ dig @8.8.8.8 test.suz-lab.com +noall +answer +stats +comments +bufsize=4096

; > DiG 9.8.3-P1 > @8.8.8.8 test.suz-lab.com +noall +answer +stats +comments +bufsize=4096
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER;; flags: qr rd ra; QUERY: 1, ANSWER: 30, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; ANSWER SECTION:
test.suz-lab.com. 59 IN A 10.0.0.23
test.suz-lab.com. 59 IN A 10.0.0.26
test.suz-lab.com. 59 IN A 10.0.0.14
test.suz-lab.com. 59 IN A 10.0.0.20
test.suz-lab.com. 59 IN A 10.0.0.8
test.suz-lab.com. 59 IN A 10.0.0.4
test.suz-lab.com. 59 IN A 10.0.0.13
test.suz-lab.com. 59 IN A 10.0.0.18
test.suz-lab.com. 59 IN A 10.0.0.27
test.suz-lab.com. 59 IN A 10.0.0.6
test.suz-lab.com. 59 IN A 10.0.0.16
test.suz-lab.com. 59 IN A 10.0.0.28
test.suz-lab.com. 59 IN A 10.0.0.7
test.suz-lab.com. 59 IN A 10.0.0.1
test.suz-lab.com. 59 IN A 10.0.0.24
test.suz-lab.com. 59 IN A 10.0.0.29
test.suz-lab.com. 59 IN A 10.0.0.5
test.suz-lab.com. 59 IN A 10.0.0.30
test.suz-lab.com. 59 IN A 10.0.0.25
test.suz-lab.com. 59 IN A 10.0.0.10
test.suz-lab.com. 59 IN A 10.0.0.9
test.suz-lab.com. 59 IN A 10.0.0.17
test.suz-lab.com. 59 IN A 10.0.0.12
test.suz-lab.com. 59 IN A 10.0.0.3
test.suz-lab.com. 59 IN A 10.0.0.11
test.suz-lab.com. 59 IN A 10.0.0.22
test.suz-lab.com. 59 IN A 10.0.0.19
test.suz-lab.com. 59 IN A 10.0.0.2
test.suz-lab.com. 59 IN A 10.0.0.21
test.suz-lab.com. 59 IN A 10.0.0.15

;; Query time: 218 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Nov 12 02:43:14 2012
;; MSG SIZE rcvd: 525

ちなみにEDNS0のついでにDNSSECはどうかというと、 下記よりサポートされてないことがわかります。

Q. Does Amazon Route 53 support DNSSEC?
Route 53はDNSSECをサポートしていますか?

No. Amazon Route 53 does not support DNSSEC at this time.
いいえ、今の時点では”Route 53″はDNSSECをサポートしていません。

こちらの記事はなかの人(suz-lab)監修のもと掲載しています。
元記事は、こちら

鈴木 宏康

鈴木 宏康

愛知県生まれ。東京工業大学大学院修士課程修了。在学時より、ベンチャー企業でインターネットに関する業務に携わり、現在はクラウド(主にAmazon Web Services)上での開発・運用を軸とした事業の、業務の中心として活躍。