DNS 协议与运维

• 递归查询（resolver 替客户端完成）与迭代查询（逐级返回下一跳权威）的区别
• 从根服务器 → 顶级域 → 权威的逐级迭代过程
• 各级缓存（本地 resolver、OS、应用）的 TTL 控制与过期策略

客户端发起解析时，先查本地缓存（应用层/OS 层），未命中则交给递归 resolver（如 8.8.8.8 或运营商 DNS）。递归 resolver 对客户端来说是"递归查询"——它替客户端完成全部解析；而 resolver 对根、顶级域、权威服务器则是"迭代查询"，根服务器不会给出最终答案，而是返回下一级（如 .com）的 NS 地址，resolver 逐级向下，直到权威服务器返回 A/AAAA 记录。每级响应都带 TTL，resolver 按 TTL 缓存并递减，TTL 归零后重新向上游查询。解析失败时降级顺序一般是：先用各层缓存兜底（即使 TTL 已过仍可尝试 stale 数据），然后重新从更高层（如本地 resolver → 上游公共 DNS）重试，最后用备用解析通道（HTTPDNS/DoH）或降级到备用 IP。

理解递归/迭代的关键是"谁在替谁干活"。递归 resolver 是递归的终点，它内部用迭代完成查询。TTL 控制是缓存的核心，运维上要平衡"缩短 TTL 加快切换"与"缓存命中率"。降级顺序本质是"缓存→重试→换通道"的多级兜底。

• Consul 内置 DNS 服务器，默认监听 8600 端口
• 服务名查询格式 <service>.service.consul 与健康节点过滤
• SRV 记录返回端口与负载均衡权重，A 记录返回节点 IP

Consul 自带一个 DNS 服务器（默认 8600 端口），把服务注册信息映射为 DNS 记录。查询 web.service.consul 会返回该服务所有健康节点的 A 记录（节点 IP）；查询 _web._tcp.service.consul 返回 SRV 记录，包含 IP、端口和权重。Consul 默认只返回 passing 状态的健康节点，因此每次查询天然得到可用实例列表，实现负载均衡与服务发现。客户端可以用标准 dig 查询，也可把 Consul 配置为系统 DNS 的转发器，让普通应用无感使用。它支持 connect 服务、sidecar 服务等扩展命名。

Consul DNS 的价值在于把注册中心抽象成标准 DNS 协议，让任何会用 DNS 的客户端都能做服务发现，同时通过与健康检查联动自动剔除故障节点。相比直接读 API，DNS 接口对老应用侵入最小。

• cache 插件在前端缓存上游查询结果，TTL 按记录最小 TTL 计算
• 缓存键（qname+qtype+class）与缓存容量、prefetch 预热
• 负缓存与 TTL 上限/下限控制

cache 插件把上一条查询结果缓存在 CoreDNS 内存中，缓存键为 qname+qtype+class。命中时返回缓存记录并刷新 TTL，未命中则转发上游并写入缓存。它默认按记录携带的 TTL 缓存，可用 success/denial 分别设置成功与负缓存（NXDOMAIN）的 TTL 上限，用 prefetch 在 TTL 即将过期时提前向上游刷新，避免"缓存刚刚集体过期导致上游突发"。负缓存默认 TTL 较短。可通过 cache 的统计（命中/未命中）评估效果。

cache 的核心是"内存缓存 + TTL 递减 + 过期预热"。prefetch 是缓解缓存雪崩的关键——所有记录同时过期时上游压力骤增。Denial 缓存（NXDOMAIN/SERVFAIL）也很重要，能避免恶意或高频不存在的域名反复打上游。

• 从 API Server 监听 Service/Endpoint 变化并生成 DNS 记录
• 支持 cluster.local 域下的 service、pod 等查询格式
• 与 kube-dns 的兼容（支持 svc、pod 后缀）

kubernetes 插件通过 watch K8s API Server 的 Service、EndpointSlice、Pod 等资源，把它们的名字映射为 DNS 记录。它负责 cluster.local 域，支持查询格式如 <svc>.<ns>.svc.cluster.local、<svc>.<ns>.svc、<ip>.<ns>.pod.cluster.local 等。解析 Service 时返回其 ClusterIP，解析 headless Service 时返回所有 Pod IP。插件在 CoreDNS 内部实现，无需额外的数据存储，通过 fallthrough 决定未匹配记录是否交给下游插件处理。

kubernetes 插件实质上是一个"API Server 驱动的动态区文件"。它把 K8s 服务模型投射到 DNS 命名空间，天然支持集群内服务发现。headless Service 的 Pod 级解析、publishNotReadyAddresses 等细节都与其相关。

