乐趣区

关于安全:DNS的解析查询调度原理是什么什么是DNS劫持污染如何监控

jiezi

DNS 的外围工作就是将域名翻译成计算机 IP 地址, 它是基于 UDP 协定实现的，本文将具体论述 DNS 相干的概念，解析，调度原理（负载平衡和区域调度）等 DNS 相干的所有知识点。@pdai

  • 网络协议 – DNS 相干详解

    • DNS 简介

      • 域名层级构造
      • 域名服务器

    • DNS 解析流程

      • 为什么 DNS 通常基于 UDP

    • DNS 查问

      • dig 查问
      • host 查问
      • nslookup 查问
      • whois 查问
      • 在线工具查问

    • DNS 调度原理

      • 地理位置调度不精确
      • 规定变更失效工夫不确定
      • 高可用

    • DNS 平安相干

      • 什么是 DNS 劫持
      • 什么是 DNS 净化
      • 为什么要 DNS 流量监控

      • DNS 流量监控

        • 防火墙
        • 入侵检测零碎
        • 流量剖析工具
        • DNS 被动复制
        • 解析器日志记录
      • DNS 服务器监控
    • 参考文章

DNS 简介

域名零碎并不像电话号码通讯录那么简略，通讯录次要是单个个体在应用，同一个名字呈现在不同个体的通讯录里并不会呈现问题，但域名是群体中所有人都在用的，必须要放弃唯一性。为了达到唯一性的目标，因特网在命名的时候采纳了层次结构的命名办法。每一个域名（本文只探讨英文域名）都是一个标号序列（labels），用字母（A-Z，a-z，大小写等价）、数字（0-9）和连接符（-）组成，标号序列总长度不能超过 255 个字符，它由点号宰割成一个个的标号（label），每个标号应该在 63 个字符之内，每个标号都能够看成一个档次的域名。级别最低的域名写在右边，级别最高的域名写在左边。域名服务次要是基于 UDP 实现的，服务器的端口号为 53。

域名层级构造

留神：最开始的域名最初都是带了点号的，比方 www.kernel.org.，最初面的点号示意根域名服务器，起初发现所有的网址都要加上最初的点，就简化了写法，罗唆所有的都不加即www.kernel.org，然而你在网址前面加上点号也是能够失常解析的。

域名服务器

有域名构造还不行，还须要有一个货色去解析域名，手机通讯录是由通讯录软件解析的，域名须要由遍布全世界的域名服务器去解析，域名服务器实际上就是装有域名零碎的主机。由高向低进行档次划分，可分为以下几大类：

  • 根域名服务器：最高档次的域名服务器，也是最重要的域名服务器，本地域名服务器如果解析不了域名就会向根域名服务器求助。寰球共有 13 个不同 IP 地址的根域名服务器，它们的名称用一个英文字母命名，从 a 始终到 m。这些服务器由各种组织管制，并由 ICANN（互联网名称和数字地址调配公司）受权，因为每分钟都要解析的名称数量多得令人难以置信，所以实际上每个根服务器都有镜像服务器，每个根服务器与它的镜像服务器共享同一个 IP 地址，中国大陆地区内只有 6 组根服务器镜像（F，I（3 台），J，L）。当你对某个根服务器发出请求时，申请会被路由到该根服务器离你最近的镜像服务器。所有的根域名服务器都晓得所有的顶级域名服务器的域名和地址，如果向根服务器收回对“pdai.tech”的申请，则根服务器是不能在它的记录文件中找到与“pdai.tech”匹配的记录。然而它会找到 “tech” 的顶级域名记录，并把负责 “tech” 地址的顶级域名服务器的地址发回给请求者。
  • 顶级域名服务器：负责管理在该顶级域名服务器下注册的二级域名。当根域名服务器通知查问者顶级域名服务器地址时，查问者紧接着就会到顶级域名服务器进行查问。比方还是查问 ”pdai.tech”，根域名服务器曾经通知了查问者 ”tech” 顶级域名服务器的地址，”tech” 顶级域名服务器会找到“pdai.tech”的域名服务器的记录，域名服务器查看其区域文件，并发现它有与“pdai.tech”相关联的区域文件。在此文件的外部，有该主机的记录。此记录阐明此主机所在的 IP 地址，并向请求者返回最终答案。
  • 权限域名服务器：负责一个区的域名解析工作
  • 本地域名服务器：当一个主机收回 DNS 查问申请的时候，这个查问申请首先就是发给本地域名服务器的。

