dns协议

介绍

Domain Network System（DNS），可以理解为将域名和IP地址相互映射的一个分布式数据库，能够使人更方便地访问互联网。DNS使用TCP和UDP端口53。当前，对于每一级域名长度的限制是63个字符（协议限制），域名总长度则不能超过253个字符。开始时，域名的字符仅限于ASCII字符的一个子集。2008年，ICANN通过一项决议，允许使用其它语言作为互联网顶级域名的字符。使用基于Punycode码的IDNA系统，可以将Unicode字符串映射为有效的DNS字符集。因此，诸如“XXX.中国”、“XXX.美国”的域名可以在地址栏直接输入并访问，而不需要安装插件。但是，由于英语的广泛使用，使用其他语言字符作为域名会产生多种问题，例如难以输入，难以在国际推广等。

早期的域名必须以英文句号.结尾。例如，当用户访问www.wikipedia.org的HTTP服务时必须在地址栏中输入：http://www.wikipedia.org.，这样DNS才能够进行域名解析。现在的DNS服务器会自动补上结尾的点号。

域名层级结构

主机名.次级域名.顶级域名.根域名

b.940504.top.

即：host.sld.tld.root

域名层级结构

DNS层级结构

所有 DNS 服务器都属于以下四个类别之一：

  • 本地域名服务器（DNS resolver/Local DNS，一般是递归解析器，用来响应客户端的递归请求，大多数 Internet 用户使用他们 ISP 提供的递归解析器）
  • 权威域名服务器（authoritative nameserver，在特定区域内具有唯一性，保存了该区域内的域名与IP地址之间的对应关系）
  • 顶级（TLD）域名服务器（top-level domains，管理顶级域名服务器下注册的二级域名，比如940504.com中，.com是顶级域名，向此域名服务器查询可返回940504.com的权威域名服务器地址）
  • 根域名服务器（本地域名服务器查询不到时，会向根查询返回顶级域名服务器地址）

DNS Master Files (Zone Files)

常用记录类型

  • 主机记录（A记录）：将域名映射到对应主机的IP地址。
  • 别名记录（CNAME记录）: 返回另一个域名，即当前查询的域名是另一个域名的跳转。最常用到 CNAME 的场景包括做 CDN、企业邮箱、全局流量管理等。
  • IPv6主机记录（AAAA记录）: 与A记录对应，用于将特定的主机名映射到一个主机的IPv6地址。
  • 服务位置记录（SRV记录）: 用于定义提供特定服务的地址和端口，下面有示例。
  • MX邮件记录（Mail eXchange）：返回接收电子邮件的服务器地址，dig 940504.top mx。
  • 域名服务器记录（NS记录）：把子域名交给其他 DNS 服务商解析。该记录只能设置为域名，不能设置为IP地址。
  • PTR：逆向查询记录（Pointer Record）：用于从IP地址查询域名。
  • TXT：一个域可以具有许多 TXT 记录，通常用于发件人策略框架（SPF）代码，这些代码可帮助电子邮件服务器判断邮件是否来自受信任的来源，有有助于域所有权验证。dig _dnsauth.b.940504.top txt。
  • 起始授权记录SOA：此记录可以存储有关域的重要信息，如管理员的电子邮件地址、上次更新域的时间，以及服务器在刷新之间应等待的时间。
  • url记录：有显性和隐性。隐性url记录使用的是iframe框架技术，不是重定向，访问后地址栏url不变；显性url记录支持url转发301、302重定向，地址栏会跟着重定向。

  1. ns记录

    NS 代表“域名服务器”，域名服务器记录指示哪个 DNS 服务器对该域名具有权威性（即，哪个服务器包含实际 DNS 记录）。一般来说，NS 记录表明了可从哪里找到域名的 IP 地址。为了服务的安全可靠，一个域名通常会有多个 NS 记录，这些记录可指示该域的主要和备用域名服务器。

  2. srv记录

example.comrecord type:value:TTL
@_sip._tcp.example.com.SRV8080 exampledomain.com41200

