Comment on How do people handle authoritative DNS redundancy for their self-hosted workloads?

dave@lemmy.pootis.network ⁨2⁩ ⁨weeks⁩ ago

coredns_config:
  zoneFiles:
    - filename: int.pootis.network.zone
      domain: int.pootis.network
      contents: |
        $ORIGIN int.pootis.network.
        $TTL 300

        @       SOA     ns.int.pootis.network. admin.pootis.network. (
          2026082001
          1200
          300
          1209600
          300
        )

        @       NS      ns.int.pootis.network.
        ns      AAAA    {{ k8s_dns_ipv6 }}
        ns      A       {{ k8s_dns_ipv4 }}

        vault     CNAME   internaltraefik.internaltraefik.svc.{{ k8s_cluster_domain }}.
        cinny     CNAME   internaltraefik.internaltraefik.svc.{{ k8s_cluster_domain }}.
        grafana   CNAME   internaltraefik.internaltraefik.svc.{{ k8s_cluster_domain }}.
        stalwart  CNAME   internaltraefik.internaltraefik.svc.{{ k8s_cluster_domain }}.
        lemmy     CNAME   internaltraefik.internaltraefik.svc.{{ k8s_cluster_domain }}.
        mail      CNAME   stalwart.stalwart.svc.{{ k8s_cluster_domain }}.
        webmail   CNAME   internaltraefik.internaltraefik.svc.{{ k8s_cluster_domain }}.

        ; ACME challenges
        ; int.pootis.network + *.int.pootis.network
        _acme-challenge      CNAME 1ca12d2c-8034-4a09-a940-dc59bd4f38d8.acme-dns.pootis.network.
        ; mail.int.pootis.network
        _acme-challenge.mail CNAME d175b66d-909f-46ba-8572-636ebc235d4c.acme-dns.pootis.network.

• chaospatterns@lemmy.world ⁨2⁩ ⁨weeks⁩ ago

  Since you’re using Kubernetes, have you looked at external-dns? In my home lab, I use external-dns to take Ingress and Service resources and register them into my internal DNS zone. I use the etcd backend. external-dns registers zones in etcd, then CoreDNS queries from etcd. As soon as I create a new Ingress, it’s automatically registered and pointing to my Traefik service.

  github.com/kubernetes-sigs/…/coredns-etcd.md

  original
• mschae@discuss.mschae23.de ⁨2⁩ ⁨weeks⁩ ago

  Interesting, that’s much more sophisticated than my setup (though to be fair, I host my services on a rented VPS instead of home)!

  The issue only occurs with my externally-facing DNS, which is needed to, for example, to reach my Lemmy backend instance (lemmy.pootis.network) and the pictrs deployment. But yeah, internal DNS works perfectly for me and it easily survives a node failure.

  Could still set up a recursive resolver for external DNS, but I guess that wouldn’t help other people who use a bad resolver. Tricky situation.

  original

  • dave@lemmy.pootis.network ⁨2⁩ ⁨weeks⁩ ago

    Yeah, the issue is that people’s resolvers are wildly different and I guess some of them do not cater to weird and wacky self-hosting setups (most people just use anycast highly-available DNS, usually provided by a registrar or by some other company).

    I had a hunch that resolvers break because one of my nodes does not have a public IPv6 address: meaning,

    • node2: externally-facing node, I host it from my home, IP 178.44.116.85, acts as NS ns1. It has IPv6 connectivity but no external IPv6;
    • node4: a cloud VPS that I rent. Externally-facing, with IPv4 91.219.150.30 and IPv6 2a06:dd00:1:4::4189, acts as NS ns2.

    If node4 decides to break, then ns2 becomes unavailable - but since resolvers can see that ns1 does not have an IPv4 address, and since everyone knows that IPv6 is better because 6 is greater than 4, then these resolvers would always prefer ns2, even though it’s clearly down.

    This could be solved by asking my ISP to set up a static IPv6 prefix for me (they already provide static IPv4), except my ISP does not do that, unfortunately. I could also rent another VPS (so I would have two VPS’es, giving me some resilience from downtimes) but that means extra $$$… anyway, I guess I should probably test the IPv6-preference hypothesis first and then act on the results.

    original