DNS 解析流程

网上找了个比拟好的例子

.com.fi 国际金融域名 DNS 解析的步骤一共分为 9 步，如果每次解析都要走完 9 个步骤，大家浏览网站的速度也不会那么快，当初之所以能放弃这么快的访问速度，其实个别的解析都是跑完第 4 步就能够了。除非一个地区齐全是第一次拜访（在都没有缓存的状况下）才会走完 9 个步骤，这个状况很少。

  • 1、本地客户机提出域名解析申请，查找本地 HOST 文件后将该申请发送给本地的域名服务器。
  • 2、将申请发送给本地的域名服务器。
  • 3、当本地的域名服务器收到申请后，就先查问本地的缓存。
  • 4、如果有该纪录项，则本地的域名服务器就间接把查问的后果返回浏览器。
  • 5、如果本地 DNS 缓存中没有该纪录，则本地域名服务器就间接把申请发给根域名服务器。
  • 6、而后根域名服务器再返回给本地域名服务器一个所查问域（根的子域）的主域名服务器的地址。
  • 7、本地服务器再向上一步返回的域名服务器发送申请，而后承受申请的服务器查问本人的缓存，如果没有该纪录，则返回相干的上级的域名服务器的地址。
  • 8、反复第 7 步，直到找到正确的纪录。
  • 9、本地域名服务器把返回的后果保留到缓存，以备下一次应用，同时还将后果返回给客户机。

注意事项：

递归查问：在该模式下 DNS 服务器接管到客户机申请，必须应用一个精确的查问后果回复客户机。如果 DNS 服务器本地没有存储查问 DNS 信息，那么该服务器会询问其余服务器，并将返回的查问后果提交给客户机。

迭代查问：DNS 所在服务器若没有能够响应的后果，会向客户机提供其余可能解析查问申请的 DNS 服务器地址，当客户机发送查问申请时，DNS 服务器并不间接回复查问后果，而是通知客户机另一台 DNS 服务器地址，客户机再向这台 DNS 服务器提交申请，顺次循环直到返回查问的后果为止。

为什么 DNS 通常基于 UDP

应用基于 UDP 的 DNS 协定只有一个申请、一个应答就好了

而应用基于 TCP 的 DNS 协定要三次握手、发送数据以及应答、四次挥手

显著基于 TCP 协定的 DNS 更节约网络资源！

当然以上只是从数据包的数量以及占有网络资源的层面来进行的剖析，那数据一致性层面呢？

DNS 数据包不是那种大数据包，所以应用 UDP 不须要思考分包，如果丢包那么就是全副丢包，如果收到了数据，那就是收到了全副数据！所以只须要思考丢包的状况，那就算是丢包了，从新申请一次就好了。而且 DNS 的报文容许填入序号字段，对于申请报文和其对应的应答报文，这个字段是雷同的，通过它能够辨别 DNS 应答是对应的哪个申请

DNS 通常是基于 UDP 的，但当数据长度大于 512 字节的时候，为了保障传输品质，就会应用基于 TCP 的实现形式

DNS 查问

dig 查问

用 dig 能够查看整个过程，看下上面的返回就能了解的

  • dig www.sina.com
pdaiMbp:/ pdai$ dig www.sina.com

; <<>> DiG 9.10.6 <<>> www.sina.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15304
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.sina.com.            IN    A

;; ANSWER SECTION:
www.sina.com.        32    IN    CNAME    us.sina.com.cn.
us.sina.com.cn.        32    IN    CNAME    spool.grid.sinaedge.com.
spool.grid.sinaedge.com. 32    IN    A    115.238.190.240

;; Query time: 20 msec
;; SERVER: 192.168.3.1#53(192.168.3.1)
;; WHEN: Fri Jan 31 14:53:39 CST 2020
;; MSG SIZE  rcvd: 108
  • dig +trace www.sina.com // 分级查问