• ready 插件在 8181 端口提供 /ready 端点
• 依赖插件（如 kubernetes）完成自身同步后才返回 200
• K8s 探针（readinessProbe）对接该端点

ready 插件在指定端口（默认 8181）的 /ready 路径上返回 CoreDNS 的聚合就绪状态。它依赖的插件（如 kubernetes、cache）在完成初始化/同步后会向 ready 注册"就绪"，所有插件都就绪时才返回 200 OK，否则返回 500。K8s 的 readinessProbe 直接请求该端点，把 CoreDNS 的就绪状态接入 Pod 生命周期，未就绪的 CoreDNS 不会进入 Service 的 Endpoint，从而避免流量打到未初始化完成的实例。它还能在运行期报告插件故障（如 kubernetes 插件失去 API 连接）。

ready 是把"插件是否可用"抽象成 HTTP 健康检查的桥接层。它让 K8s 探针能感知 CoreDNS 内部依赖（如 etcd/API Server）的状态，实现真正的"就绪"而非仅"存活"。

• DoT 用 TLS 隧道封装 DNS 查询，默认端口 853
• 与 DoH（443/HTTPS）、明文 DNS（53）的对比
• 证书校验与验证（openssl s_client、dig +tls）

DNS over TLS 在 DNS 报文外再套一层 TLS，用标准 853 端口，加密查询与响应，防止窃听与篡改。部署时服务端在 853 上启用 TLS 并配置证书；客户端用 stubby 或 systemd-resolved 把明文 53 转发到加密的 DoT 上游。验证时可用 dig @127.0.0.1 -p 853 +tls example.com 发起 DoT 查询，或用 openssl s_client -connect 1.1.1.1:853 检查证书链。DoT 与 DoH 相比，DoT 用专有端口、更易被防火墙识别与封禁，DoH 复用 443 更隐蔽但需独立协议处理。

安全上 DoT 与 DoH 等价，区别在传输层封装与端口。DoT 的 853 端口相对固定，中间网络可识别并阻断；DoH 复用 HTTPS 与普通流量混在同端口，更抗封锁但解析行为与 HTTP 耦合。运维选型要权衡安全性与兼容性。

• AXFR 全量传送与 IXFR 增量传送的区别
• 主从用 SOA 序列号 + 定时 NOTIFY 触发同步
• 从服务器通过 NOTIFY 通知后拉取区域

区域传送是权威 DNS 主从同步的机制。AXFR 一次传送整个区域，IXFR 只传送自上次同步以来的增量变化。主服务器在 SOA 记录中维护递增的序列号，变化时通过 NOTIFY 通知从服务器；从服务器收到 NOTIFY 后对比 SOA 序列号，若主服务器序列号更大则发起 AXFR/IXFR。从服务器还按 SOA 中的 refresh/retry 定时刷新，防止漏掉通知。生产环境要用 TSIG 为区域传送签名，并在主服务器上限制只允许从服务器 IP 连接，防止区域被未授权拉取。

同步的核心是"序列号 + NOTIFY + 定时刷新"三重保障。序列号是版本号，NOTIFY 是事件驱动，定时刷新是兜底。TSIG 是安全前提，未签名的主从传送可能被中间人窃取或篡改区域数据。

• 提前降低 TTL 以加快切换生效
• 按比例/按区域灰度分发（ECS、GeoDNS、权重）
• 回滚方案（恢复旧记录、旧 IP 保留）

DNS 变更的灰度与回滚核心是"提前降 TTL + 分步切换 + 可快速回滚"。变更前 1-2 天把 TTL 从小时级降到 60s 左右，让客户端缓存尽快过期。灰度可通过权重（如 10%→50%→100%）、GeoDNS 按区域、ECS 按客户端子网逐步放量。切换后用拨测工具监控新地址的解析正确性与可用性。回滚时恢复旧记录，并保留旧 IP 一段时间（新旧 IP 双活），因为缓存未过期的客户端仍会访问旧 IP。整个变更要有变更单、回滚条件和监控大盘。

DNS 变更最大的风险是"TTL 未降导致的残留缓存"与"切换后新目标不可用"。因此必须先降 TTL、灰度放量、双 IP 并存、监控兜底。回滚不是删记录，而是切回旧记录并容忍缓存滞后窗口。

• NXDOMAIN：域名不存在，权威确认
• SERVFAIL：服务器无法完成解析（上游故障、递归失败）
• REFUSED：服务器拒绝（未授权、策略限制）

