DNS解析常见问题：什么是主DNS服务器和辅助DNS服务器？

很多人可能都听过主DNS服务器和辅助DNS服务器，但对于两者有什么区别和作用不太了解，下面中科三方将简单介绍下这两种DNS服务器的相关特点。

设置DNS服务器时，服务器管理员可以选择是将DNS服务器指定为主服务器还是辅助服务器（也称为从服务器）。在某些情况下，服务器可以是一个区域的主要服务器，也可以是另一个区域的辅助服务器。

DNS主服务器

主服务器托管控制区域文件，该文件包含域的所有权威信息（这意味着它是重要信息的可信源，例如域的IP地址）。这包括重要信息，例如域的IP地址以及负责该域管理的人员。主服务器直接从本地文件获取此信息。只能在主服务器上更改区域的DNS记录，然后主服务器才能更新辅助服务器。

DNS辅助服务器

辅助服务器包含区域文件的只读副本，它们通过称为区域传输的通信从主服务器获取其信息。每个区域只能有一个主DNS服务器，但它可以有任意数量的辅助DNS服务器。无法在辅助服务器上更改区域的DNS记录，但在某些情况下，辅助服务器可以将更改请求传递到主服务器。

为什么要有辅助DNS服务器？

主DNS服务器包含所有相关资源记录，并且可以处理域的DNS查询，但是标准（并且许多注册商需要）至少具有一个辅助DNS服务器。这些辅助服务器的好处是它们在主DNS服务器关闭时提供冗余，并且它们还有助于将请求的负载分配到域，以便主服务器不会过载，这可能导致拒绝服务。他们可以使用循环DNS来实现这一点，循环DNS是一种负载平衡技术，旨在为群集中的每个服务器发送大致相等的流量。

以上就是关注主DNS服务器和辅助DNS服务器的相关介绍。

最近工作过程中需要设定邮件服务器，其中涉及到dns服务器的设定。

整理并且记录自己的理解。

A、CNAME、MX、NS、TXT、SPF

下面挨个介绍一下。

我们在浏览器输入域名后，需要向DNS服务器请求，找到这个域名对应的服务器IP。上面示例就是这么一条记录。

虽然域名和IP都可以变更，但是相比来说域名变更更加简单和随意。所以当网站更换自己域名的时候，就需要修改这条记录。

给某一个domain起多个名字。

类似于，jdcom,jd360com,jingdongcom虽然是不同名字的域名，但是可以指向同一个原名jdcom。可以让企业的对外展示更加灵活。

举例：

jd360com IN CNAME jdcom

jingdongcom IN CNAME jdcom

jdcom IN A 123123123123 （这条是A记录例子）

当发信侧服务器给受信侧发邮件时，首先会要求DNS服务器解析受信侧邮箱地址中@后面部分的域名对应的MX记录（DNS的写法可以理解成 examplecom 的A记录下面，有一行上面示例的MX记录，当然邮箱服务器也有对应的A记录）。

这样，邮件就直接发到对应的MX记录的A记录里的IP了。

例子：给 test@exmaplecom 发邮件的话，

DNS会返回给发信侧198511003这个IP

※如果是普通用户通过exmaplecom浏览主页，那么DNS继续返回 198511002 。这个其实也需要DNS判断请求服务器是邮件服务器还是普通的访问。

指定该域名由哪个DNS服务器来进行解析。

一般指某个主机名或域名的说明，或者****，或者标注提醒等等。

SPF记录是TXT记录的一个运用。后面的备注需要按照指定的格式才能有效。

从发信侧服务器设定到DNS上的这条记录中，读取信息，判断发信侧是否合法。

如果不符合规则，那么按照约定的规则处理掉。

跟MX记录正好相反。

MX：我是收件服务器，你找我时，请参考我设定到DNS服务器上的MX记录。

SPF：我是发信服务器，你接受邮件时，请参考我设定到DNS服务器上SPF规则。如果不是我发的信，你可以删掉或者接收。

有一个问题，调查后更新。

设定好SPF的记录之后怎么快速测试呢？

总不能每次都等DNS更新完再测试吧？

20210914更新：

SPF测试方法很多，google一下的话可以找到很多网站。

我常用的是 https://mxtoolboxcom/spfaspx

DNS是域名系统（DomainNameSystem）。在Internet上域名与IP地址之间是一一对应的，域名虽然便于人们记忆，但机器之间只能互相认识IP地址，它们之间的转换工作称为域名解析，域名解析需要由专门的域名解析系统来完成，DNS就是进行域名解析的系统。

DNS 包括七大资源记录类型：

SOA （起始授权机构） 定义了该与众的权威名称服务器

NS （名称服务器） 表示某区域的权威服务器鹤SOA中指定的该区域的主服务器的辅助服务器

A （主机） 列出了区域中的FQDN(完全合格的域名) 到ip 地址的映射

PTR（指针） 相对于A资源记录，ptr记录是把ip地址映射到FQDN

MX 邮件交换器记录，向指定的邮件交换主机提供消息路由

SRV （服务） 列出了正在提供特定服务的服务器

CNAME （别名） 将多个名字映射到同一台计算机上，便于访问。

https://wwwresearchgatenet/scientific-contributions/28445163_Asaf_Shabtai

摘要：在存在安全对策的情况下，设计用于数据泄露的恶意软件必须使用隐蔽的通道来实现其目标。域名系统(DNS)协议是目前恶意软件开发者常用的秘密渠道。虽然近十年来人们一直在研究利用DNS进行隐蔽通道的检测，但以往的研究主要涉及到一个特定的隐蔽通道子类，即DNS隧道化。虽然隧道检测的重要性不应该被最小化，但是整个低吞吐量DNS泄露恶意软件被忽略了。

