宁可枝头抱香死,何曾吹落北风中。这篇文章主要讲述F5 GTM DNS 知识点和实验 3 -加速dns解析相关的知识,希望能为你提供帮助。
第三章:加速dns解析
目标:
- 了解一个请求是如何发送到一个dns资源池中的,并且了解如何监控资源池中成员的健康状态
- 使用dns缓存对dns请求进行加速
- 使用dns express进行对dns请求进行加速
- 智能解析dns请求
- 加速解析(dns express,dns cache,load balance dns queries)
- 配置监听器
- wide ip
- dns express
- dns cache
- dns resolving cache
- load balance pool
- local BIND
- forward to other dns
文章图片
文章图片
3.2、监听器 Listener
监听器就是接收dns请求数据包的的地址和端口的结合,通常端口使用udp 53。你可以使用self ip作为监听ip,但是self ip一般用于iQuery和一些敏感的数据传输,所以在广域网,建议配置一个单独的ip用于监听,并且不要复用这个ip做其他事。
如果是高可用模式,你只想让其中一个big-ip进行响应,你可以将监听器(listener)配置在traffic-group-1中,如果你想两个系统都响应,你需要将监听器配置在traffic-group-local-only中。
转发dns请求到其他dns服务器上如果你想将dns请求转发到其他dns上,你需要将监听器配置成和其他dns服务器一样的ip地址。并将profile的USE BIND SERVER on BIG-IP设置成disabled。
anycast模型如果使用anycast模型,则可以将dns请求报文路由到最近的big-ip dns设备上,这种方案的优势是可以分散攻击流量,减小单个dns压力,同时提供高可用能力。但是如果需要使用anycast模型,需要使用big-ip的路由(routing)模块。
listener 配置界面路径:DNS??Delivery : Listeners : Listener List??New...
文章图片
- name:名字,一个标识而已
- address:监听器ip地址,例如10.10.10.10
- port:默认53端口
- vlan traffic:应用在哪个接口上,如同交换机的vlanif一样。
- protocol:默认udp
- profile:默认dns,后边会自定义一些profile,profile可以理解为一种功能配置文件。
- source address translation:源地址转换,主要用于负载均衡池的场景。默认未开启。
- address translation:目的地址转换,主要用于负载均衡池的场景。默认未开启。
实验 配置一个listenerGUI:
路径:DNS??Delivery : Listeners : Listener List??New...
配置:
- Name:dns_50_listener
- Destination :10.10.10.50
文章图片
TMSH:
creategtmlistener dns_50_listener address 10.10.10.50
3.3、域名负载均衡池 (dns load balance pool)
域名负载均衡池的能力是将解析操作通过负载均衡算法分散到池中的成员上,让成员去解析dns请求。使用域名负载均衡池的优势,是可以根据请求数量,横向扩展dns设备的个数。可以将请求分发到多个dns服务器,同时可以使用监控手段确认后端dns服务器是可以工作的。
文章图片
listener、pool、monitor关系先建一个pool,里边包含可以处理dns请求的成员,并关联一个monitor,monitor可以监控pool中成员的健康状态,如果monitor请求失败,则这个成员将会从可用状态变为不可用状态,流量也将不会再发送给不可用设备。pool需要关联一个监听器,只有请求到这个监听器上的报文才会转发到pool的成员上,否则,成员将无法收到客户端发来的dns请求。
文章图片
monitor在F5中有部分默认策略,例如tcp,icmp,http,除此之外还有很多可以自定义的监控方式,当我们新建一个monitor的时候,会发现F5还可以针对dns、mysql、pop3等协议进行监控。下边是dns的monitor示例,标蓝的是必填项,dns的monitor是通过向目标发送一个dns请求,并检验响应结果是否和预配置的ip一样,来判断目标是否健康。
monitor配置路径:DNS??Delivery : Load Balancing : Monitors??New Monitor...
monitor的配置界面:
文章图片
pool配置路径:DNS??Delivery : Load Balancing : Pools : Pool List??New Pool...
pool配置界面:
文章图片
pool成员状态:
Status Indicator | Description |
---|---|
绿色圆圈 文章图片 |
对象可用。 此图标表示 BIG-IP 系统为发往该对象的流量提供服务。 |
蓝色方块 文章图片 |
该对象的可用性是未知的。 例如,当对象未配置服务检查、对象的 IP 地址配置错误或对象与网络断开连接时,可能会出现此状态。 |
黄色三角形 文章图片 |
该对象当前不可用,但以后可能无需用户干预即可使用。 例如,已达到其配置的连接限制的对象可能会显示黄色状态,然后在连接数低于配置的限制时切换到绿色状态。 |
红色菱形 文章图片 |
对象不可用。 此图标表示 BIG-IP 系统无法为发往该对象的流量提供服务。 例如,当一个节点因为它变得不可用而未能通过服务检查时,就会出现这种状态。 此状态需要用户干预才能将对象状态恢复为绿色。 |
黑色圆圈 文章图片 |
用户主动禁用了(disabled)可用对象。 |
黑色菱形 文章图片 |
用户主动禁用了(disabled)不可用的对象。 |
灰色图标 文章图片 |
父对象已禁用该对象或该对象已启用但由于另一个禁用的对象而不可用。 |
黑色方形 文章图片 |
对象的可用性未知并且对象被禁用。 |
实验 建立一个monitorGUI:
路径:DNS??Delivery : Load Balancing : Monitors??New Monitor...
配置:
- Name:dns_monitor
- Type:DNS
- Query Name:monitor.f5.com
- Receive String:1.2.3.4
文章图片
TMSH:
create ltm monitor dns dns_monitor qname monitor.f5.com recv 1.2.3.4
建立一个pool路径:DNS??Delivery : Load Balancing : Pools : Pool List??New Pool...
配置:
- Name:dns_pool
- Health Monitors:dns_monitor
- New Members:172.16.20.3,172.16.20.4,172.16.20.5
文章图片
TMSH:
create ltm pool dns_pool members add 172.16.20.3:53 172.16.20.4:53 172.16.20.5:53monitor dns_monitor
更改listener路径:DNS??Delivery : Listeners : Listener List??Properties : dns_50_listener
配置:
- Source Address Translation:Auto Map
- Address Translation :Enable
- Default Pool:dns_pool
文章图片
文章图片
测试
dig +short @10.10.10.50 s.f5.com
通过Statistics??Module Statistics : DNS : Delivery??Pools查看
文章图片
TMSH:
show ltm pool dns_pool detail
通过测试应该看到请求被轮询到三个成员上。并且pool成员的状态应该都为健康(绿色),dns_pool的总请求时为三个成员请求总和。
3.4、缓存Dns (DNS Cache)
三种缓存方式这是第二种加速方式,有三种模式的缓存配置:
- transparent cache
- resolver cache
- validating resolver cache
文章图片
resolver cache执行迭代 dns 解析 DNS 查询并缓存响应。下次系统接收到对缓存中存在的响应的查询时,系统会立即从缓存中读取并响应。
文章图片
validating resolver DNS cache递归查询公共DNS服务器,验证发送响应的DNS服务器的身份,然后缓存响应。 下次系统收到对缓存中存在的响应的查询时,系统会从缓存中返回符合 DNSSEC 的响应。
默认使用resolver cache模式,它既可以充当本地dns发起请求,也可以基于缓存直接响应请求。
Dns Cache基本配置对于dns cache,你可以配置TTL的范围,当你配置了最大和最小ttl值的时候,他会检查dns解析结果中的ttl值,如果小于你配置的最小值,则会修改成为你配置的最小值,同样的,ttl如果超过配置的最大值,也会被修改为你配置的最大值。
配置路径:DNS??Settings : Caches
文章图片
实验创建一个transparent DNS cache
配置dns cache的全局参数GUI:
路径:DNS??Settings : Caches
配置:
- Minimum TTL: 20
- Maximum TTL:300
文章图片
TMSH:
modify ltm dns cache global-settings cache-maximum-ttl 300 cache-minimum-ttl 20
建立一个transparent cacheGUI:
路径:DNS??Caches : Cache List
配置:
- Name:dns_transparent_cache
- Resolver Type:Transparent(None)
文章图片
TMSH:
create ltm dns cache transparent dns_transparent_cache
建立一个dns profile,关联建好的cache路径:DNS??Delivery : Profiles : DNS??New DNS Profile...
配置:
- Name:dns_cache_profile
- Parent Profile: dns
- DNS Cache:Enable
- DNS Cache Name:dns_transparent_cache
文章图片
TMSH:
create ltm profile dns dns_cache_profile defaults-from dns enable-cache yes cache dns_transparent_cache
将dns profile关联dns 监听器GUI:
路径:DNS??Delivery : Listeners : Listener List??Properties : dns_50_listener
配置:
- DNS Profile:dns_cache_profile
文章图片
TMSH:
modify gtm listener dns_50_listener profiles replace-all-with dns_cache_profile
测试先通过Statistics??Module Statistics : DNS : Delivery??Pools路径进入统计信息界面,勾选左侧复选框,点击reset将统计数据清空。在通过dig +short @10.10.10.50 www.f5.com进行请求,第一次请求会发现数据包转发到一个后端,但是之后多次请求就没有转发到后端。
文章图片
同时,我们在观察一下flag位,会发现,第一次请求结果是flags: qr aa rd ra,之后的请求为 flags: qr rd ra,没有了aa(flag含义详见下),因为之后几次的请求都不是权威解析,而是缓存解析出来的。我们再观察一下TTL,会发现第一次是11,是我们在bind9 中配置的数值,但是第二次请求响应TTL是19,这个数值是我们在全局cache设置中cache-minimum-ttl减1秒的数值,之后这个TTL值会每秒减1,直到为0,从缓存中消失。
文章图片
我们继续观察,通过路径Statistics??Module Statistics : DNS : Caches??Caches进行查看,会发现我们请求了三次,但是值响应了两次,是因为第一次缓存没有命中,所以使用负载均衡池的成员去解析,也就是外部dns解析能力,外部dns解析之后,结果配缓存下来,之后的两次就直接响应而不再需要外部dns的帮助。
文章图片
如果我们想看缓存的信息或者删除单个缓存记录,我们需要使用tmsh命令。通过查询命令我们可以看到TTL值在递减。
show ltm dns cache records rrset cache dns_transparent_cache #查看
delete ltm dns cache records rrset cache dns_transparent_cache owner www.f5.com #删除
文章图片
3.5、辅助dns (DNS Express)
第二种加速技术叫做DNS express,配置了DNS Express之后,BIGIP 将作为辅助DNS服务器,他会同步主dns 服务器中zone数据并放入内存中,这时,BIGIP dns系统将直接响应请求。响应速度可以高达125000次解析每秒每个cpu。DNS Express可以缓解ddos的攻击,减小后端dns server的压力。如果使用DNS Express技术,可以使用TSIG(transaction signatures)来确认是否从主dns上同步成功。
原理当创建一个DNS Express 服务时候,bip-ip 系统将会从权威dns服务上同步相对应的zone file,并将zone数据载入系统内存,后续请求将会直接通过DNS Express进行解析,而不需要主dns。如下两个图所示
文章图片
F5成功从主权威dns server同步解析数据
文章图片
当用户发起访问,F5直接从内存上进行解析,而不需要访问主权威dns服务器,从而提高了响应速度。
配置步骤BIG-IP DNS 系统:
- 需要将dns profile中的DNS Express 配置成enable
- 配置name server
- 关联name server和DNS Express zone
- 开启白名单
- 可选,将big-ip放入通知列表
文章图片
BIG-IP配置
- 配置一个监听器,且打开DNS express
- 配置一个或者多个DNS服务器
- 关联DNS Express区域和域名服务器
- 开启区域传送功能
- 添加监听器ip到通知列表
方法 | 命令 |
---|---|
dnsxdump | dnsxdump > /shared/tmp /myzone.txt |
GUI | statistics-> modules statistics:DNS |
TMSH | tmsh show /ltm dns zone [< zone-name> ] |
路径:DNS??Delivery : Nameservers : Nameserver List??New Nameserver...
配置:
- Name:f5_nameserver
- Address:172.16.20.3
文章图片
TMSH:
create ltm dns nameserver f5_nameserver address 172.16.20.3
在zone中开启DNS Express功能GUI
路径:DNS??Zones : Zones : Zone List??New Zone...
配置:
- Name:f5.com
- Server:f5_nameserver
文章图片
TMSH:
create ltm dns zone f5.com dns-express-server f5_nameserver
测试首先先清楚dns_pool 和dns_transparent_cache的统计,但不不要清楚dns cache数据。确保缓存中还有一个A记录。
使用dig +short @10.10.10.50 www.f5.com解析,我们能够正常解析出结果,并且flags: qr aa rd显示为权威解析结果,多次请求后,发现TTL值并未变化,一直是11,表明这不是同cache中解析出来的。通过Statistics??Module Statistics : DNS : Zones??Zones查看统计,发现请求的五次均被记录到DNS Express中。TMSH:show ltm dns zone f5.com
文章图片
dns_pool 和dns_transparent_cache的统计数据都为0,当我们请求一个其他域名的时候,比如s.f5test.com,请求会先发送到pool的成员进行解析,等解析之后会被缓存在big-ip的cache中,因为nameserver没有配置f5test.com。
使用dnsxdump查看数据。如下:
文章图片
如果不想使用DNS Express功能,需要将对应的profile中的DNS Express配置成disabled。
3.6、Wide IP介绍
Wide ip是做智能dns的要素,是配置智能dns的第一位的要素。Wide ip将匹配到的FQDN绑定到一个或者多个虚拟服务上,当一个LDNS将解析请求发送到一个Wide ip上时,wide ip将会检测哪个虚拟池有资格响应这个请求,并配合负载算法进行选择虚拟池。
配置了wide ip 的解析,是权威的解析,同时ttl是被配置为0。如果没有匹配到wide ip,则会进行dns express、dns cache等匹配。
本节主要表达的是Wide IP比DNS Express和DNS cache优先级高,Wide IP负载算法及解析规则后边详细说明。
文章图片
实验 创建一个irulesGUI
路径:DNS??GSLB : iRules??New iRule...
配置:
- Name:simple_resolution_irule
- Definition:
when DNS_REQUEST
host 172.16.16.16
创建一个wide ipGUI
路径:DNS??GSLB : Wide IPs : Wide IP List??New...
配置:
- Name:www.f5.com
- Type:A
- iRule List:simple_resolution_irule
文章图片
TMSH:
create gtm wideip a www.f5.com rulessimple_resolution_irule
测试通过dig@10.10.10.50 www.f5.com命令,我们看到会先的解析结果为172.16.16.16,权威解析,同时ttl为0,这个解析符合预期。在之后的配置中,我们通过负载算法功能还能根据地理位置或者解析地址的性能来动态改变解析结果。
文章图片
我们通过Statistics??Module Statistics : DNS : GSLB能查看统计信息,会发现这个请求并没有被dns cache或者dns express处理,而是统统被wide ip处理了。
文章图片
我们再使用 dig@10.10.10.50 s.f5.com发起请求,会发现它使用dns express,他的解析记录是权威的,而dig@10.10.10.50 s.f5test.com则使用了dns cache进行解析,他的解析是非权威的,且TTL值在递减。
再linux CLI模式下,使用cat进行查看,会发现GSLB(wide ip)的配置存在了bigip_gtm.conf文件中,而DNS Express zone和cache等配置存在了bigip.conf中。
这个实验通过一个irule做一个有限制wide ip,目的是表明wide ip优先级比加速dns和智能dns高。
3.7、使用其他的方式进行dns解析
使用本地BIND如果没有匹配到wide ip,也没有匹配到dns express,也没有匹配到dns cache,也没有匹配到负载均衡池,你还可以使用F5自带的BIND,但是官方不推荐将请求发送到bip-ip的BIND实例上,如果非要用,也建议将BIND作为隐藏主dns,搭配DNS Express使用。
如果想使用本地BIND,配置在监听器上的dns profile需要开启USER BIND Server in BIG-IP,默认开启。
你可以使用ZoneRunner去创建和管理dns zone file,也可以配置BIND 实例,ZoneRunner是一个F5开发的用于配置BIND的管理工具。ZoneRunner具体使用方式不做介绍。只介绍如何创建BIND 实例。
调用远端的dns服务器除了本地BIND,还可以搭配使用微软的dns或者其他厂商的dns服务。
如果没有匹配到wide ip,也没有匹配到dns express,也没有匹配到dns cache,也没有匹配到负载均衡池,并且关闭了USER BIND Server in BIG-IP,同时远端的其他dns服务器的ip和监听器的ip是一样的,并且还要有去往目的服务器的路由,则可以将请求转发到其他dns服务器上进行解析,再由其他dns服务器直接回应客户端,形成一个三角模式,而不通过F5进行响应。如图。
文章图片
使用远端dns服务器的优势在于可平缓且稳进的将旧的dns服务迁移到big-ip dns上,旧的dns服务器不需要做啥配置,只需要将big-ip dns放置旧的dns服务器前边。但是缺点是dns回包是不经过big-ip dns的,所以不能使用缓存技术和DNSSEC的签名技术。
在使用相同ip的时候,需要防止在同一个网络中出现ip重复的问题,如果出现arp冲突,那样只能导致请求时断时续,你需要将流量先引导到big-ip dns而不是旧的dns服务器上。
实验: 创建一个profileGUI
路径:DNS??Delivery : Profiles : DNS??New DNS Profile...
配置:
- Name:dns_nobind_profile
- Parent Profile:dns
- Use BIND Server on BIG-IP:disabled
文章图片
TMSH
create ltm profile dns dns_nobind_profile defaults-fromdns use-local-bind no
创建一个监听器GUI
路径:
配置:
- Name:dns_forwarding_listener
- Destination:172.16.20.3
- DNS Profile:dns_nobind_profile
- Address Translation:不勾选
- Source Address Translation:None
文章图片
TMSH
create gtm listener dns_forwarding_listener address 172.16.20.3 profiles adddns_nobind_profile
需要在big-ip上添加路由信息,如 route add 172.16.20.3 mask 255.255.0.0 10.10.a.3
测试:
【F5 GTM DNS 知识点和实验 3 -加速dns解析】由于测试环境所限,没法做这个实验。但是实验预期应该是,源目地址均没有被转换,发送到旧的dns上,通过tcpdump抓包应该是和bip-ip上抓的包一样。在F5统计页面上,应该看不到任何关于wide ip,dns express,dns cache和负载相关的增加。
推荐阅读
- F5 GTM DNS 知识点和实验 2 -DNS基础知识
- MySQL数据库——MHA高可用配置及故障切换
- F5 GTM DNS 知识点和实验 4 -智能DNS基础
- #yyds干货盘点#spring-cloud-kubernetes与SpringCloud Gateway
- F5 GTM DNS 知识点和实验 5 -智能DNS的探针
- #yyds干货盘点#Spring源码三千问Spring AOP 中 TargetSource 的作用及原理分析
- F5 GTM DNS 知识点和实验 6 -智能DNS算法
- 后台应用架构(单体SOA微服务)理解
- MySQL主从复制与读写分离解析和图文详细步骤