内部用の名前解決DNSを用意する

物理サーバでインフラ環境を作っていた時は、サーバに固定IPをつけたりネットワークアドレスも「10.1.1.0/24がAPPSセグメントで10.1.2.0/24がDBセグメントで・・・」と設計することがほとんどでした。 EC2を試した時はデフォルトでDHCPな環境だったので、AWSで構築するときはネットワークアドレス、IPアドレスをなるべく意識しなくても良いようにしたいと考えています。

$ssh staging-app-1のようにhost名でどのサーバかある程度識別できるようにはしたいので、自前で名前解決を用意することにします。 自分にとってはBINDでの構築が手っ取り早いので、即決でBINDを採用します。

このDNSサーバはVPC内のクライアントからDNS問い合わせを受け付けて、この案件用の内部ドメイン例えばexample.internalの名前解決を行います。 yahoo.co.jpのような他のドメインの問い合わせの場合はAWSで用意しているDNSにフォワードします。

/etc/named.conf一部

options {
  ....
  forwarders{
    172.31.0.2; 
  };
  ...
};

zone "example.internal" {
        type master;
        file "example.internal.db";
        allow-query { any; } ;
        //allow-transfer{ x.x.x.x; };
        //notify yes;
        //also-notify { x.x.x.x; };
};

いつものDNS運用ならゾーンファイルのレコード情報をたまに更新する程度なのですが、EC2環境の場合だと「インスタンスを新規に起動したからそのインスタンスの名前とIPを調べて、ゾーンファイルに書いて、namedリロードして、、、」なんてことを頻繁にやりそうです。そんな細かい作業を手で毎回やるのもしんどいのでスクリプト化します。

内容としてはVPC内にいるインスタンスのタグNameとプライベートIPを組み合わせたAレコードをゾーンファイルに書き出し、/usr/sbin/named-checkzoneでゾーンファイルに異常がなければnamedをリロードします。

AWS::EC2.new.instances.each {|ins|
  if ins.tags['Name'] && ins.private_ip_address.match(/\d+\.\d+\.\d+\.\d+/)
    p "#{ins.tags['Name']}   IN   A   #{ins.private_ip_address}"
  end
}