pdaiMbp:/ pdai$ dig +trace www.sina.com

; <<>> DiG 9.10.6 <<>> +trace www.sina.com
;; global options: +cmd
.            52722    IN    NS    f.root-servers.net.
.            52722    IN    NS    k.root-servers.net.
.            52722    IN    NS    m.root-servers.net.
.            52722    IN    NS    l.root-servers.net.
.            52722    IN    NS    d.root-servers.net.
.            52722    IN    NS    i.root-servers.net.
.            52722    IN    NS    c.root-servers.net.
.            52722    IN    NS    e.root-servers.net.
.            52722    IN    NS    a.root-servers.net.
.            52722    IN    NS    g.root-servers.net.
.            52722    IN    NS    b.root-servers.net.
.            52722    IN    NS    h.root-servers.net.
.            52722    IN    NS    j.root-servers.net.
;; Received 228 bytes from 192.168.3.1#53(192.168.3.1) in 3 ms

com.            172800    IN    NS    a.gtld-servers.net.
com.            172800    IN    NS    b.gtld-servers.net.
com.            172800    IN    NS    c.gtld-servers.net.
com.            172800    IN    NS    d.gtld-servers.net.
com.            172800    IN    NS    e.gtld-servers.net.
com.            172800    IN    NS    f.gtld-servers.net.
com.            172800    IN    NS    g.gtld-servers.net.
com.            172800    IN    NS    h.gtld-servers.net.
com.            172800    IN    NS    i.gtld-servers.net.
com.            172800    IN    NS    j.gtld-servers.net.
com.            172800    IN    NS    k.gtld-servers.net.
com.            172800    IN    NS    l.gtld-servers.net.
com.            172800    IN    NS    m.gtld-servers.net.
com.            86400    IN    DS    30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com.            86400    IN    RRSIG    DS 8 1 86400 20200213050000 20200131040000 33853 . zMeZpKg/LGzpVjlBUJRfkmk8tSvZW+L0UFHnzSn8agztJ8sMGU+knBLW 5LLoPoh6iG7exLV5wVIJZVh+0ISk3AG85VJXZ3HSTWcHZfjMOYI7JXpe pv/5JqT9Eai0ScEJAowDa1qctGOE/LHdNwr30VF8U0LoZL0iXVN3KQ4k iKnl0S0hB41KH+BHFcNpWqxKHRK2piMZRNe8+8Nu9I4GilfW/D90e69p SgG7puU3J3srarhccj0OS5WcLi6nsMf/2k0C6rQMe+WD7aOVZXoLts93 /thoNSWIprseKrYze2STnuG+T/VxzZRJ3fjoZARGHtDf3gTibHC2syXL xaXz5w==
;; Received 1172 bytes from 198.97.190.53#53(h.root-servers.net) in 54 ms

sina.com.        172800    IN    NS    ns1.sina.com.cn.
sina.com.        172800    IN    NS    ns2.sina.com.cn.
sina.com.        172800    IN    NS    ns3.sina.com.cn.
sina.com.        172800    IN    NS    ns1.sina.com.
sina.com.        172800    IN    NS    ns2.sina.com.
sina.com.        172800    IN    NS    ns4.sina.com.
sina.com.        172800    IN    NS    ns3.sina.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A  NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20200207054811 20200131043811 56311 com. N15f7ia8A0pd2A5iWM/8t+T6gs8mQJaOWe/aj3bs4cWxpG7WmCaquZp7 6gfbfotFmss+DuBm9MAd6bwe2fm9m60FQgROWGOZwGRrvZqawy/5eDeV sLIJqhnwM0lT1PuDgNe2SFYsV506melwC4cEtR8M6gkX3nwYMCf6Frus anO+4Lufi229N5Y00N4x9vrlO3zsGBR1yg2xBki9Ni379A==
TGAG8VMC6NS5VVK68CIGRJ6Q414N2KB2.com. 86400 IN NSEC3 1 1 0 - TGAGRAEN3DVBS761O1PSQ1TU0407EVHO  NS DS RRSIG
TGAG8VMC6NS5VVK68CIGRJ6Q414N2KB2.com. 86400 IN RRSIG NSEC3 8 2 86400 20200206061700 20200130050700 56311 com. TMrk1/56Wa+isS5Y6OFQz9OZWMAAbt2TOEzaBp1Uuj9z1Eg4uio92+ff sWRB6vACYSBAJJLy4NPJfqxYpue39hvaDgFRYAZreDuCC0x+p9yi7yQ8 JaN2mS7W8Mbv0iEV0AUyzZGyhYq83DA58slNSGRhZfcvLYBAETURyH0X bJp+Hgq0bqXOqGyi/lAAv8/2mr+tiramb/pNst1MBBPaig==
;; Received 791 bytes from 192.48.79.30#53(j.gtld-servers.net) in 215 ms

