运维123 - DNS
type: channel
link: https://www.sddts.cn/index.php/tag/DNS/
items: Linux systemd-resolved DNS 缓存失效问题排查
items: dnsmasq DNS 记录与解析
items: dnsmasq DNS 配置基础
items: dnsmasq min-cache-ttl 参数工作原理技术分析
items: ACME DNS 验证与自定义递归服务器作用分析
items: acme.sh 跨 DNS 服务商多域名证书申请指南
items: CNAME 与 A 记录顺序引发的全网 DNS 解析故障分析
items: dog 命令行 DNS 客户端技术分析
items: 故障排除前先关闭这6个路由器默认设置
items: Round Robin DNS 工作原理与实践分析

Linux systemd-resolved DNS 缓存失效问题排查
type: item
date: 2026-01-30T09:03:27+00:00
description: Linux systemd-resolved DNS 缓存失效问题排查一、事件概述1. 事件背景在 Linux 系统上使用 dnscache 工具检查 DNS 缓存状态时，发现缓存统计数据异常，缓存条目始终为 0，命中率极低。2. 影响范围A. 影响功能DNS 查询无法利用本地缓存，每次查询都需要访问网络，增加延迟和网络负载。B. 影响程度缓存命中率仅 4.85%所有 DNS 查询均走网络请求3. 问题表现Total Entries 始终为 0Cache Hits 不增加Cache Misses 持续增长resolvectl query 显示 Data from: network二、事件时间线1. 问题发现A. 现象描述执行 dnscache -stats 命令，观察到以下异常输出：DNS Cache Statistics ==================== Total Entries: 0 Cache Hits: 3551 Cache Misses: 69660 Hit Rate: 4.85%B. 初步判断缓存条目为 0 但有历史命中记录，说明缓存曾经工作过但当前无法保留条目。2. 深入排查A. 验证缓存刷新执行 dnscache -flush 后再次查看统计，Misses 继续增加但 Entries 仍为 0。B. 系统级验证使用 resolvectl statistics 确认系统级 DNS 缓存状态：Cache Current Cache Size: 0 Cache Hits: 3551 Cache Misses: 696853. 配置检查A. resolved 配置文件检查 /etc/systemd/resolved.conf：#Cache=no-negative #CacheFromLocalhost=no配置项被注释，使用默认值（Cache=yes），排除配置禁用缓存的可能。4. 根因定位A. 查询来源验证执行 resolvectl query google.com，输出显示：-- Data from: network确认 DNS 查询结果来自网络而非缓存，即使刚刚查询过同一域名。sequenceDiagram participant U as 用户 participant D as dnscache 工具 participant R as systemd-resolved participant N as 网络 DNS U->>D: dnscache -stats D->>R: 获取统计信息 R-->>D: Entries=0, Hits=3551 D-->>U: 显示统计结果 U->>R: resolvectl query google.com R->>N: DNS 查询请求 N-->>R: 返回 IP（TTL=0?） R-->>U: Data from: network Note over R: 缓存条目因 TTL 过期 立即被清除三、问题分析1. 直接原因DNS 查询结果没有被缓存，或缓存后立即过期被清除。2. 根本原因（5 Whys 分析）A. 为什么缓存条目始终为 0？DNS 记录的 TTL（Time To Live）值非常短或为 0，导致缓存立即过期。B. 为什么 TTL 会是 0？上游 DNS 服务器（企业内网 DNS 或特定配置的公共 DNS）返回的记录 TTL 被设置为极短值。C. 为什么上游 DNS 要设置短 TTL？企业 DNS 策略：便于快速切换 IP、负载均衡CDN 服务：动态调整流量分配安全考虑：防止 DNS 缓存投毒攻击3. 深层反思Cache Hits 是累计值，表示历史上有过缓存命中Current Cache Size 是实时值，表示当前缓存中的条目数两者不一致说明缓存机制正常，但条目因 TTL 过期被清除四、解决方案1. 诊断方法A. 检查 DNS 记录 TTL使用 dig 命令查看具体域名的 TTL 值：dig google.com +noall +answer若 TTL 显示为 0 或极小值（1-5 秒），确认是上游 DNS 配置问题。B. 连续查询对比# 第一次查询 dig example.com +noall +answer # 等待几秒后再次查询 dig example.com +noall +answer观察 TTL 值变化，正常情况下第二次查询的 TTL 应该比第一次小。2. 可能的解决方案A. 更换 DNS 服务器若当前使用企业 DNS，可尝试切换到公共 DNS（如 8.8.8.8、1.1.1.1）测试：# 临时测试 resolvectl dns eth0 8.8.8.8B. 配置本地 DNS 缓存部署 dnsmasq 或 unbound 作为本地缓存层…

