首先我们简单了解一下互联网上顶级域名（如 .com）的 DNS 工作方式：
对于每一台客户端而言，我们都知道网卡上需要设置“DNS 服务器（DNS Server）”，这个 “DNS 服务器”通常是指定 ISP（Internet Service Provider，因特网服务提供商）的 DNS 服务器。ISP 的 DNS 服务器上肯定不会有全球所有域名的DNS条目，当它接收到客户端的查询不在它的本地缓存中，无法作解析时，它会向它的 “权威 DNS 服务器（Authoritative Name Server）” 查询。通过这种由下向上的递归式查询，全球所有的请求最终将由13台 “根 DNS 服务器（Root Name Server）” 作出解答。
这13台根服务器由 VeriSign、ICANN（Internet Corporation for Assigned Names and Numbers）等组织维护。它们授权给全球各国的域名服务提供商，让他们出售域名。任何单位或个人网站运营者向域名服务商购买域名之后，会得到一个账号，通过这个账号就有权修改 DNS 服务器中的自己域名的条目，指定其解析到特定的 IP 地址。
通过以上的描述，我们不难发现，只要能够想办法篡改 DNS 服务器中的资料或是冒充 DNS 服务器，都会导致网站域名被导向到错误的IP。而这两种状况正好对应了两类 DNS 的攻击方式：DNS 篡改和 DNS 欺骗。
下面我们就谈谈这两种方式，
请注意:
1. 我们只针对发生在网络和DNS服务器端的篡改和欺骗进行介绍，至于客户端DNS错误解析（如被恶意软件感染）等攻击性问题，不再进行说明；
2. 欺骗(Spoofing)、重定向(Redirection)、劫持(Hijacking)等术语少数情况下会被用来表达同一含义，在这里我们按照被攻击对象、位置和特点进行区分描述；
一、DNS 篡改（DNS Hijacking or DNS Redirection）
DNS 篡改通常是指直接修改根服务器中的 DNS 条目，当然这种篡改更有可能发生在域名注册商的存放客户注册配置信息的服务器中, 从而导致相应的域名在全球范围内都解析错误。（有些情况下，也有可能只是在中层的 DNS 服务器作篡改，这样仅仅劫持某部份的域名解析，只会影响部分地区 。）
这种攻击方式的特点如下：
全球性。因为根服务器条目被更改，在下游 DNS 缓存时间过后，被篡改条目必然会更新到所有下游服务器，从而影响到所有用户。
通常所说的“技术性”并非必需。在多数情况下，这种攻击方式在DNS攻击阶段甚至不需要涉及技术性，可以借助社会工程学等手段，攻击者通常已经拥有了足够的修改DNS条目的权限。虽然不排除黑客能够通过技术手段入侵根DNS服务器或者域名服务商，在这种情况下，黑客就可以指哪儿打哪儿无法无天了。但相信这种天下大乱的情况我们不一定能有幸见到。更可能的情况是，某个网站运营商的域名的账号密码被窃取了，黑客拿到账号密码之后，就能像网站管理员一样冠冕堂皇地登陆域名提供商网站，修改相应的IP地址。
二、DNS 欺骗 （DNS Spoofing）
一种 DNS 欺骗方式是利用漏洞，去年上半年，DNS 协议被发现存在严重漏洞，攻击者可以欺骗下游服务器，使其相信一台假冒的服务器是它的权威服务器。这样攻击者就可以通过在假冒服务器上添加虚假的 DNS 信息来欺骗下游服务器，最终欺骗客户端。在 Windows 系统中，这个漏洞已经在稍早的安全布丁发布获得中解决：http://www.microsoft.com/china/technet/security/bulletin/ms08-037.mspx
其他操作系统中也可以查询到相应的漏洞。还有一种 DNS欺骗思路，借助其他欺骗达到DNS欺骗的目的，例如先在目标客户端或DNS服务器的同一局域网网段作ARP欺骗，使受攻击的计算机向ARP攻击的发起者作DNS查询。但是这种攻击方式必须先攻破与目标主机同网段的另一台计算机，而互联网中的DNS服务器通常在ISP的控制之下，渗透进ISP网络的难度不小。攻击根服务器的难度就更别提了。
DNS 欺骗攻击方式的特点如下：
区域性。因为这种攻击只能攻击下游服务器，因此攻击的有效范围必然有限，只会影响到此台服务器下层的服务器和客户端。
漏洞利用。要实现 MS08-037 攻击必然需要利用 DNS 协议的漏洞（MS08-037 或者其他可能存在的漏洞）。如果 DNS 服务器上的漏洞已经修复，那么这种攻击就无法成功。
技巧性。不论利用漏洞还是利用 ARP 的设计缺陷，这类攻击方式在 DNS 攻击阶段都需要一定的技术手段。
希望以上对 DNS 攻击的简单介绍能够让大家了解个大概。
发表于 @ 2010年01月13日　11:42:00
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/MSSecurity/archive/2010/01/13/5184857.aspx