NXDOMAIN 表示"域名确实不存在"，权威服务器明确应答，常见于拼写错误、记录被删除；若权威返回 NXDOMAIN 但业务认为域名存在，多为权威数据异常。SERVFAIL 表示"服务器未能完成解析"，通常是上游递归超时、权威不可达、根服务器不可达或 DNSSEC 验证失败，属于可用性故障而非"不存在"。REFUSED 表示"服务器拒绝处理"，常见于权威未配置该 zone、使用非授权服务器、或策略限制（如只允许特定客户端）。排障时先看响应码落在哪一层：NXDOMAIN 查权威数据，SERVFAIL 查链路与上游，REFUSED 查配置与策略。

三个码的区分是定位 DNS 故障的起点。NXDOMAIN 是确定性结果，SERVFAIL 是过程性失败，REFUSED 是策略性拒绝。SERVFAIL 在运维中占比最高，往往对应网络或上游问题。

• 缓存污染（cache poisoning）原理：伪造响应注入缓存
• 防御：源端口随机化、0x20 随机大小写、DNSSEC 验证
• 检测：对比公共 DNS 与本地结果、检查异常解析

DNS 缓存污染是攻击者向递归 resolver 注入伪造的 DNS 响应，使大量客户端被劫持到恶意地址。防御要点：一是源端口随机化，让攻击者难以猜中请求的源端口（0x20 编码随机化查询名大小写同理）；二是 DNSSEC 验证，使伪造响应无法通过签名校验；三是只信任可信上游。检测方法：用 dig 对比本地 resolver 与公共 DNS（如 8.8.8.8）的结果是否一致，或对关键域名做基线比对，发现异常解析立即排查。企业内网的递归解析器应限制开放范围、启用 DNSSEC 验证并监控异常解析。

污染的本质是"伪造响应早于真实响应到达并被缓存"。源端口随机化提高猜测难度，DNSSEC 提供密码学杜绝伪造。检测的核心是"多源比对 + 基线监控"。

• A 记录 IPV4、AAAA 记录 IPV6 地址映射
• CNAME 别名指向、NS 权威服务器、MX 邮件交换
• TXT 文本验证、SOA 区域起始信息、SRV 服务定位

A 记录把域名映射到 IPv4 地址，AAAA 映射到 IPv6。CNAME 是别名，把域名指向另一个域名（如 www 指向 @），注意 CNAME 不能与同名的其他记录共存且不能指向 IP。NS 记录声明该区域的权威服务器，MX 记录声明邮件交换服务器（带优先级），TXT 记录用于任意文本（SPF、DKIM、域名验证等）。SOA 记录是区域的起始信息，含序列号、refresh/retry/expire 与主 NS，用于主从同步与会话。SRV 记录用于定位特定服务（如 _sip._tcp），包含目标、端口与优先级/权重，是服务发现（如 Consul、K8s）的基础。

需要区分"地址记录"（A/AAAA）、"别名/权限记录"（CNAME/NS）、"服务记录"（MX/SRV）与"元数据记录"（SOA/TXT）。CNAME 与 A 不能共存、MX 与 NS 的层级关系是常见考点。

• DNSKEY 记录包含 ZSK/KSK 的公钥，随区域发布
• DS 记录把 KSK 摘要提交到父区，形成信任链
• 分角色密钥：KSK 签名 DNSKEY，ZSK 签名数据记录

DNSSEC 中 DNSKEY 记录承载区域公钥，随区域一起发布，供验证者使用。为分层保护，区域一般有两类密钥：ZSK（Zone Signing Key）签名普通数据记录（A、NS 等），KSK（Key Signing Key）只签名 DNSKEY 记录。KSK 的摘要通过 DS 记录提交到父区，这样从根到父区再到本区的信任链就建立起来。验证者从根密钥开始，用 DS 校验子区的 DNSKEY，再用 ZSK 校验数据记录，从而确认数据未被篡改。发布 DNSKEY 时要注意密钥轮换，KSK 轮换因涉及 DS 提交父区，风险更高。

DNSKEY 是 DNSSEC 的"公钥发布"载体，信任链靠 DS 记录逐级传递。ZSK 轮换只需改区内记录，KSK 轮换需要父区 DS 更新，因此 KSK 轮换要更谨慎、更慢。

• ZSK 轮换：发布新 ZSK、签名、旧密钥保留一段预发布期
• KSK 轮换：新 KSK 发布 → 验证 → 父区 DS 更新 → 删除旧 KSK
• 风险点：DS 更新失败、缓存旧密钥、密钥过早删除

