Something like tailscale's "magicdns"?

[boehs]

Networking is not my specialty, sorry if this is stupid, obvious, etc. A built in DNS solution would be interesting, like tailscale's magic dns, but maybe less magic and more better?

L1: It assigns each peer it's own DNS entry, so you can do dave:8000 to connect to whatever IP dave has been assigned. Much easier that way.
L2: Would be even better if dave could name his port, so I could connect to webserver.dave for 8000
L3: Dreaming, what if two IP's could both be associated with one DNS entry, and each one can claim ports, so if I have two homelab servers for instance, one has claimed nextcloud.lab as port 3333 and the other has claimed plex.lab as 1234
L4: DNS entries can also be unrelated to peers, so nextcloud could simply map to lab:3333, how whimsical is that?

Past L1, tailscale gets beaten. I'm not looking for something magic like theirs, but powerful and flexible like the rest of this wonderful program. Unless it was not clear, these L's are not demands by any means, I'm just very excited about this idea and tossing around ideas :)

Perhaps there is some alternative program I can use that is like this?

[boehs]

Related:

Tailscale FR's:

tailscale/tailscale#3847 tailscale/tailscale#1543 tailscale/tailscale#4455 tailscale/tailscale#1152

[strohel]

Hi @boehs, innernet already assigns human hostnames like myhost.mynet.wg for each peer (unless disabled). It currently does it by editing /etc/hosts (or equivalent), but that's an implementation detail that can change.

I fear that embedding a port into hostname cannot work, as hostname resolution library functions usually have no means of returning a port number.

[boehs]

That makes sense, unfortunate. I am still interested in L1? I understand if it's not a priority but myhost would be preferable. If not I understand, thanks for the awesome project

[strohel]

I fear that providing bare myhost names would not be general enough for innernet (multiple interfaces could then clash). But you should be able to emulate the same effect by "search domains". See manpage for resolv.conf in case of UNIX systems.

[dbr]

Perhaps there is some alternative program I can use that is like this?

As mentioned, the "level 2" and beyond steps aren't doable by DNS resolver

It doesn't really overlap with the innernet project at all, but:

For HTTP traffic, the use cases are all (more or less) doable with a "reverse proxy" HTTP server. E.g you point webserver.dave and webserver.emma etc etc to the same IP where the reverse-proxy is running, then when you navigate to any of those domain names, based on the Host: ... in the HTTP request the proxy redirects the traffic to the approriate server. This all works because the HTTP protocol is designed for this (virtual hosting) - it wouldn't work for most other things (e.g SSH has no way of knowing if packets were destined for a particular domain-name)

Something like nginx can be configured to do this proxying; and things like Traefik are a more specialized version of this (I have a vague feeling like it's possible to write some kind of innernet-traefik integration to do exactly what you describe, but, it's most likely a huge amount of effort for a fairly unusual use-case)

[boehs]

Your point about nginx is very very interesting. Seems like a fun side project honestly, so to the backlog it goes! If you so wish, you are welcome to close this issue.

FWIW I apologize for my initial naivety but am glad I opened this issue because it's prompted really interesting ideas like @dbr 's suggestion. Keep the thinking going and thanks to everyone for making an awesome project happen.

[mcginty]

For what it's worth, I think with the advent of more DNS implementations that support plugins like CoreDNS, innernet can and should focus on offering multiple name resolution options besides the hacky hostsfile implementation it currently uses.

Especially in the Linux world, I don't see there being a one-size-fits-all solution any time soon, and trying to support way too many different obscure configurations will be a nightmare, but maybe deciding on 1-3 offerings to support common setups wouldn't be crazy.

[noseshimself]

I fear that embedding a port into hostname cannot work, as hostname resolution library functions usually have no means of returning a port number.

You can of course let libc do the work (or how do you think "telnet host smtp" is working). Just as you are augmenting /etc/hosts you could modify /etc/services (or extend the relevant nis database). But it seems a bit useless to me; if someone really needs it he can start reading up on nss and nsswitch.confq.

I'd rather add unbound to the innernet-server or dig out prehistoric nis (which has been torturing me for decades and still leaves you with fun things like nsswitch.conf).

[courtc]

In the effort to provide an alternative to editing /etc/hosts, I made a simple NSS module for innernet, which just reads the JSON files in /var/lib/innernet. It's possible to use the HTTP API directly instead.

I looked into an integrated DNS solution (e.g. trust-dns, aardvark-dns, dcompass), but I think just the configuration of the server (e.g. forwarding, TLS, HTTP) would dwarf the simplicity of innernet. Even then, there remain questions about how it's served (by innernet-server or locally at each client) and how forwarding works (or if we defer that problem to another resolver like systemd-resolved's DNS routing domains.)

[adminy]

innernet-server sounds like a better idea to do the dns resolving as that would let you centrally manage dns resolution, great for places like routers where you want the clients to just get the same treatment.