ConsulのDNSインターフェースから学ぶDNSの基本

• ConsulはDNSインターフェースを通してノードとサービスの死活監視の状況を提供することができる
  • e.g. ロードバランスのためラウンドロビンしているノード群を問い合わせ結果として提供するとき、問い合わせ結果からダウンしたノード・サービスを動的に外す
• DNSをどのようにインターフェースとして利用しているか、を見ていく過程で、DNSについて学ぶことができる

www.consul.io

• localhostでConsulサーバが動いていて、ノードルックアップを行う場合、例えばfoo.node.consulの名前解決を行う際は$ dig @127.0.0.1 -p 8600 foo.node.consul ANYのように行う
• DNSサフィックスがOSの設定によって自動的に付加されることを防ぐためにFQDNはピリオドで終端するので、DNSサフィックスが不要な場合、digで問い合わせする際にピリオドで終端することでFQDNであることを明示するのが良い
• このANYはIPv4のAレコードだけでなく、メールサーバのMXやIPv6のAAAAなどを問わずに問い合わせを行うことを示す（ConsulではAレコードとSRVレコード、あとIPv6対応していればAAAAレコード、のみの管理になるはずだけれどどうだろう）
• サービスルックアップを行う場合、IPアドレスだけでなくサービスが待ち受けているポート番号を得る必要があり、その場合はDNSの拡張機能としてRFC 2782で規定されているSRVレコードを問い合わせる

• RFC 2782ではアンダースコア_を付与するフォーマットが定義されているが、Consulではアンダースコア_を付けずに問い合わせできる

• SRVレコード問い合わせ結果ANSWER SECTION

;; ANSWER SECTION:
_rabbitmq._amqp.service.consul. 0   IN  SRV 1 1 5672 rabbitmq.node1.dc1.consul.

• DNSの問い合わせはUDPで行われるため、問い合わせ結果が1パケットに収まらない場合に複数パケットにフラグメントされてしまい、UDPであるため順序反転などの問題が起こってしまうため、truncate bitを立てて1パケットだけ返信し、再度TCPで問い合わせを実施してもらうようクライアント側に促す
• Consulでは、このような負荷となる動作を抑制するためtruncate bitは立てない
• DNSの問い合わせ結果は通常ある程度の期間クライアント側にキャッシュされるが、毎回問い合わせを行わないと死活監視の結果をダイナミックに伝えることができない
• Consulでは問い合わせ結果をキャッシュしないようにデフォルトでTTLを0に設定している
• DNSクライアントによってはNegative Response、つまり名前解決ができなかった、という結果をキャッシュするものがあるので、この機能は死活監視の結果をよりダイナミックに伝えるためにoffにしておくべきである

プッシュはどうする？

• DNSインターフェースを使う場合はプル的な動作になるので、プッシュ的な通知ができない
• HTTPインターフェースには、HTTPの応答を遅延させるLong pollingを使ったBlocking Queueという機能があり、それによってプッシュ的な役割を果たすことができる

どこかで見たような...

• MobageではMyDNSを使うことで名前解決によって透過的にノード群の増減をアプリケーションに反映している
• Consul Agentをサーバで動かしておくことで、DNSインタフェースを持つConsulに全てまかせることができる