dnsmasq DNS 记录与解析
type: item
date: 2026-01-29T22:54:19+00:00
description: dnsmasq DNS 记录与解析一、概述1. DNS 记录类型深度解析A. 什么是 DNS 记录DNS 记录（Resource Record，RR）是 DNS 系统中存储域名相关信息的基本单位。每条记录包含以下信息：名称（Name）：记录所属的域名类型（Type）：记录的类型（A、AAAA、CNAME、MX 等）类（Class）：通常是 IN（Internet）TTL：生存时间数据（Data）：记录的具体内容B. dnsmasq 支持的记录类型dnsmasq 支持以下 DNS 记录类型的配置：记录类型用途配置选项AIPv4 地址映射--host-record, --addressAAAAIPv6 地址映射--host-record, --addressCNAME域名别名--cnameMX邮件服务器--mx-host, --mx-targetSRV服务定位--srv-hostTXT文本信息--txt-recordPTR反向解析--ptr-recordNS域名服务器(权威模式自动生成)NAPTR命名权限指针--naptr-recordCAA证书颁发机构授权--caa-record二、各类记录详细配置1. A 和 AAAA 记录A. host-record 选项--host-record 是最灵活的主机记录配置方式：# 基本语法 host-record=name[,name...],[IPv4],[IPv6],[TTL] # 单个主机 host-record=server1,192.168.1.10 # 多个名称指向同一地址 host-record=www,web,server,192.168.1.10 # 同时配置 IPv4 和 IPv6 host-record=server1,192.168.1.10,2001:db8::10 # 指定 TTL host-record=server1,192.168.1.10,3600 # 完整示例 host-record=laptop,laptop.local.lan,192.168.1.100,fd00::100B. address 选项--address 选项主要用于域名重定向：# 基本语法 address=/domain/ipaddr # 广告拦截 address=/ad.example.com/0.0.0.0 # 服务重定向 address=/api.old.com/192.168.1.50 # 通配符重定向 address=/.internal.com/192.168.1.12. CNAME 记录A. 基本配置# 基本语法 cname=cname[,cname...],target[,TTL] # 单个别名 cname=www,server1 # 多个别名 cname=www,web,server1 # 指定 TTL cname=api,v2.api,backend.example.com,300 # 通配符别名 cname=*.example.com,default.example.comB. CNAME 链dnsmasq 支持多级 CNAME：# 配置示例 cname=blog,www cname=www,server1 host-record=server1,192.168.1.10 # 解析链：blog -> www -> server1 -> 192.168.1.103. MX 记录A. 邮件服务器配置# 指定邮件服务器 mx-host=mail.example.com,mail.example.com,10 # 使用 mx-target 设置默认目标 mx-target=mailserver.example.com mx-host=example.com # 多个 MX 记录（优先级不同） mx-host=mail1.example.com,mail1.example.com,10 mx-host=mail2.example.com,mail2.example.com,20B. MX 记录详解graph LR A[邮件发送者] -->|查询 MX| B[DNS 服务器] B -->|返回 MX 记录| C[邮件服务器列表] C --> D[MX 10: mail1] C --> E[MX 20: mail2] D -->|尝试连接| F[投递邮件] E -->|备用| F4. SRV 记录A. 服务定位配置# 基本语法 srv-host=_service._proto[.domain],[target][,port][,priority][,weight] # LDAP 服务器 srv-host=_ldap._tcp.example.com,ldap.example.c…

dnsmasq DNS 配置基础
type: item
date: 2026-01-29T22:54:14+00:00
description: dnsmasq DNS 配置基础一、概述1. DNS 服务概述A. 什么是 DNS 转发器dnsmasq 的 DNS 功能本质上是一个转发器（Forwarder）和缓存服务器的组合，而不是一个完整的递归解析器。这意味着 dnsmasq 不会像 BIND 那样从根服务器开始逐级查询域名，而是将客户端的 DNS 查询请求转发到上游的递归 DNS 服务器，然后将结果返回给客户端。这种设计有以下几个优势：资源占用小：不需要维护完整的域名树数据结构，内存占用极小响应速度快：利用缓存机制，重复查询直接从内存返回配置简单：不需要配置根区域、区域文件等复杂概念安全性高：不直接与互联网上的 DNS 服务器通信，减少攻击面B. DNS 转发工作原理当一个 DNS 查询到达 dnsmasq 时，会经历以下处理流程：flowchart TD A[客户端 DNS 查询] --> B{检查本地配置} B -->|有 address 配置| C[返回指定 IP] B -->|无配置| D{检查 /etc/hosts} D -->|找到记录| E[返回 hosts 记录] D -->|未找到| F{检查 DNS 缓存} F -->|缓存命中| G[返回缓存结果] F -->|缓存未命中| H[转发到上游 DNS] H --> I[等待上游响应] I --> J[存入缓存] J --> K[返回给客户端]C. 为什么使用 DNS 转发器使用 DNS 转发器而不是直接使用上游 DNS 服务器有以下好处：降低延迟：本地缓存可以显著减少查询延迟，尤其是对于频繁访问的域名减轻上游压力：减少对上游 DNS 服务器的查询次数，节省网络带宽提高可靠性：当上游服务器不可用时，缓存中的记录仍然可以提供服务灵活性：可以根据域名智能选择不同的上游服务器隐私保护：减少与外部 DNS 服务器的通信次数2. 前置知识A. DNS 基础概念域名结构：DNS 采用分层树状结构，从根域（.）开始，向下分为顶级域（.com、.cn）、二级域（example.com）、子域（www.example.com）等。记录类型：A 记录：将域名映射到 IPv4 地址AAAA 记录：将域名映射到 IPv6 地址CNAME 记录：域名别名MX 记录：邮件服务器TXT 记录：文本信息NS 记录：域名服务器PTR 记录：反向解析（IP 到域名）递归查询 vs 迭代查询：递归查询：DNS 服务器负责查询并返回最终结果迭代查询：DNS 服务器返回下一步应该查询的服务器地址B. 推荐知识了解 /etc/resolv.conf 文件的作用了解 dig 或 nslookup 工具的基本用法了解 DNS 查询日志如何查看和分析二、DNS 转发器配置1. 上游服务器设置A. 基本配置dnsmasq 默认从 /etc/resolv.conf 文件读取上游 DNS 服务器。对于大多数 Linux 发行版，这个文件由网络管理器（如 NetworkManager、systemd-networkd）自动维护。查看当前上游服务器：cat /etc/resolv.conf手动指定上游服务器：使用 --server 选项可以指定上游 DNS 服务器：# 配置文件语法 server=8.8.8.8 server=8.8.4.4 server=114.114.114.114完全禁用 /etc/resolv.conf：如果不想使用 /etc/resolv.conf 中的服务器，可以使用 --no-resolv 选项：# 完整配置示例 no-resolv server=8.8.8.8 server=8.8.4.4B. 指定域名使用特定服务器dnsmasq 最强大的功能之一是可以根据域名将查询转发到不同的上游服务器。这在国际网络环境下特别有用，可以实现国内外 DNS 分流。基本语法：# 将特定域名的查询转发到指定服务器 server=/domain/upstream_dns实际应用示例：# 国内域名使用国内 DNS server=/cn/114.114.114.114 server=/qq.com/119.29.29.29 server=/taobao.com/223.5.5.5 # 国外域名使用国外 DNS server=/com/8.8.8.8 server=/org/8.8.8.8 server=/net/1.1.1.1 # 企业内网域名 server=/internal.corp.com/192.168.1.1C. 域名匹配规则详解dnsmasq 的域名匹配规则非常灵活，支持多种匹配模式：精确匹配：# 只匹配 example.com，不匹配 www.example.com server=/example.com/192.168.1.1子域名匹配…

