feat(dns): 用模板生成各后端配置
This commit is contained in:
@@ -55,51 +55,9 @@ data:
|
||||
rcode NXDOMAIN
|
||||
}
|
||||
}
|
||||
# ── split-horizon for the Authelia hostname ─────────────────────────────
|
||||
# Cloudflare is authoritative for ddupan.top (the DC only holds ad.ddupan.top),
|
||||
# so auth.ddupan.top publicly resolves to Cloudflare proxy IPs — 104.21.6.55 and
|
||||
# 172.67.154.245. TCP/443 to BOTH fails from this network, persistently, while
|
||||
# other Cloudflare IPs (104.16.132.229) connect fine. So every in-cluster
|
||||
# consumer of Authelia was hairpinning out to an internet path that does not
|
||||
# work, to reach a Service sitting in the same cluster.
|
||||
#
|
||||
# Concretely (2026-07-28): the Gitea chart runs `gitea admin auth update-oauth`
|
||||
# in an INIT container, which FETCHES the OIDC discovery URL on every pod start.
|
||||
# It timed out, so Gitea CrashLoopBackOff'd on any restart, and server-side
|
||||
# token exchange failed for logins. This was latent — any restart would do it.
|
||||
#
|
||||
# Answer with the Envoy Gateway LAN address instead. The gateway terminates TLS
|
||||
# with a real Let's Encrypt cert for this exact name
|
||||
# (../cert-manager/certificate-auth-ddupan.yaml) and routes to the authelia
|
||||
# Service (../../apps/authelia/httproute.yaml), so the name, issuer, redirect URIs and
|
||||
# cookie domain are all unchanged — only the path stops leaving the LAN.
|
||||
#
|
||||
# A `template` block (not `hosts`) so it answers only A/AAAA-shaped queries and
|
||||
# returns NOERROR/no-data rather than NXDOMAIN for anything else.
|
||||
auth-ddupan-top.server: |
|
||||
auth.ddupan.top:53 {
|
||||
errors
|
||||
template IN A {
|
||||
answer "{{ .Name }} 60 IN A 192.168.10.127"
|
||||
}
|
||||
template IN AAAA {
|
||||
rcode NOERROR
|
||||
}
|
||||
}
|
||||
# ── split-horizon for Gitea ─────────────────────────────────────────────
|
||||
# Same shape and same reason as auth.ddupan.top above: git.ddupan.top publicly
|
||||
# resolves to Cloudflare, so an in-cluster client cloning from Gitea would leave
|
||||
# the LAN, cross the WAN and come back down the tunnel into this same cluster.
|
||||
#
|
||||
# This matters for CI: an Actions runner checking out the repo, and anything
|
||||
# else that clones from inside the cluster. Served by the `https-git` listener
|
||||
# with a real LE cert for the name (../cert-manager/certificate-git-ddupan.yaml),
|
||||
# so the clone URL is identical inside and outside — no remote needs rewriting.
|
||||
#
|
||||
# ⚠ This only covers PODS. LAN clients resolve via the DC, which forwards
|
||||
# ddupan.top to the router — and the NEC IX has no static-host/proxy-DNS
|
||||
# feature (`show dns` offers only fqdn-database). The DC therefore needs its own
|
||||
# `git.ddupan.top` zone for laptops and PVE nodes to get the LAN answer.
|
||||
# Split-horizon blocks are generated from ../../infrastructure/dns/records.yml.
|
||||
# They keep pod traffic on the LAN while preserving public hostnames and LE certs.
|
||||
# BEGIN GENERATED: homelab DNS (coredns)
|
||||
git-ddupan-top.server: |
|
||||
git.ddupan.top:53 {
|
||||
errors
|
||||
@@ -110,6 +68,17 @@ data:
|
||||
rcode NOERROR
|
||||
}
|
||||
}
|
||||
auth-ddupan-top.server: |
|
||||
auth.ddupan.top:53 {
|
||||
errors
|
||||
template IN A {
|
||||
answer "{{ .Name }} 60 IN A 192.168.10.127"
|
||||
}
|
||||
template IN AAAA {
|
||||
rcode NOERROR
|
||||
}
|
||||
}
|
||||
# END GENERATED: homelab DNS (coredns)
|
||||
---
|
||||
# NOTE: `serve_stale` could NOT be added here.
|
||||
#
|
||||
|
||||
Reference in New Issue
Block a user