基于VNF forwarding graph实现DNS分布式解析的一种方法

董传杰

摘 要：目前分布式DNS需借助BRAS专用硬件实现，与通用DNS服务器硬件不兼容，且其软件功能差异也较大，无法通用。针对上述问题，文章提出了基于VNF forwarding graph实现DNS分布式解析的一种方法，通过将DNS Agent和DNS cache虚拟化，实现了DNS的分布式部署，让DNS不再受限于硬件或软件兼容性的限制，让分布式DNS可以提供给各类场景（宽带、2G、3G）复用，即实现了DNS的分布式部署及统一复用。

关键词：分布式DNS；VNF部署；通信

1 现有技术方案

现有域名系统（Domain Name System，DNS）解析技术实现方案：用户向宽带远程接入服务器（Broadband Remote Access Server，BRAS）拨号，上线成功后，BRAS会给用户分配地址并同时下发DNS服务器地址给用户。当用户上网时，如果域名对应的IP地址在本地缓存中不存在，那么用户就会发起相应的DNS查询，BRAS收到用户的DNS查询不作任何处理，直接转发给DNS服务器进行解析。DNS服务器收到查询请求后，查找本地记录，查找成功后会将查询结果返回给用户。用户收到DNS查询结果后，就可以正常访问网络资源。

在有的场景中，BRAS设备会启用DNS server，来实现DNS分布式解析功能。在用户上线时，BRAS将自己的地址作为DNS server告诉用户。当用户就会发起相应的DNS查询时，BRAS收到用户的DNS查询后，先查找本地DNS缓存，如果匹配到就直接将结果返回给用户。如果在本地DNS缓存中查不到，BRAS就会向DNS server发起查询，查询的域名为用户发起DNS请求中的域名。当BRAS收到DNS服务器返回的查询结果后，会将该结果返回给用户，并同时将该查询结果写入DNS缓存中。DNS缓存中的DNS条目会进行更新和老化处理，来保证BRAS和DNS server上的DNS条目一致性[1]。现有DNS解析方案示意如图1所示。

图1 现有DNS解析方案示意

现有技术方案主要存在两点缺陷：（1）硬件没有网络功能虚拟化（Network Function Virtualization，NFV）。BRAS和DNS服务器硬件不能通用。（2）软件没有NFV化。DNS server和DNS缓存管理等功能都是运行在各个专有网元上，需要在各个网元上单独实现，不能复用。

2 DNS分布式查询方案

为了改进上述缺陷，本文提出了一种基于VNF forwarding graph实现DNS分布式查询的方式。VNF forwarding graph如图2所示，该方案的工作原理如下[2]。

（1）用户向VBRAS（VNF1）拨号，上线成功后，VBRAS会给用户分配地址并同时下发DNS服务器地址给用户。但是此时VBRAS给用户下发的DNS地址并非DNS服务器的地址，而是DNS Agent地址。

（2）用户上网时，如果域名对应的IP地址在本地缓存中不存在，那么用户就会发起DNS查询，VBRAS收到用户的DNS查询不作任何处理，直接转发给DNS Agent（VNF2）进行解析。

（3）DNS Agent收到查询请求后，向DNS cache（VNF3）发起查询，如果DNS cache中存在对应的DNS条目，那么DNS cache就会将该条目返回给DNS Agent；如果不存在对应的条目，则DNS cache返回一个空结果给DNS Agent，表示该条目在DNS cache中不存在。

（4）DNS Agent收到DNS cache返回的查询结果，如果结果中有对应的条目，那么DNS Agent会直接将该结果返回给用户；如果返回的查询结果为空，那么DNS Agent会向DNS服务器发起一个DNS查询，查询中的域名为用户发起DNS请求中的域名。当DNS Agent收到DNS服务器返回的查询结果后，会将该结果返回给用户，并同时将该查询结果写入DNS cache中。

（5）用户收到DNS查询结果后，此次DNS查询结束。

（6）DNS cache管理和cache中DNS条目更新方式和传统BRAS保存一致，不在本文论述范围内。

各个NF/VNF之间报文交互接口：

（1）用户和VBRAS之间采用PPPOE，或者native IP。

图2 DNS分布式查询的VNF forwarding graph示意

（2）用户和DNS Agent之间采用DNS标准。

（3）VBRAS和DNS Agent之间采用native IP。

DNS Agent和DNS server之间采用DNS标准。

（4）DNS Agent和DNS cache之间：查询接口采用DNS标准；DNS条目写入接口采用DNS UPDATE消息，或者采用其他接口。

各个NF/VNF之间报文交互确认机制：

（1）DNS Agent和DNS cache的查询确认机制。DNS Agent在等待DNS cache应答时，需要有超时保护机制，如果超时，DNS Agent需要重传；在重传一定次数后，如果仍然失败，则认为DNS cache不可用，DNS Agent需要向DNS server发起DNS查询。

（2）DNS Agent和DNS cache的条目写入确认机制。DNS Agent在等待DNS cache写入应答时，需要有超时保护机制，如果超时，DNS Agent需要重传；在重传一定次数后，如果仍然失败，则认为DNS cache不可用，本次记录写入失败，并产生相应的告警或者事件。

（3）DNS Agent和DNS server的确认机制。DNS Agent在等待DNS server应答时，需要有超时机制，如果超时，DNS Agent需要重传；在重传一定次数后，如果仍然失败，则认为DNS server不可用。如果在有备用DNS server的情况下，DNS Agent需要向备用DNS server发起DNS查询。如果所有DNS server都不可用，则本次查询失败，并产生相应的告警或者事件。

VNF forwarding graph中各个VNF的部署关系：

（1）VBRAS和DNS Agent部署关系。一个VBRAS可以对应多个DNS Agent，一个DNS Agent也可以服务多个VBRAS，主要取决于VBRAS下面管理的用户数量和DNS Agent的查询处理能力，以及冗余部署的要求。通常部署时，一个DNS Agent对应多个VBRAS比较常见。用户上线时，可由Radius下发对应的DNS Agent地址给用户。

（2）DNS Agent和DNS cache部署关系。为了简化方案的复杂度，一个DNS Agent对应一个DNS cache；一个DNS cache对应一个或者多个DNS Agent，取决于DNS cache的大小。

（3）DNS Agent和DNS server部署关系。一个DNS Agent可对应多个DNS server，但同一时间只有一个DNS server是主用的，其余DNS server是备用；一个DNS server对应多个DNS Agent，这样才能实现分布式查询的好处。

3 结语

使用VNF forwarding graph实现DSN的分布式解析，可提高硬件通用性，本方案中所有的VNF都部署在VM上，底层基于通用硬件服务器。同时使用VNF forwarding graph进行实现，可提高网络功能的复用度，将DNS Agent和DNS cache抽象成VNF，可以用在任何需要DNS查询/解析的场景。譬如：不管是宽带用户接入场景还是无线用户（2G/3G/4G）接入場景，都可以复用。在传统网络中，需要在BRAS和XGW分别实现该功能，提高了改方案的可移植性及冗余性。