ZSK 轮换相对简单：先在区域内发布新 ZSK 并用它签名，同时保留旧 ZSK 让其签名继续有效，待所有 resolver 缓存过期后再移除旧 ZSK，避免出现"新密钥无法验证旧签名"的窗口。KSK 轮换更复杂：先发布新 KSK 并让新 KSK 签名 DNSKEY 集合（双签名），然后向父区提交新的 DS 记录（DS 变更），等待父区生效且缓存过期，最后删除旧 KSK 与旧 DS。风险点在于：DS 更新延迟或失败会导致验证断链；resolver 缓存旧 DS 与新 DNSKEY 不匹配；密钥过早删除造成验证失败。因此 KSK 轮换要"平行发射"并留足传播时间。

轮换的核心是"新旧并存、交叉验证、逐步退出"。任何一步把旧密钥删得太早都会撕裂验证链。ZSK 防区内，KSK 防父区，KSK 轮换的风险与等待窗口远大于 ZSK。

• ECS 是 EDNS0 扩展，在查询中携带客户端 IP 前缀
• 权威据此返回就近的地址，改善 CDN 调度精度
• 隐私与安全权衡（前缀截断、信任）

ECS（EDNS Client Subnet, RFC 7871）是 EDNS0 的一个扩展选项，递归 resolver 在转发查询时把客户端 IP 前缀（如 /24）附在查询中，权威服务器据此返回更贴近客户端的位置结果，从而改善 CDN 等按地域/运营商调度的精确度。默认情况下权威只能看到 resolver 的 IP，无法感知真实客户端位置，ECS 解决了这个问题。但它涉及隐私（暴露客户端子网）与滥用风险，因此一般只传前缀（如 /24）而非完整 IP，且 resolver 可配置是否透传。注意 ECS 查询结果缓存键要包含子网，否则会串台。

ECS 的价值在"让权威能看到客户端位置"，代价是"暴露客户端子网 + 缓存键复杂化"。它促使 CDN 就近调度更准，但缓存与隐私管理也需相应设计。

• 公共 DNS（8.8.8.8/1.1.1.1/223.5.5.5）安全性与隐私差异
• LocalDNS 劫持：运营商篡改/污染解析导致调度错误或投毒
• HTTPDNS 用 HTTP API 直连权威，绕过 LocalDNS

公共 DNS 中，8.8.8.8（Google）与 1.1.1.1（Cloudflare）支持 DoH/DoT 与 DNSSEC，安全性高，但海外解析到国内 CDN 可能存在延迟；223.5.5.5（阿里）与 119.29.29.29（腾讯）在国内调度更准。运营商 LocalDNS 常被劫持，表现为：解析结果被篡改指向广告/错误 IP、对不存在域名返回运营广告页、对权威结果做白名单过滤。HTTPDNS 是应对劫持的常用方案：客户端用 HTTP API 直接向权威/HTTPDNS 服务商查询域名，得到真实 IP，绕过 LocalDNS，且支持按接入点（运营商/地域）就近调度、故障自动降级。配合短 TTL 可减少劫持窗口。

选型核心是"安全 vs 调度精度"。HTTPDNS 的价值在于绕过 LocalDNS 的不可信链路，用可信网络通道直接拿 IP。国内环境尤其要防止 LocalDNS 污染与劫持。

• 转发器（forwarder）把非本区查询转发给上游
• 条件转发（conditional forwarder）按域名转发到指定服务器
• 缓存层规划：分层缓存、TTL 管理、避免单点

内网 DNS 通常分"权威区"与"递归/转发区"。权威区承载内网域名（如 corp.local），由内部 DNS 服务器维护 zone。递归/转发层把非本区查询转发给上游（公共 DNS 或上级），并做缓存降低上游压力。条件转发按域名路由：如 .example.com 转发给内网权威，其余域名转发给公共 DNS，避免内网域名泄漏到公网。缓存层要分层次规划（如每个机房的本地缓存 + 中心缓存），合理设置 TTL 与缓存命中率监控，并用多实例 + 就近部署避免单点、降低解析延迟。

内网 DNS 设计的关键是"权威与递归分离、条件转发隔离域、缓存分层兜底"。条件转发解决"哪些域名走内网、哪些走公网"，同时防止内网域名被递归到公网泄露。

• DNSSEC 验证保证数据完整性，防止伪造
• 源端口随机化 + 0x20 提高投毒难度
• DoT/DoH 加密传输，防止窃听篡改

