“保安堂在逃蛇精”通过精心收集，向本站投稿了15篇DNS缓存攻击介绍，下面是小编给大家带来的DNS缓存攻击介绍，以供大家参考，我们一起来看看吧!
篇1：DNS缓存攻击介绍
近来，网络上出现史上最强大的互联网漏洞DNS缓存漏洞，此漏洞直指我们应用中互联网脆弱的安全系统，而安全性差的根源在于设计缺陷，
DNS缓存攻击介绍
，
利用该漏洞轻则可以让用户无法打开网页，重则是网络钓鱼和金融诈骗，给受害者造成巨大损失。 缓存中毒攻击者(cache poisonin
篇2：如何保护DNS设施免受缓存毒害攻击
当你审查网络基础设施的时候，不要忘记审查最关键的域名系统(DNS)，如果域名系统受到破坏，可能导致企业无法连接互联网或者将企业客户重定向到竞争对手的网站，甚至还可能通过中间电子邮件服务器分流重要电子邮件或者将你的用户重新导向到某个知名网站的钓鱼网站，从而获取用户的帐户名和密码等信息，
以下是七种方法可以帮助你保护DNS基础设施的安全：
1.只有授权的查询者才可以使用递归，或者完全禁用递归
你设置域名服务器是为了这样的目的：实现对域的查询，或者向内部解析器和域名服务器关于互联网域名的查询提供服务，或者两者兼而有之。如果你的域名服务器只是为了实现互联网其他域名服务器的查询，就可以完全禁用递归。如果你的域名服务器的功能还包括为内部客户查询互联网域名提供服务，就可以将查询限制为那些来自内部地址空间的查询。如果你的域名服务器包括以上两个功能，就可以考虑按照两个不同的功能采用两种不同方式保护域名服务器。如果你不能分隔这两个功能，至少要将递归功能限制为仅内部地址空间可用。
2. 将区域传送限制给授权辅助域名服务器
互联网上的大多数用户都不需要能够从你的名称服务器传送整个区域，当然也有特例，有些DNS注册要求能够从其注册者的域名服务器传送区域。如果可能的话，可以使用TSIG将区域传送限制给授权的辅助域名服务器。对于不应该进行区域传送的辅助域名服务器，完全禁用这个功能。
3. 使用转发器来减少风险
可以通过让所有内部域名服务器直接与互联网域名服务器进行通信来提供互联网域名解析。但是如果你的域名服务器存在漏洞，允许攻击者通过恶意格式化的响应使服务器崩溃，那么你就需要花费很多时间去更新所有的漏洞域名服务器。相反的，通过较小组域名服务器的互联网域名解析被指定为转发器，这些可以夹在内部防火墙和外部防火墙之间，这样就可以将所有威胁都分割，从而减少内部网络的安全问题，
4. 运行最新的域名服务器软件
根据调查显示，大约只有一般的域名服务器运行的是最新的名称服务器代码，较老的域名服务器存在这样那样的漏洞，最好的做法就是将软件升级为最新版本。对于BIND域名服务器，应该使用9.5或者9.6版本。
5. 保护平台安全
域名服务器软件本身并不总是 用于攻击域名服务器的介质，除了保护域名服务器外，你还需要保护底层的操作系统平台，你将需要禁用不必要的网络服务并移除不必要的帐户，当然如果你购买设备的话，设备就能帮你完成这些工作。
6. 检查工作
BIND域名服务器对于语法是很敏感的，任何区域数据文件或者named.conf文件中的细微错误都可能造成严重的影响，会导致SERVFAIL对查询响应或者设置会组织域名服务器重新启动。最新版本的BIND就保护两个非常游泳的工具，named-checkconf和 named-checkzone，这样就可以使用这两个工具来检查named.conf和区域数据文件的语法(在重新载入前)，或者使用GUI来避免基本语法的复杂性。
7. 限制管理权限
在运行域名服务器的主机行，确保只有授权的用户才有管理权限，并且需要对他们的操作活动进行日志记录，这在Unix和Linux主机上会比较麻烦，因为拥有root访问权的用户可以做任何事情。但是你的操作系统可能可以支持更多分隔的管理访问权限，或者你可以使用sudo来设置管理权限，还有些商业产品也能够提供这些功能。
篇3：dns欺骗攻击
定义： DNS欺骗就是攻击者冒充域名服务器的一种欺骗行为，
原理：如果可以冒充域名服务器，然后把查询的IP地址设为攻击者的IP地址，这样的话，用户上网就只能看到攻击者的主页，而不是用户想要取得的网站的主页了，这就是DNS欺骗的基本原理。DNS欺骗其实并不是真的“黑掉”了对方的网站，而是冒名顶替、招摇撞骗罢了。
现在的Internet上存在的DNS服务器有绝大多数都是用bind来架设的,使用的bind版本主要为bind 4.9.5+P1以前版本和bind 8.2.2-P5以前版本.这些bind有个共同的特点,就是BIND会缓存(Cache)所有已经查询过的结果,这个问题就引起了下面的几个问题的存在.
1>.DNS欺骗
在DNS的缓存还没有过期之前,如果在DNS的缓存中已经存在的记录,一旦有客户查询,DNS服务器将会直接返回缓存中的记录.
下面我们来看一个例子:
一台运行着unix的Internet主机,并且提供rlogin服务,它的IP地址为123.45.67.89,它使用的DNS服务器(即/etc/resolv.conf中指向的DNS服务器)的IP地址为98.76.54.32,某个客户端(IP地址为38.222.74.2)试图连接到unix主机的rlogin端口,假设unix主机的/etc/hosts.equiv文件中使用的是dns名称来允许目标主机的访问,那么unix主机会向IP为98.76.54.32的DNS服务器发出一个PTR记录的查询:
123.45.67.89 -> 98.76.54.32 [Query]
NQY: 1 NAN: 0 NNS: 0 NAD: 0
QY: 2.74.222.38.in-addr.arpa PTR
IP为98.76.54.32的DNS服务器中没有这个反向查询域的信息,经过一番查询,这个DNS服务器找到38.222.74.2和38.222.74.10为74.222.38.in-addr.arpa.的权威DNS服务器,所以它会向38.222.74.2发出PTR查询:
98.76.54.32 -> 38.222.74.2 [Query]
NQY: 1 NAN: 0 NNS: 0 NAD: 0
QY: 2.74.222.38.in-addr.arpa PTR
请注意,38.222.74.2是我们的客户端IP,也就是说这台机子是完全掌握在我们手中的.我们可以更改它的DNS记录,让它返回我们所需要的结果:
38.222.74.2 -> 98.76.54.32 [Answer]
NQY: 1 NAN: 2 NNS: 2 NAD: 2
QY: 2.74.222.38.in-addr.arpa PTR
AN: 2.74.222.38.in-addr.arpa PTR trusted.host.com
AN: trusted.host.com A 38.222.74.2
NS: 74.222.38.in-addr.arpa NS ns.sventech.com
NS: 74.222.38.in-addr.arpa NS ns1.sventech.com
AD: ns.sventech.com A 38.222.74.2
AD: ns1.sventech.com A 38.222.74.10
当98.76.54.32的DNS服务器收到这个应答后,会把结果转发给123.45.67.98,就是那台有rlogin服务的unix主机(也是我们的目标 ),并且98.76.54.32这台DNS服务器会把这次的查询结果缓存起来.
这时unix主机就认为IP地址为38.222.74.2的主机名为trusted.host.com,然后unix主机查询本地的/etc/hosts.equiv文件,看这台主机是否被允许使用rlogin服务,很显然,我们的欺骗达到了.
在unix的环境中,有另外一种技术来防止这种欺骗的发生,就是查询PTR记录后,也查询PTR返回的主机名的A记录,然后比较两个IP地址是否相同:
123.45.67.89 -> 98.76.54.32 [Query]
NQY: 1 NAN: 0 NNS: 0 NAD: 0
QY: trusted.host.com A
很不幸,在98.76.54.32的DNS服务器不会去查询这个记录,而会直接返回在查询2.74.222.38.in-addr.arpa时得到的并且存在缓存中的信息:
98.76.54.32 -> 123.45.67.89 [Query]
NQY: 1 NAN: 1 NNS: 2 NAD: 2
QY: trusted.host.com A
AN: trusted.host.com A 38.222.74.2
NS: 74.222.38.in-addr.arpa NS ns.sventech.com
NS: 74.222.38.in-addr.arpa NS ns1.sventech.com
AD: ns.sventech.com A 38.222.74.2
AD: ns1.sventech.com A 38.222.74.10
那么现在unix主机就认为38.222.74.2就是真正的trusted.host.com了,我们的目的达到了!
这种IP欺骗的条件是:你必须有一台Internet上的授权的DNS服务器,并且你能控制这台服务器,至少要能修改这台服务器的DNS记录,我们的欺 能进行.
2>.拒绝服务攻击 Denial of service
还是上面的例子,如果我们更改位于38.222.74.2的记录,然后对位于98.76.54.32的DNS服务器发出2.74.222.38.in-addr.arpa的查询,并使得查询结果如下:
因为74.222.38.in-addr.arpa完全由我们控制,所以我们能很方便的修改这些信息来实现我们的目的.
38.222.74.2 -> 98.76.54.32 [Answer]
NQY: 1 NAN: 2 NNS: 2 NAD: 2
QY: 2.74.222.38.in-addr.arpa PTR
AN: 2.74.222.38.in-addr.arpa PTR trusted.host.com
AN: www.company.com A 0.0.0.1
NS: 74.222.38.in-addr.arpa NS ns.sventech.com
NS: 74.222.38.in-addr.arpa NS ns1.sventech.com
AD: ns.sventech.com A 38.222.74.2
AD: ns1.sventech.com A 38.222.74.10
这样一来,使用98.76.54.32这台DNS服务器的用户就不能访问www.company.com了,因为这个IP根本就不存在!
3>.偷取服务 Theft of services
还是上面的例子,只是更改的查询结果如下:
38.222.74.2 -> 98.76.54.32 [Answer]
NQY: 1 NAN: 3 NNS: 2 NAD: 2
QY: 2.74.222.38.in-addr.arpa PTR
AN: 2.74.222.38.in-addr.arpa PTR trusted.host.com
AN: www.company.com CNAME www.competitor.com
AN: company.com MX 0 mail.competitor.com
NS: 74.222.38.in-addr.arpa NS ns.sventech.com
NS: 74.222.38.in-addr.arpa NS ns1.sventech.com
AD: ns.sventech.com A 38.222.74.2
AD: ns1.sventech.com A 38.222.74.10
这样一来,一个本想访问www.competitor.com的用户会被带到另外一个地方,甚至是敌对的公司的竹叶(想想把华为和北电联起来是什么样的感觉. ).并且发给company.com的邮件会被发送给mail.compertitor.com.(越来越觉得在网络上的日子不踏实! xxbin这样想).
4>.限制
对这些攻击,也有一定的限制.
首先,攻击者不能替换缓存中已经存在的记录.比如说,如果在98.76.54.32这个DNS服务器上已经有一条www.company.com的CNAME记录,那么攻击者试图替换为www.competitor.com将不会成功.然而,一些记录可以累加,比如A记录,如果在DNS的缓存中已经存在一条www.company.com的A记录为1.2.3.4,而攻击者却欺骗DNS服务器说www.company.com的A记录为4.3.2.1,那么www.company.com将会有两个A记录,客户端查询时会随机返回其中一个.(呵呵,这不是loading balance么?)
其次,DNS服务器有个缓存刷新时间问题,如果www.netbuddy.org的TTL为7200,那么DNS服务器仅仅会把www.netbuddy.org的信息缓存7200秒或者说两个小时.如果攻击者放入一条TLL为604800的A记录,那么这条记录将会在缓存中保存一周时间,过了默认的两天后,这个DNS服务器就会到处“分发”攻击者假造的记录.
下面是常用的几种可以累加和不能累加的记录:
A can add
NS can add
MX can add
PTR cannot add
篇4：如何清除DNS缓存 怎么命令清除dns缓存
遇到电脑不能上网，或者某些网站不能打开，但是另外一些网站却能打开，通常这样的情况是DNS缓存的导致的。
那么遇到类似问题，我们最好清除DNS缓存。
具体步骤：
通过“开始->运行->输入CMD”进入命令行模式。 (注意是命令行模式哦）
第二步：在命令行模式中我们可以看到在ipconfig /?中有一个名为/flushdns的参数，这个就是清除DNS缓存信息的命令。 第三步：执行ipconfig /flushdns命令，当出现“successfully flushed the dns resolver cache”的提示时就说明当前计算机的缓存信息已经被成功清除，
第四步：接下来我们再访问域名时，就会到DNS服务器上获取最新解析地址，再也不会出现因为以前的缓存造成解析错误故障了。
当然对于win7电脑，可能会不太一样，（也可以使用windows+R键，也可以呼出下面的对话框）
1、我们点击左下角的开始，并输入cmd
2、输入cmd后就会弹出如下对话框，
3、这时候我们输入清空DNS缓存命令的：ipconfig/flushdns，我们输入完了命令之后，按下电脑键盘上的回车键（Enter）即可开始清空DNS缓存了， 如下图所示：
4、成功的完成了DNS缓存清理了。 最后也可以给大家一个本机的DNS缓存信息命令：ipconfig /displaydns
篇5：DNS欺骗攻击及防御
你是否遭遇过这样的情况?当你在浏览器中输入正确的URL地址，但是打开的并不是你想要去的网站，
DNS欺骗攻击及防御
，
它可能是114的查询页面，可能是一个广告页面，更可能是一个刷流量的页面，甚至是一个挂马的网站。如果你遇到了上述情况话，那么极有可能你遭遇了DNS欺骗，那么什
篇6：DNS欺骗攻击及其防护
域名系统(Domain Name System,DNS)是一个将Domain Name和IP Address进行互相映射的Distributed Database，DNS是网络应用的基础设施，它的安全性对于互联网的安全有着举足轻重的影响。但是由于DNS Protocol在自身设计方面存在缺陷，安全保护和认证机制不健全，造成DNS自身存在较多安全隐患，导致其很容易遭受攻击。很多专家就DNS Protocol的安全缺陷提出了很多技术解决方案。例如IETF提出的域名系统安全协议(Domain Name System Security,DNSSEC)，其目标就在于解决这些安全隐患。这个Protocol增加了安全认证项目，增强了Protocol自身的安全功能。但是新增加的安全机制需要占用更多的系统和网络资源，同时要升级Database和System Manggament Software,这些基于DNSSEC协议的软件还不成熟，距离普及应用还有较长时间。目前，常见的措施是定期升级DNS软件和加强相关的安全配置，禁用不安全的端口等。本文对以侦听为基础的DNS ID欺骗(DNS ID spoofing)进行了探讨，并提出了相关的防护解决方案。
一、DNS SERVER的服务工作过程
DNS是一种实现Domain Name和IP Address之间转换的系统，它的工作原理就是在两者间进行相互映射，相当于起到翻译作用，所以称为域名解析系统。DNS System分为Server和Client两部分，Server的通用Port是53。当Client向Server发出解析请求时，Local DNS Server第一步查询自身的Database是否存在需要的内容，如果有则发送应答数据包并给出相应的结果;否则它将向上一层DNS Server查询。如此不断查询，最终直至找到相应的结果或者将查询失败的信息反馈给客户机。如果Local DNS Server查到信息,则先将其保存在本机的高速缓存中，然后再向客户发出应答。日常我们上网是通过Browser方式来申请从Domain Name到IP Address的解析，即Client向DNS Server提交域名翻译申请，希望得到对应的IP Address。这里以笔者所在院校为例,说明DNS的工作原理。
例如Client的Address为10.252.2.16，学校DNS Server为218.30.19.40，从此客户机来访问西安财经学院网站。在地址栏键入学校网站的www.xaufe.edu.cn，通过DNS Server查找其对应的IP Address。这个申请从10.252.2.16的一个随机PORT发送出去，由218.30.19.40的53绑定端口接收到此申请并进行翻译，首先在218.30.19.40的高速缓存中查找www.xaufe.edu.cn的IP Address，若存在对应的映射关系,就直接将IP Address发送给客户机，若缓存中没有，则218.30.19.40会向上层DNS SERVER查询，最后将查询到的结果先发送到218.30.19.40，最后由218.30.19.40将西安财经学院的IP Address(281.195.32.1)返回给Client 10.252.2.16。这样10.252.2.16就可以和西安财经学院站点建立连接并访问了。
二、DNS欺骗攻击原理
2.1 欺骗原理
Client的DNS查询请求和DNS Server的应答数据包是依靠DNS报文的ID标识来相互对应的。在进行域名解析时，Client首先用特定的ID号向DNS Server发送域名解析数据包，这个ID是随机产生的。DNS Server找到结果后使用此ID给Client发送应答数据包。Client接收到应答包后，将接收到的ID与请求包的ID对比，如果相同则说明接收到的数据包是自己所需要的，如果不同就丢弃此应答包。根据攻击者的查询和应答原理，可使用不同方法实现攻击，如：
(1)因为DNS Message仅使用一个简单的认证码来实施真实性验证，认证码是由Client程序产生并由DNS Server返回结果的，客户机只是使用这个认证码来辨别应答与申请查询是否匹配，这就使得针对ID认证码的攻击威胁成为可能。
(2)在DNS Request Message中可以增加信息，这些信息可以与客户机所申请查询的内容没有必然联系，因此攻击者就能在Request Message中根据自己的目的增加某些虚假的信息，比如增加其它Domain Server的Domain Name及其IP Address。此时Client在受到攻击的Domain Server上的查询申请均被转向此前攻击者在Request Message中增加的虚假Domain Server，由此DNS欺骗得以产生并对网络构成威胁。
(3)当DNS Server接收到Domain Name和IP Address相互映射的数据时，就将其保存在本地的Cache中，
若再有Client请求查询此Domain Name对应的IP Address，Domain Server就会从Cache中将映射信息回复给Client，而无需在Database中再次查询。如果 将DNS Request Message的存在周期设定较长时间，就可进行长期欺骗。
2.2 DNS欺骗攻击的方式
DNS欺骗技术常见的有内应攻击和序列号攻击两种。内应攻击即 在掌控一台DNS Server后,对其Domain Database内容进行更改，将虚假IP Address指定给特定的Domain Name，当Client请求查询这个特定域名的IP时，将得到伪造的IP。
序列号攻击是指伪装的DNS Server在真实的DNS Server之前向客户端发送应答数据报文，该报文中含有的序列号ID与客户端向真实的DNS Server发出请求数据包中含有的ID相同，因此客户端会接收该虚假报文，而丢弃晚到的真实报文，这样DNS ID序列号欺骗成功。客户机得到的虚假报文中提供的域名的IP是攻击者设定的IP，这个IP将把客户带到攻击者指定的站点。
2.3 DNS 序列号欺骗攻击原理
DNS 序列号(ID)欺骗以侦测ID和Port为基础。在Switch构建的网络中，攻击方首先向目标实施ARP欺骗。当Client、攻击者和DNS Server同在一个网络时，攻击流程如下：①攻击方向目标反复发送伪造的ARP Request Message，修改目标机的ARP 缓存内容，同时依靠IP续传使Data经过攻击方再流向目的地;攻击方用Sniffer软件侦测DNS请求包，获取ID序列号和Potr;②攻击方一旦获得ID和Potr，即刻向客户机发送虚假的DNS Request Message，Client接收后验证ID和Potr正确，认为接收了合法的DNS应答;而Client得到的IP可能被转向攻击方诱导的非法站点，从而使Client信息安全受到威胁;③Client再接收DNS Server的Request Message，因落后于虚假的DNS响应，故被Client丢弃。当Client访问攻击者指向的虚假IP时，一次DNS ID欺骗随即完成
三、DNS欺骗检测和防范思路
3.1 检测思路
发生DNS欺骗时，Client最少会接收到两个以上的应答数据报文，报文中都含有相同的ID序列号，一个是合法的，另一个是伪装的。据此特点，有以下两种检测办法：
(1)被动监听检测。即监听、检测所有DNS的请求和应答报文。通常DNS Server对一个请求查询仅仅发送一个应答数据报文(即使一个域名和多个IP有映射关系，此时多个关系在一个报文中回答)。因此在限定的时间段内一个请求如果会收到两个或以上的响应数据报文，则被怀疑遭受了DNS欺骗。
(2)主动试探检测。即主动发送验证包去检查是否有DNS欺骗存在。通常发送验证数据包接收不到应答，然而 为了在合法应答包抵达客户机之前就将欺骗信息发送给客户，所以不会对DNS Server的IP合法性校验，继续实施欺骗。若收到应答包，则说明受到了欺骗攻击。
3.2 防范思路
在侦测到网络中可能有DNS欺骗攻击后，防范措施有：①在客户端直接使用IP Address访问重要的站点，从而避免DNS欺骗; ②对DNS Server和Client的数据流进行加密，Server端可以使用SSH加密协议，Client端使用PGP软件实施数据加密。
对于常见的ID序列号欺骗攻击，采用专业软件在网络中进行监听检查，在较短时间内，客户端如果接收到两个以上的应答数据包，则说明可能存在DNS欺骗攻击，将后到的合法包发送到DNS Server并对DNS数据进行修改，这样下次查询申请时就会得到正确结果
四、DNS防护方案
4.1 进行IP地址和MAC地址的绑定
(1)预防ARP欺骗攻击。因为DNS攻击的欺骗行为要以ARP欺骗作为开端，所以如果能有效防范或避免ARP欺骗，也就使得DNS ID欺骗攻击无从下手。例如可以通过将Gateway Router 的Ip Address和MAC Address静态绑定在一起，就可以防范ARP攻击欺骗。
(2)DNS信息绑定。DNS欺骗攻击是利用变更或者伪装成DNS Server的IP Address，因此也可以使用MAC Address和IP Address静态绑定来防御DNS欺骗的发生。由于每个Network Card的MAC Address具有唯一性质，所以可以把DNS Server的MAC Address与其IP Address绑定，然后此绑定信息存储在客户机网卡的Eprom中。当客户机每次向DNS Server发出查询申请后，就会检测DNS Server响应的应答数据包中的MAC Address是否与Eprom存储器中的MAC Address相同，要是不同，则很有可能该网络中的DNS Server受到DNS欺骗攻击。这种方法有一定的不足，因为如果局域网内部的客户主机也保存了DNS Server的MAC Address，仍然可以利用MAC Address进行伪装欺骗攻击。
篇7：DNS攻击原理与防范
随着网络的逐步普及，网络安全已成为INTERNET路上事实上的焦点，它关系着INTERNET的进一步发展和普及，甚至关系着INTERNET的生存，可喜的是我们那些互联网专家们并没有令广大INTERNET用户失望，网络安全技术也不断出现，使广大网民和企业有了更多的放心，下面就网络安全中的主要技术作一简介，希望能为网民和企业在网络安全方面提供一个网络安全方案参考。
DNS的工作原理
DNS分为Client和Server，Client扮演发问的角色，也就是问Server一个Domain Name，而Server必须要回答此Domain Name的真正IP地址。而当地的DNS先会查自己的资料库。如果自己的资料库没有，则会往该DNS上所设的的DNS询问，依此得到答案之后，将收到的答案存起来，并回答客户。
DNS服务器会根据不同的授权区(Zone)，记录所属该网域下的各名称资料，这个资料包括网域下的次网域名称及主机名称。
在每一个名称服务器中都有一个快取缓存区(Cache)，这个快取缓存区的主要目的是将该名称服务器所查询出来的名称及相对的IP地址记录在快取缓存区中，这样当下一次还有另外一个客户端到次服务器上去查询相同的名称 时，服务器就不用在到别台主机上去寻找，而直接可以从缓存区中找到该笔名称记录资料，传回给客户端，加速客户端对名称查询的速度。例如：
当DNS客户端向指定的DNS服务器查询网际网路上的某一台主机名称 DNS服务器会在该资料库中找寻用户所指定的名称 如果没有，该服务器会先在自己的快取缓存区中查询有无该笔纪录，如果找到该笔名称记录后，会从DNS服务器直接将所对应到的IP地址传回给客户端 ，如果名称服务器在资料记录查不到且快取缓存区中也没有时，服务器首先会才会向别的名称服务器查询所要的名称。例如：
DNS客户端向指定的DNS服务器查询网际网路上某台主机名称，当DNS服务器在该资料记录找不到用户所指定的名称时，会转向该服务器的快取缓存区找寻是否有该资料 ，当快取缓存区也找不到时，会向最接近的名称服务器去要求帮忙找寻该名称的IP地址 ，在另一台服务器上也有相同的动作的查询，当查询到后会回复原本要求查询的服务器，该DNS服务器在接收到另一台DNS服务器查询的结果后，先将所查询到的主机名称及对应IP地址记录到快取缓存区中 ，最后在将所查询到的结果回复给客户端
常见的DNS攻击包括：
1) 域名劫持
通过采用 手段控制了域名管理密码和域名管理邮箱，然后将该域名的NS纪录指向到 可以控制的DNS服务器，然后通过在该DNS服务器上添加相应域名纪录，从而使网民访问该域名时，进入了 所指向的内容。
这显然是DNS服务提供商的责任，用户束手无策。
2) 缓存投毒
利用控制DNS缓存服务器，把原本准备访问某网站的用户在不知不觉中带到 指向的其他网站上。其实现方式有多种，比如可以通过利用网民ISP端的DNS缓存服务器的漏洞进行攻击或控制，从而改变该ISP内的用户访问域名的响应结果;或者， 通过利用用户权威域名服务器上的漏洞，如当用户权威域名服务器同时可以被当作缓存服务器使用， 可以实现缓存投毒，将错误的域名纪录存入缓存中，从而使所有使用该缓存服务器的用户得到错误的DNS解析结果。
最近发现的DNS重大缺陷，就是这种方式的。只所以说是“重大”缺陷，据报道是因为是协议自身的设计实现问题造成的，几乎所有的DNS软件都存在这样的问题。
3)DDOS攻击
一种攻击针对DNS服务器软件本身，通常利用BIND软件程序中的漏洞，导致DNS服务器崩溃或拒绝服务;另一种攻击的目标不是DNS服务器，而是利用DNS服务器作为中间的“攻击放大器”，去攻击其它互联网上的主机，导致被攻击主机拒绝服务。
4) DNS欺骗
DNS欺骗就是攻击者冒充域名服务器的一种欺骗行为。
原理：如果可以冒充域名服务器，然后把查询的IP地址设为攻击者的IP地址，这样的话，用户上网就只能看到攻击者的主页，而不是用户想要取得的网站的主页了，这就是DNS欺骗的基本原理，
DNS欺骗其实并不是真的“黑掉”了对方的网站，而是冒名顶替、招摇撞骗罢了。
现在的Internet上存在的DNS服务器有绝大多数都是用bind来架设的,使用的bind版本主要为bind 4.9.5+P1以前版本和bind 8.2.2-P5以前版本.这些bind有个共同的特点,就是BIND会缓存(Cache)所有已经查询过的结果,这个问题就引起了下面的几个问题的存在.
DNS欺骗
在DNS的缓存还没有过期之前,如果在DNS的缓存中已经存在的记录,一旦有客户查询,DNS服务器将会直接返回缓存中的记录
防止DNS被攻击的若干防范性措施
互联网上的DNS放大攻击(DNS amplification attacks)急剧增长。这种攻击是一种数据包的大量变体能够产生针对一个目标的大量的虚假的通讯。这种虚假通讯的数量有多大?每秒钟达数GB，足以阻止任何人进入互联网。
与老式的“smurf attacks”攻击非常相似，DNS放大攻击使用针对无辜的第三方的欺骗性的数据包来放大通讯量，其目的是耗尽受害者的全部带宽。但是，“smurf attacks”攻击是向一个网络广播地址发送数据包以达到放大通讯的目的。DNS放大攻击不包括广播地址。相反，这种攻击向互联网上的一系列无辜的第三方DNS服务器发送小的和欺骗性的询问信息。这些DNS服务器随后将向表面上是提出查询的那台服务器发回大量的回复，导致通讯量的放大并且最终把攻击目标淹没。因为DNS是以无状态的UDP数据包为基础的，采取这种欺骗方式是司空见惯的。
这种攻击主要依靠对DNS实施60个字节左右的查询，回复最多可达512个字节，从而使通讯量放大8.5倍。这对于攻击者来说是不错的，但是，仍没有达到攻击者希望得到了淹没的水平。最近，攻击者采用了一些更新的技术把目前的DNS放大攻击提高了好几倍。
当前许多DNS服务器支持EDNS。EDNS是DNS的一套扩大机制，RFC 2671对次有介绍。一些选择能够让DNS回复超过512字节并且仍然使用UDP，如果要求者指出它能够处理这样大的DNS查询的话。攻击者已经利用这种方法产生了大量的通讯。通过发送一个60个字节的查询来获取一个大约4000个字节的记录，攻击者能够把通讯量放大66倍。一些这种性质的攻击已经产生了每秒钟许多GB的通讯量，对于某些目标的攻击甚至超过了每秒钟10GB的通讯量。
要实现这种攻击，攻击者首先要找到几台代表互联网上的某个人实施循环查询工作的第三方DNS服务器(大多数DNS服务器都有这种设置)。由于支持循环查询，攻击者可以向一台DNS服务器发送一个查询，这台DNS服务器随后把这个查询(以循环的方式)发送给攻击者选择的一台DNS服务器。接下来，攻击者向这些服务器发送一个DNS记录查询，这个记录是攻击者在自己的DNS服务器上控制的。由于这些服务器被设置为循环查询，这些第三方服务器就向攻击者发回这些请求。攻击者在DNS服务器上存储了一个4000个字节的文本用于进行这种DNS放大攻击。
现在，由于攻击者已经向第三方DNS服务器的缓存中加入了大量的记录，攻击者接下来向这些服务器发送DNS查询信息(带有启用大量回复的EDNS选项)，并采取欺骗手段让那些DNS服务器认为这个查询信息是从攻击者希望攻击的那个IP地址发出来的。这些第三方DNS服务器于是就用这个4000个字节的文本记录进行回复，用大量的UDP数据包淹没受害者。攻击者向第三方DNS服务器发出数百万小的和欺骗性的查询信息，这些DNS服务器将用大量的DNS回复数据包淹没那个受害者。
如何防御这种大规模攻击呢?首先，保证你拥有足够的带宽承受小规模的洪水般的攻击。一个单一的T1线路对于重要的互联网连接是不够的，因为任何恶意的脚本少年都可以消耗掉你的带宽。如果你的连接不是执行重要任务的，一条T1线路就够了。否则，你就需要更多的带宽以便承受小规模的洪水般的攻击。不过，几乎任何人都无法承受每秒钟数GB的DNS放大攻击。
因此，你要保证手边有能够与你的ISP随时取得联系的应急电话号码。这样，一旦发生这种攻击，你可以马上与ISP联系，让他们在上游过滤掉这种攻击。要识别这种攻击，你要查看包含DNS回复的大量通讯(源UDP端口53)，特别是要查看那些拥有大量DNS记录的端口。一些ISP已经在其整个网络上部署了传感器以便检测各种类型的早期大量通讯。这样，你的ISP很可能在你发现这种攻击之前就发现和避免了这种攻击。你要问一下你的ISP是否拥有这个能力。
篇8：检查DNS缓存中毒的办法
*DNS服务器端检测方法： 本文主要探讨的是BIND服务器，以下实验针对的对象为Solaris10上安装的BIND9服务（Version: 9.2.4），
检查DNS缓存中毒的办法
，
BIND服务器端检测方式有两种：通过query来辨认异常或是通过查看CACHE的记录来辨认异常。 1）通过query来辨认异常 本功能需要开启B
篇9：无法清除DNS缓存的解决办法
，
最后，我们再去看看是否可以正常上网了，如果不可以，可以再次右键点击“本地连接”，选择“修复”，就不会出现“清除dns缓存”的提示了，这个时候一般就可以上网了，如果依旧不行，可能是网络问题。
篇10：如何刷新 OS X 的 DNS 缓存?
此方法在 Lion 和 Mountain Lion 有效，只需打开”终端”，输入以下命令即可：
sudo killall -HUP mDNSResponder
篇11：检查DNS缓存中毒的方法
彼岸、花未_
*DNS服务器端检测方法：
本文主要探讨的是BIND服务器，以下实验针对的对象为Solaris10上安装的BIND9服务（Version: 9.2.4），
BIND服务器端检测方式有两种：通过query来辨认异常或是通过查看CACHE的记录来辨认异常。
1）通过query来辨认异常
本功能需要开启BIND的日志审计功能，首先通过rndc命令确认是否已开启日志审计功能：
-bash-3.00# rndc status
number of zones: 6
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF <--这里的OFF代表目前还没开启query日志审计功能
server is up and running
下一步是开启query记录：
-bash-3.00# rndc querylog <--此命令为query记录的开关命令
再查看一下状态^_^
-bash-3.00# rndc status
number of zones: 6
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON <--这里的ON代表目前已开启query日志审计功能
server is up and running
来到这一步还需要编辑一下BIND的配置文件named.conf：
-bash-3.00# vi /etc/named.conf
加入以下审计配置内容块：
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
logging {
channel audit_log {
file “named.log” versions 3 size 20m;
severity info;
print-time yes;
print-category yes;
};
category default { audit_log; };
category general { audit_log; };
category security { audit_log; };
category config { audit_log; };
category resolver { audit_log; };
category xfer-in { audit_log; };
category xfer-out { audit_log; };
category notify { audit_log; };
category client { audit_log; };
category network { audit_log; };
category update { audit_log; };
category queries { audit_log; };
category lame-servers { audit_log; };
category database { audit_log; };
};
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
*注：其实只需要激活“category queries { audit_log; };”就可以了，不过为了保证日志内容的全面性，所以...
最后重新启动named：
-bash-3.00# /etc/init.d/named restart
现在我们就可以直接通过tail来查看日志了：
-bash-3.00# tail -f /var/named/named.log
其中可能包含很多类似以下的query记录：
Aug 06 02:27:29.364 queries: client 192.168.20.197#13939: query: demonalex.3322.org IN A
Aug 06 02:27:30.406 queries: client 192.168.20.197#13940: query: demonalex.3322.org IN A
Aug 06 02:27:30.994 queries: client 192.168.20.197#13941: query: demonalex.3322.org IN A
Aug 06 02:27:31.529 queries: client 192.168.20.197#13942: query: demonalex.3322.org IN A
Aug 06 02:27:32.043 queries: client 192.168.20.197#13943: query: demonalex.3322.org IN A
Aug 06 02:27:32.554 queries: client 192.168.20.197#13944: query: demonalex.3322.org IN A
Aug 06 02:27:33.034 queries: client 192.168.20.197#13945: query: demonalex.3322.org IN A
Aug 06 02:27:33.511 queries: client 192.168.20.197#13946: query: demonalex.3322.org IN A
Aug 06 02:27:33.972 queries: client 192.168.20.197#13947: query: demonalex.3322.org IN A
Aug 06 02:27:34.436 queries: client 192.168.20.197#13948: query: demonalex.3322.org IN A
若发现大量‘查询内容相同，且源端口连贯（“#”号后为源端口）’的记录，则可能是DNS缓存中毒的先兆，
但此时
不宜太早下定论，再看看下一种检查方法吧:)
2）通过查看CACHE的记录辨认异常
BIND本身不提供直接查看CACHE的功能，但我们可以通过rndc命令把CACHE给DUMP下来。当怀疑BIND服务端存在DNS缓存
中毒时，可以通过以下方式进行检查：
-bash-3.00# rndc dumpdb
-bash-3.00# cat /var/named/named_dump.db
在named_dump.db这个文本文件里包含目前BIND所‘知道’的DNS记录，不过我们主要关注的是客户端查询的记录，如：
=========================================================================
; authanswer
demonalex.3322.org. 54 A 219.137.123.41
=========================================================================
我们可以通过nslookup等命令切换到其它DNS服务器中，对以上相关记录进行查询，确认该BIND是否已被缓存中毒攻击
了。
*DNS客户端检测方法：
客户端检测方法具体需要视操作系统类型而定。若是WINDOWS系统，可以把网卡中的DNS服务器设置为‘怀疑被缓存中
毒攻击’的DNS服务器，然后通过ipconfig检查当前主机的DNS缓存：
ipconfig /displaydns
，或是通过nslookup等命令进行实时检查；若是UNIX/LINUX系统，在默认没有安装nscd服务的情况下是不会具备DNS缓
存功能的，因此只能通过nslookup等命令进行实时检查了。
*参考资料：
candon123所写的《rhel5中配置DNS服务器的日志》，原URL：
candon123.blog.51cto.com/704299/141616
邹福泰所写的《DNS的缓存中毒(cache poison)问题分析及建议》，原URL：
html“>hi.baidu.com/zoufutai/blog/item/1b380ffb56ee9f156d22eb0b.html
yfhe所写的《BIND9详解之日志篇》，原URL：
www.chinaunix.net/jh/16/212998.html
篇12：Wordpress缓存插件介绍
Wordpress是最受欢迎的独立博客系统，这点是毋容置疑的。但当一个博客数据请求量高于空间的限制时，你就需要一个缓存插件来减少对数据库的查询。
不使用缓存插件但流量有很大会有什么后果？你可以尝试看看王小峰的博客，直到我写这篇文章的时刻（2月26日，20:57），他的博客还是无法访问。
造成这个后果的原因可能是多方面的，但有2个可能是致命伤：
1、使用IIS+PHP，而不是更适合wordpress的LAMP（Linux+Apache+Mysql+PHP）主机。
2、他没有使用缓存插件
假设他用了缓存插件，可能就不会有这种事发生。
篇13：Wordpress缓存插件介绍
目前我使用过的缓存插件有3个，Super Cache，Hyper Cache，Cos-html-cache。最终我选择了Cos-html-cache.
1、Cos-html-cache
这是首推的缓存插件，由江东开发。根据目前的观察，这个插件能极其有效地节省数据库查询量，做到完完全全的静态化。
然而，有得必失，你的文章URL必须伪静态为html或htm结尾，因为cos-html-cache确实生成了静态html文件。
具体使用方法：
（1）下载cos-html-cache插件，上传到plugins目录。
（2）在根目录下建立index.bak文件夹，权限为0666.
（3）在Wordpress的设置后台里将永久链接改成“/post/%postname%.html”或”/article/%post_id%.html“或其它。
其中”post“和”article“是自定义的，因为静态化的文件必须存放到一个目录。末尾的.html或.htm是必须的。
（4）启用cos-html-cache插件。
优势：
（1）所有文章和首页都被绝对静态化了，只有当文章被修改（文章内容修改、删除、留言）缓存才被重新生成，很大程度上减少了数据库的负担。
（2）支持Cookie验证（WP不是默认支持么？后面你会知道为什么我特意提到这一点）
劣势：
（1）博客文章永久链接必须是伪静态的。如果你博客之前的URL不是以.html或.htm结尾的，除非你用重定向，否则你将无法使用cos-html-cache。对于一个已经有比较长历史的博客，改动URL不是一件容易的事。
（2）不即时刷新。出发缓存重新建立的动作只是文章修改或主题变动，插件的动作不会导致缓存被重新生成。
但你真的需要那么多花哨的插件吗？
2、Super Cache
我之前使用的就是super cache，直到下午负荷过重，
管理资料
要使用这个插件，需要修改wp-config.php和.htaccess文件。具体可以参考官方说明。
优势：
（1）无需修改博客永久链接。
（2）支持Cookie验证
（3）支持Gzip（即便Wordpress在wp2.5就取消了gzip选项）
劣势：
（1）依然需要查询数据库。相对cos-html-cache来说，super cache依旧需要对数据库进行查询。
update：这个结论可能是错误的。
（2）Gzip有时出错
3、Hyper Cache
这是我使用了2小时然后放弃的一个缓存插件。根据北极冰仔的介绍，它的思想和Cos-html-cache是一样的，但是考虑到永久链接的问题，它并没有完全绕过wordpress实现静态化。
相比之下，我认为它比Super Cache更为优秀，安装要求没有Super cache那么苛刻，而且对Gzip的支持似乎更好一些。
如果你不想将永久链接更改为.html结尾，可以考虑Hyper Cache。
但是，Hyper Cache有个不好的地方，将在第三点讨论。
篇14：Wordpress缓存插件介绍
所谓的常见问题，其实是我遇到的两个可能比较普遍的问题而已。
1、Cos-html-cache记录的昵称空格变加号
使用chc的朋友可能会发现，第二次留言时，昵称里的空格会变成“+”号，如图所示：
在twitter上请教了cosbeta，得到了解决方案，将“+”替换为“ ”。具体方法如下：
打开插件文件夹里的common.js.php，将第33行替换为：
setovalue(”author“,readCosBetaCookie(author_cookie).replace(”+“,” " ) );
2、Hyper Cache无法实现cookie验证
之前我在阿禅日记试用了Hyper Cache，发现访客的cookie不会被记录，每次留言都要重新输入昵称等相关信息。这是缓存造成的。
解决方法是用js来实现cookie的验证，具体方法请移步WordPress 完全静态化后的 cookie 验证。
篇15：Wordpress缓存插件介绍
这次博客被挂起到使用3款缓存插件的经过，我得到了下面的结论：
1、博客被挂起不一定因为和谐，但因为和谐博客必定会被挂起
2、Wordpress一定要使用缓存插件
3、缓存插件首选cos-html-cache，然后是Hyper Cache
4、Google Analytics的数据统计可能非常不可靠（不展开讨论）
5、如果有一天你发现可能吧打死也不能访问，请留意我在twitter上的消息，我的twitter:jason5ng32.
