运维123 - DNS
type: channel
link: https://www.sddts.cn/index.php/tag/DNS/
items: .online 域名被封禁引发的死循环故障复盘
items: 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 客户端技术分析

.online 域名被封禁引发的死循环故障复盘
type: item
date: 2026-02-25T15:12:07+00:00
description: .online 域名被封禁引发的死循环故障复盘一、事件概述1. 事件背景作者在 Namecheap 的促销活动中免费获得了一个 .online 顶级域名，用于托管一个小型浏览器项目。几周后发现该域名完全无法访问，被标记为不安全网站。2. 影响范围A. 影响用户数项目刚上线，用户量极小，实际影响有限B. 影响时长从发现到最终解决，持续数小时（文章发布后 40 分钟内得到解决）C. 影响功能整个网站无法访问，DNS 解析完全失效3. 严重程度P3 级故障（非核心业务，但域名完全无法使用）二、事件时间线1. 故障发生（时间：不明）A. 现象描述域名突然无法解析，访问时显示全屏红色警告"这是一个不安全的网站"B. 监控告警无监控告警，作者是在检查其他域名流量数据时偶然发现2. 问题发现（时间：几周后）A. 发现途径查看流量数据时发现过去 48 小时零访问量B. 初步判断可能是域名被标记或挂起3. 排查过程A. 检查 CloudflareCloudflare 仍正常激活，Worker 指向正确B. 检查注册商域名在 Namecheap 账户中正常显示，过期日期正确，域名服务器配置正确C. DNS 查询dig NS getwisp.online +short返回为空，解析完全失败D. WHOIS 查询状态显示：serverHold4. 深入调查A. 联系注册商Namecheap 回复：域名是由注册局（registry）挂起的，不是他们。注册局通常因为域名涉及滥用操作而挂起域名。B. 联系注册局 RadixRadix 回复：域名因在 Google Safe Browsing 黑名单上而被暂停。需要按照列表页面上的说明申请移除。sequenceDiagram participant U as 用户 participant N as Namecheap participant R as Radix(注册局) participant G as Google U->>N: 发现域名无法访问 N->>U: 域名由注册局挂起 U->>R: 询问挂起原因 R->>U: 因Google黑名单而暂停 U->>G: 申请移除黑名单 G->>U: 需验证域名所有权 U->>U: 无法验证（域名不解析） Note over U,G: 死循环5. 解决尝试A. Google Safe Bleaning 报告在多个渠道提交误报报告，但无进展B. Google Search Console需要通过 DNS TXT 或 CNAME 记录验证域名所有权，但域名不解析无法添加记录C. Safe Search 团队审核提交审核请求，但收到"未提交有效页面"的错误D. 注册局临时释放向注册局申请临时释放以便 Google 审核内容6. 最终解决A. HN 发布将故事发布到 Hacker NewsB. Google 响应发布后 40 分钟内，域名从 Google Safe Search 黑名单中移除C. 域名恢复域名恢复正常访问三、问题分析1. 直接原因域名被 Google Safe Browsing 误标记为不安全网站，注册局 Radix 据此暂停了域名2. 根本原因（5 Whys 分析）A. 为什么域名被标记？原因不明，可能是有人恶意举报或算法误判B. 为什么注册局立即暂停？Radix 对 .online 等新顶级域名采取"零容忍"策略，一旦被标记立即暂停C. 为什么无法解除？Google 要求验证域名所有权才能审核，但域名暂停无法解析，形成死循环D. 为什么没有通知？注册商和注册局都没有发送任何通知邮件E. 为什么没有监控？作者没有添加域名到 Google Search Console，也没有配置监控3. 深层反思新顶级域名的注册机制存在严重缺陷Google 和注册局的审核流程缺乏沟通机制用户在域名管理上的疏忽加剧了问题四、解决方案1. 临时方案A. 社区发声在 Hacker News 等社区发布经历，引起关注B. 多渠道申诉向 Google Safe Browsing、Safe Search 多个渠道提交申诉2. 永久方案A. 避免 .online 域名回归 .com 黄金标准，不再使用新顶级域名B. 立即验证新域名注册后立即添加到 Google Search ConsoleC. 监控告警配置域名监控和可用性告警3. 预防措施注册新域名后立即配置所有必要的验证和监控选择可靠的注册商和顶级域名定期检查域名状态graph TB A[注册新域名] --> B[选择可靠TLD] B --> C[立即添加到GSC] C --> D[配置DNS验证] D --> E[设置监控告警] E --> F[定期检查状态]五、经验总结1. 做得好的地方彻底排查了问题根源尝试了多种解决途径通过社区…