dnsmasq min-cache-ttl 参数工作原理技术分析
type: item
date: 2026-01-29T21:47:07+00:00
description: dnsmasq min-cache-ttl 参数工作原理技术分析一、概述1. 问题定义在使用 dnsmasq 作为 DNS 缓存服务器时，min-cache-ttl 参数是一个重要但常被误解的配置选项。本文将深入分析该参数的工作原理、限制条件以及实际应用场景。2. 核心问题什么是 min-cache-ttl 参数？它与普通的 DNS TTL 有什么区别？为什么设置 min-cache-ttl=36000（10 小时）会遇到问题？3. 分析目标理解 dnsmasq 的 DNS 缓存机制掌握 min-cache-ttl 参数的工作原理了解该参数的限制和替代方案二、背景知识1. DNS TTL 基础概念DNS TTL（Time To Live）是指 DNS 记录在缓存中的生存时间，单位为秒。当 DNS 解析器查询域名时，会将结果缓存指定时长，过期后需要重新查询。2. dnsmasq 简介dnsmasq 是一个轻量级的 DNS 转发器和 DHCP 服务器，广泛用于家庭路由器、嵌入式设备和小型网络环境。其主要功能包括：DNS 缓存：缓存 DNS 查询结果，提高解析速度DHCP 服务：为网络设备分配 IP 地址DNS 转发：将查询请求转发到上游 DNS 服务器三、dnsmasq 缓存机制1. 缓存工作流程graph TD A[客户端 DNS 查询] --> B{检查本地缓存} B -->|命中| C[返回缓存结果] B -->|未命中| D[转发到上游 DNS] D --> E[接收上游响应] E --> F[应用 TTL 规则] F --> G[存入缓存] G --> C C --> H[返回给客户端]2. TTL 相关参数dnsmasq 提供了多个与 TTL 相关的配置参数：参数作用默认值cache-ttl缓存条目的默认 TTL无min-cache-ttl最小缓存 TTL0max-cache-ttl最大缓存 TTL无限制max-ttl返回给客户端的最大 TTL无限制local-ttl本地记录（如 /etc/hosts）的 TTL0neg-ttl否定响应（NXDOMAIN）的缓存时间无四、min-cache-ttl 参数详解1. 参数定义min-cache-ttl= 用于设置 DNS 缓存条目的最小生存时间。2. 工作原理A. 首次查询当客户端首次查询某个域名时：dnsmasq 将查询转发到上游 DNS 服务器上游服务器返回 DNS 记录及其 TTL 值dnsmasq 将记录存入缓存，返回给客户端的 TTL 为原始值B. 后续查询当客户端再次查询同一域名时：dnsmasq 检查本地缓存如果缓存未过期，直接返回结果返回给客户端的 TTL 是缓存中剩余的时间C. TTL 扩展机制min-cache-ttl 的核心功能是扩展短 TTL 值：graph LR A[上游返回 TTL=60s] --> B{min-cache-ttl 设置值} B -->|min-cache-ttl=300| C[缓存 TTL 扩展为 300s] B -->|min-cache-ttl=0| D[使用原始 TTL=60s] C --> E[减少上游查询] D --> F[遵守原始 TTL]3. 代码实现原理根据 dnsmasq 源码分析，min-cache-ttl 的实现逻辑如下：// src/cache.c 中的 TTL 调整逻辑 if (daemon->min_cache_ttl != 0 && ttl < daemon->min_cache_ttl) ttl = daemon->min_cache_ttl;这段代码的核心含义是：如果配置了 min-cache-ttl 且上游返回的 TTL 小于该值，则强制使用 min-cache-ttl 作为缓存时间。4. 关键限制A. 硬编码限制dnsmasq 在源码中对 min-cache-ttl 设置了硬编码限制：// src/config.h #define TTL_FLOOR_LIMIT 3600 /* 不允许 min-cache-ttl 超过 1 小时 */这意味着：即使配置文件中设置 min-cache-ttl=36000，dnsmasq 实际使用的最大值只能是 3600 秒（1 小时）。B. 为什么有此限制？DNS 协议设计原则：TTL 反映了域名所有者对该记录变化频率的预期，人为延长可能违反这一原则数据新鲜度：过长的缓存时间可能导致客户端使用过期的 IP 地址故障恢复：当需要紧急切换 DNS 记录时，过长的缓存会延迟生效五、36000 秒配置的问题1. 问题分析用户设置 min-cache-ttl=36000（10 小时）的初衷可能是：减少频繁的 DNS 查询降低上游 DNS 服务器负载提高域名解析速度2. …

