后端网络云原生【免费下载链接】corednsCoreDNS is a DNS server that chains plugins项目地址https://gitcode.com/gh_mirrors/co/coredns点击查看免费下载导读CoreDNS 1.9.2 是 2022 年 5 月发布的一个以安全修复与功能增强为核心的版本最大的亮点是引入了 Trail of Bits 的第三方安全审计并修复了审计发现的问题包括 cache 插件的缓存投毒漏洞同时为 cache 的serve_stale增加了immediate/verify刷新模式、为 forward 健康检查增加了可配置域名、为 geoip 增加了 EDNS0 子网来源 IP 读取等多项实用能力。本文以官方发布说明 notes/coredns-1.9.2.md 为主体结合当前仓库源码逐项展开帮助你理解每个变更的语法、行为与底层实现并能在实际 Corefile 中直接使用这些新特性。版本概览一次以安全为基调的发布This is a release with many added features and security and bug fixes. The most notable one is the release of 3rd party security audit from Trail of Bits. Security issues discovered by this audit have all been fixed or covered.按发布说明的定位1.9.2 是一个集新特性、安全修复与缺陷修复于一体的版本其中最值得关注的是来自Trail of Bits的第三方安全审计审计发现的安全问题在该版本中已全部修复或覆盖。这意味着从 1.9.2 起CoreDNS 的官方第三方安全审计方列表新增了 Trail of Bitscore 层面变更对应 PR 5356。本版本由以下贡献者共同完成Antoine Tollenaere、Balazs Nagy、Chris OHaver、dilyevsky、hansedong、Lorenz Brun、Marius Kimmina、nathannaveen、Ondřej Benkovský、Patrick W. Healy、Qasim Sarfraz、xuweiwei、Yong Tang。版本同时包含一处与安全相关的核心层改进避免使用伪随机数对应 PR 5228。这一改动同样被应用到 route53 插件直接触发了该插件对 Corefile 中明文密钥的弃用详见下文。安全审计与核心层修复避免伪随机数为安全审计打下的地基发布说明中的 core: avoid usage of pseudo-random numberPR 5228是安全审计整改的一部分。在 DNS 服务中若随机数可被预测可能被用于缓存投毒、事务 ID 猜测等攻击。1.9.2 在核心层移除了对伪随机数的依赖改用更安全的随机来源从源头降低了随机性可被猜测的风险。修复 cache 插件的缓存投毒漏洞plugin/cache: fix cache poisoning exploit (PR 5174)这是本次审计修复中最关键的一项。cache 插件此前存在缓存投毒cache poisoning漏洞——攻击者可通过精心构造的请求/响应组合让缓存中写入与其请求问题名不匹配的应答从而毒化其他用户的查询结果。修复后的 cache 插件会严格校验请求与响应的问题名question name一致性不匹配的响应会被拒绝进入缓存。这一行为在当前源码中有迹可循cache 插件提供coredns_cache_drops_total{server, zones, view}指标其语义正是 Counter of responses excluded from the cache due to request/response question name mismatch见 plugin/cache/README.md即因请求/响应问题名不匹配而被排除出缓存的响应计数。这条指标的存在与 1.9.2 的投毒修复一脉相承运维上可以借此监控是否有异常的不匹配响应被丢弃。cache 插件serve_stale 新增刷新模式immediate / verify背景什么是 serve_stalecache 插件的serve_stale允许在缓存条目过期后仍向客户端返回过期数据RFC 8767 场景默认在返回过期应答后再异步刷新缓存。1.9.2 之前该行为是固定的本次PR 5131为serve_stale引入了REFRESH_MODE刷新模式即immediate与verify两种可选策略用于控制过期条目刷新的时机。完整语法如下cache [TTL] [ZONES...] { serve_stale [DURATION] [immediate [RESPONSE_TTL [FAILURE_RECHECK]] | verify [VERIFY_TIMEOUT [RESPONSE_TTL [FAILURE_RECHECK]]]] }参数语义当前 plugin/cache/README.md 已同步DURATION过期条目最长可被继续服务的时长默认 1 小时1h。REFRESH_MODEverify会先向上游验证条目确实不可用再向客户端返回过期条目immediate则先立即把过期条目发给客户端再在后台检查上游。默认值是immediate。设为verify会带来更高的过期应答延迟但能避免在上游明明有新数据时仍发出过期应答。VERIFY_TIMEOUT仅verify模式有效限制等待上游验证的超时时间0表示一直等到上游自身超时。验证在超时后仍会在后台继续并刷新缓存后续查询即可拿到新条目。示例serve_stale 1h verify 100ms。RESPONSE_TTL过期应答返回给客户端的 TTL默认 0向后兼容。RFC 8767 要求过期应答 TTL 大于 0并推荐 30s。示例serve_stale 1h immediate 30s、serve_stale 1h verify 100ms 30s、serve_stale 1h verify 0 30s用 0 表示等上游超时同时设置应答 TTL。FAILURE_RECHECK跟随RESPONSE_TTL限制同一缓存条目在刷新失败后多久可被再次尝试刷新进行中或处于失败重查窗口期内时直接返回过期条目不再发起上游请求。默认 0 保持原有重试行为RFC 8767 推荐 30s 且不超过 5 分钟。示例serve_stale 1h immediate 30s 30s、serve_stale 1h verify 100ms 30s 30s。源码级的解析逻辑当前仓库 plugin/cache/setup.go 中的解析逻辑与发布说明完全对应serve_stale分支最多接受 5 个参数staleUpTo默认1h、staleTTL与staleRecheck默认 0第二个参数会转为小写后与immediate/verify比较非法值直接报错invalid value for serve_stale refresh modesetup.go L201-207。随后按模式分别解析 VERIFY_TIMEOUT仅 verify、RESPONSE_TTL 与 FAILURE_RECHECK且对负数超时、非法 TTL 均会拒绝。测试用例同样覆盖了这些组合见 plugin/cache/setup_test.goserve_stale 1h immediate 30s # 合法 serve_stale 1h immediate 30s 30s # 合法 serve_stale 1h verify 100ms # 合法 serve_stale 1h verify 100ms 30s 30s # 合法 serve_stale 1h immediate 100ms # 非法immediate 模式下第三参数只能是整秒 TTL serve_stale 1h immediate -1s # 非法负值 serve_stale 1h immediate garbage # 非法无法解析forward 插件健康检查支持可配置域名plugin/forward: configurable domain support for healthcheck (PR 5281)forward 插件对上游的健康检查默认使用根域.作为探测域名。1.9.2 允许通过domain参数自定义健康检查使用的FQDN语法为forward FROM TO... { health_check DURATION [no_rec] [domain FQDN] }参数说明见 plugin/forward/README.mdDURATION健康检查间隔默认 0.5s。no_rec可选将健康检查 DNS 查询的 RecursionDesired 标志置为false默认为true。domain FQDN可选设置健康检查使用的域名默认是.。例如. { forward . 10.0.0.1:53 { health_check 5s domain example.org } }实现上forward 插件通过HCDomain为健康检查请求设置探测域名见 plugin/forward/forward.gosetup 中对domain参数做 FQDN 合法性校验非法域名会报错health_check: invalid domain name见 plugin/forward/setup.go。相关的解析与校验行为在 plugin/forward/resolve_test.go 中有对应测试如health_check 5s domain example.org.期望健康检查域名为example.org.。geoip 插件从 EDNS0 子网读取来源 IPplugin/geoip: read source IP from EDNS0 subnet if provided (PR 5183)geoip 插件通过 metadata 机制把请求来源 IP 的地理位置city与 ASN 信息注入请求上下文供下游插件消费。1.9.2 之前它只使用 TCP/UDP 连接的真实源 IP现在PR 5183当请求携带EDNS0 Client SubnetECSRFC 7871选项时优先用 ECS 中携带的地址作为查询 IP更适合解析器/递归器转发场景下按客户端真实位置做地域分发。当前源码 plugin/geoip/geoip.go 中Metadata方法的实现先解析state.IP()若开启了edns0开关则遍历请求的 EDNS0 选项找到*dns.EDNS0_SUBNET后将其地址作为srcIP随后分别对 city、asn 数据库执行查询并写入 metadataif g.edns0 { if o : state.Req.IsEdns0(); o ! nil { for _, s : range o.Option { if e, ok : s.(*dns.EDNS0_SUBNET); ok { if addr, ok : netip.AddrFromSlice(e.Address); ok { srcIP addr } break } } } }该开关由 setup 解析见 plugin/geoip/setup.go测试通过构造带dns.EDNS0_SUBNET的请求验证读取行为见 plugin/geoip/geoip_test.go。注意ECS 选项本身并没有标准定义的固定掩码长度实际部署中应由上游解析器决定发送的前缀长度可参考 RFC 7871。health 插件overloaded 协程支持优雅退出plugin/health: rework overloaded goroutine to support graceful shutdown (PR 5244)health 插件的overloaded功能会周期性地请求自身健康端点统计健康检查耗时与失败次数。1.9.2 对其内部 goroutine 进行了重构使其在 CoreDNS 关闭时能够优雅退出避免退出过程中残留 goroutine 或资源泄漏。从当前源码 plugin/health/overloaded.go 可以看到重构后的结构goroutine 持有context.Context通过time.NewTicker(1 * time.Second)周期发起请求同时监听ctx.Done()当父级 context 被取消例如插件关闭时立即返回且每次请求失败时若检测到ctx.Err() context.Canceled也会直接退出从而保证 shutdown 路径干净利落。该协程同时维护两条指标coredns_health_request_duration_seconds每次请求 /health 端点的耗时直方图coredns_health_request_failures_total健康检查失败次数计数。k8s_external 插件AA 位与 TC 位修复1.9.2 对 k8s_external 插件有两处协议层面的修复设置权威位PR 5284k8s_external 此前生成的应答未设置 AAAuthoritative位1.9.2 起所有由该插件直接生成的响应都会置位。当前源码 plugin/k8s_external/external.go 中m.Authoritative trueapex 应答同样如此见 plugin/k8s_external/apex.go测试也在断言resp.Authoritative为真。透传 TC 位PR 4716当上游查询如 A/AAAA 解析返回截断TC 置位时k8s_external 会把这个截断状态透传给客户端而不是吞掉。源码中m.Answer, m.Truncated e.a(ctx, svc, state)将查询阶段的截断标志直接写入应答消息见 plugin/k8s_external/external.go客户端收到 TC1 后可以自行改用 TCP 重试保证大数据量应答不被静默截断。kubernetes 插件修复启动超时 tickerplugin/kubernetes: fix k8s start up timeout ticker (PR 5361)kubernetes 插件在启动时会等待 Kubernetes API 的 informer 缓存同步sync并受startup_timeout DURATION限制默认为 1m见 plugin/kubernetes/README.md。1.9.2 修复了启动超时 ticker 的问题——此前的实现可能无法在超时后正确放行或产生错误的时间行为。当前源码 plugin/kubernetes/kubernetes.go 中的onStart回调展示了修复后的三重 ticker 协作checkSyncTicker100ms 间隔轮询APIConn.HasSynced()一旦同步完成立即返回logTicker500ms在等待期间周期性输出 waiting for Kubernetes API before starting servertimeoutTicker即startupTimeout到期后记录警告 starting server with unsynced Kubernetes API 并放行启动。三个 ticker 均通过defer ticker.Stop()确保退出时被正确释放这正是本次修复的核心——超时逻辑不再出现 ticker 泄漏或误触发。etcd 插件修复多记录 TXT 查询plugin/etcd: fix multi record TXT lookups (PR 5293)etcd 插件支持以 etcd 为后端存储 DNS 数据。1.9.2 修复了同一名称对应多条 TXT 记录时查询结果不正确的问题。etcd 插件的数据模型中TXT 记录是一类特殊的服务条目当查询类型为 TXT 且服务条目的Text字段非空时可直接解析为 TXT 记录见 plugin/etcd/etcd.go 中关于 TXT 解析条件的注释。修复前多记录 TXT同一键下多条文本在查询时可能只返回其中一条或解析错乱修复后可按 etcd 中存储的多条 TXT 数据完整返回。相关测试覆盖了cname3.region3.skydns.test. 300 IN TXT SOME-RECORD-TEXT这类带 CNAME 与 TXT 组合的查询场景见 plugin/etcd/cname_test.go。route53 插件弃用明文密钥并扩展 AWS 凭据配置1.9.2 对 route53 插件有两项重要调整弃用 Corefile 中的明文 secretPR 5228aws_access_key AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY选项被标记为Deprecated未来版本可能移除。官方建议改用环境变量AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY或 AWS 标准凭据链环境变量、共享凭据文件、必要时共享配置文件、最后 EC2 实例角色。该弃用说明已同步进 plugin/route53/README.md。扩展 AWS 配置/凭据设置PR 5370新增credentials PROFILE [FILENAME]选项可为指定 zone 覆盖共享凭据文件名与 Profile 名称——PROFILE默认defaultFILENAME默认~/.aws/credentials默认只加载共享凭据文件设置环境变量AWS_SDK_LOAD_CONFIG为真值后可同时加载~/.aws/config例如用于 IAM 角色扮演配置。aws_endpoint选项则用于覆盖 AWS API 端点。当前语法route53 [ZONE:HOSTED_ZONE_ID...] { aws_access_key [AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY] # Deprecated aws_endpoint ENDPOINT credentials PROFILE [FILENAME] fallthrough [ZONES...] refresh DURATION }使用示例example.org { route53 example.org.:Z1Z2Z3Z4DZ5Z6Z7 { credentials myprofile ~/.aws/credentials refresh 3m } }template 插件修正 rcode 选项文档plugin/template: fix rcode option documentation (PR 5328)template 插件用于根据模板动态生成应答。1.9.2 修正了其rcode选项的文档描述使文档与实际行为一致此前文档对 rcode 参数的说明存在偏差。这是一处纯文档修复不影响语法本身但提醒使用者在自定义 rcode 时应以当前版本文档为准。迁移与升级建议安全优先建议所有使用 CoreDNS 1.9.2 之前版本的用户尽快升级以覆盖 Trail of Bits 审计发现的安全问题尤其是 cache 投毒漏洞。route53 用户若 Corefile 中仍在使用aws_access_key请尽快迁移到环境变量或credentials选项避免未来版本移除后配置失效。cache 用户serve_stale的刷新模式默认仍为immediate向后兼容若希望在上游可恢复时绝不返回过期数据可显式配置serve_stale 1h verify并搭配RESPONSE_TTL 30s以符合 RFC 8767 建议。k8s_external 用户升级后应答会正确携带 AA 位与 TC 位客户端解析行为将更符合 DNS 协议预期无需额外配置。总结CoreDNS 1.9.2 在“安全审计修复”的基调下同时为 cache、forward、geoip、health、k8s_external、kubernetes、etcd、route53、template 九个插件带来了实质性的功能或修复。其中serve_stale的immediate/verify刷新模式、forward 健康检查域名、geoip 的 EDNS0 子网支持都是可以直接写入 Corefile 投入生产的新能力而 cache 投毒漏洞修复与伪随机数移除则为整个 1.9.x 系列的安全基线树立了新标杆。各变更对应的源码实现与测试用例均已同步在当前仓库中可自行深入阅读验证。赞分享后端网络云原生【免费下载链接】corednsCoreDNS is a DNS server that chains plugins项目地址https://gitcode.com/gh_mirrors/co/coredns点击查看免费下载相关推荐RabbitMQ 3.6.1 维护版发布详解安全修复、核心缺陷修复与生态插件增强全解析RabbitMQ 3.6.1 维护版发布详解安全修复、核心缺陷修复与生态插件增强全解析 RabbitMQ 3.6.1 是 3.6 系列的首个维护版本main后端消息队列消息路由EMQX MQTT Bridge 新增 retain_as_published 订阅选项保留上游 Retained 消息的 retain 标志EMQX MQTT Bridge 新增 retain_as_published 订阅选项保留上游 Retained 消息的 retain 标志 导读 本文基于后端网络云原生Grafana Pyroscope 1.15 版本发布详解增强、修复与安全更新全解析Grafana Pyroscope 1.15 版本发布详解增强、修复与安全更新全解析 导读 本文以 docs/sources/release notes/v1可观测性性能剖析后端运维观测上一篇ChatTTS-ui终极指南3分钟搞定本地文字转语音部署下一篇Fritzing终极指南零基础快速掌握电子电路设计创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考