www.sina.com.        60    IN    CNAME    us.sina.com.cn.
us.sina.com.cn.        60    IN    CNAME    spool.grid.sinaedge.com.
;; Received 103 bytes from 180.149.138.199#53(ns2.sina.com.cn) in 30 ms

域名与 IP 之间的对应关系，称为 ” 记录 ”（record）。依据应用场景，” 记录 ” 能够分成不同的类型（type），后面曾经看到了有 A 记录和 NS 记录。

常见的 DNS 记录类型如下。

  • A：地址记录（Address），返回域名指向的 IP 地址。
  • NS：域名服务器记录（Name Server），返回保留下一级域名信息的服务器地址。该记录只能设置为域名，不能设置为 IP 地址。
  • MX：邮件记录（Mail eXchange），返回接管电子邮件的服务器地址。
  • CNAME：标准名称记录（Canonical Name），返回另一个域名，即以后查问的域名是另一个域名的跳转，详见下文。
  • PTR：逆向查问记录（Pointer Record），只用于从 IP 地址查问域名，详见下文。

一般来说，为了服务的安全可靠，至多应该有两条 NS 记录，而 A 记录和 MX 记录也能够有多条，这样就提供了服务的冗余性，防止出现单点失败。

CNAME 记录次要用于域名的外部跳转，为服务器配置提供灵活性，用户感知不到。

host 查问

pdaiMbp:/ pdai$ host www.sina.com
www.sina.com is an alias for us.sina.com.cn.
us.sina.com.cn is an alias for spool.grid.sinaedge.com.
spool.grid.sinaedge.com has address 115.238.190.240
spool.grid.sinaedge.com has IPv6 address 240e:f7:a000:221::75:71

nslookup 查问

pdaiMbp:/ pdai$ nslookup
> www.sina.com
Server:        192.168.3.1
Address:    192.168.3.1#53

Non-authoritative answer:
www.sina.com    canonical name = us.sina.com.cn.
us.sina.com.cn    canonical name = spool.grid.sinaedge.com.
Name:    spool.grid.sinaedge.com
Address: 115.238.190.240

whois 查问

pdaiMbp:/ pdai$ whois www.sina.com
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object

refer:        whois.verisign-grs.com

domain:       COM

organisation: VeriSign Global Registry Services
address:      12061 Bluemont Way
address:      Reston Virginia 20190
address:      United States

contact:      administrative
name:         Registry Customer Service
organisation: VeriSign Global Registry Services
address:      12061 Bluemont Way
address:      Reston Virginia 20190
address:      United States
phone:        +1 703 925-6999
fax-no:       +1 703 948 3978
e-mail:       info@verisign-grs.com

contact:      technical
name:         Registry Customer Service
organisation: VeriSign Global Registry Services
address:      12061 Bluemont Way
address:      Reston Virginia 20190
address:      United States
phone:        +1 703 925-6999
fax-no:       +1 703 948 3978
e-mail:       info@verisign-grs.com

