搜索结果: "dns"

title: Kubernetes CoreDNS 自定义域名解析 — 五种场景从原理到生产实操

tags: [kubernetes, dns, networking, troubleshooting, production]

- raw/articles/wechat-Kubernetes CoreDNS 实现自定义域名解析：从原理到生产实操.md

# Kubernetes CoreDNS 自定义域名解析

> **核心思路：** 不要把 DNS 当成零碎配置，而是当成集群流量治理的一部分。CoreDNS 把"域名该怎么被解析"变成一套集中、可审计、可回滚的规则。

title: K8s DNS 间歇性解析超时 5s 排查：conntrack 竞态与 ndots 放大

tags: [kubernetes, dns, troubleshooting, networking, case-study, production]

- raw/articles/K8s-DNS-间歇性解析超时-5s-的终极排查之路.md

# K8s DNS 间歇性解析超时 5s 排查

> **一句话复盘：** Pod 访问外部域名偶发 `dial tcp: lookup api.example.com: i/o timeout`，超时稳定卡在 5s（glibc resolver 默认 timeout）。根因并非 CoreDNS 繁忙，而是 **DNS UDP 请求经过 kube-proxy iptables 转发时，conntrack 发生竞态丢包，加上 ndots:5 放大了请求量**。组合方案：NodeLocal DNSCache + ndots 调优。

title: K8s DNS 故障排查实战：iptables 封禁 53 端口引发的 DNS 雪崩

tags: [kubernetes, dns, iptables, troubleshooting, networking, production]

- raw/articles/一条错误的iptables规则-干翻了整个K8s集群DNS-附完整排查过程.md

# K8s DNS 故障排查实战：iptables 封禁 53 端口引发的 DNS 雪崩

> **一句话复盘：** 运维安全加固脚本误加了一条 `iptables -A OUTPUT -p udp --dport 53 -j DROP`，导致 DNS 上游转发失败 → CoreDNS 超时积压崩溃 → 全集群 DNS 解析不可用。从症状到根因，层层递进排查了 76 分钟。

title: Service 与网络排障 — Endpoints / DNS / kube-proxy / CNI / NetworkPolicy / Ingress

tags: [kubernetes, troubleshooting, service, networking, ingress, cni, dns]

## DNS 解析异常

# 检查 CoreDNS Pod

kubectl get pods -n kube-system -l k8s-app=kube-dns

title: DNS 故障排查实战指南 — 从本地解析到权威 DNS 全链路

tags: [dns, networking, linux, troubleshooting, command]

sources: [raw/articles/DNS-故障排查实战-为什么你的域名突然-quot-解析不了-quot.md]

# DNS 故障排查实战指南

> DNS 是逐级缓存、多层转发、分布式协作的系统。问题根因可能出在本地 resolver、递归 DNS、权威 DNS、域名注册商、CDN 调度等任何一环。排查核心：**分阶段定位，从本地到远端，从客户端到服务器。**

| ③ | 内网 DNS 无法解析 | 中（服务不可用） | 高 |

### 坑三：内网 DNS 无法解析

**现象：** 宿主机能 ping 通内网域名（如 `redis-master.internal`），容器内 ping 不通；容器能解析公网 DNS 但无法解析内网域名。

**原理：** Docker 默认使用内置 DNS 服务（127.0.0.11），它知道容器内部域名但不知道宿主机网络中的自定义 DNS 记录。

# 方式一：运行时指定 DNS

### 1. DNS 解析异常

# 检查 CoreDNS

kubectl get pods -n kube-system -l k8s-app=kube-dns

kubectl logs -n kube-system -l k8s-app=kube-dns -c coredns

# 重启 CoreDNS

> **排查网络故障的核心逻辑：** 先打通物理层 → 数据链路层 → 网络层 → 传输层 → 应用层，逐层递进。搞清楚 IP、掩码、网关、路由、DNS、防火墙这几个概念，80% 的网络问题能在 5 分钟内定位。

nslookup 域名 → 失败：DNS 问题

nslookup / dig +short # 查 DNS

### 案例 4：DNS 正常但无法访问

| [[dns-troubleshooting-practical-guide]] | DNS 故障排查指南 |

### ③ 本机排查：IP / 网卡 / 路由 / DNS

**DNS 解析：**

经典故障：IP 能 ping 通，域名 ping 不通 → 这是 DNS 问题，不是网络问题。

本机 IP、路由、DNS 都正常但服务访问不了？八成是防火墙。

| DNS | `nslookup www.baidu.com` | 测试 DNS |

| 7 | 应用层 | 各种应用软件 | HTTP, FTP, SMTP, DNS |

### 22. DNS 解析流程

