本文介绍在自建DNS服务器的场景下，如何将AWS相关域名的请求转发到VPC内。
一、背景
1、VPC自带DNS解析的使用
云上VPC内默认提供DNS服务，为本VPC内的EC2等资源的请求提供解析。VPC自带DNS是固定的第二个IP，以默认VPC CIDR是172.31.0.0/16为例，VPC DNS就是172.31.0.2。
需要注意的是，VPC默认的.2DNS，只接受来自本VPC内的请求，不接受来自其他VPC Peering、不接受来自专线、不接受来自VPN、不接受来自IDC的请求。此时，如果使用了在IDC环境内搭建的自建DNS，那么就会遇到无法请求VPC内自带.2DNS的问题。这个问题可以被Route 53 Resolver Inbound Endpoint功能解决。
2、在云上使用自建DNS的两种方式
在云上自建DNS是大型系统部署常见的方式。使用自建DNS的一种方式是让EC2继续使用VPC自带的.2DNS服务器，然后配置Route 53 Resolver Outbound Endpoint将特定域名的解析转发到云之外的环境（例如通过专线/VPN到IDC）。这种方式适合在IDC部署Active Directory活动目录等场景
另一种方式是直接修改EC2的DNS服务器，手工指定EC2使用其他DNS服务器。由于EC2的DNS是通过本VPC的DHCP下发的，由此一般会修改VPC自带的DHCP Set，让VPC的DHCP Server内下发给EC2的DNS Server IP地址不再是本VPC自带DNS默认的.2，而是用户指定的DNS Server。
这两种方式均可。一般后一种直接修改EC2的DNS IP地址这种方式使用更多。
3、自建DNS根据位置不同的两种场景
自建DNS的场景根据位置不同又有两种可能，一种是在云上用EC2，一种是在IDC或者使用其他云的DNS。下面分别阐述。
当自建的DNS在云上时候，整个配置相对简单：
- 需要打开VPC的DNS解析功能；
- 在VPC的DHCP Set中将DNS的IP地址配置为云上承担DNS任务的EC2；
- 在自建的DNS如Bind或者微软Windows AD/域控的DNS中，将结尾是amazonaws.com的域名转发给VPC的DNS
.2。由于自建DNS也是EC2，也在VPC中，因此这个转发不需要额外配置Route 53 Resolver，即可直接生效。
在云上使用IDC或者其他云的DNS服务自建的DNS时候，因为.2DNS不接受VPC之外的请求，因此要使用Route 53 Resolver，配置过程相对步骤多一些：
- 修改VPC的DHCP Set让EC2获得指定的DNS IP
- 打开本VPC的DNS开关
- 创建Route 53 Resolver需要的安全规则组
- 在VPC内配置Route 53 Resolver Inbound Endpoint
- 在IDC的测试VPC的DNS可访问
- 在IDC的DNS上配置转发规则
二、将IDC内自建的DNS的请求转发到云端的使用场景
1、DNS解析全流程介绍
在IDC自建DNS、让EC2使用自建DNS的整个流程是：
- 1、在云上VPC的修改DHCP Set，为EC2自动分配IDC自建的DNS IP地址
- 2、EC2查询域名时候，看到EC2内获得DNS服务器是IDC上自建的IP，因此从EC2通过专线发给IDC自建DNS
- 3、IDC的自建DNS判断要查询的域名是否是特定AWS结尾的域名，是的话触发转发规则，转发发给AWS的Route53 DNS Resolver落在VPC内的两个IP
- 4、Route53 DNS Resolver将解析发给本VPC的
.2DNS，完成查询
2、修改VPC的DHCP Set让EC2获得指定的DNS IP
VPC默认的DHCP Set是不允许修改的，因此要更换DHCP推送给EC2的DNS，需要新建一个DHCP Set。
进入VPC服务界面，从左侧菜单中找到DHCP option sets，点击右上角的创建按钮。如下截图。
在创建向导中，输入DHCP Set的名称，输入域名例如mydomain.com，输入DNS服务器IP地址。这里输入至少2个地址，用逗号隔离开。其他选项无需输入，点击保存即可。如下截图。
3、打开本VPC的DNS开关
(1) 打开VPC自带的DNS
进入VPC界面，找到当前要修改的VPC，点击编辑Edit VPC settings。如下截图。
在修改VPC设置界面中，将DHCP Set的下拉框从默认的DHCP设置修改为上一步新创建的DHCP设置。然后选中DNS的两个开关，表示打开DNS解析。如下截图。
点击保存。
(2) 在本VPC内验证DNS服务正常
在本VPC内，用一台EC2验证下本VPC的.2DNS服务工作正常。被验证的目标是本VPC的VPC Endpoint。通过VPC Endpoint界面，可看到事先有创建好的ECR Endpoint，其私有地址是api.ecr.ap-southeast-1.amazonaws.com，我们将测试VPC DNS对这个地址的解析。如下截图。
预期的正确结果，可通过VPC Endpoint的子网Subnet界面查看。VPC Endpoint会被解析为本VPC的三个内网IP。如下截图。
EC2上执行nslookup命令，然后输入server 172.31.0.2表示使用VPC的DNS，然后输入要查询的VPC Endpoint的域名，可看到查询结果与预期的一致。
由此确定本VPC的DNS服务已经开启，且在本VPC内请求正常。
(3) 在本VPC外（如模拟IDC环境）验证VPC的DNS无法访问（可选）
本VPC提供DNS的.2服务是不接受VPC之外的IP地址查询请求的，则并非.2DNS的安全组配置不对，而是设计上.2就只接受本VPC内的查询。这里用一个Windows环境来验证。
本文测试环境，假设云端VPC CIDR是172.31.0.0/16，IDC一侧CIDR是172.16.0.0。本文档中，使用另外一个区域的AWS云模拟了IDC，中间是经过Peering模拟的VPN连接。其模拟出来的效果与在IDC内测试完全相同。
首先在Windows上执行ping命令访问本VPC的EC2，可以看到是能ping通的，证明能够通达VPC的内部网络。在Windows上执行nslookup命令，再输入server 172.31.0.2切换DNS地址到.2DNS。这个时候Windows的nslookup命令可能会查询本IP地址的反向解析，返回信息成功与否都不需要关注（反向解析记录与对外提供解析的功能无关）。接着输入要查询的域名，可以看到.2因为超时连接不上，不回返回结果。如下截图。
> api.ecr.ap-southeast-1.amazonaws.com
Server: [172.31.0.2]
Address: 172.31.0.2
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to [172.31.0.2] timed-out
>则也就验证了.2DNS只接受本VPC的访问。
3、创建Route 53 Resolver需要的安全规则组（不可跳过）
由于Route 53 Resolver创建时候选定的安全组后续无法修改，因此这里必须事先创建一个安全规则组。
- 名称：route53resolver
- 入站规则：允许来自云下入IDC网段的TCP和UDP协议的53端口入站（不建议直接放行0.0.0.0/0，放行任意地址不够安全）
- 出站规则：允许
All traffic去往任意位置0.0.0.0/0
创建时候注意选择正确的VPC。安全组是和VPC一一对应。
4、在VPC内配置Route 53 Resolver Inbound Endpoint
为了本VPC之外的网络，例如IDC或者其他云能够正常转发和解析到VPC内，需要配置Route 53 Resolver Inbound Endpoint。
进入Route53界面。Route53是全球设置，但是Route 53 Resolver是针对Region区域的设置，因此务必要选择到云资源部署的Region，例如本文是新加坡Region。点击左侧菜单的Inbound endpoints，点击创建按钮。如下截图。
选择创建Inbound Only的Endpoint，点击Next按钮继续。
输入Endpoint名称，选择当前VPC，选择上一步创建的安全组（注意安全组创建后不能修改），因此一定要事先选择安全组。Endpoint Type选择IPv4。如下截图。
在Resolver Inbound落地的IP地址的配置位置，选择第一个可用区，选择内部子网，选择IPv4。如下截图。
再对第二个可用区也选择子网落地，生成第二个IP地址。如下截图。
将页面翻到最下方，点击下一步。之后不需要再修改选项了。在创建最后点击创建。
创建完成，可以在Resolver Inbound endpoints下看到。这里可以二次确认下创建的Region是正确的。如下截图。
点击进入Inbound endpoint后，即可看到本VPC Resolver落地的两个IP地址是172.31.49.154、172.31.72.65。
接下来这两个IP地址即可被用于自建DNS的转发。
5、在IDC的测试VPC的DNS可访问
现在到模拟IDC的客户端，验证新建的Resolver是否能接受外部的请求。
在模拟IDC的客户端，执行nslookup命令.
D:\Users\lxy>nslookup
Default Server: AWS-F6822F83DE.corp.amazonworkspaces.com
Address: 172.16.1.142在模拟IDC的客户端的nslookup命令上，执行server 172.31.49.154，让位于IDC的机器去查询新建的Route 53 Resolver的IP地址。在如下的反馈信息中，Windows上的nslookup进行了反向查询，把172.31.49.154这个IP地址反向解析成了AWS云上的IP，这个提示信息不影响使用。
> server 172.31.49.154
in-addr.arpa
primary name server = ns0.ap-northeast-1.compute.internal
responsible mail addr = hostmaster.amazon.com
serial = 2012103100
refresh = 3600 (1 hour)
retry = 3600 (1 hour)
expire = 3600 (1 hour)
default TTL = 60 (1 min)
Default Server: [172.31.49.154]
Address: 172.31.49.154输入要查询的VPC Endpoint域名api.ecr.ap-southeast-1.amazonaws.com，可看到Route 53 Resolver返回了查询结果。
> api.ecr.ap-southeast-1.amazonaws.com
Server: [172.31.49.154]
Address: 172.31.49.154
Non-authoritative answer:
Name: api.ecr.ap-southeast-1.amazonaws.com
Addresses: 172.31.86.236
172.31.48.42
172.31.74.72将以上解析结果，与之前在本VPC内查询域名相对比，发现是一致的。由此表示Route 53 Resolver正常的接受到了来自IDC的查询请求。
6、在IDC的DNS上配置转发规则
在确认Route 53 Resolver工作正常后，可以在自建的DNS上配置转发规则：
- 要转发的域名：*.ap-southeast-1.amazonaws.com
- 被转发目标（Resolver的IP）：
172.31.49.154、172.31.72.65
四、参考文档
Forwarding inbound DNS queries to your VPCs
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-inbound-queries.html