DNS简介

DNS的层次结构

domain name system 呈树状结构

  graph TD
    %% 自定义节点样式,使其看起来更像原图
    classDef rootNode fill:#f9f9f9,stroke:#333,stroke-width:2px,font-weight:bold;
    classDef level1 fill:#e1f5fe,stroke:#01579b;
    classDef level2 fill:#fff3e0,stroke:#e65100;
    classDef level3 fill:#e8f5e9,stroke:#1b5e20;
    classDef level4 fill:#f3e5f5,stroke:#4a148c;

    %% 根节点
    Root((根 .)):::rootNode

    %% 第一层:顶级域名
    Root --> T_aero(aero):::level1
    Root --> T_com(com):::level1
    Root --> T_net(net):::level1
    Root --> T_org(org):::level1
    Root --> T_edu(edu):::level1
    Root --> T_gov(gov):::level1
    Root --> T_cn(cn):::level1
    Root --> T_uk(uk):::level1

    %% 第二层:com 分支
    T_com --> S_baidu(baidu):::level2
    T_com --> S_cctv(cctv):::level2
    T_com --> S_google(google):::level2

    %% 第三层:cskaoyan 分支
    S_baidu --> L_map(map):::level3
    S_baidu--> L_www(www):::level3

    %% 第二层:cn 分支
    T_cn --> S_bj(bj):::level2
    T_cn --> S_edu(edu):::level2
    T_cn --> S_com(com):::level2

    %% 第三层:cn -> edu 分支
    S_edu --> L_hust(hust):::level3
    S_edu --> L_tsinghua(tsinghua):::level3

    %% 第四层:hust 分支
    L_hust --> F_mail(mail):::level4
    L_hust --> F_www(www):::level4

根域

  • 根域(.)

    根域即“.”,是最高级别的域名。

    域名在DNS系统中的完整格式为“example.com.”。当我们在浏览器中输入域名时,通常会省略最后的“.”,输入“example.com”,DNS系统会默认将域名转换为完整格式。

    “.”对应根域名服务器,是最高级别的DNS服务器,保存顶级域DNS服务器地址。

  • 顶级域(.com)

    顶级域根据域名后缀进行区分,主要包括两大类:

    • 通用顶级域,如.com,.net,.org,.top等。
    • 国家顶级域,如.cn,.uk,.de等。

    顶级域对应顶级域名服务器,保存顶级域对应一级域DNS服务器地址。例如,.com顶级域对应的顶级域名服务器保存后缀为.com的一级域名的DNS服务器地址。

  • 二级域(example.com)

    二级域是顶级域的子域,对应二级域服务器,为域名提供权威域名解析服务。

    例如,您在域名服务商处购买域名example.com,并设置域名的DNS服务器地址,实际上就是将为域名example.com提供权威解析服务的DNS服务器地址告知.com顶级域的过程。

eTLD

  • 顶级域(TLD):是 RFC 1034 树状结构中,根节点的直接子节点。它是一个技术概念。

  • 有效顶级域(eTLD):是公共后缀列表(Public Suffix List, PSL)中定义的、用户不能直接注册的域名后缀。它是一个管理/安全概念。

 DNS 的树状结构里,顶级域就是紧挨着根域(.)下面的那一层。

  • 在 www.123.com.cn 中,.cn 是顶级域(因为它是根的直接子节点)。

  • 在 www.baidu.com 中,.com 是顶级域。

  • 在 www.example.org 中,.org 是顶级域。

有效顶级域(eTLD):管理上的“注册边界”: 有效顶级域(effective TLD),也叫公共后缀(Public Suffix),它回答的问题是:“在哪个层级之下,普通用户才可以注册自己的域名?”

  • 在 www.123.com.cn 中,用户不能注册 .cn,也不能注册 .com.cn。用户能注册的是 123.com.cn 中的 123。所以,对于这个域名来说,.com.cn 才是有效顶级域(eTLD)。

  • 同理,www.baidu.com 中,.com 是有效顶级域,用户可以在它下面注册 baidu

FQDN

  • 绝对域名(FQDN, Fully Qualified Domain Name):以点号 . 结尾。例如 example.com.。最后的那个点代表根域,表示这是一个完整、无歧义的路径,计算机可以直接解析。

  • 相对域名(Relative Domain Name):不以点号结尾。例如 example.com。它表示相对于当前所在域的一个名字。比如你在 com 域里输入 example,它会被自动补全为 example.com.。我们平时在浏览器里输入的网址,绝大多数都是相对域名(省略了最后的根点),浏览器通常会自动把它当作绝对域名来处理。

DNS 解析过程