nserver:      A.GTLD-SERVERS.NET 192.5.6.30 2001:503:a83e:0:0:0:2:30
nserver:      B.GTLD-SERVERS.NET 192.33.14.30 2001:503:231d:0:0:0:2:30
nserver:      C.GTLD-SERVERS.NET 192.26.92.30 2001:503:83eb:0:0:0:0:30
nserver:      D.GTLD-SERVERS.NET 192.31.80.30 2001:500:856e:0:0:0:0:30
nserver:      E.GTLD-SERVERS.NET 192.12.94.30 2001:502:1ca1:0:0:0:0:30
nserver:      F.GTLD-SERVERS.NET 192.35.51.30 2001:503:d414:0:0:0:0:30
nserver:      G.GTLD-SERVERS.NET 192.42.93.30 2001:503:eea3:0:0:0:0:30
nserver:      H.GTLD-SERVERS.NET 192.54.112.30 2001:502:8cc:0:0:0:0:30
nserver:      I.GTLD-SERVERS.NET 192.43.172.30 2001:503:39c1:0:0:0:0:30
nserver:      J.GTLD-SERVERS.NET 192.48.79.30 2001:502:7094:0:0:0:0:30
nserver:      K.GTLD-SERVERS.NET 192.52.178.30 2001:503:d2d:0:0:0:0:30
nserver:      L.GTLD-SERVERS.NET 192.41.162.30 2001:500:d937:0:0:0:0:30
nserver:      M.GTLD-SERVERS.NET 192.55.83.30 2001:501:b1f9:0:0:0:0:30
ds-rdata:     30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CFC41A5766

whois:        whois.verisign-grs.com

status:       ACTIVE
remarks:      Registration information: http://www.verisigninc.com

created:      1985-01-01
changed:      2017-10-05
source:       IANA

No match for domain "WWW.SINA.COM".
>>> Last update of whois database: 2020-01-31T07:03:29Z <<<

在线工具查问

https://www.nslookuptool.com/chs/

DNS 调度原理

本节转自：【网易 MC】DNS 调度原理解析

当初，大部分利用和业务都采纳域名作为服务的入口，因而用 DNS 来负载平衡和区域调度是十分广泛的做法，网易云也有着一套基于 DNS 的调度零碎。某些用户在进行直播推流时用的并不是网易云的直播 SDK，而是一些第三方的推流软件，如 obs，这样就不能应用咱们的 GSLB 全局调度服务器来调度。对于这些用户，咱们应用 DNS 调度的形式，对不同地区的申请返回不同解析后果，将申请调度到离用户最近的服务器节点，从而缩小提早拜访。

咋一看，DNS 调度这么简略不便，那为什么不让所有的用户都走 DNS 调度呢？想晓得起因？来，咱们持续讲。

地理位置调度不精确

在 DNS 解析过程中，与权威服务器通信的只有 DNS 缓存服务器，所以权威服务器只能依据 DNS 缓存服务器的 IP 来进行调度。因而 DNS 调度有一个前提：假设用户应用的缓存 DNS 与用户自身在同个网络内，即至多在同一个 AS(自治域)内，在该前提下，DNS 的解析才是精确的。通常状况下，用户应用 ISP 提供的本地缓存(简称 local DNS)，local DNS 个别与用户在同个网络内，这时候 DNS 调度是无效的。

但近些年，不少互联网厂商推广基于 BGP Anycast 的公共 DNS (Public DNS)，而这些 Anycaset IP 的节点个别是远少于各个 ISP 的节点，例如可能广州电信用户应用了某公共 DNS，但该公共 DNS 里用户最近的是上海电信节点，甚至更极其的如 Google DNS 8.8.8.8，在中国大陆没有节点 (最近的是台湾)。而可怜的是国内有不少用户应用了 Google DNS，这其实升高了他们的网络拜访体验。总的来说， 应用公共 DNS，实际上毁坏了上文的前提，导致 DNS 区域调度生效，用户认为失去了更快更平安的 DNS 解析，但理论失去了谬误的解析，减少了网络拜访提早。

传统 DNS 协定的区域调度过程示例如下图，假设某业务以 foo.163.com 对外提供服务，在北京和东京各有一个节点，业务冀望国内大陆的用户拜访北京节点，而非大陆用户则拜访东京节点。因为权威是依据 DNS 缓存来决定返回的后果，所以当用户应用不必的 DNS 缓存时，可能会解析到不同的后果。