DNS域名系统详解教程
type: item
date: 2026-02-07T22:53:01+00:00
description: DNS 域名系统详解教程一、概述1. 简介A. 是什么DNS（Domain Name System，域名系统）是互联网的核心基础设施，负责将人类可读的域名转换为机器可识别的 IP 地址。当用户在浏览器中输入 example.com 时，DNS 系统会解析出对应的 IP 地址 93.184.216.34，使浏览器能够建立连接。B. 为什么学理解互联网基础设施的工作原理掌握域名解析和故障排查技能优化网站性能和可用性保障电子邮件系统的正常运行C. 学完能做什么配置和管理 DNS 记录排查 DNS 解析问题优化 DNS 传播时间理解负载均衡和高可用架构2. 前置知识A. 必备技能基本 IP 地址概念（IPv4、IPv6）命令行操作基础B. 推荐知识网络基础知识Web 服务器概念二、核心概念1. DNS 层级结构DNS 采用分层架构，类似 referrals 链条。每一层只知道自己下一层的信息，没有单一实体掌握全部信息。graph TD A[Root 根服务器 .] --> B[TLD 顶级域名服务器 .com] A --> C[TLD 顶级域名服务器 .org] A --> D[TLD 顶级域名服务器 .io] B --> E[权威域名服务器 example.com] B --> F[权威域名服务器 google.com] E --> G[子域名 api.example.com] E --> H[子域名 mail.example.com]A. Root（根服务器）全球共有 13 个根服务器集群，由 Verisign、ICANN、NASA 等组织运营。根服务器不直接知道任何域名地址，但知道所有 TLD 服务器的位置，是 DNS 查询的起点。B. TLD（Top Level Domain，顶级域名）域名的最后一部分，如 .com、.org、.io、.dev。TLD 服务器知道其下注册的所有域名。常见 TLD 类型：.com：商业用途，任何人均可注册.org：组织机构.net：网络服务.io：英属印度洋领地（科技行业热门）.dev：开发者（强制 HTTPS）.gov：美国政府专用.edu：教育机构C. Domain（域名）从注册商购买的实际名称，如 example、google、github。与 TLD 组合形成完整域名 example.com。常用注册商包括 Namecheap、GoDaddy、Cloudflare。D. Subdomain（子域名）域名前的任何部分，如 api.example.com、mail.example.com、staging.example.com。子域名可免费无限创建，通过 DNS 记录配置。三、DNS 记录类型1. A 记录将域名映射到 IPv4 地址，是最常用的记录类型。example.com A 93.184.216.34当用户请求 example.com 时，DNS 返回 93.184.216.34。2. AAAA 记录将域名映射到 IPv6 地址。名称源于四个 A（IPv6 地址长度是 IPv4 的四倍）。example.com AAAA 2606:2800:220:1:248:1893:25c8:19463. CNAME（Canonical Name，规范名称）将域名指向另一个域名，而非 IP 地址。常用于第三方服务集成。www.example.com CNAME example.com blog.example.com CNAME example.ghost.io使用场景：将子域名指向托管服务（Ghost、GitBook 等），无需管理其 IP 地址。4. MX（Mail Exchange，邮件交换）指定域名的邮件服务器地址。优先级数字越小，优先级越高。example.com MX 10 mail1.example.com example.com MX 20 mail2.example.com当发送邮件至 hello@example.com 时，邮件服务器查询 MX 记录。若 mail1（优先级 10）不可用，则尝试 mail2（优先级 20）。5. TXT 记录存储文本信息，用于多种验证和安全场景。example.com TXT "v=spf1 include:_spf.google.com ~all" example.com TXT "google-site-verification=abc123xyz"常见用途：域名所有权验证：Google、Stripe、AWS 要求添加 TXT 记录SPF：指定哪些服务器可代表该域名发送邮件（防止伪造）DKIM：使用加密签名进行邮件认证DMARC：定义 SPF/DKIM 检查失败的处理策略四、TTL（Time To Live，生存时间）1. TTL 作用T…

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：不格式化…