几种针对DNS的DDoS攻击应对方法

DDoS攻击是指通过僵尸网络利用各种服务请求耗尽被攻击网络的系统资源，造成被攻击网络无法处理合法用户的请求。而针对DNS的DDoS攻击又可按攻击发起者和攻击特征进行分类：

1、按攻击发起者分类 僵尸网络：控制大批僵尸网络利用真实DNS协议栈发起大量域名查询请求 模拟工具：利用工具软件伪造源IP发送海量DNS查询

2、按攻击特征分类 Flood攻击：发送海量DNS查询报文导致网络带宽耗尽而无法传送正常DNS 查询请求。

资源消耗攻击：发送大量非法域名查询报文引起DNS服务器持续进行迭代查询，从而达到较少的攻击流量消耗大量服务器资源的目的。

处理办法：

屏蔽未经请求发送的DNS响应信息

一个典型的DNS交换信息是由请求信息组成的。DNS解析器会将用户的请求信息发送至DNS服务器中，在DNS服务器对查询请求进行处理之后，服务器会将响应信息返回给DNS解析器。但值得注意的是，响应信息是不会主动发送的。

服务器在没有接收到查询请求之前，就已经生成了对应的响应信息，回应就被丢弃

丢弃快速重传数据包。

1.即便是在数据包丢失的情况下，任何合法的DNS客户端都不会在较短的时间间隔内向同一DNS服务器发送相同的DNS查询请求。

2.如果从相同IP地址发送至同一目标地址的相同查询请求发送频率过高，这些请求数据包可丢弃。

启用TTL

如果DNS服务器已经将响应信息成功发送了，应该禁止服务器在较短的时间间隔内对相同的查询请求信息进行响应。

1.对于一个合法的DNS客户端如果已经接收到了响应信息，就不会再次发送相同的查询请求。

2.每一个响应信息都应进行缓存处理直到TTL过期。

3.当DNS服务器遭遇大量查询请求时，可以屏蔽掉不需要的数据包。

丢弃未知来源的DNS查询请求和响应数据

通常情况下，攻击者会利用脚本来对目标进行分布式拒绝服务攻击（DDoS攻击），而且这些脚本通常是有漏洞的。因此，在服务器中部署简单的匿名检测机制，在某种程度上可以限制传入服务器的数据包数量。

丢弃未经请求或突发的DNS请求

这类请求信息很可能是由伪造的代理服务器所发送的，或是由于客户端配置错误或者是攻击流量。所以无论是哪一种情况，都应该直接丢弃这类数据包。

非泛洪攻击 (non-flood) 时段，创建一个白名单，添加允许服务器处理的合法请求信息。白名单可以屏蔽掉非法的查询请求信息以及此前从未见过的数据包。

这种方法能够有效地保护服务器不受泛洪攻击的威胁，也能保证合法的域名服务器只对合法的DNS查询请求进行处理和响应。

启动DNS客户端验证

伪造是DNS攻击中常用的一种技术。如果设备可以启动客户端验证信任状，便可以用于从伪造泛洪数据中筛选出非泛洪数据包。

对响应信息进行缓存处理

如果某一查询请求对应的响应信息已经存在于服务器的DNS缓存之中，缓存可以直接对请求进行处理。这样可以有效地防止服务器因过载而发生宕机。

很多请求中包含了服务器不具有或不支持的信息，我们可以进行简单的阻断设置，例如外部IP地址请求区域转换或碎片化数据包，直接将这类请求数据包丢弃。

利用ACL，BCP38，及IP信誉功能的使用

托管DNS服务器的任何企业都有用户轨迹的限制，当攻击数据包被伪造，伪造请求来自世界各地的源地址。设置一个简单的过滤器可阻断不需要的地理位置的IP地址请求或只允许在地理位置白名单内的IP请求。

还有一种情况，某些伪造的数据包可能来自与内部网络地址，可以利用BCP38通过硬件过滤也可以清除异常来源地址的请求。

BCP38对于提供DNS解析的服务提供商也相当有用，可以避免用户向外发送攻击或受到内部地址请求的攻击，过滤用户并保证其数据传输。

提供余量带宽

如果服务器日常需要处理的DNS通信量达到了X Gbps，请确保流量通道不止是日常的量，有一定的带宽余量可以有利于处理大规模攻击。

结语，目前针对DNS的攻击已成为最严重的网络威胁之一。目前越来越多的大型网站注重DNS保护这一块。为保障网站安全，保障网站利益，选择高防型的DNS为自己的域名进行解析已经迫在眉睫。

希望可以帮到您，谢谢！

在我们修复Windows网络连接时，要确保本地TCP/IP栈没有问题。本文将一步步地指导您进行本地主机连接DNS服务器和默认网关服务器的能力测试，并介绍如何测试主机名解析。

在“检查IP配置”中，我阐述了如何确定哪个IP地址是我们的系统使用的主地址。接下来，我们会验证IP地址配置是正常工作的，以及本地TCP/IP堆栈没有问题。