三层加固各防一类威胁：DNSSEC 解决"数据完整性"，用公钥签名 + 验证链防止响应被篡改/伪造；端口随机化与 0x20 编码禁止投毒，针对"伪响应抢先注入缓存"；DoT/DoH 解决"传输保密"，用 TLS 加密查询与响应，防窃听与中间人篡改。落地时：递归解析器开启 DNSSEC 验证（unbound 的 validate）、启用随机源端口（unbound 默认 use-source-port-random）、把上游换成 DoT/DoH（forward-tls-upstream）。企业内网可把可信解析器作为唯一出口，辅以协议日志与异常解析告警。

三层互为补充：DNSSEC 防"内容被改"，端口随机化防"缓存被投"，DoT/DoH 防"传输被嗅探/篡改"。组合使用才能形成纵深防御。

• dig +trace 逐级展示从根到权威的查询过程
• nslookup 调试输出（QNAME、server、Non-authoritative）
• /etc/resolv.conf 的 nameserver、timeout、attempts、rotate

dig +trace example.com 从根开始逐级发起迭代查询，展示每一步的响应与耗时，能精确定位是根、顶级域还是权威域失败。nslookup -debug example.com 显示查询的目标、发送的服务器与收到响应，nslookup example.com 8.8.8.8 可指定服务器对比。/etc/resolv.conf 的 nameserver 指定解析器，options timeout:n attempts:n rotate 控制超时秒数、重试次数与多服务器轮询。若 dig 直接查询权威正常而系统解析失败，多因 resolv.conf 指向的 resolver 不可达、超时过短或缓存问题；若某级权威超时，则定位到该级。

工具链的核心是"分层定位"：dig +trace 看链路，nslookup 看本机视角，resolv.conf 看解析器配置。三者结合能区分"配置问题、网络问题、权威问题"。

• Knot DNS 的 zone 配置与 zonefile 管理
• 动态更新（RFC 2136）与 DNSSEC 签名
• knot 命令管理工具（zone check、reload）

Knot DNS 用 knot.conf 配置 zone，zone 数据存放在 zonefile 中，支持 knotc zone-reload、knotc zone-check 等命令管理。它支持主从动态更新（RFC 2136）、AXFR/IXFR 区域传送、DNSSEC 在线签名，性能高、内存占用低，适合大规模权威运营。相比 BIND，Knot 更聚焦权威解析、配置更简洁，但生态与文档不如 BIND 丰富。管理上通过 knotc 命令实时 reload zone、查看 knotc status 状态，zonefile 变更后需 reload 生效。

Knot DNS 是"现代、高性能、聚焦权威"的解析器，与 BIND 的最大差异是简洁与性能。管理 zone 的核心是 zonefile + knotc 命令 + 区域传送/DNSSEC 能力。

• kube-dns 架构（kube-dns/SkyDNS + dnsmasq + sidecar）与 CoreDNS 单进程
• CoreDNS 的 kubernetes 插件取代 kube-dns 的多个组件
• 迁移后配置项（forward、cache、ready）对齐

K8s 高版本默认用 CoreDNS 替代 kube-dns。kube-dns 由 kube-dns（SkyDNS 代理）、dnsmasq（缓存）、sidecar（指标）三个进程构成；CoreDNS 是单进程、插件化（kubernetes 插件做服务发现、forward 转发、cache 缓存、ready 就绪）。迁移时把 kube-dns 的 Service 替换为 CoreDNS Deployment，配置 Corefile 对齐 kube-dns 的查询语义（cluster.local、反代解析、上游转发），并设置 readinessProbe 到 /ready。迁移后验证 nslookup service.ns.svc.cluster.local 解析正常，监控解析耗时与错误率，必要时可回滚到 kube-dns。

CoreDNS 是 kube-dns 的现代化替代，单进程 + 插件架构更利于扩展与可观测。迁移要点是"语义对齐 + 健康检查 + 验证回滚"。

• 分层：权威内网区 + 递归转发层 + 公网区
• 条件转发隔离内网域名，不向上游转发
• split-horizon（分区视图）：同一域名内外网解析不同

内网与公网 DNS 分层设计把解析拆为：内网权威区（承载 corp.local 等内网域名）、递归/转发层（缓存与转发非本区查询）、公网区（公共 DNS）。用条件转发把内网域名只交给内网权威，绝不转发到外网，从而避免内网域名解析泄漏到公网。split-horizon（视图 view）让同一域名（如 portal.example.com）在内网解析到内网 IP、公网解析到公网 IP，由内网权威与公网权威分别处理。防护上要确保内网 zone 的 NS 不指向公网服务器、不做全量转发、内网递归只服务内网客户端。

核心是"域隔离 + 视图隔离"。条件转发从"路由"上隔离，split-horizon 从"数据"上隔离，两者组合保证内网域名不泄露、内外网解析正确。