Something like yggdrasil would work or a daemon that publishes mdns and connects to known peers.

At the same time?

Can i also double it and pass it to the next guy?

Surprise: He’s not dead

Arstotzka.

I’ve searched for something like this in the past and didn’t find anything.
I’ve though of hacking together a few scripts or 8n8 to interface with freshrss to do this but it’s far down my list™

Disable the firewall if you can to check if that’s the issue, then do a tcpdump using root with the port. Do tcpdump inside the container too and compare what you see to the docker environment.

Is caddy-caddy really the correct image?

Try with this command, it’s the minimal setup that works by default (on my machine): podman run -p 0.0.0.0:5050:80 docker.io/library/caddy:latest

Use ss -tlpn or podman ps to show what ports podman is listening on, my guess is it is only listening on localhost.

is kludging NAT for IPv6 not a better solution versus ULA addresses?

There are very few hosts that allow only ipv6 (though there are many who only do ipv4). Ipv6 would improve internet stability and long-term communication when you’re not using a nat but that isn’t what you’re trying to build. Seeing as you’re not getting any advantage anyway I recommend ULA because it won’t get in the way of possible future migration to GUA ipv6 (globally unicast address) and still run over the ipv6 network while also avoiding Nat.

Or is the clear answer just use IPv6 as intended and let the devices handle their privacy with IPv6 privacy extensions?

It’s my clear answer at least.

If you don’t want that you can use ULA addresses for now and later add GUA ipv6 addresses. ULAs are meant to be used when you only have a dynamic ipv6 prefix so that internal devices can have ipv6 internet (GUA) while also having a static ipv6 address(ULA).

Use ULA addresses for hosts inside your LAN, they are static, cannot be used to reach outside your LAN and use IPv6. Then give your server/VPN endpoint a real ipv6, that’s your VPN endpoint. This doesn’t require any nat and can be easily changed to GUA when you want to.

CGnat is a “solution” for running out of ipv4 addresses, it has the same problems as any other nat but the problems are even more noticeable because the out-facing ipv4 address changes more often than the typical home nat configuration and tricks like FTP- and other helpers don’t work as well.

Ipv6 would not only avoid the issues of cgnat, it would avoid cgnat entirely because you don’t need to Nat when you have enough ips.

Most (all?) advantage of ipv6 when compared to ipv4 don’t work behind Nat. Thus there’s no reason to use it.

Either Nat with ipv4 or don’t Nat with ipv6.

Why did you want to use ipv6 when you don’t want what it represents? (End to end communication/IPs)

Either use ipv6 privacy extension (enabled by default, so this can just be called ipv6) or don’t enable ipv6.

That way you have working ipv6 or wait until you come to your senses. Using nat6 ipv6 isn’t worth it.

Connect a lan cable and:

ip a (shows network interfaces and ips

ip a a 192.168.<subnet>.<unused ip>/24 dev <interface> (get the subnet from your router or phone WiFi settings, interface is the interface starting with "en" from the first command, for unused ip just try your phone IP +1)

ip r a default via <router IP> (router IP can be seen in your phones WiFi settings under gateway)

Also checkout /etc/resolv.conf, replace its content with “nameserver 8.8.8.8”

I just follow the software release pages with RSS.

Because pi-hole asks the configured DNS the whole domain, the root server will promptly <access denied> because that’s not how DNS is supposed to work.

There’s a difference between asking about the individual domain parts of the domain to the corresponding authorative DNS server and just sending the whole thing to a root server. If you did that then the root server would get ddosed to death.
Pi-hole can’t ask the root servers, it can only forward. Unbound can forward or be authorative or ask using the root servers and go down the chain or do all of those at once.

There are 13 root name servers, they container info about which DNS is authorative (can tell you about) a given TLD (like .com or .de) then that repeats for every part of your query with that given server.

Something
^ most of the time the same as.
Foo.
^ DNS for baz or bar dns again.
Bar.
^ DNS for Bar.
Com.
^ DNS server for the .com tld
<root name server>
^ the one unbound asks first, not part of the domain

Giving us the IP of something.foo.bar.com
Though the DNS name would be something.foo.bar.com.

The root server ips are known to unbound and static.

Then it will ask that server? Like I said unbound remove the middle man and somewhat increases privacy (debatable if only you use it but anyway)

Forwarding: just passes the DNS query to another DNS server (e.g. your ISP’s). Home routers use forwarding to pass DNS queries from your home network’s clients to your ISP’s DNS servers. For example, for foo.example.com, a forwarding DNS server would first check its cache (did it already ask this question before), and if the answer is not in its cache, it would ask its forwarder (your ISP’s DNS server) for the answer, which would respond with either a cached response, or would perform recursion until it figured out the answer.

Recursion: the DNS server receiving the query takes it upon itself to figure out the answer to that query by recursively querying authoritative DNS servers for that domain. For example, for foo.example.com, a recursor would first query the root servers for what DNS servers are responsible for the .com TLD, then it would ask those servers for example.com, then it would query the servers for example.com for foo.example.com, finally getting the answer to the original query.

Copy-pate from here.

Basically, it remove one middle man from the DNS resolving.

Windows vms for beating kernel level anticheat takes a lot of work to prevent detection. I recommend dual booting instead for that use case.

For the Linux environments I’d recommend using containers/podman/docker, systemd-nspawn or libvirt. These three solutions use the host kernel as the hypervisor and don’t require much setup.

Containers can also share the GPU with the host easily.

Your setup would be Hardware > Windows | Bazzite > Ubuntu(container) | OSX (libvirtd)

Edit: You can also triple boot with windows, Bazzite and Ubuntu or add a proxmox/whatever hypervisor disk and try it out without touching your working system.

And with it, the infinitely recursive wsllswwsllswwsllsw…

Pi-hole forwards the requests to another DNS server. Unbound can ask the root servers and go down the DNS chain.