浏览器 → hosts 文件 → 本地 DNS 缓存 → DNS 服务器

→ 根域名服务器 → 顶级域服务器 → 权威 DNS → 返回 IP

常见记录类型：A（IPv4）、AAAA（IPv6）、CNAME（别名）、NS（DNS 服务器）、MX（邮件）、TXT（文本/SPF）。

| **ExternalName** | DNS CNAME | DNS 解析 | 外部服务映射 |

| 网络标识 | 无 | 稳定 DNS（xxx-0.svc.ns.svc.cluster.local） |

Pod → DNS 查询 (my-svc.default.svc.cluster.local)

→ CoreDNS 解析

### DNS 命名规范

tags: [kubernetes, troubleshooting, service, pod, ingress, networking, cni, dns]

> 记住口诀：**先 Pod 再 Svc，EP 不为空则网络通；Ingress 有问题先看日志，DNS 不通查 CoreDNS。**

Pod 内进程访问 `http://service-name.namespace.svc.cluster.local:port` → CoreDNS 解析为 Service IP → kube-proxy 拦截并 DNAT 转发到后端某个 Endpoint IP。

- DNS 解析是否正常（CoreDNS 日志、ndots 配置）

# 1. DNS 解析测试

| 网络标识 | 通过 Service 负载均衡访问 | 每个 Pod 有固定 DNS 名称 |

即使 Pod 被删除重建，新 Pod 继承同一名称和序号，DNS 记录自动更新指向新 IP。

Headless Service 不做负载均衡，DNS 查询 `my-headless-svc` 返回所有 Ready Pod 的 IP 列表。

# 通过 DNS 直接访问特定副本

- 每个节点有稳定 DNS 名称，配置 `replicate-from` 直接写 `mysql-0.svc`

**诊断入口：** 三步定位法——DNS 解析 / kube-proxy 转发 / Pod 监听

| DNS 解析 | CoreDNS Pod 状态、`/etc/resolv.conf` | `nslookup`, `dig`, CoreDNS 日志 |

| `no such host` / `i/o timeout` | 网络不通 | 检查节点 DNS / 安全组 / 代理配置 |

## 问题九：DNS 解析异常

| CoreDNS 状态 | `kubectl get pod -n kube-system \| grep coredns` | Pod 是否 Running |

- [[dns-troubleshooting-practical-guide]] — DNS 故障排查实战指南 — dig/nslookup 工具详解、四阶段排查流程、SERVFAIL/NXDOMAIN/TIMEOUT 错误类型速查

- [[k8s-coredns-custom-domain-resolution]] — K8s CoreDNS 自定义域名解析：五种场景（hosts/rewrite/存根域/上游DNS/AAAA拦截）+ 变更三件套

- [[k8s-dns-conntrack-5s-timeout]] — K8s DNS 间歇性5s解析超时排查——conntrack 竞态 + ndots 放大

- [[k8s-dns-iptables-troubleshooting]] — K8s DNS 故障真实案例复盘：iptables 封禁 53 端口导致 CoreDNS 雪崩，完整排障过程与加固方案

- [[k8s-service-access-troubleshooting]] — K8s 服务访问排查十步工作流：Pod→Service→kube-proxy→CNI→Ingress→DNS→NetworkPolicy

- 覆盖：Pod Pending / CrashLoopBackOff / Service 访问失败 / 镜像拉取失败 / Node NotReady / 存储挂载异常 / 资源配额耗尽 / etcd 故障 / DNS 异常 / Pod 安全策略 — 10 大场景

## [2026-05-18] ingest | K8s CoreDNS 自定义域名解析：五种场景实操

- Created raw: raw/articles/wechat-Kubernetes CoreDNS 实现自定义域名解析：从原理到生产实操.md

- Created concepts: kubernetes/k8s-coredns-custom-domain-resolution.md

- 五种场景全解析（hosts/rewrite/存根域/上游DNS/AAAA拦截）+ Corefile 配置片段

### DNS 丢包

dig +trace example.com # 追踪 DNS 解析路径

# DNS 服务器 UDP 53 被防火墙拦截

- [[dns-troubleshooting-practical-guide]] — DNS 排障实战

tags: [troubleshooting, networking, linux, tcp, security, dns]

服务进程 → 端口监听 → 本机防火墙 → 云安全组 → SELinux → 网络路由 → DNS

## 第六步：网络路由与 DNS

nslookup yourdomain.com # DNS 解析

Kubernetes 中一个极度隐蔽的网络问题——**Pod 内部能通 localhost 和自身 PodIP，但访问自身 ServiceIP 却百分百超时**。所有上层组件（kube-proxy、CoreDNS、Endpoint）全部正常。

