LineageOS, mostly due to the fact that it’s pretty close to the original vision of AOSP; and my devices do not support Graphene or PostmarketOS, so there are almost no viable alternatives.

That does seem to be a good solution, thank you for the recommendation!

Running an AS and obtaining a /48 through a sponsoring LIR seems to cost about $150/year in my country, but hardly anyone (except hosting providers and large companies) does this, since self-hosting, especially more complicated stuff, isn’t really that popular here; people are mostly uninformed that it even exists.

But route64 is apparently completely free (donations are welcome); they provide a /56 PA-like IPv6 block carved out of their PI, and they also handle BGP stuff, and I don’t even have to pay for any of this - overall, a great choice, considering my constraints. Anycast to multiple tunnels costs money (maybe that’s what you meant with 2 EUR/month?) but that’s pretty much lunch money so it would be OK with me.

At this point I pretty much think this may be the exact case - and it may work in reverse: “since ns2 has AAAA listed then it’s an IPv6-capable deployment and we are allowed to fall back to IPv4, but since ns1 lacks the AAAA record, then we won’t even consider falling back to ns1 if ns2 is down”.

Or maybe another scenario:

• let’s check ns2’s AAAA record
• oh it’s down! Let’s check ns2’s A record
• it’s down too! Let’s switch to ns1…
• … but at that time the DNS resolution timeout expires, since we took too long resolving the records; and on the second try, no one remembers that ns2 was down, repeating the cycle

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.

Basically my internal DNS zonefile is configured like this (it should be easier to read than my explanation):

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.

Trying to understand your setup: this seems like a split-horizon DNS, where app.example.com is only visible from your internal network (or Tailnet), right?

If so - I explained my similar setup in this comment; in short, my internal DNS works perfectly because the internal DNS server has a static “service IP” (handled by kube-proxy); if my currently-running pod breaks, k8s will simply spawn a new one and the DNS server IP won’t even have to change - meaning, the internal DNS zone continues to be served no matter which node breaks (it’ll even survive multiple node failures).

But the external DNS is different and I can’t simply plug in a “fake loadbalancer IP” there… (there are valid workarounds but they either are incredibly finicky or I have to spend an obscene amount of money to implement them)

I actually already have a local DNS resolver… well, sort of: most of my cluster’s internal services, such as Vaultwarden and other stuff, are available only over an in-cluster IKEv2 VPN.

What I mean is, I have to connect to the VPN first, which pushes a Configuration Payload to my IKEv2 client, and that payload contains a DNS server IP, and that DNS server (exposed by a Kubernetes Service) serves a custom “internal” zone (.int.pootis.network), and proxies everything else either to k8s coredns, or to upstream DNS forwarders.

Okay, that explanation may have been somewhat complicated (it sounded simpler in my head) but the end result is that I can resolve and reach stuff like lemmy.int.pootis.network (my Lemmy frontend) only while connected to the in-cluster VPN. It is completely hidden from external users (no CT log record, no external DNS record, and only proxyable by internal Traefik instance).

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.

The enclosure itself is fully DIY (I just yanked out the vape internals and glued the board edges to the vape); there’s a hole with an SMA antenna connector, visible on the photo. Plus, there are a few I2C sensors inside the vape, also glued to its inner plastic “walls”.

The hardware is partly-DIY; it’s a Meshtastic node on nRF52840 combined with HT-RA62 on a Faketec-like PCB. It runs mainline Meshtastic firmware. I originally planned to make it export its sensor and mesh data over Bluetooth (so my other stuff would ingest the data and put it into my observability pipeline), but decided against it and left this “vape” as a pure Meshtastic node that also announces its temperature, pressure and humidity. It has no screen unlike many other similar nodes.

Basically it was a fun project, and I even got a good deal on the components (it cost me like $8 total or maybe a little more).

And I also wasn’t sure of health hazards of gigahertz radio emissions in relation to cats - my design had the antenna in a VERY close proximity to the cat’s body, so that would have been yet another problem to solve…

You probably won’t believe it but I actually considered doing something like this!

The setup: I have an old Pi 3a with Alpine Linux set up; it is connected to a AR9271 USB Wi-Fi dongle running in active-monitor mode. A cheap power bank is used to, well, power the entire thing. Plus, a small 2.4 GHz antenna.

The Pi runs a custom Go app which sniffs handshakes, performs deauth and PMKID attacks, and also tries to bruteforce WPA2 (with a small password list). It also records everything and allows me to upload captured frames to the special-purpose dissector.

Finally, all of this gets put into a small bag and we’re off to, uh, “explore” the neighborhood.

I wanted to use the cat to automate the exploration, and it almost worked, except there’s an issue with the powering: Pi + dongle eat too much power, and my power bank is heavy and hazardous, so I decided against putting it in a cat “harness”. The cat itself can easily carry the board and the dongle, but having to carry a power bank would be too much for the cat.

The second cat-related issue is that people do not generally trust a cat with a 2.4 GHz antenna poking out of its harness, especially if some wiring is visible, and I didn’t want to bring negative “publicity” to the cat…

So uh, yeah, the idea was sound on paper, but cat-ifying the Wi-Fi setup had to be shelved, unfortunately.