F5 GTM DNS 知识点和实验 3 -加速dns解析

Posted 2022-02-18 cnxhsy

第三章：加速dns解析

目标：

• 了解一个请求是如何发送到一个dns资源池中的，并且了解如何监控资源池中成员的健康状态
• 使用dns缓存对dns请求进行加速

• 使用dns express进行对dns请求进行加速

• 智能解析dns请求
• 加速解析（dns express，dns cache，load balance dns queries）
• 配置监听器

3.1、Big-IP DNS解析过程

• wide ip
• dns express
• dns cache
• dns resolving cache
• load balance pool
• local BIND
• forward to other dns

如下图，如果dns请求包目的地址为监听器（listener）ip，则进行域名解析，如果能匹配到wide-ip，则进行智能解析，否则检查是否在dns express 的区域文件中，如果匹配上，进行加速解析处理，否则进行dns缓存查询，如果匹配上，则进行加速解析处理，否则查看big-ip是否配置了dns解析能力，如果有，则主动进行解析，并记录到缓存，否则检查是否配置了dns负载均衡池，如果配置了，则将解析请求发送到其中一个成员，让其解析，并缓存解析结果，否则检查是否配置了本地bind能力，如果配置了则进行解析并缓存解析结果，如果没有配置，则检查目的地址是否不是自身接口ip（self ip），如果不是自身接口ip，则转发到具有相同ip的目标地址上。

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：目的地址转换，主要用于负载均衡池的场景。默认未开启。

注：source address translation和address translation使用场景下一环节用实验说明。

实验

配置一个listener

GUI：

路径：DNS ›› Delivery : Listeners : Listener List ›› New...

配置：

• Name：dns_50_listener
• Destination ：10.10.10.50

TMSH：

create  gtm  listener 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）不可用的对象。
灰色图标	父对象已禁用该对象或该对象已启用但由于另一个禁用的对象而不可用。
黑色方形	对象的可用性未知并且对象被禁用。

pool的负载算法：

常用的轮询（round robin），加权轮询（ratio），最小连接数（least connection）

实验

建立一个monitor

GUI：

路径：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:53  monitor 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

transparent cache

使用外部 DNS 解析器解析查询，然后缓存解析器的响应。 下次系统接收到缓存中存在的响应的查询时，系统会立即从缓存中读取并响应。

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 cache

GUI：

路径：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

主dns：

• 开启白名单
• 可选，将big-ip放入通知列表

BIG-IP配置

• 配置一个监听器，且打开DNS express
• 配置一个或者多个DNS服务器
• 关联DNS Express区域和域名服务器

主DNS 服务器

• 开启区域传送功能
• 添加监听器ip到通知列表

确认区域传输信息和状态方法

方法	命令
dnsxdump	dnsxdump > /shared/tmp /myzone.txt
GUI	statistics->modules statistics:DNS
TMSH	tmsh show /ltm dns zone [<zone-name>]

实验

创建一个nameserver

GUI

路径：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负载算法及解析规则后边详细说明。

实验

创建一个irules

GUI

路径：DNS ›› GSLB : iRules ›› New iRule...

配置：

• Name：simple_resolution_irule
• Definition：

when DNS_REQUEST 
  host 172.16.16.16

创建一个wide ip

GUI

路径：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 rules  simple_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服务器上。

实验：

创建一个profile

GUI

路径：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-from  dns 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 add  dns_nobind_profile 

需要在big-ip上添加路由信息，如 route add 172.16.20.3 mask 255.255.0.0 10.10.a.3

测试：

由于测试环境所限，没法做这个实验。但是实验预期应该是，源目地址均没有被转换，发送到旧的dns上，通过tcpdump抓包应该是和bip-ip上抓的包一样。在F5统计页面上，应该看不到任何关于wide ip，dns express，dns cache和负载相关的增加。