ACME DNS 验证与自定义递归服务器作用分析
type: item
date: 2026-01-29T07:49:35+00:00
description: ACME DNS 验证与自定义递归服务器作用分析一、问题背景1. 核心疑问在使用 acme.sh 的 DNS 验证方式申请域名证书时，用户可以指定自定义的递归 DNS 服务器。这引发了一个疑问：ACME 服务器是通过互联网的公共 DNS 进行域名验证的，用户指定的 DNS 服务器能起到什么作用？2. 涉及组件ACME 协议：自动化证书管理环境协议acme.sh：Shell 脚本实现的 ACME 客户端DNS 验证：ACME 挑战-响应验证方式之一递归 DNS 服务器：负责递归查询域名解析的服务器二、ACME DNS 验证机制1. 验证流程概述sequenceDiagram participant Client as acme.sh 客户端 participant DNS as DNS 服务商 participant Propagation as DNS 传播 participant ACME as ACME 服务器 (Let's Encrypt) participant PublicDNS as 公共 DNS Client->>DNS: 1. 申请证书 Client->>DNS: 2. 添加 TXT 记录 _acme-challenge.example.com DNS-->>Client: 确认添加成功 Note over Client,ACME: 等待 DNS 传播完成 Client->>PublicDNS: 3. 轮询检测 TXT 记录 (使用指定 DNS 服务器) PublicDNS-->>Client: 仍不可见 Client->>PublicDNS: 继续轮询... PublicDNS-->>Client: 记录已可见 Client->>ACME: 4. 通知 ACME 服务器验证 ACME->>PublicDNS: 5. 从多个位置查询 TXT 记录 PublicDNS-->>ACME: 返回 TXT 记录值 ACME-->>Client: 6. 验证通过，颁发证书 Client->>DNS: 7. 清理 TXT 记录2. ACME 服务器的验证行为A. 多位置验证ACME 服务器（如 Let's Encrypt）从全球多个位置验证 DNS 记录：验证源分布：美国、欧洲、亚太等地使用的 DNS：公共递归服务器（如 Google 8.8.8.8、Cloudflare 1.1.1.1）验证逻辑：必须从多个位置都能查询到正确的 TXT 记录B. 权威性验证路径ACME 服务器 → 公共递归 DNS → 权威 DNS → DNS 记录验证关键点：ACME 服务器不使用用户指定的 DNS 服务器进行验证。三、自定义 DNS 服务器的作用1. 本地预检测机制用户指定的 DNS 服务器仅用于 acme.sh 本地的预检测，不影响 ACME 服务器的验证过程。A. 问题场景时间轴： T0: 用户添加 TXT 记录到 DNS 服务商 T1: DNS 服务商更新权威记录 T2: 记录传播到部分 DNS 服务器 T3: 记录全球可见 acme.sh 在 T2 时刻触发验证 → ACME 服务器可能看不到记录 → 验证失败B. 解决方案# 方式 1：固定等待时间（粗暴） acme.sh --issue --dns dns_cf -d example.com --dnssleep 120 # 方式 2：指定 DNS 服务器进行智能检测 export ACME_DNS_SERVER="8.8.8.8" acme.sh --issue --dns dns_cf -d example.com2. 工作原理对比graph TB subgraph "方式 1：固定等待" A1[添加 TXT 记录] -->|等待 120 秒| B1[触发 ACME 验证] B1 --> C1{ACME 服务器查询} C1 -->|成功| D1[颁发证书] C1 -->|失败| E1[重试] end subgraph "方式 2：智能检测" A2[添加 TXT 记录] -->|轮询检测| B2[使用指定 DNS 查询] B2 -->|未检测到| B2 B2 -->|检测到| C2[触发 ACME 验证] C2 --> D2[颁发证书] end3. 具体配置示例A. 使用公共递归 DNS# 使用 Google DNS 进行预检测 export ACME_DNS_SERVER="8.8.8.8:53" # 使用 Cloudflare DNS export ACME_DNS_SERVER="1.1.1.1:53" # 使用国内 DNS（加速检测） export ACME_DNS_SERVER="223.5.5.5:53"B. 使用权威 DNS# 直接查询权威 DNS 服务器，…

acme.sh 跨 DNS 服务商多域名证书申请指南
type: item
date: 2026-01-29T07:00:25+00:00
description: acme.sh 跨 DNS 服务商多域名证书申请指南一、概述1. 问题背景在实际使用场景中，用户可能拥有多个分散在不同 DNS 服务商的域名。例如：a.com 及其子域名的 DNS 解析托管在阿里云b.com 及其子域名的 DNS 解析托管在腾讯云 DNSPod用户希望生成一张 SSL 证书，同时覆盖 a.com、.a.com、b.com、.b.com 这些域名。2. 核心结论重要提示：acme.sh 官方不支持在单个证书中混合使用多个 DNS 服务商的 API。这是 acme.sh 的设计限制，而非配置问题。二、技术原理1. acme.sh 的工作原理acme.sh 使用 ACME 协议申请证书，支持 DNS-01 验证方式。在 DNS-01 验证中，acme.sh 需要在每个域名的 DNS 解析中添加一条 TXT 记录，证明申请者对该域名的控制权。2. 多 DNS API 的技术限制当申请一个包含多个域名的证书时，acme.sh 会为所有域名使用相同的 DNS API 插件。这是因为：acme.sh 的证书申请命令只接受一个 --dns 参数每个域名的 DNS 验证必须通过该指定的 DNS API 完成如果域名不在该 DNS 服务商处，API 调用将失败graph TD A[acme.sh 申请证书] --> B{指定 DNS API} B -->|阿里云 API| C[验证 a.com] B -->|阿里云 API| D[验证 b.com 失败] C --> E[证书申请失败] D --> E三、解决方案方案一：分别为每个域名生成独立证书（推荐）1. 方案说明为每个 DNS 服务商处的域名分别生成证书，这是最简单、最可靠的方式。2. 阿里云域名证书申请A. 获取阿里云 API 密钥登录阿里云控制台进入访问控制（RAM）-> 用户创建新用户或使用现有用户为用户添加 DNS 管理权限创建 AccessKey，记录 AccessKey ID 和 AccessKey SecretB. 配置环境变量export Ali_Key="your_aliyun_access_key_id" export Ali_Secret="your_aliyun_access_key_secret"C. 申请证书acme.sh --issue --dns dns_ali \ -d a.com \ -d *.a.com3. 腾讯云域名证书申请A. 获取腾讯云 API 密钥登录腾讯云控制台进入访问管理 -> API 密钥管理创建密钥，记录 SecretId 和 SecretKeyB. 配置环境变量export DP_Id="your_tencent_secret_id" export DP_Key="your_tencent_secret_key"C. 申请证书acme.sh --issue --dns dns_dp \ -d b.com \ -d *.b.com4. 优点与缺点优点：配置简单，不易出错证书续期互不影响灵活性高，可独立管理符合最佳实践缺点：需要管理多个证书文件Web 服务器需要配置多个证书方案二：统一 DNS 服务商1. 方案说明将所有域名的 DNS 解析迁移到同一个服务商，然后使用单个证书覆盖所有域名。2. 实施步骤A. 选择目标 DNS 服务商根据需求选择阿里云或腾讯云作为统一 DNS 服务商。B. 迁移 DNS 解析在目标 DNS 服务商添加域名复制所有 DNS 记录到新服务商修改域名 NS 记录，指向新的 DNS 服务器等待 DNS 生效（通常需要 24-48 小时）C. 申请统一证书# 假设全部迁移到阿里云 export Ali_Key="your_aliyun_access_key_id" export Ali_Secret="your_aliyun_access_key_secret" acme.sh --issue --dns dns_ali \ -d a.com \ -d *.a.com \ -d b.com \ -d *.b.com3. 优点与缺点优点：单一证书管理简单减少证书续期任务缺点：需要迁移 DNS 服务迁移过程可能影响服务失去多云冗余优势方案三：DNS 别名模式（不推荐）1. 方案说明acme.sh 支持 DNS 别名模式，但配置复杂，不建议普通用户使用。2. 技术原理DNS 别名模式允许通过 CNAME 记录，将一个域名的 ACME 挑战记录指向另一个域名。这样：a.com 的 ACME 挑战通过阿里云 DNS 验证b.com 的 ACME 挑战通过 CNAME 指向 a.com，间接通过阿里云验证3. 配置复杂度需要手动配置 CNAME 记录需要理解 ACME 协议细节故障排查困难四、最佳实践1. 证书管…

CNAME 与 A 记录顺序引发的全网 DNS 解析故障分析
type: item
date: 2026-01-19T22:20:36+00:00
description: CNAME 与 A 记录顺序引发的全网 DNS 解析故障分析一、事件概述1. 事件背景2026 年 1 月 8 日，Cloudflare 公共 DNS 服务 1.1.1.1 的一次例行更新意外引发了互联网范围内的 DNS 解析失败。此次故障的根本原因并非攻击或停机，而是 DNS 响应中记录顺序的微妙变化。2. 影响范围A. 影响用户使用 1.1.1.1 作为 DNS 解析器的全球用户B. 影响时长约 1 小时 36 分钟（18:19 - 19:55 UTC）C. 影响系统Linux 系统中使用 glibc getaddrinfo 的应用三款 Cisco 以太网交换机的 DNSC 进程3. 严重程度P1 级故障（核心解析功能受损）二、事件时间线时间事件描述2025-12-02记录重排序代码引入 1.1.1.1 代码库2025-12-10变更发布到测试环境2026-01-07 23:48包含该变更的全球发布开始2026-01-08 17:40发布覆盖 90% 的服务器2026-01-08 18:19宣布故障2026-01-08 18:27开始回滚发布2026-01-08 19:55回滚完成，故障结束gantt title DNS CNAME 顺序故障时间线 dateFormat YYYY-MM-DD HH:mm axisFormat %m-%d section 开发阶段 代码变更引入 :done, 2025-12-02, 1d 发布到测试环境 :done, 2025-12-10, 1d section 生产部署 全球发布开始 :2026-01-07 23:48, 18h 90%部署完成 :2026-01-08 17:40, 1h section 故障处理 宣布故障 :crit, 2026-01-08 18:19, 8m 开始回滚 :crit, 2026-01-08 18:27, 88m三、问题分析1. 直接原因1.1.1.1 在优化缓存实现的内存使用时，改变了 CNAME 记录在 DNS 响应中的顺序，将 CNAME 记录从响应开头移到了末尾。2. 根本原因A. DNS CNAME 链的工作原理当查询如 www.example.com 的域名时，可能会得到 CNAME（规范名称）记录，表示一个名称是另一个名称的别名。公共解析器如 1.1.1.1 需要跟随这条别名链，直到获得最终响应：www.example.com → cdn.example.com → server.cdn-provider.com → 198.51.100.1CNAME 链中的每个记录都有自己的 TTL（生存时间），指示可以缓存多久。CNAME 链中的所有 TTL 不必相同：www.example.com → cdn.example.com (TTL: 3600 秒) # 仍在缓存 cdn.example.com → 198.51.100.1 (TTL: 300 秒) # 已过期当 CNAME 链中的一个或多个记录过期时，称为部分过期。由于链的部分仍在缓存中，无需重新解析整个 CNAME 链，只需重新解析已过期的部分。B. 代码逻辑变更合并这两条链的代码是变更发生的地方。之前的代码会创建一个新列表，插入现有的 CNAME 链，然后追加新记录：impl PartialChain { pub fn fill_cache(&self, entry: &mut CacheEntry) { let mut answer_rrs = Vec::with_capacity(entry.answer.len() + self.records.len()); answer_rrs.extend_from_slice(&self.records); // CNAME 在前 answer_rrs.extend_from_slice(&entry.answer); // 然后 A/AAAA 记录 entry.answer = answer_rrs; } }为了节省一些内存分配和复制，代码被改为将 CNAME 追加到现有答案列表：impl PartialChain { pub fn fill_cache(&self, entry: &mut CacheEntry) { entry.answer.extend(self.records); // CNAME 在后 } }结果是 1.1.1.1 返回的响应中，CNAME 记录有时会出现在底部，位于最终解析的答案之后。C. 为什么会导致解析失败某些 DNS 客户端实现通过在顺序遍历时跟踪记录的预期名称来处理 CNAME 链。当遇到 CNAME 时，预期名称会更新：正确的顺序：;; ANSWER SECTION: www.example.com.…

dog 命令行 DNS 客户端技术分析
type: item
date: 2026-01-17T07:48:01+00:00
description: dog 命令行 DNS 客户端技术分析一、概述1. 简介A. 是什么dog 是一个用 Rust 编写的命令行 DNS 客户端工具，类似于传统的 dig 工具，但提供了更现代的用户体验和更强大的功能。B. 为什么值得关注彩色输出让 DNS 查询结果更易读支持标准的命令行参数语法，学习曲线更平缓支持 DNS-over-TLS 和 DNS-over-HTTPS 加密查询协议可以输出 JSON 格式，便于与其他工具集成使用 Rust 编写，性能优异且内存安全C. 能做什么查询各类 DNS 记录（A、MX、NS、TXT 等）指定自定义 DNS 服务器进行查询通过 UDP、TCP、TLS 或 HTTPS 协议进行查询以彩色或 JSON 格式输出结果测量 DNS 响应时间二、核心特性1. 基本功能dog 提供了完整的 DNS 查询功能，支持所有常见的记录类型和网络类。2. 协议支持graph LR subgraph 传统协议 UDP[UDP] TCP[TCP] end subgraph 加密协议 DoT[DNS-over-TLS] DoH[DNS-over-HTTPS] end Client[dog客户端] --> UDP Client --> TCP Client --> DoT Client --> DoH UDP --> Server[DNS服务器] TCP --> Server DoT --> Secure[安全DNS解析] DoH --> Secure3. 输出格式默认彩色输出：易于阅读，自动高亮重要信息JSON 输出：便于脚本处理和与其他工具集成短格式：仅显示第一个结果三、安装方式1. 包管理器安装根据不同平台，可通过以下方式安装：Arch Linux：dog 包macOS Homebrew：dog formulaNixOS：dogdns 包2. 预编译二进制从 GitHub Releases 页面下载适用于 Windows、macOS 和 Linux 的预编译二进制文件。3. 从源码编译graph TD A[获取源码] --> B{选择编译选项} B -->|完整功能| C[cargo build] B -->|最小体积| D[cargo build --no-default-features] C --> E[编译完成] D --> E E --> F[复制到 PATH]前置要求：Rust 编译器 1.45.0 或更高版本推荐使用 rustup 安装 Rust编译命令：cargo build cargo test发布版本编译：cargo build --release # 或使用 just just build-release编译后的二进制文件位于 target/release 目录，建议复制到 /usr/local/bin 等 PATH 目录。四、功能特性开关dog 提供三个 Cargo 功能开关，默认全部启用：1. with_idna启用国际化域名支持，允许查询非 ASCII 字符的域名。2. with_tls启用 DNS-over-TLS 支持，通过 TLS 加密 DNS 查询。3. with_https启用 DNS-over-HTTPS 支持，通过 HTTPS 加密 DNS 查询（依赖 with_tls）。示例：仅保留 IDNA 支持，禁用 TLS 和 HTTPScargo build --no-default-features --features=with_idna可通过 --version 参数查看已禁用的功能列表。五、命令行参数1. 查询选项：人类可读的主机名、名称服务器、类型或类-q, --query=HOST：要查询的主机名或域名-t, --type=TYPE：DNS 记录类型（A、MX、NS 等）-n, --nameserver=ADDR：发送数据包的名称服务器地址--class=CLASS：DNS 记录的网络类（IN、CH、HS）2. 发送选项--edns=SETTING：是否选择使用 EDNS（disable、hide、show）--txid=NUMBER：将事务 ID 设置为特定值-Z=TWEAKS：设置不常见的协议级调整3. 协议选项-U, --udp：使用 UDP 上的 DNS 协议-T, --tcp：使用 TCP 上的 DNS 协议-S, --tls：使用 DNS-over-TLS 协议-H, --https：使用 DNS-over-HTTPS 协议4. 输出选项-1, --short：短模式，仅显示第一个结果-J, --json：以 JSON 格式显示输出--color, --colour=WHEN：何时为输出着色（always、automatic、never）--seconds：不格式化…

故障排除前先关闭这6个路由器默认设置
type: item
date: 2026-01-16T09:23:43+00:00
description: 故障排除前先关闭这6个路由器默认设置一、概述1. 文档背景随着家用路由器变得越来越强大，它们也配备了更智能的功能，让使用更加便捷，并为我们的联网设备提供更好的体验。但直到出现问题，你需要排查家庭网络故障时，这些高级功能反而可能成为阻碍，掩盖真正的问题根源。2. 核心观点在诊断网络问题时，应该暂时关闭这些默认功能，以便更清晰地了解问题所在。如果你的路由器有内容限制设置，如年龄限制或其他家庭限制，也应该关闭，或者至少在没有限制的新用户配置文件上进行测试。二、需要关闭的六大默认设置1. WPA3 安全协议A. 问题描述WPA3 是最新且最安全的 Wi-Fi 加密协议，使用 Wi-Fi 7 路由器或接入点时必须使用。尽管它在 2018 年就已获得认证，但仍存在大量兼容性问题，并非所有制造商都清除了其固件中的 bug。B. 问题根源许多问题源于 WPA2/WPA3 混合模式，该模式旨在让较老的无线设备在同一 SSID 上共存，但往往导致这些设备无法连接到接入点。C. 解决方案在故障排查时将设置更改为 WPA2。如果发现这样可以解决问题，就保持这种设置，或者考虑为仅支持 WPA3 的设备添加另一个 SSID。2. DNS 重绑定保护A. 功能说明对于大多数家庭网络来说，DNS 重绑定保护是一件好事，因为它可以防止攻击者将你的 DNS 请求重定向到受损的网站。简单来说，它阻止 DNS 查询由本地 IP 地址响应。B. 问题场景如果你在使用 ISP 的 DNS 服务器、Quad9 或任何其他互联网可达的服务器，这个功能很有用。但如果你在进行自托管，可能有一些想要使用的本地可解析域名，并且可能运行自己的 DNS 服务器、Pi-hole 或类似服务。C. 影响范围启用 DNS 重绑定时，Pi-hole 将无法作为 DNS 服务器工作，你的自托管域名也无法解析。如果注意到这些问题，请在路由器上禁用 DNS 重绑定保护。3. 服务质量（QoS）和流量整形A. 工作原理QoS、流量整形和 SQM 以类似的方式工作：通过各种优先级减少整个网络或单个设备的可用带宽。这可以防止一个视频流媒体设备占用所有可用容量。B. 排查问题在故障排查时，这些设置会给速度或延迟测试提供不准确的读数。C. 操作建议关闭这些功能进行故障排查，并记录测试的最大上传和下载速度，这些将是之后重新设置 QoS 时使用的上限值。4. 频段引导A. 设计理念频段引导是一个很棒的功能，它使用各种技巧将客户端设备推送到最适合它们的 2.4GHz、5GHz 或 6GHz 频段，并尽可能让它们保持在那个频段上。B. 实际问题它经常让设备在较低范围的 5GHz 或 6GHz 频段上停留太久，而切换到 2.4GHz 频段会因距离路由器的距离而提供更稳定的连接。这通常看起来像随机的断开连接，但实际上并非如此。C. 解决方案制造商固件优化通常可以解决这个问题，但在故障排查时关闭它可以揭示它不适合你的家庭网络配置。5. UPnP 和 NAT-PMPA. 功能说明UPnP 和 NAT-PMP 都是允许设备自动打开防火墙端口的方式。B. 安全风险显式控制允许哪些端口通过你的防御对网络来说更好，建议应该一直关闭这些功能。C. 替代方案现代设备和软件已经设计了其他处理连接性的方法，不需要永久打开端口。D. 排查建议如果在故障排查时注意到这些功能已启用，请关闭它们并保持关闭状态。它们只会掩盖端口转发的问题或创建你不知道的安全漏洞。6. 空中时间公平性A. 设计初衷Wi-Fi 路由器倾向于优先考虑向后兼容性而非性能，使你在每次将路由器升级到新的 Wi-Fi 版本时不必升级所有设备。但这可能会导致你拥有的最新设备出现问题。B. 工作机制空中时间公平性旨在防止更快的客户端占用所有带宽，确保物联网设备和其他不支持更高性能 Wi-Fi 模式的设备有足够的空中时间。C. 实际影响在实践中，它会在连接的设备数量之间分割广播电波上的空中时间。这对你笔记本电脑或手机等快速设备的影响较小，但可能会让你的智能家居设备传输数据的时间更长。D. 性能代价这需要更多的处理能力，如果你的路由器已经过载，这可能成为一个问题。E. 解决方案如果发现那些慢设备是罪魁祸首，将它们移动到自己的网段、SSID 或 VLAN 会有所帮助，这样它们就不会与你拥有的快速通道设备混在一起。graph TD A[网络故障排查] --> B{问题类型?} B --> C[连接问题] B --> D[速度问题] B --> E[自托管问题] B --> F[设备兼容性] C --> C1[关闭 WPA3 使用 WPA2] C --> C2[关闭频段引导] D --> D1[关闭 QoS] D --> D2[关闭空中时间公平性] E --> E1[关闭 DNS 重绑定保护]…

Round Robin DNS 工作原理与实践分析
type: item
date: 2026-01-16T08:54:22+00:00
description: Round Robin DNS 工作原理与实践分析一、概述1. 背景Round Robin DNS 是一种简单而优雅的负载均衡解决方案。通过在 DNS 记录中配置多个 IP 地址，可以让流量自动分散到不同的服务器上。这种方法无需昂贵的负载均衡设备，适用于需要全球分布式部署的服务。2. 核心问题虽然 Round Robin DNS 的概念简单，但实际使用中存在几个关键问题：客户端如何选择服务器如何实现就近接入（低延迟）服务器离线时如何故障转移CDN 服务器的行为是否符合预期3. 实验设计作者在全球部署了 3 个 VPS（美国、欧洲、新加坡），分别配置了直连和 Cloudflare 代理的 A 记录，通过不同客户端测试其选择行为。二、Round Robin DNS 基本原理1. 传统 DNS 配置传统的单一 A 记录配置如下：域名 类型 TTL 值 rr-direct.example.com A 300 5.223.46.55这种配置下，所有请求都指向单一服务器。2. Round Robin DNS 配置Round Robin DNS 配置多个 A 记录指向同一域名：域名 类型 TTL 值 rr-direct.example.com A 300 5.223.46.55 rr-direct.example.com A 300 1.2.3.4 rr-direct.example.com A 300 9.8.7.63. 工作原理graph LR A[客户端] -->|1. DNS 查询| B[DNS 服务器] B -->|2. 返回 IP 列表 5.223.46.55 1.2.3.4 9.8.7.6| A A -->|3. 客户端选择| C{选择策略} C -->|Ping 测试| D[延迟最低] C -->|随机选择| E[第一个 IP] C -->|IP Hash| F[固定 IP] D --> G[连接服务器 1] E --> H[连接服务器 2] F --> I[连接服务器 3]三、理论标准：RFC 8305 Happy Eyeballs1. 标准概述RFC 8305（Happy Eyeballs）定义了客户端在连接前应如何对地址进行排序。关键规则是：如果客户端是有状态的，并且具有访问每个地址的路由的历史往返时间（RTT），它应该在规则 8 和 9 之间添加目标地址选择规则，优先选择具有较低 RTT 的地址。2. 理论流程sequenceDiagram participant C as 客户端 participant D as DNS 服务器 participant S1 as 服务器 1（近） participant S2 as 服务器 2（远） participant S3 as 服务器 3（极远） C->>D: DNS 查询 D-->>C: 返回 IP 列表 Note over C: 检查服务器在线状态 C->>S1: Ping/连接测试 C->>S2: Ping/连接测试 C->>S3: Ping/连接测试 Note over C: 按 RTT 排序 C->>S1: 连接延迟最低的服务器3. 理论总结检查服务器在线/离线状态对在线服务器按 Ping 时间排序选择延迟最低的服务器四、客户端行为实测1. 测试环境客户端位置：欧洲服务器分布：美国（绿色）、欧洲（蓝色）、新加坡（红色）预期：应该连接到延迟最低的欧洲服务器（蓝色）2. Chrome 浏览器行为特征：启动时随机选择一个服务器选择后会保持连接（缓存）数小时后才会重新评估可能连接到延迟最高的服务器（如新加坡）问题：不考虑地理位置和延迟，可能导致性能极差。3. Firefox 浏览器行为特征：与 Chrome 类似启动时随机选择重启浏览器后重新随机选择问题：同样不考虑延迟。4. Safari 浏览器行为特征：总是正确选择最近的欧洲服务器服务器离线后能快速恢复到正确选择表现最符合理论预期优势：实现了智能的延迟感知选择。5. curl 命令行工具行为特征：第一次可能不准确第二次运行时总是选择最近的服务器行为正确且可预测graph LR A[curl 第一次请求] --> B{DNS 结果顺序} B --> C[使用第一个 IP] C --> D[测量 RTT] D --> E[curl 第二次请求] E --> F[选择最低 RTT 的 IP]五、Cloudflare 行为分析1. 行为特征正常情况：根据客户端 IP 哈希选择服务器一旦选择后保持固定（类似 client_ip_hash modulo server_num）每个客户端 IP 总是连接到同一个服务器不考虑延迟和地理位置问题示例：家庭 IP 固定连接到美国服务器使用移动热点后固定连接到欧洲服务器全球各地的 VPS …