DNS的查询方式有两种,分别为递归查询(recursion)和迭代查询(iteration)。

  • 递归查询:客户端发起一个DNS解析请求,若本地DNS服务器若不能为客户端直接解析域名,则域名服务器会代替客户端(下级服务器)向域名系统中的各分支的上下级服务器进行递归查询,直到有服务器响应回答了该请求后,将该请求结果返回客户端。在此期间,客户端将一直处于等待状态。

  • 迭代查询:客户端(下级服务器)发起一个DNS解析请求后,若上级DNS服务器并不能直接提供该DNS的解析结果,则该上级DNS服务器会告知客户端(下级服务器)另一个可能查询到该DNS解析结果的DNS服务器IP,客户端(下级服务器)再次向这个DNS服务器发起解析请求,如此类推,直到查询到对应的结果为止。

  • 为了提高DNS的查询效率,并减少因特网上的DNS查询报文数量,在域名服务器中广泛地使用了缓存。当一个DNS服务器接收到DNS查询结果时,它能将该DNS信息缓存在缓存中。这样,当另一个相同的域名查询到达该DNS服务器时,该服务器就能够直接提供所要求的IP地址,而不需要再去向其他DNS服务器询问。因为主机名和IP地址之间的映射不是永久的,所以DNS服务器将在一段间后丢弃缓存中的信息。

  sequenceDiagram
    autonumber
    participant Host as m.xyz.com<br/>(需要查找y.abc.com的IP)
    participant Local as 本地域名服务器<br/>dns.xyz.com
    participant Root as 根域名服务器
    participant TLD as 顶级域名服务器<br/>dns.com
    participant Auth as 权限域名服务器<br/>dns.abc.com

    Host->>Local: 递归查询 (y.abc.com的IP)

    Note over Local, Auth: 请求逐级向下传递 (代替下级去问)
    Local->>Root: 递归查询
    Root->>TLD: 递归查询
    TLD->>Auth: 递归查询

    Note over Local, Auth: 拿到结果后,各级逐步原路返回
    Auth-->>TLD: 返回 y.abc.com的IP地址
    TLD-->>Root: 返回 y.abc.com的IP地址
    Root-->>Local: 返回 y.abc.com的IP地址

    Local-->>Host: 返回 y.abc.com的IP地址
Note over Host, Auth: ⚠️ 实际中几乎不使用:每次查询都要经过根域名服务器,<br/>会导致根服务器负载过大!
  sequenceDiagram
    autonumber
    participant Host as m.xyz.com<br/>(需要查找y.abc.com的IP)
    participant Local as 本地域名服务器<br/>dns.xyz.com
    participant Root as 根域名服务器
    participant TLD as 顶级域名服务器<br/>dns.com
    participant Auth as 权限域名服务器<br/>dns.abc.com

    Host->>Local: 递归查询 (y.abc.com的IP)

    Note over Local, Auth: 本地服务器进行迭代查询
    Local->>Root: 迭代查询
    Root-->>Local: 返回顶级域名服务器(dns.com)地址

    Local->>TLD: 迭代查询
    TLD-->>Local: 返回权限域名服务器(dns.abc.com)地址

    Local->>Auth: 迭代查询
    Auth-->>Local: 返回 y.abc.com的IP地址

    Local-->>Host: 返回 y.abc.com的IP地址
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
Domain Name System (query)
    Transaction ID: 0x9d51
    Flags: 0x0120 Standard query
        0... .... .... .... = Response: Message is a query
        .000 0... .... .... = Opcode: Standard query (0)
        .... .0.. .... .... = Truncated: Message is not truncated
        .... ..1. .... .... = Recursion desired: Do query recursively
        .... ...0 ..0. .... = Z: reserved (0)
        .... .... ..1. .... = AD bit: Set
        .... .... ...0 .... = Non-authenticated data: Unacceptable
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 1
    Queries
        mail.pku.edu.cn: type A, class IN

Recursion desired:(期望递归) 标志位为 1,准确地说是:“主机希望本地域名服务器替它进行代理查询“ 。我作为客户端,不想自己去找根、找顶级域,太麻烦了。本地服务器你帮我把最终 IP 找回来吧。

1
2
3
4
# 可以用dig 来测试
dig 12345678.com.cn +norecurse
dig 12345678.com.cn 
dig 12345678.com.cn +trace

DNS 报文长度

Truncated flag

RFC1035-4.2.1

Messages carried by UDP are restricted to 512 bytes (not counting the IP or UDP headers). Longer messages are truncated and the TC bit is set in the header. RFC1123-6.1.3.2

If the Answer section of the response is truncated and if the requester supports TCP, it SHOULD try the query again using TCP.

UDP携带的消息限制为512字节(不包括IP或UDP报头)。较长的消息被截断,TC位被设置在报头中。客户端收到带截断标志的dns 回复,应当用TCP 重新请求。

1
dig . DNSKEY @8.8.8.8 +bufsize=512

EDNS0

RFC6891-4.3

Traditional DNS messages are limited to 512 octets in size when sent over UDP [RFC1035]. Fitting the increasing amounts of data that can be transported in DNS in this 512-byte limit is becoming more difficult. For instance, inclusion of DNSSEC records frequently requires a much larger response than a 512-byte message can hold. EDNS(0) specifies a way to advertise additional features such as larger response size capability, which is intended to help avoid truncated UDP responses, which in turn cause retry over TCP. It therefore provides support for transporting these larger packet sizes without needing to resort to TCP for transport.

传统的 DNS 消息在通过 UDP 传输时,大小被限制在 512 个八位组(octets,即字节)以内 [RFC1035]。随着 DNS 中需要传输的数据量不断增加,要在 512 字节的限制内装下这些数据变得越来越困难。例如,包含 DNSSEC 记录时,响应往往远大于 512 字节消息所能容纳的大小。EDNS(0) 规定了一种方式来通告额外的能力,例如更大的响应大小能力。其目的是帮助避免 UDP 响应被截断,因为截断会导致通过 TCP 重试。因此,它支持传输更大的数据包,而不必为了传输而改用 TCP。

1
dig . DNSKEY @8.8.8.8 +bufsize=1232

为了规避 IP 分片带来的丢包风险(丢一个分片,整个 UDP 报文就废了),业界推荐使用 1232 字节。这个数字来自 IPv6 最小 MTU(1280)减去 IPv6 头和 UDP 头(48 字节)

Licensed under CC BY-NC-SA 4.0
使用 Hugo 构建
主题 Stack 由 Jimmy 设计