通过本地DNS劫持来测试dns迁移是否生效
大致图片,上图!
AWS端配置
1.在AWS Route53上创建一个公有托管域名,此域名要和生产域名一致
比如我的生产域名是 shayuyoumengxiang.com,那么我在AWS Route53上也要创建一个名为shayuyoumengxiang.com的公有托管区域
2.在AWS Route53上添加相应的解析记录(与生产环境一致)
3.解析AWS 权威服务器的地址 nslookup xxx.xxx.xxx
205.251.199.58
205.251.195.138
205.251.197.149
205.251.192.68
再看我的机器
DNSMASQ的配置
dnsmasq简介,此处参照百度
DNSmasq是一个小巧且方便地用于配置DNS和DHCP的工具,适用于小型网络,它提供了DNS功能和可选择的DHCP功能。它服务那些只在本地适用的域名,这些域名是不会在全球的DNS服务器中出现的。DHCP服务器和DNS服务器结合,并且允许DHCP分配的地址能在DNS中正常解析,而这些DHCP分配的地址和相关命令可以配置到每台主机中,也可以配置到一台核心设备中(比如路由器),DNSmasq支持静态和动态两种DHCP配置方式。
此处将此工具当作DNS劫持工具
1. 首先安装 dnsmasq这个工具
yum -y install dnsmasq / apt-get -y install dnsmasq
systemctl enable dnsmasq
2. 配置此工具
用到的参数有:
server=/dashayu.xyz/205.251.199.58 将所有*.dashayu.xyz的查询全部指定到AWS Route53的权威服务器
server=/dashayu.xyz/205.251.195.138
server=/dashayu.xyz/205.251.197.149
server=/dashayu.xyz/205.251.192.68
server=/#/10.0.0.2 这里的#代表其他的查询,全部通过10.0.0.2(因为我用的是AWS机器,所以这个是我VPC的DNS服务器。其他人可以设置成8.8.8.8或者运营商的DNS)dns出去
resolv-file=/root/resolv.dnsmasq.conf 读取我的上游解析文件
all-servers 全部服务器
local-service
listen-address=10.0.1.95 监听地址,本机地址
3.禁用本地的/etc/resolve文件
很多人也许会疑惑为什么我要将这里的nameserver注释掉。
原因很简单,nslookup是用来查询DNS记录的,他是一个程序的名字,他只会来找这个配置文件。当我注释掉,并且在dnsmasq指定了解析文件的路径,那么nslookup就会去找我指定的配置文件,从而达到将所有*.dashayu.xyz的查询全部指定到AWS Route53的权威服务器的目的
[root@ip-10-0-1-95 ~]# cat /etc/resolv.conf
options timeout:2 attempts:5
; generated by /usr/sbin/dhclient-script
#search ap-southeast-1.compute.internal
#nameserver 10.0.0.2
4.配置文件的路径
cp /etc/resolv.conf ~/resolv.dnsmasq.conf # 复制一份配置文件到根路径下,也不一定是根路径,也可以是其他路径
切记,唯独不能复制到/etc/dnsmasq.d/这个路径下,不然你会喜提报错
dnsmasq:bbad option at line 1.....
5.启动dnsmasq
systemctl start dnsmasq
到此dnsmasq配置完成
很多人会以为,这就完事了….
作者我只能用以下图片表示(此处手动狗头)
进入我们的测试环节
测试
1.测试我们的A记录
[root@ip-10-0-1-95 ~]# nslookup test.dashayu.xyz
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: test.dashayu.xyz
Address: 18.140.56.195
root@ip-10-0-1-95 ~]# curl test.dashayu.xyz
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
我们此时可以发现,我访问是OK的
2.测试我们的CNAME记录
[root@ip-10-0-1-95 ~]# nslookup chile.dashayu.xyz
Server: 127.0.0.1
Address: 127.0.0.1#53chile.dashayu.xyz canonical name = dwf0uc5pdqrlt.cloudfront.net.
[root@ip-10-0-1-95 ~]# curl chile.dashayu.xyz
curl: (6) Could not resolve host: chile.dashayu.xyz
这里我们发现。我能解析出来,为什么我访问不了呢?
答案很简单,因为权威名称服务器通常不做递归查询,它只会返回一个记录值给你(你记录的是什么记录,就会返回什么结果),而我们的浏览器其实是通过IP去访问的。你给我一个CNAME值,俺也不知道在哪啊。
解决方案
1.那我们既然知道了权威服务器不做递归查询,我们要怎么办呢?
答案也很简单。我们可以想象一下DNS查询的流程(结合文章开头的图片,虽然不太准确)
正常流程(大致)client ---> Local DNS(也就是运营商) ----> Other DNS Server
那我们现在的流程client(dnsmasq) ---> 权威服务器
client到localdns是一个递归查询,而我们的localdns到其他dns是一个迭代的查询,localdns会负责将一个域名的a记录查找出来,返回给客户端
2.缺少什么?
我们有权威DNS,递归DNS,转发DNS,以及公共DNS
再看看我们的流程图,通过上一条我的可以发现,client到权威dns的中间似乎少了什么?少了啥?
很明确。我们少了一个可以递归查询的DNS
这里笔者采用的是转发DNS,何为转发DNS?
转发DNS是一种特殊的递归。如果本地的缓存记录中没有相应域名结果时,其将查询请求转发给另外一台DNS服务器,由另外一台DNS服务器来完成查询请求。
3.如何配置?
3.1 我们先安装一个dns服务
yum -y install bind
3.2 如何配置?
options {
listen-on port 53 { any; };
listen-on-v6 port 53 { any; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
recursing-file "/var/named/data/named.recursing";
secroots-file "/var/named/data/named.secroots";
allow-query { any; }; // 所有查询
forwarders { 10.0.1.95; }; // 这里是dnsmasq的地址,这里会将查询转发到我们的dnsmasq服务器上
/*
- If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
- If you are building a RECURSIVE (caching) DNS server, you need to enable
recursion.
- If your recursive DNS server has a public IP address, you MUST enable access
control to limit queries to your legitimate users. Failing to do so will
cause your server to become part of large scale DNS amplification
attacks. Implementing BCP38 within your network would greatly
reduce such attack surface
*/
recursion yes;
dnssec-enable no;
dnssec-validation no;
3.3 启动dns服务
systemctl enable named;systemctl start named;
再次测试
这里笔者使用本地计算机来测试。别问,问就是AWS机器太贵了。
修改配置resolv.conf这个文件
接下来就是
测试结果
网页测试
这里我要澄清一下嗷。这个cloudfront(AWS CDN)是因为笔者设置了OAI的原因。实际上是能够访问的到
最后
笔者希望,这个文章能够帮助到大家。
我会不定期更新一些非常有趣的东西。谢谢