首先，我们需要执行的测试是PING本地主机地址。有几种不同的方法可以实现这个步骤。其中一个是输入下面的命令：

PING LOCALHOST

当我们输入这个命令时，Windows将PING地址127.0.0.1。不管我们的机器的地址是什么，Windows总会使用127.0.0.1作为本地主机地址。因此，对于上面所列出来的命令，另外一个替代的命令是：

Ping 127.0.0.1

输入这个命令时，我们应该可以查看到一个成功的PING，如同使用其它的PING命令一样。我们可以看到图A所显示的例子。

PING本地主机地址对诊断远程主机连接问题没有什么作用。然而，它却可以允许我们确认我们的本地TCP/IP 栈运行是否正确。当我们PING本地主机地址时接收到目的主机无法到达的错误信息时，这往往意味着TCP/IP的配置是不正确的，或者本地TCP/IP栈的某个部分出错了。

依据我的个人经验，我们通常可以通过删除计算机的TCP/IP协议来处理这个问题，然后重新设置。

PING默认网关

在本系列的前面的部分文章中，我提到有几种不同的TCP/IP配置部分需要文档化，它们是故障修复过程所必需的。其中有默认网关的IP地址和主DNS服务器的信息。

假设我们尝试连接的是远程网络或者在企业网络的不同分片上的主机，那么我们下一步需要尝试的是PING默认网关。我们可以简单地通过在PING命令后添加默认网关的IP地址来完成。比如，如图B，请注意我的TCP/IP配置列出了我的默认网关地址是147.100.100.100。然后，我会直接PING这个地址。这就验证了本地机器可以连接到默认网关。同时，它也告诉我们本地网络的连接工作正常，至少在IP地址层上是正常的。

PING DNS服务器

目前，我们已经确定在本地计算机和默认网关之间的IP层连接是正常的。然而，这并不保证主机名被解析到正确的IP地址。在这一系列的文章的第一部分“使用PING命令来修复网络连接故障”中，我已经探讨了如何使用目的主机的正式域名和PING命令来验证DNS服务器是否正常工作。还有几种其它的方法我们可以用来简单地测试DNS名字解析。

其中一个是，我们可以PING DNS服务器的IP地址，如图C所示。这并不保证名字解析是正确工作的，但是它肯定可以验证本地机器能够连接到DNS服务器上。

另外一个方法是使用Nslookup命令来验证域名解析是正确工作的。我们只需简单地输入Nslookup，后面加上远程主机的正式域名。Nslookup命令就应该能够将域名解析到一个IP地址，如图D所示。

如果我们不经常使用Nslookup，那么一开始上面的图象可能会有点误导我们。首先，这个屏幕似乎在报告一个错误。如果我们更仔细点观察，我们可以看到返回的信息的第一部分是来自于本地DNS服务器。这是因为所引用的IP地址是与DNS服务器的IP地址相匹配的。然而，返回的信息的后面部分为我们提供的是我们所要查询的主机的IP地址。只要列出了这个IP地址，那么DNS查询就是成功的。

如果域名解析过程失败了，那么就可以肯定存在一个DNS问题。实际问题可能是许多不同的DNS服务器问题中的其中一个。比如，转发的DNS服务器地址可能是不正确的，或者DNS服务器可能并不访问因特网，这些都是连接更高级DNS服务器所必须的。类似的，DNS服务器的DNS服务可能已经中断。典型地，由于许多客户往往都依赖于一个DNS服务器，因此这些类型的问题将会影响到其它客户。

如果DNS域名解析成功了，那么，重要的是我们要验证域名解析过程中返回的IP地址。我们可以通过对比返回的IP地址和远程主机正在使用的实际的IP地址来进行验证。这些IP地址必须是相匹配的，但是，其中可能会有不匹配的情况，它将造成连接失败。

当出现IP地址不匹配时，可能是客户端感染了恶意软件或者是DNS中毒了。DNS中毒指的是DNS缓存中被写入无效的或者不正确的IP地址。

当出现这样一个问题时，我会建议客户端机器的进行恶意软件扫描。同时对间谍软件和病毒进行扫描是很重要的，因为它们都会引起这种问题。一旦清除了恶意软件的问题，那么可以尝试清空DNS缓存。我们可以输入下面的命令来清空DNS缓存：

IPCONFIG /FLUSHDNS

我们可以看看这个例子，如图E所示：

其中需要记住的重要一点是， DNS缓存包含不准确IP地址，并不总是意味着发生了DNS中毒。因为有时主机被指派了新的IP地址后，DNS缓存需要一段时间才会得到修改后的IP地址。

出现这个问题，你应该先和其他的电脑换下网线试试

如果你还不可以上，就是你自己电脑的问题

如果换了以后，你可以上，用你以前网线的那台电脑不能上，你就再将两条网线的交换机端口换一下，

如果还是那台不可以，就是网线出现了问题，

如果变成你这台又不可以了，就是交换机的端口出现问题。

---