在互联网场景下使用DNS会受到中间DNS服务器的影响,最常见的就是缓存问题,运营商的DNS服务器往往会强制改写域名的TTL并将该结果进行缓存。遇到需要通过域名进行业务切换的场景时(比如,想要将一个业务通过域名从一个数据中心切换到另一个数据中心),需要等待DNS缓存时间过期,这个机制延长了切换的时间。
很多DNS的策略是基于源地址进行配置的,但是在实际通过DNS请求域名解析的过程中,运营商DNS会作为代理DNS,以其自身的源IP去向权威DNS请求结果。导致一些基于域名做的负载均衡策略无法精细到客户端层面,只能到运营商DNS层面。
对于这些问题,可以通过https DNS去解决。
实验概述:
访问流程如下,客户端发出的DNS请求被https报文封装,可以绕过local dns直接到达权威DNS服务器,其过程不受local DNS缓存的影响,可以更好的进行DNS策略的应用。
这里由于环境中没有权威DNS,所以使用公网DNS代替权威DNS。
1、Firefox浏览器配置
调整如下几个参数:
network.trr.mode 3
network.trr.useGET true
2、FireFox浏览器配置https DNS
进入Firefox的设置界面,搜索dns,然后安全DNS启用策略选择—增强保护。选择提供方填写自定义的DNS服务器地址,也可以选用公网的DNS提供方,比如cloud flare。我这里选用了我自己搭建的DNS服务器。
3、使用FireFox浏览器进行DNS解析测试
在浏览器中输入,about:networking,进入到网络调试界面
简单演示了一下,使用https dns进行查询的过程。
抓包可以看到,报文是通过加密的方式发出的。
这里使用了F5的负载设备作为代理,将https的DNS请求解密,发送到公网DNS获得解析结果。
4、总结
HTTPs DNS可用于自建DNS的场景,中间使用一个代理接收https dns的请求,并将请求解密为正常DNS请求发送到自建DNS上,获得结果。
附F5配置:
F5提供iRule LX组件,通过iRule和js脚本去对加密的DNS请求进行处理
ltm virtual 10.1.10.241 {
creation-time 2023-12-21:19:54:47
destination 10.1.10.241:https
ip-protocol tcp
last-modified-time 2023-12-21:21:01:40
mask 255.255.255.255
pool pool_dns
profiles {
clientssl-insecure-compatible {
context clientside
}
http { }
tcp { }
}
rules {
DoH_to_DNS_Proxy/DoH_to_DNS_Proxy
}
serverssl-use-sni disabled
source 0.0.0.0/0
source-address-translation {
type automap
}
translate-address enabled
translate-port enabled
vs-index 195
}
ltm pool pool_dns {
members {
223.5.5.5:domain {
address 223.5.5.5
session user-disabled
state user-down
}
_auto_223.6.6.6:domain {
address 223.6.6.6
ephemeral true
session monitor-enabled
state up
fqdn {
autopopulate enabled
name dns.alidns.com
}
}
_auto_2400.3200..1:domain {
address 2400:3200::1
ephemeral true
session monitor-enabled
state down
fqdn {
autopopulate enabled
name dns.alidns.com
}
}
_auto_2400.3200.baba..1:domain {
address 2400:3200:baba::1
ephemeral true
session monitor-enabled
state down
fqdn {
autopopulate enabled
name dns.alidns.com
}
}
dns.alidns.com:domain {
fqdn {
autopopulate enabled
name dns.alidns.com
}
state fqdn-up
}
}
monitor gateway_icmp
}