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

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

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にしておくべきである