optimally you would be using something OpenDHT which could either provide a flat list or recursively defer to other OpenDHT instances (in the same way DNS works).

fortunately it will accomplish the same goal of segmenting records up across peers. This is effectively how GNS works (GNS goes one step further and anonymizes the record, peer relationship)

We're gonna stick to systemd and utilized systemd-resolved. Resolvectl actually makes it pretty easy with our schema. For other systems, it'll be on their heads to update nameservers

there's a DNS entry you can use that's built into the Wireguard config that ... works.... client side, but not well. I sincerely doubt Wireguard is advanced enough to watch port traffic like NAT reflection tricks, where you basically just snatch up everything leaving udp 53 and just redirect it to the DNS server you've got rolled. Seems like you'd have to add something else on there for that.

my understanding is that the dns entry from wg-quick will route all dns to that endpoint, which works for like a nordvpn style vpn, but we're aiming for something like a corporate style vpn, where the dns server is just handling private endpoints like "my-api.internal"

seems like too much effort for... what do I get in that scenario? I may not be the best person to ask since I just buy domains and only use them internally. Like my coredns right now just points at my domain controller because I had Windows server licenses. It's possible Unbound may have the functionality you're looking for though. I've seen people use it conjuctions with Pihole, I just haven't had a chance to play with it yet.

honest answer is i thought it would be easy and now im too deep to go back

cause now you're opening up the certificate bag

main use case is people find ip addresses annoying and want to be able to remember what stuff is on which box

In 97% of those corporate scenarios you're probably already gonna have an AD/DNS server rolled. You really just need to facilitiate the meshes pivot to that.... lol, which could potentially land you back in Windows client land.... and even then, I'd feel gross putting Netmaker (or really anything else on a Domain Controller). Who knows when/if that beast will ever die.

You could probably get away with a gateway to it existing on WSL or just a VM somewhere though.

as for the hobby user side, I'm lazy and still just hand jam everything into my ssh configs. Like with Nebula, I just keep two entries for the same machine. The local subnet and the nebula subnet, just name them nearly identical and call it a day.

The killer feature you'd be looking for in a corporate scenario is; can I launch this VM/node/pod whatever, with a 1 time use key pre-baked into it. Have it strap up, call out to Netmaker and either add itself to the correct network with a more permanent key, or at least just sit and wait to be approved to the right network.... Now if DNS is involved, you disco-dog name the box whatever and have it auto add to the DNS server..... but that's digging waaay into the pipeline weeds in an industry where we've really just moved snowflake servers to snowflake pipelines

Yeah DNS probably should not be so early in the development process, but I had some non-dns related reasons for starting on it earlier. I'm using CoreDNS, and in the next iteration I'd like to tackle udp hole punching using either WGSD or our own equivalent home-baked process. If we 've already got the process in place for standing up and integrating coredns it'll make it quite a bit easier. The other reason is, more selfishly, we're gonna start working on the kubernetes stuff soon and getting some CoreDNS experience in will be handy.

That said, I thought this was gonna be a lil side thing to implement, did not expect it to be such a slog

dns is always a pain in the ass, and if you don't give it full attention.... it will diva for you

You might find this helpful though, https://github.com/miekg/dns If building into the netmaker client might make things easier / slash insanely more difficult

I have no idea ¯\_(ツ)_/¯

I'll check it out!

the problem with a true p2p network is that you have to solve p2p problems

you can use a single dns server or even a discrete set of DNS servers but you'll eventually need to implement bgp and anycast internally if you want latency to not suck

doing it the p2p way isn't harder, it's actually easier. it just requires restructuring your codebase.

The thought I had was to just sidecar dns in a netties cluster, so that you basically launch a vd-vm with DNS hanging off the side, but yeah @narrow-flag-53296 the foundation of that seems much more conducive to DNS use. We could always go back to just hand jam grooming the hosts file 😛 I mean, my goal here is to basically block the internet and start over.

sidecars don't scale

That sucks, what problems do you run into there?

soft failures (eg one pod doesn't communicate while others do) - so the ops team is like wtf

hard deployment requirements go up (eg more ram, computation)

you can get interesting deployment problems which are to debug

like a "sidecar" that accidently gets deployed in a seperate pod and unless you dig into it you could be sitting there going wff

dude... gnunet is insane.... why are like.... more people not looking at this as a solution to soooo many things.