在这项研究中，我们提出了一种在DNS上检测隧道和低吞吐量数据泄露的方法。在确定之前检测到的恶意软件使用了网络活动注册的网络域名，而不是损害现有的合法域名后，我们专注于检测和拒绝这些域名的请求，作为一个有效的数据泄漏关闭。因此，我们提出的解决方案处理流式DNS流量，以便检测和自动拒绝用于数据交换的域的请求。初始数据收集阶段以允许长时间扫描的方式收集每个域的DNS日志，因此能够处理“慢速”攻击。第二阶段是基于每个域的查询行为提取特征，最后阶段是利用异常检测模型对域进行分类。至于检测，DNS请求被分类为用于数据泄露的域将被无限期拒绝。

我们的方法是在一个大型递归DNS服务器日志上进行评估，其峰值为每小时4700万次请求。在这些DNS日志中，我们从DNS隧道挖掘工具以及两个现实生活中的恶意软件中注入了数据泄露流量:FrameworkPOS，它曾在2014年被用于从家得宝(Home Depot)窃取5600万张信用卡;BackdoorWin32Denis，在2016年被用于Cobalt Kitty APT。即使将我们的方法限制在极低的假阳性率(5万个域中的1个)时，它也检测到了上述所有情况。此外，这些日志还被用来比较我们的系统和最近发表的两种方法，这两种方法的重点是检测DNS隧道，以强调检测低吞吐量过滤恶意软件的新颖性。

一、介绍

个人电脑和计算机网络一直是数据盗窃攻击的目标，通常使用的技术包括中间人攻击[7]或通过秘密渠道[25][40]泄露数据的恶意软件。在恶意软件的情况下，通常是作为命令和控制(C&C)的远程服务器，等待来自恶意软件的通信并记录传输到它的数据。然而，在受保护的网络(私有的或组织的)中，目标主机可以驻留在一个有限的段中，与外界的访问受限。在这种情况下，即使允许连接，通常也会由安全解决方案对可疑行为进行监视。因此，在这种情况下，恶意软件必须找到一个隐蔽的通道，以便将数据过滤到远程服务器，而现有的安全解决方案不会阻止或检测到这些数据。实现这一目标的一个渠道是域名系统(DNS)协议，这是本研究的重点。

从本地计算机到Internet的任何通信(不包括基于静态ip的通信)都依赖于DNS服务。因此，限制DNS通信可能导致合法远程服务断开连接;因此，必须保守地使用DNS来阻止内容。从攻击者的角度来看，这使得DNS协议成为数据泄漏[3]的隐蔽通信通道的一个很好的候选。

典型地，DNS协议不是为任意数据交换而设计的;DNS消息相对较短，响应不相关，这意味着它们到达的顺序不一定与发送[27]的请求的顺序相同。这些局限性可以通过攻击者使用两种方法之一:(1)建立一个双向通信信道上的DNS(例如,通过模拟一个可靠的C&C的恶意软件和服务器之间的会话),或(2)使用通道发送小短的数据点，用最小的开销和请求，并且消息是独立的(如信用卡号码、用户凭证,keylogging和地理位置)。我们将这两种方法分别称为高吞吐量隧穿和低吞吐量恶意软件。DNS过滤的完整威胁环境包括这两类，因此，任何通过DNS协议检测或防止数据泄漏的解决方案都必须同时处理这两类问题。

近年来检测到的低吞吐量泄露恶意软件使用的互联网域名购买、注册和操作完全是为了他们的网络运动。对于需要用户提供和配置Internet域的DNS隧道工具来说也是如此。因此，拒绝这些域的请求相当于在不影响正常网络运行的情况下停止数据泄漏。

本文提出了一种基于机器学习技术的新型DNS泄露检测方法，该方法既针对DNS隧道化，又针对低吞吐量的恶意软件泄露。我们的方法的输入是一个DNS流量日志流，它经常按域分组。这些日志收集的时间足够长，即使数据交换速度相对较慢，也可以检测到恶意软件。对每个域的收集日志定期应用特征提取阶段。然后，对每个域的特征进行分类阶段，以确定该域是否用于数据交换。该分类是使用隔离森林[21]异常检测模型进行的，该模型事先对合法流量进行了训练。在分类之后，对任何已被分类为异常的域的请求将被无限期地阻塞，从而停止数据泄漏。

我们使用隧道工具和之前检测到的低吞吐量泄露恶意软件的流量模拟来评估我们的工作。这些模拟与合法的大规模DNS流量一起执行，其峰值速率为每小时4100万次请求，从而使检测任务尽可能真实。该该检测覆盖率下表明少于0002%假阳性率以及低误报率随着时间的推移而更少,我们将最近发表的两篇论文旨在检测隧道方法与本文进行比较，证明我们的方法的贡献——检测的低吞吐量漏出恶意软件。

我们工作的贡献有三方面:

1)除了检测DNS隧道外，我们的工作还能够检测低吞吐量DNS泄露恶意软件。

2)因为我们的方法在特定的时间范围内对域进行分类(称为每个域)，所以它通过拒绝对被分类为用于数据交换的域的请求，来立即、准确和自动地阻止出现的DNS数据泄漏尝试。可以论证的是，对于在特定时间段内对用户进行分类的检测系统来说，情况并非如此，因为基于恶意软件的存在对合法用户的流量进行无限期阻塞可能是不可接受的。

3)据我们所知，之前的研究还没有对大规模、高质量的DNS流量日志(超过106个查询/小时)进行评估。由于DNS上的数据泄露可能试图低调神秘地操作，针对大规模流量的测试可能是任何检测系统的最终挑战。前一种说法得到了支持，因为当我们将我们提出的方法与以前建议的方法进行比较时，我们发现它们的报告结果有所减少。

二、背景