在上面的示例中，“_sip”指示服务的名字，“_tcp”指示协议，“8080”指示端口，而“example.com”是主机，格式为 优先级 权重 端口 目标地址 ，每项中间需以空格分隔。例如：

srv-record

  1. PTR记录

    反向查找是电子邮件服务器常用的方法。许多电子邮件服务器会拒绝来自任何不支持反向查找的服务器的邮件。这是因为，垃圾邮件发送者通常使用无效的 IP，所以这些电子邮件服务器会先检查并查看邮件是否来自有效的服务器，然后再将其放入自己的网络中。此外，日志记录软件通常也采用反向查找，以便在其日志数据中为用户提供可读性好的域名，而不是一堆数字地址。

解析过程

两个概念：

  1. 递归查询 - 在递归查询中，DNS 客户端要求 DNS 服务器（一般为 DNS 递归解析器）返回准确的资源记录响应结果，如果解析器无法找到该记录，则返回错误消息。
  2. 迭代查询 - 在这种情况下，DNS 客户端将允许 DNS 服务器返回其能够给出的最佳应答。客户端再向此应答发起请求，依次反复，直至返回结果、发生错误或超时为止。

在 DNS 查找中（没有缓存时），这四个 DNS 服务器协同工作来完成解析任务（客户端一般是一个存根解析器 – 内置于操作系统的简单解析器）。下图是解析过程：

DNS递归解析器

dns缓存

DNS 高速缓存：DNS 高速缓存涉及将数据存储在更靠近请求客户端的位置，以便能够更早地解析 DNS 查询，并且能够避免在 DNS 查找链中进一步向下的额外查询，从而缩短加载时间并减少带宽/CPU 消耗。DNS 数据可缓存到各种不同的位置上，每个位置都存储了 DNS 记录，保存时间由生存时间TTL决定。

浏览器 DNS 缓存

浏览器默认将 DNS 记录缓存一段时间，路径最短、处理步骤最少，响应更快

Chrome 中，转到 chrome://net-internals/#dns 查看或清除 DNS 缓存

操作系统级 DNS 缓存

操作系统级 DNS 解析器是 DNS 查询离开计算机前的第二站，也是本地最后一站。此解析器通常称为“存根解析器”或 DNS 客户端。当存根解析器收到来自某个应用程序的请求时，其首先检查自己的缓存，查看是否有此记录。如果没有，则将此 DNS 查询（一般默认设置了递归标记）发送到ISP的 DNS 递归解析器。

与先前所有步骤一样，当 ISP 内的递归解析器收到 DNS 查询时，先查看所请求的域名到IP的对应关系是否已经存储在其本地持久化层中。

根据其缓存结果，递归解析器进行下面的操作：

  1. 如果解析器没有记录，但有权威性域名服务器的 NS 记录，则其将直接查询这些域名服务器，从而绕过 DNS 查询中的几个步骤。此快捷方式可防止从根和 .com 域名服务器（在我们对 example.com 的搜索中）进行查找，并且有助于更快地解析 DNS 查询。
  2. 如果解析器没有 NS 记录，它会向 TLD 服务器（本例中为 .com）发送查询，从而跳过根服务器。
  3. 如果解析器没有指向 TLD 服务器的记录，其将查询根服务器。这种情况通常在清除了 DNS 高速缓存后发生。

img

传输协议

DNS 协议建立在 UDP 或 TCP 协议之上，默认使用 53 号端口。客户端默认通过 UDP 协议进行通讯，但是由于广域网中不适合传输过大的 UDP 数据包，因此规定当报文长度超过了 512 字节时，应转换为使用 TCP 协议进行数据传输。

使用TCP的情况：

  • 客户端认为 UDP 响应包长度可能超过 512 字节，主动使用 TCP 协议；
  • 客户端使用 UDP 协议发送 DNS 请求，服务端发现响应报文超过了 512 字节，在截断的 UDP 响应报文中将 TC 设置为 1 ，以通知客户端该报文已经被截断，客户端收到之后再发起一次 TCP 请求；
  • 区域传输，例如dns主备