监控层面却一切正常：Pod Running、探针稳定、Service 配置和 Endpoint 完整、CoreDNS 解析正常、kube-proxy 进程正常、节点 CPU/内存/带宽均无瓶颈。**上层组件全部显示正常，业务就是超时。**

3. ❌ 怀疑 DNS 解析抖动

# 检查 nodelocal DNSCache 自链路

| 47 | 服务发现机制？ | DNS（CoreDNS）+ 环境变量 + API | — |

| 66 | 服务发现和负载均衡？ | DNS 服务发现 + ClusterIP/NodePort/LoadBalancer/Ingress 负载均衡 |

| [[k8s-service-access-troubleshooting]] | Service/Ingress/DNS/NetworkPolicy |

| [[service-troubleshooting]] | Service Endpoints/DNS/kube-proxy/CNI |

| DNS 解析失败 | `kubectl logs -n kube-system coredns` | CoreDNS 异常、NetworkPolicy 阻断 |

- DNS 解析是否正常（CoreDNS 日志、ndots 配置）

Ingress 有问题先看日志，DNS 不通查 CoreDNS。

| [[k8s-coredns-custom-domain-resolution]] | CoreDNS 自定义域名解析（变更风险评估与回滚） |

enable_dns_hostnames = true

enable_dns_support = true

enable_dns_hostnames = var.enable_dns_hostnames

enable_dns_support = var.enable_dns_support

- **CiliumNetworkPolicy**：比 K8s NetworkPolicy 更丰富的安全策略（DNS-aware、HTTP-aware、L7 策略）

- **高安全合规要求**：L7 策略 + DNS 策略 + 加密通信

| **NetPol 支持** | ❌ 无 | ✅ K8s 原生 + 高级（GlobalNetPol） | ✅ K8s + L7（HTTP/gRPC/DNS） |

> Headless Service 让 Jenkins Agent 通过 Pod DNS 名称（`jenkins-master-0.jenkins-master-svc.jenkins-team-a.svc.cluster.local`）直连 Master 的 50000 端口，避免经过 kube-proxy 造成不必要的网络跳转。

dnsNames:

| Agent 无法连接到 Master | Agent → Master 50000 端口网络不通 | 检查 Headless Service DNS、NetworkPolicy |

客户端 -> DNS -> 外部负载均衡 -> Ingress/Gateway API -> NodePort/ClusterIP -> kube-proxy -> Endpoints -> Pod

- **ExternalName**：DNS 级别的转发

- **DNS 解析风暴**：应用频繁解析 Service DNS 导致大量 UDP conntrack 条目

| 全局入口 | ExternalDNS / GSLB / GeoDNS | Region 级别引流 |

GeoDNS / GSLB / Anycast — 负责用户先落到哪个 Region，不参与服务级 Canary。

├── resolv.conf # DNS 服务器

| 查看 DNS 配置 | /etc/resolv.conf |

| ⑤ DNS 解析 | `nslookup backend.example.com` | 域名是否可解析 |

| [[dns-troubleshooting-practical-guide]] | DNS 故障排查实战指南 — dig/nslookup 工具详解、四阶段排查流程、SERVFAIL/ |

| OCSP stapling 无效 | `ssl_stapling` 相关报错 | DNS 不通 / 证书无 AIA / issuer chain 不全 | 见下方 OCSP 排查 |

3. Nginx 必须能 DNS 解析 OCSP responder 域名 → `resolver` 必须配置

- dns: DNS 解析/CoreDNS

- [[k8s-service-access-troubleshooting]] — K8s 服务访问排查十步工作流（含服务发现与 DNS 排障）

一个 playbook 完成 13 步：主机名 → DNS → 基础工具（vim/wget/curl/htop/sysstat 等）→ 创建运维用户 → sudo 免密 → SSH 公钥 → 关 SELinux → 关 firewalld → 内核参数调优（`fs.file-max`/`net.core.somaxconn`/`vm.swappiness` 等）→ 时区 → NTP → 远程 syslog → 清理无用服务（postfix/abrt）。

DNS 问题当网络问题 / 监听地址当连通性问题 / NetworkPolicy 当 CNI 故障 / 单节点内核参数漂移当全局故障 / MTU 不一致当偶发超时

| [[k8s-dns-iptables-troubleshooting]] | DNS + iptables 排障 |

# 2. 测试 DNS 解析

- 镜像仓库网络不通（防火墙、DNS 异常）

- [[dns-troubleshooting-practical-guide]] — DNS 故障排查实战指南 — dig/nslookup 工具详解、四阶段排查流程、SERVFAIL/

### 案例 6：DNS 解析超时导致 502

| Cloudflare | DNS/CDN | `cloudflare/cloudflare` |