2011 年，Google 为首的几家公司在提出了一个 DNS 的扩大计划 edns-client-subnet (以下简称 ECS)，该扩大计划的核心思想是通过在 DNS 申请报文里退出原始申请的 IP(即 client 的 IP)，使得权威能依据该信息返回正确的后果。目前，该计划仍处于草案阶段。该计划很好地解决了上述提到的 remote DNS 导致解析不精确的问题，但也带了一些问题：

  • 至多须要 cache 和权威都反对，能力实现残缺的 ECS 解析
  • ECS 给 cache 减少了很大的缓存压力，因为实践上可能须要为每个 IP 段调配空间去缓存解析后果

规定变更失效工夫不确定

当缓存服务器向权威服务器查问失去记录之后，会将其缓存起来，在缓存有效期内，如果收到雷同记录的查问，缓存服务器会间接返回给客户端，而不须要再次向权威查问，当有效期过后，缓存则是须要再次发动查问。这个缓存有效期即是 TTL。

尽管 DNS 的缓存机制在大多数状况下缩短了客户端的记录解析工夫，但缓存也意味着失效同步的提早。当权威服务器的记录变更时，须要期待一段时间能力让所有客户端能解析到新的后果，因为很可能缓存服务器还缓存着旧的记录。

咱们将权威的记录变更到全网失效这个过程称为 propagation，它的工夫是不确定的，实践上的最大值即是 TTL 的值，对于记录变更或删除，这个工夫是记录本来的 TTL，对于记录新增则是域的 nTTL 值。

如果一个域名记录本来的 TTL 是 18000，能够认为，变更该记录实践上须要期待 5 个小时能力保障记录能失效到全网。假如该域名的业务方心愿缩短切换的工夫，正确的做法是，至多提前 5 个小时批改记录，仅改小 TTL，例如改为 5 分钟，期待该变更同步到全网之后，再进行批改指向的操作，确认无误再将 TTL 批改为本来的值。

尽管 DNS 协定规范里倡议缓存服务器应该记住或者缩短 TTL 的值，但实际上，有一些 DNS 缓存会批改权威服务器的 TTL，将其变大，这在国内几大运营商中是很常见的。例如，某域记录的 TTL 值实际上设置为 60，但在运营商的 DNS 缓存上，却变成 600 或者更大的值，甚至还有一些 DNS 缓存是不遵循 TTL 机制。这些都会影响域名的理论失效工夫。

高可用

为防止受 DNS 缓存的影响，须要保障 DNS 中 A 记录的 IP 节点高可用性。对此，网易云 DNS 调度零碎采纳的计划是在同一区域的多台直播服务器节点之间做负载平衡，对外只裸露一个虚 IP，这样，即便某台服务器宕机，负载平衡能迅速感知到，排除故障节点，而对 DNS 而言，因为虚 IP 不变而不受影响。

DNS 平安相干

本章节局部内容参考自：OneAPM blog

犯罪分子会抓住任何互联网服务或协定的破绽动员攻打，这当然也包含域名零碎（DNS）。他们会注册一次性域名用于垃圾邮件流动和僵尸网络管理，还会盗用域名进行钓鱼和恶意软件下载。他们会注入歹意查问代码以利用域名服务器的破绽或扰乱域名解析过程。他们会注入伪造的响应净化解析器缓存或强化 DDOS 攻打。他们甚至将 DNS 用作数据渗漏或恶意软件更新的荫蔽通道。

你可能没方法理解每一个新的 DNS 破绽攻打，然而能够应用防火墙、网络入侵监测零碎或域名解析器报告可疑的 DNS 行为迹象，作为被动防备的措施。

先讲下最罕用的伎俩：DNS 劫持 和DNS 净化。

什么是 DNS 劫持

DNS 劫持就是通过劫持了 DNS 服务器，通过某些伎俩获得某域名的解析记录控制权，进而批改此域名的解析后果，导致对该域名的拜访由原 IP 地址转入到批改后的指定 IP，其后果就是对特定的网址不能拜访或拜访的是假网址，从而实现窃取材料或者毁坏原有失常服务的目标。DNS 劫持通过篡改 DNS 服务器上的数据返回给用户一个谬误的查问后果来实现的。

DNS 劫持症状：在某些地区的用户在胜利连贯宽带后，首次关上任何页面都指向 ISP 提供的“电信互联星空”、“网通黄页广告”等内容页面。还有就是已经呈现过用户拜访 Google 域名的时候呈现了百度的网站。这些都属于 DNS 劫持。