消息格式

dns查询和响应消息格式一样，由下面几部分组成

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

 +---------------------+
 |        Header       | 报文头
 +---------------------+
 |       Question      | 查询请求
 +---------------------+
 |        Answer       | 应答
 +---------------------+
 |      Authority      | 授权应答
 +---------------------+
 |      Additional     | 附加信息
 +---------------------+
header组成
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

每个字段长16位
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|          ID 用于客户端区分不同的请求应答           |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|  Opcode  |AA|TC|RD|RA|   Z    |   RCODE    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                QDCOUNT问题记录数                |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                ANCOUNT回答记录数                |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                NSCOUNT授权记录数                |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                ARCOUNT附加记录数                |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Field描述长度(bits)
QR查询包0，响应11
OPCODE0标准查询，1反向查询，2 server状态检查位4
AA响应包出现，表明是否权威应答1
TC是否由于过长被截断1
RD请求包中，期望使用递归查询1
RA响应包中出现，server是否支持递归1
Z保留位3
RCODE响应码，NOERROR (0)，FORMERR (1, Format error)，SERVFAIL (2)，NXDOMAIN (3, Nonexistent domain)，Not Implemented(4，查询类型没实现)，Refused(5，一般安全策略导致)4
  • Header 定义了报文是请求还是应答、错误码以及其它的一些标志位；
  • Question 描述了查询的请求报文，包括查询类型(QTYPE)、查询类(QCLASS) 以及查询的域名(QNAME)；
  • 剩下的3个段包含相同的格式：一系列可能为空的资源记录(RRs)。 Answer段包含回答问题的RRs；授权段包含授权域名服务器的RRs；附加段包含和请求相关的，但是不是必须回答的RRs。
Queries 部分

img

  • QNAME编码规则：
    • 以 . 分隔为多段，每段以字节数打头
      • 单字节，前2bit必须为0
    • ASCII编码每段字符
    • 以0结尾
Answer

img

抓包分析

  • wireshark

解析查询工具

  • dig +trace

  • nslookup

dns常见攻击了解

  • DNS 欺骗/缓存中毒：将伪造的 DNS 数据引入 DNS 解析器缓存中的攻击，其将导致解析器返回错误地址。流量可能会被转移到恶意计算机或攻击者想要的其他任何位置，而不是前往正确网站；通常是用于恶意目的的原始站点副本，例如分发恶意软件或收集登录信息。DNS 中毒攻击并非易事，由于 DNS 解析器实际上确实查询权威性域名服务器，因此在权威性域名服务器作出真实答复前，攻击者只有几毫秒的时间来发送虚假答复。

  • DNS 劫持：在 DNS 劫持中，攻击者将查询重定向到其他域名服务器。这可通过恶意软件或未经授权的 DNS 服务器修改来实现。尽管其结果与 DNS 欺骗的结果相似，但这是一种截然不同的攻击，因为其目标是域名服务器上网站的 DNS 记录，而不是解析器的高速缓存。

  • NXDOMAIN 攻击：这是一种 DNS 洪水攻击（属于DDos类），攻击者利用请求淹没 DNS 服务器，请求不存在的记录等恶意请求，以导致合法流量的拒绝服务。这可使用复杂的攻击工具来实现，这些工具可为每个请求自动生成唯一子域。NXDOMAIN 攻击还可将递归解析器作为目标，目标是用垃圾请求填充解析器的高速缓存。

  • dns放大攻击：利用dns攻击别人

img

dns防御参考：https://blog.cloudflare.com/dnssec-an-introduction/

DDoS了解

  • 应用层攻击

    • http洪水

  • 协议攻击

    协议攻击利用协议堆栈第 3 层和第 4 层的弱点致使目标无法访问。这类攻击会过度消耗服务器资源和/或防火墙和负载平衡器之类的网络设备资源。

部分内容整理自网络