きっかけ

DTIのDNSサーバ202.216.229.30、なんでcloudfrontの正引きを高確率で127.0.0.1返すの。

— エアコンが新しくなったmatsuu (@matsuu)

2014, 6月 15

まじか！と思い、conohaからdigって見るものの、REFUSEDになってしまいました。「ちぇー、ちゃんアクセス制限してんのかー」と思っていたところ、@tss_ontapさんから「繰り返し聞いてみましょう」とのアドバイスをいただきました。

言われた通り何度もdigった結果、、、

@tss_ontap うお、返ってきた！え！？

— こんごー@頑張らないために頑張る (@kongou_ae)

2014, 6月 15

アクセス制限しているにも関わらず、何回かに1回、応答を返すという謎動作。「このDNS、ロードバランサか？」ということで、どんな構成なのか調べてみました。

調べかた

DTIが提供する以下のキャッシュDNSサーバ（202.216.224.30、202.216.229.30）にServersMans VPSから再帰問い合わせ行う。（このためだけにVPSを借りた。）
問い合わせで利用するFQDNは、絶対にキャッシュされていないドメイン（自ドメインのNXDOMAINになるもの）を使う
自ドメインの権威DNSはIPv4アドレスのみでListenする。
自ドメインの権威DNSのクエリログを確認し、問い合わせで使ったFQDNを問い合わせに来たDNSサーバをチェックする。
問い合わせに来たDNSサーバに、ConohaVPSから再帰問い合わせを行い、オープンリゾルバかどうかチェックする。
面白そうなので、問い合わせに来たDNSサーバに、ServersManからversion.bindを問い合わせる。

202.216.224.30は13台中2台がオープンリゾルバでした。version.bindを信じるのであれば、ソースからコンパイルしたbindはちゃんとしていて、RHELのパッケージを使っているbindはオープンリゾルバのようです。

VIP	Real server	Open Resolver	Version bind
202.216.224.30	202.216.224.10	Yes	9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1
	202.216.224.11		9.10.0-P1
	202.216.224.12		9.10.0-P1
	202.216.224.13		9.10.0-P1
	202.216.224.14		9.10.0-P1
	202.216.224.15		9.10.0-P1
	202.216.224.16		9.10.0-P1
	202.216.224.17		9.10.0-P1
	202.216.224.18		9.10.0-P1
	202.216.224.19		9.10.0-P1
	202.216.224.34	Yes	9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1
	202.216.224.60		9.10.0-P1
	202.216.224.61		9.10.0-P1

202.216.229.30は8台中5台がオープンリゾルバでした。version.bindを信じるのであれば、202.216.224.30と同様、ソースからコンパイルしたbindはちゃんとしていて、RHELのパッケージを使っているbindはオープンリゾルバのようです。

VIP	Real server	Open Resolver	Version bind
202.216.229.30	202.216.229.6	Yes	9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1
	202.216.229.10	Yes	9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1
	202.216.229.11		9.10.0-P1
	202.216.229.13		9.10.0-P1
	202.216.229.14		9.10.0-P1
	202.216.229.41	Yes	9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1
	202.216.229.135	Yes	9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1
	202.216.229.146	Yes	9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1