dig +trace 追踪域名从根服务器到权威服务器的完整解析路径，识别 A/AAAA/CNAME/MX 等 DNS 记录类型，理解 ARP 将 IP 映射到 MAC 地址的广播机制，并掌握 DNS 劫持和 ARP 欺骗两种常见网络攻击的原理与防御手段。你每天都在用 DNS。在浏览器输入 www.example.com 时，计算机会先通过 DNS（Domain Name System，域名系统）把这个人类可读的名字翻译成机器需要的 IP 地址（如 93.184.216.34）。没有 DNS，你得记住每个网站的 IP 数字串才能访问。
DNS 的角色很像老式的"114 查号台"：你知道一家公司叫"联想集团"，拨 114 说"帮我查联想集团的电话"，话务员在自己的号码簿里找到后告诉你"010-12345678"。DNS 做的事一样——你给它域名，它给你 IP 地址。区别在于，DNS 的号码簿分布在全球数百万台服务器上，不是一本厚书。
域名是倒置的树形结构，从右到左层级递降。以 www.example.com. 为例：
. — 全球 13 组根 DNS 服务器，管理顶级域信息com — 通用顶级域（com/org/net）或国家顶级域（cn/jp/us）example — 注册的域名，由权威 DNS 服务器管理www — 由二级域所有者自行划分的主机名在 DNS 出现之前，每台电脑维护一个本地文件记录"域名→IP"映射。这个文件至今仍存在，优先级高于 DNS 查询——你的系统会先查本地，找不到才去问 DNS 服务器。
当你在浏览器输入 example.com 时，系统先读 /etc/hosts，发现已有对应记录，直接使用 93.184.216.34，不会发起 DNS 查询。这个机制既是调试利器，也是攻击者篡改域名解析的常见入口。
echo "127.0.0.1 test.local" | sudo tee -a /etc/hosts，之后浏览器访问 test.local 就会连到本机。DNS 使用 53 号端口（UDP 用于查询，TCP 用于区域传送）。在安全领域，记住端口号与服务的对应关系是基本功——扫描时看到开放端口，你得立刻判断背后跑的是什么服务。
| 端口 | 协议 | 服务 | 安全风险 |
|---|---|---|---|
21 |
TCP | FTP 文件传输 | 明文传输密码 |
22 |
TCP | SSH 远程登录 | 暴力破解 |
23 |
TCP | Telnet 远程登录 | 明文传输所有数据 |
25 |
TCP | SMTP 邮件发送 | 邮件伪造 |
53 |
UDP/TCP | DNS 域名解析 | DNS 劫持/投毒 |
80 |
TCP | HTTP Web 服务 | 明文 Web 流量 |
443 |
TCP | HTTPS 加密 Web | 证书伪造 |
3306 |
TCP | MySQL 数据库 | 数据库暴露 |
3389 |
TCP | RDP 远程桌面 | 暴力破解 |
8080 |
TCP | HTTP-Alt 非标准 Web | 隐蔽 Web 服务 |
你已经知道 DNS 是"查号台"。现在来看一次完整的 DNS 查询经过哪些环节。当你在浏览器输入 www.example.com 时，解析请求会经过以下步骤：
关键区分两种查询模式：你的电脑到本地 DNS 服务器之间是递归查询（你问一次，解析器负责帮你跑完所有后续步骤）；本地 DNS 服务器到各级服务器之间是迭代查询（解析器每次得到下一级地址，再主动去问下一级）。
| 特性 | 递归查询 | 迭代查询 |
|---|---|---|
| 谁负责跑完 | 被问者全权代劳 | 问询者自己逐级追 |
| 返回内容 | 最终 IP 地址 | 下一级服务器地址 |
| 典型场景 | 客户端 → 本地 DNS | 本地 DNS → 根/TLD/权威 |
| 负载压力 | 解析器承担较大 | 各级分担，单点压力小 |
用 dig +trace 可以亲眼看到这个迭代过程——它从根服务器开始，逐级查询并打印每一跳的结果：
第 4 行显示根服务器返回了 com 顶级域的 NS 记录。第 5 行是顶级域返回的权威服务器地址。第 6 行是权威服务器返回的最终 IP。这就是一次完整的迭代解析过程。
DNS 不只是存"域名→IP"一种映射。它维护着多种记录类型，每种承载不同的信息。掌握这些记录类型，是分析网络基础设施的基本功。
| 记录类型 | 含义 | 示例值 |
|---|---|---|
A |
域名 → IPv4 地址 | 93.184.216.34 |
AAAA |
域名 → IPv6 地址 | 2606:2800:220:1:... |
CNAME |
域名 → 另一个域名（别名） | example.com |
MX |
邮件交换服务器 | 10 mail.example.com |
NS |
域名管辖的权威服务器 | ns1.example.com |
TXT |
文本记录（SPF/DKIM 验证） | v=spf1 include:_spf... |
PTR |
IP → 域名（反向解析） | example.com |
SOA |
区域授权起始（管理信息） | ns1.example.com admin... |
dig（Domain Information Groper）是 DNS 诊断的首选工具。最基础的用法是直接查一个域名的 A 记录：
输出中的 status: NOERROR 表示查询成功。86400 是 TTL（生存时间），单位秒，表示这条记录可以缓存一天。查 MX 记录只需加类型参数：
MX 记录中的数字（10/20/30）是优先级，越小越优先。发邮件时，邮件服务器会优先连 10 这台，如果连不上才依次尝试 20、30。只需要 IP 不要废话时，加 +short 参数：
nslookup 和 host 是另外两个常见 DNS 查询工具。nslookup 交互能力更强，host 输出更简洁：
系统使用哪个 DNS 服务器由 /etc/resolv.conf 指定。这个文件决定了你的 DNS 查询发往哪里：
nameserver 行指定 DNS 服务器地址。Kali 默认用 127.0.0.53（systemd-resolved 本地代理），实际转发到路由器或 ISP 的 DNS。安全测试中常改为 8.8.8.8（Google DNS）或 1.1.1.1（Cloudflare DNS）以绕过本地 DNS 污染。
echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf — 用 tee 在 root 权限下写入
DNS 设计于 1983 年，最初没有考虑安全。查询和响应都是明文传输，没有身份验证，任何人都可以伪造 DNS 响应。这些缺陷催生了三类常见攻击：
| 攻击类型 | 原理 | 危害 |
|---|---|---|
| DNS 劫持 | 篡改 /etc/hosts 或 DNS 服务器配置，返回假 IP | 用户被引导到钓鱼网站 |
| DNS 投毒 | 向 DNS 缓存注入伪造记录，影响所有使用该缓存的用户 | 大规模域名劫持 |
| DNS 隧道 | 将数据编码到 DNS 查询中，绕过防火墙传出数据 | 数据泄露、命令控制通道 |
最简单的 DNS 劫持就是修改 /etc/hosts 文件。在 Kali 上可以模拟：将某个域名指向错误 IP，观察浏览器行为：
劫持后，curl 尝试连接 127.0.0.1（本机没有 Web 服务所以失败）。如果在 127.0.0.1:80 上部署一个钓鱼页面，用户访问 example.com 就会看到这个伪造页面。测试完毕后务必恢复：sudo sed -i '/example.com/d' /etc/hosts。
DNS 隧道利用了一个事实：大多数防火墙允许 DNS 流量（53 端口）自由出入。攻击者将窃取的数据编码成子域名，通过 DNS 查询发出。例如，要泄露文件内容 secret=pass123，攻击者构造查询 c2VjcmV0PXBhc3MxMjM.evil.com（Base64 编码后拼接攻击者域名）。DNS 服务器会把这个查询转发到攻击者控制的域名服务器，攻击者从查询日志中解码出原始数据。
用 tcpdump 可以观察 DNS 查询流量，发现异常长的子域名是 DNS 隧道的典型特征：
DNSSEC（DNS Security Extensions）为 DNS 响应添加数字签名，让解析器能验证响应的真实性。DoH（DNS over HTTPS）和 DoT（DNS over TLS）则将 DNS 查询加密传输，防止中间人窃听和篡改。用 dig 可以检查域名是否启用了 DNSSEC：
输出中的 ad 标志（Authentic Data）表示响应已通过 DNSSEC 验证。RRSIG 记录就是数字签名本身。
从应用层 DNS 降到链路层。你在上一篇学了 HTTP over TCP over IP，但 IP 数据包最终要通过网卡发出，网卡只认 MAC 地址（Media Access Control，物理地址）。ARP（Address Resolution Protocol，地址解析协议）负责把 IP 地址翻译成 MAC 地址——没有 ARP，IP 数据包无法到达物理网络。
ARP 的工作方式像办公楼前台广播找人：你知道同事张三的工号（IP 地址），但不知道他坐哪个工位（MAC 地址）。前台向全楼层广播"工号 1001 的张三在吗？"，张三听到后回复"我在工位 42"，你就知道该往哪送文件了。
当你的电脑（IP: 192.168.1.50）要发数据给网关（IP: 192.168.1.1），它需要知道网关的 MAC 地址。过程分两步：
ARP 请求是广播（发给 FF:FF:FF:FF:FF:FF，同一网段所有设备都收到），ARP 应答是单播（只回复给请求者）。请求中已经包含源机的 IP 和 MAC，所以应答者顺便也能学到请求者的映射关系。
每台设备维护一张 ARP 缓存表，记录已知的 IP→MAC 映射，避免每次通信都广播。用 arp -n 查看：
新版 Linux 推荐用 ip neigh（iproute2 工具集），输出信息更丰富：
REACHABLE 表示近期通信过且确认可达，STALE 表示有一段时间没通信，记录可能过期。ARP 缓存条目默认存活约 60 秒（可配置），过期后重新发起 ARP 请求。
arp -n 里通常只有同子网设备和网关的记录。ARP 协议有一个致命缺陷：它没有身份验证。任何设备都可以发送 ARP 应答声称"我这个 IP 对应这个 MAC"，接收方会无条件更新自己的 ARP 缓存。这个设计缺陷使 ARP 欺骗成为局域网攻击的经典手段。
攻击者向局域网发送伪造的 ARP 应答，告诉受害者"网关 192.168.1.1 的 MAC 是我的 MAC"，同时告诉网关"受害者 192.168.1.50 的 MAC 是我的 MAC"。双向欺骗后，受害者↔网关的所有流量都经过攻击者，形成中间人攻击（MITM）：
攻击者可以窃取 HTTP 明文密码、篡改网页内容、注入恶意脚本。即使 HTTPS 也可能因证书警告被用户忽略而中招。Kali 中的 arpspoof 工具（dsniff 包）可实现此攻击——但仅在授权测试环境中使用。
最简单的检测方法是对比 ARP 表中的 MAC 地址。如果同一网关 IP 对应了两个不同的 MAC，或者多个 IP 指向同一个 MAC，就可能遭受 ARP 欺骗。用 arping 可以主动验证：
arping -I eth0 -c 3 192.168.1.1 — 明确指定接口和发送次数
最直接的手段是设置静态 ARP 绑定，将网关 IP 与 MAC 固定关联，拒绝接受该 IP 的其他 ARP 应答：
企业环境中，更实用的防御是交换机层面的 DHCP Snooping + 动态 ARP 检测（DAI）：交换机只允许 DHCP 服务器分配的 IP 发送 ARP 应答，伪造的 ARP 包在交换机端口被直接丢弃。终端用户层面，始终使用 HTTPS（TLS 加密）可以防止 ARP 欺骗窃取应用层数据——即使流量被劫持，攻击者也只能看到加密密文。
dig +short example.com A 和 dig +short example.com AAAA，记录两种记录返回的 IP 地址差异，并解释为什么一个域名可能有 A 和 AAAA 两种记录。dig +trace 追踪 github.com 的完整解析路径，记录沿途经过的每一级 NS 服务器。然后用 arp -n 查看本机 ARP 表，找出网关的 IP 和 MAC 地址，并用 arping -I [接口] -c 3 [网关IP] 验证网关 MAC 是否一致。tcpdump -i eth0 port 53 -n -c 50 抓取 50 个 DNS 查询包，然后浏览几个网站。分析抓包结果：哪些域名被查询了？用的是 UDP 还是 TCP？有没有异常长的子域名（可能是 DNS 隧道）？尝试用 dig @1.1.1.1 [域名] 指定用 Cloudflare DNS 重新查询，对比结果是否一致（不一致可能是 DNS 污染）。