2.6. 域名系统

    2.6.2. 术语

    Multicast DNS (mDNS),多播DNS,使用5353端口,组播地址为 或 [FF02::FB] 。在一个没有常规DNS服务器的小型网络内可以使用mDNS来实现类似DNS的编程接口、包格式和操作语义。mDNS协议的报文与DNS的报文结构相同,但有些字段对于mDNS来说有新的含义。

    启动mDNS的主机会在进入局域网后向所有主机组播消息,包含主机名、IP等信息,其他拥有相应服务的主机也会响应含有主机名和IP的信息。

    mDNS的域名是用 和普通域名区分开的。

    2.6.2.2. FQDN

    FQDN (Fully-Qualified Domain Name) 是域名的完全形态,主要是包含零长度的根标签,例如 www.example.com.

    2.6.2.3. TLD

    Top-Level Domain (TLD) 是属于根域的一个域,例如 或 jp

    TLD一般可以分为 Country Code Top-Level Domains (ccTLDs) 、Generic Top-Level Domains (gTLDs) 以及其它。

    2.6.2.4. IDN

    Internationalized Domain Names for Applications (IDNA) 是为了处理非ASCII字符的情况。

    2.6.2.5. CNAME

    CNAME即Canonical name,又称alias,将域名指向另一个域名。

    2.6.3. 请求响应

    2.6.3.1. 响应码

    • NOERROR
    • FORMERR
    1. Format error - The name server was unable to interpret the query
    • SERVFAIL
    • NXDOMAIN
    1. this code signifies that the domain name referenced in the query does not exist
    • NOTIMP
    • REFUSED
    1. Refused - The name server refuses to perform the specified operation for policy reasons
    • NODATA

    DNS解析过程是递归查询的,具体过程如下:

    • 用户要访问域名www.example.com时,先查看本机hosts是否有记录或者本机是否有DNS缓存,如果有,直接返回结果,否则向递归服务器查询该域名的IP地址
    • 递归缓存为空时,首先向根服务器查询com顶级域的IP地址
    • 根服务器告知递归服务器com顶级域名服务器的IP地址
    • 递归向com顶级域名服务器查询负责example.com的权威服务器的IP
    • com顶级域名服务器返回相应的IP地址
    • 递归向example.com的权威服务器查询www.example.com的地址记录
    • 权威服务器告知www.example.com的地址记录

    2.6.5. 根服务器

    根服务器是DNS的核心,负责互联网顶级域名的解析,用于维护域的权威信息,并将DNS查询引导到相应的域名服务器。

    根服务器在域名树中代表最顶级的 域, 一般省略。

    13台IPv4根服务器的域名标号为a到m,即a.root-servers.org到m.root-servers.org,所有服务器存储的数据相同,仅包含ICANN批准的TLD域名权威信息。

    2.6.6. 权威服务器

    权威服务器上存储域名Zone文件,维护域内域名的权威信息,递归服务器可以从权威服务器获得DNS查询的资源记录。

    权威服务器需要在所承载的域名所属的TLD管理局注册,同一个权威服务器可以承载不同TLD域名,同一个域也可以有多个权威服务器。

    递归服务器负责接收用户的查询请求,进行递归查询并响应用户查询请求。在初始时递归服务器仅有记录了根域名的Hint文件。

    2.6.8. DGA

    DGA(Domain Generate Algorithm,域名生成算法)是一种利用随机字符来生成C&C域名,从而逃避域名黑名单检测的技术手段,常见于botnet中。一般来说,一个DGA域名的存活时间约在1-7天左右。

    DGA域名有多种生成方式,根据种子类型可以分为确定性和不确定性的生成。不确定性的种子可能会选用当天的一些即时数据,如汇率信息等。

    2.6.9. 安全机制

    作为主流的防御方案,DNS加密有五种方案,分别是 DNS-over-TLS (DoT)、DNS-over-DTLS、DNS-over-HTTPS (DoH)、DNS-over-QUIC以及DNSCrypt。

    2.6.9.1. DoT

    DoT方案在2016年发表于RFC7858,使用853端口。主要思想是Client和Server通过TCP协议建立TLS会话后再进行DNS传输,Client通过SSL证书验证服务器身份。

    2.6.9.2. DNS-over-DTLS

    DNS-over-DTLS和DoT类似,区别在于使用UDP协议而不是TCP协议。

    2.6.9.3. DoH

    DoH方案在发表RFC8484,使用 https://dns.example.com/dns-query{?dns} 来查询服务器的IP,复用https的443端口,流量特征比较小。DoH会对DNS服务器进行加密认证,不提供fallback选项。目前Cloudflare、Google等服务商对DoH提供了支持。

    DNS-over-QUIC安全特性和DoT类似,但是性能更高,目前没有合适的软件实现。

    2.6.9.5. DNSCrypt

    DNSCrypt使用X25519-XSalsa20Poly1305而非标准的TLS,且DNSCrypt的Client需要额外的软件,Server需要的专门的证书。

    DNS隧道工具将进入隧道的其他协议流量封装到DNS协议内,在隧道上传输。这些数据包出隧道时进行解封装,还原数据。

    2.6.11. 参考链接

    2.6.11.1. RFC

    2.6.11.2. 工具

    2.6.11.3. 研究文章

    • Plohmann D, Yakdan K, Klatt M, et al. A comprehensive measurement study of domain generating malware[C]//25th {USENIX} Security Symposium ({USENIX} Security 16). 2016: 263-278.