この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
コンニチハ、千葉です。
オンプレ+AWSのハイブリッドな構成で、AWS側のDNS引きたいということがあります。
例えば、ELBやRDSです。オンプレ側がインターネット接続可能でパブリックなDNSを引く場合はあまり問題になりません。が、オンプレ側がパブリックDNSを引けない場合は困りますね。
この場合、AWSのDNSをを利用したくなるのですが残念ながらオンプレからAWSのDNSを直接引くことはできません。
構成
そこで、直接引くのではなくAWS上にDNSフォワーダーを立て、オンプレのサーバではこちらを参照するように構成します。
自前で立てるのではなく、AWS Directory Serviceを使えばマネージドなので運用が楽になります。参考
ただ、今回はオンプレからDirect Connect(またはVPC、以下略)経由にてS3をアクセスする構成を考えており、今回立てるDNSフォワーダー上にhttpプロキシも同居させる構成を考えています。
そのため、AWS Directory Serviceは使わずに自前でDNSフォワーダーを立てます。DNSフォワーダーにはUnboundを使います。オンプレ側のDNSサーバはBINDとします。
また、Direct Connect環境がないため、検証は擬似的にVPCをピアリングすることで構成します。
※本記事ではVPCのピアリングやEC2作成、セキュリティグループの構成については省略しす ※オンプレ側の内部DNSの変更したくない!という場合は、クライアント側のresolv.confにAWS側のDNSフォワードサーバを指定することも可能です
DNSフォワードの構成
DNSフォワーダを構成します。
以下のスクリプトを流すことで実施します。
#!/bin/bash
# Set the variables for your environment
vpc_dns=10.88.135.2
onprem_domain=example.local
onprem_dns=192.0.2.2
# Install updates and dependencies
yum update -y
yum install -y gcc openssl-devel expat-devel
# Get, build, and install latest Unbound
wget https://unbound.net/downloads/unbound-latest.tar.gz
tar -zxvf unbound-latest.tar.gz
cd unbound-*
./configure && make && make install
# Add run-time user
useradd unbound
# Write Unbound configuration file with values from variables
cat << EOF | tee /usr/local/etc/unbound/unbound.conf
server:
interface: 0.0.0.0
access-control: 0.0.0.0/0 allow
forward-zone:
name: "."
forward-addr: ${vpc_dns}
EOF
# Install Unbound as service and run
cat << EOF | tee /etc/init/unbound.conf
start on runlevel [2345]
exec /usr/local/sbin/unbound
EOF
start unbound
今回は冗長構成のため、これを2台構成します。
オンプレDNSの構成
既存のオンプレDNSを想定して、特定のドメインのみAWSへフォワードする構成にします。
また、DNSサーバとしてBINDをインストールします。今回はchiba.localドメインを、DNSフォワーダーへ転送するように設定します。
# yum install bind -y
# vi /etc/named.conf
### DNSSECを無効化
< dnssec-enable yes;
< dnssec-validation yes;
---
> dnssec-enable no;
> dnssec-validation no;
### chiba.localドメインをDNSフォワーダーへ転送する
> zone "chiba.local" {
> type forward;
> forward only;
> forwarders {
> XX.XX.XX.XX;
> XX.XX.XX.XX;
> };
# service named start
# chkconfig named on
DNSクライアントの構成
resolv.confの設定をします。
# vi /etc/sysconfig/network-scripts/ifcfg-eth0
## yesをnoへ
PEERDNS=no
# vi /etc/resolv.conf
## オンプレDNSのプライベートIPを指定
nameserver XX.XX.XX.XX
動作確認
動作確認用に、Route53にてプライベートホストゾーン「chiba.local」を構成しVPC2:AWS環境にアタッチします。
これで、VPC1:オンプレ環境からはchiba.localは名前解決できませんが、DNSフォワーダーを経由することで名前解決できるようになります。
では、やってみます。まずは、DNSクライアントサーバより、オンプレ環境のDNSサーバに問い合わせを行います。
# nslookup ec2-proxy-1.chiba.local 192.168.0.2
Server: 192.168.0.2
Address: 192.168.0.2#53
** server can't find ec2-proxy-1.chiba.local: NXDOMAIN
引くことはできません。
では、DNSフォワーダ経由で引いてみます。
# nslookup ec2-proxy-1.chiba.local 192.168.0.29
Server: 192.168.0.29
Address: 192.168.0.29#53
Non-authoritative answer:
Name: ec2-proxy-1.chiba.local
Address: 192.169.0.48
引くことができました。これで、問題なくAWS環境のRoute53プライベートホストゾーンDNSを引けていることが確認できました。
では、今度はAWS環境のDNSフォワーダーを停止しても引けるか確認してみます。
# nslookup ec2-proxy-1.chiba.local 192.168.0.29
Server: 192.168.0.29
Address: 192.168.0.29#53
Non-authoritative answer:
Name: ec2-proxy-1.chiba.local
Address: 192.169.0.48
問題なく引くことができました。(もちろん逆を停止しても引けました)
まとめ
これで、オンプレ側からAWSのDNSを引くことができました。また、Route53との連携もできるのでELBのALIAS等と組み合わせると、拡張性が高い構成が組めます。今回はEC2上にフォワーダーを構築しましたが、AWS Directory Serviceを利用することでメンテナンスフリーな構成にすることもできます。