什么是 DNS 净化

DNS 净化是一种让个别用户因为失去虚伪指标主机 IP 而不能与其通信的办法，是一种 DNS 缓存投毒攻打（DNS cache poisoning）。其工作形式是：因为通常的 DNS 查问没有任何认证机制，而且 DNS 查问通常基于的 UDP 是无连贯不牢靠的协定，因而 DNS 的查问非常容易被篡改，通过对 UDP 端口 53 上的 DNS 查问进行入侵检测，一经发现与关键词相匹配的申请则立刻伪装成指标域名的解析服务器（NS，Name Server）给查问者返回虚伪后果。

而 DNS 净化则是产生在用户申请的第一步上，间接从协定上对用户的 DNS 申请进行烦扰。

DNS 净化症状：目前一些被禁止拜访的网站很多就是通过 DNS 净化来实现的，例如 YouTube、Facebook 等网站。

解决办法:

  • 对于 DNS 劫持，能够采纳应用国外收费专用的 DNS 服务器解决。例如 OpenDNS（208.67.222.222）或 GoogleDNS（8.8.8.8）。
  • 对于 DNS 净化，能够说，个人用户很难单单靠设置解决，通常能够应用 VPN 或者域名近程解析的办法解决，但这大多须要购买付费的 VPN 或 SSH 等，也能够通过批改 Hosts 的办法，手动设置域名正确的 IP 地址。

为什么要 DNS 流量监控

预示网络中正呈现可疑或恶意代码的 DNS 组合查问或流量特色。例如：

  • 1. 来自伪造源地址的 DNS 查问、或未受权应用且无进口过滤地址的 DNS 查问，若同时察看到异样大的 DNS 查问量或应用 TCP 而非 UDP 进行 DNS 查问，这可能表明网络内存在被感化的主机，受到了 DDoS 攻打。
  • 2. 异样 DNS 查问可能是针对域名服务器或解析器（依据指标 IP 地址确定）的破绽攻打的标记。与此同时，这些查问也可能表明网络中有不失常运行的设施。起因可能是恶意软件或未能胜利革除恶意软件。
  • 3. 在很多状况下，DNS 查问要求解析的域名如果是已知的歹意域名，或具备域名生成算法(DGA)（与非法僵尸网络无关）常见特色的域名，或者向未受权应用的解析器发送的查问，都是证实网络中存在被感化主机的无力证据。
  • 4.DNS 响应也能露出可疑或歹意数据在网络主机间流传的迹象。例如，DNS 响应的长度或组合特色能够裸露歹意或非法行为。例如，响应音讯异样微小（放大攻打），或响应音讯的 Answer Section 或 Additional Section 十分可疑（缓存净化，荫蔽通道）。
  • 5. 针对本身域名组合的 DNS 响应，如果解析至不同于你公布在受权区域中的 IP 地址，或来自未受权区域主机的域名服务器的响应，或解析为名称谬误 (NXDOMAIN) 的对区域主机名的必定响应，均表明域名或注册账号可能被劫持或 DNS 响应被篡改。
  • 6. 来自可疑 IP 地址的 DNS 响应，例如来自调配给宽带接入网络 IP 段的地址、非标准端口上呈现的 DNS 流量，异样大量的解析至短生存工夫 (TTL) 域名的响应音讯，或异样大量的蕴含“name error”(NXDOMAIN)的响应音讯，往往是主机被僵尸网络管制、运行恶意软件或被感化的体现。

DNS 流量监控

如何借助网络入侵检测零碎、流量剖析和日志数据在网络防火墙上利用这些机制以检测此类威逼?

防火墙

咱们从最罕用的平安零碎开始吧，那就是防火墙。所有的防火墙都容许自定义规定以避免 IP 地址坑骗。增加一条规定，回绝接管来自指定范畴段以外的 IP 地址的 DNS 查问，从而防止域名解析器被 DDOS 攻打用作凋谢的反射器。

接下来，启动 DNS 流量检测性能，监测是否存在可疑的字节模式或异样 DNS 流量，以阻止域名服务器软件破绽攻打。具备本性能的罕用防火墙的介绍材料在许多网站都能够找到（例如 Palo Alto、思科、沃奇卫士等）。Sonicwall 和 Palo Alto 还能够监测并拦挡特定的 DNS 隧道流量。

入侵检测零碎

无论你应用 Snort、Suricata 还是 OSSEC，都能够制订规定，要求系统对未受权客户的 DNS 申请发送报告。你也能够制订规定来计数或报告 NXDomain 响应、蕴含较小 TTL 数值记录的响应、通过 TCP 发动的 DNS 查问、对非标准端口的 DNS 查问和可疑的大规模 DNS 响应等。DNS 查问或响应信息中的任何字段、任何数值基本上都“能检测”。惟一能限度你的，就是你的想象力和对 DNS 的相熟水平。防火墙的 IDS（入侵检测零碎）对大多数常见检测我的项目都提供了容许和回绝两种配置规定。

流量剖析工具

Wireshark 和 Bro 的理论案例都表明，被动流量剖析对辨认恶意软件流量很有成果。捕捉并过滤客户端与解析器之间的 DNS 数据，保留为 PCAP（网络封包）文件。创立脚本程序搜寻这些网络封包，以寻找你正在考察的某种可疑行为。或应用 PacketQ（最后是 DNS2DB）对网络封包间接进行 SQL 查问。

（记住：除了本人的本地解析器之外，禁止客户应用任何其余解析器或非规范端口。）

DNS 被动复制

该办法波及对解析器应用传感器以创立数据库，使之蕴含通过给定解析器或解析器组进行的所有 DNS 交易（查问 / 响应）。在剖析中蕴含 DNS 被动数据对辨认恶意软件域名有着重要作用，尤其实用于恶意软件应用由算法生成的域名的状况。将 Suricata 用做 IDS（入侵检测零碎）引擎的 Palo Alto 防火墙和平安管理系统，正是联合应用被动 DNS 与 IPS（入侵进攻零碎）以进攻已知歹意域名的平安零碎范例。

解析器日志记录

本地解析器的日志文件是考察 DNS 流量的最初一项，也可能是最显著的数据起源。在开启日志记录的状况下，你能够应用 Splunk 加 getwatchlist 或是 OSSEC 之类的工具收集 DNS 服务器的日志，并搜寻已知歹意域名。

只管本文提到了不少材料链接、案例剖析和理论例子，但也只是波及了泛滥监控 DNS 流量办法中的沧海一粟，疏漏在劫难逃，要想全面快捷及时无效监控 DNS 流量，无妨试试 DNS 服务器监控。

DNS 服务器监控

利用管理器可对域名零碎（DNS）进行全面深刻的可用性和性能监控，也可监控 DNS 监控器的个别属性，比方响应工夫、记录类型、可用记录、搜寻字段、搜寻值、搜寻值状态以及搜寻工夫等。

DNS 中被监控的一些要害组件：

指标 形容
响应工夫 给出 DNS 监控器的响应工夫，以毫秒示意
记录类型 显示记录类型连贯到 DNS 服务器的耗时
可用记录 依据可用记录类型输入 True 或 False
搜寻字段 显示用于 DNS 服务器的字段类型
搜寻值 显示在 DNS 服务器中执行的搜寻值
搜寻值状态 依据输入信息显示搜寻值状态：Success (胜利)或 Failed (失败)
搜寻工夫 DNS 服务器中的搜寻执行工夫

监控可用性 和响应工夫 等性能统计数据。这些数据可绘制成性能图表和报表，即时可用，还能够依照可用性和欠缺性对报表进行分组显示。

若 DNS 服务器或零碎内任何特定属性呈现问题，会依据配置好的阈值生成告诉和正告，并依据配置主动执行相干操作。目前，国内外 DNS 监控工具次要有 New relic、appDynamic、OneAPM。

参考文章

  • 【网易 MC】DNS 调度原理解析
  • DNS 原理入门
  • DNS 原理及其解析过程【精彩分析】
  • 当咱们谈网络时，咱们谈些什么(2)–DNS 的工作原理
  • 企业如何抵挡利用 DNS 隧道的恶意软件?
  • 监控 DNS 流量，预防安全隐患五大招！
  • DNS 协定详解及报文格式剖析
退出移动版