innernet: Please don't edit /etc/hosts

Unrealistic, but you could also push everyone else to implement support for /etc/hosts.d/ — then /etc/hosts.d/innernet would be OK 😀

I’m interested in a mode where a standalone separate tool could read state from innernet and then publish regular DNS records to a DNS provider (whether internal or internet-facing).

On all of my machines running NixOS (the distribution is working on packaging innernet here) /etc/hosts is strictly read-only as an OS feature (immutable configuration generated from a single source of truth), so no option of changing /etc/hosts at all for me.

Going to go against the grain slightly and vote for keeping /etc/hosts, at least as an option.

I don’t want to be tied to glibc, nor do I want to add another moving part to all my systems for dns, nor is it the case that everything on the system is necessarily using the system dns resolver (especially in the age of DoH).

NSS is not a workable solution if you want to support all Linux distros, among other things it won’t work on Alpine where NSS does not exist. Ignoring this for the moment, NSS is a complex beast to wrestle with due to it loading into every process launched on the system. In one of my own projects I’ve flagged NSS as out of scope because its semantics really aren’t designed for interacting with the network in an online context (though I am working with the passwd/group/shadow databases, not the hosts database which could be completely cached to disk).

I’d recommend adding an option to not edit the hosts file, but also adding an option to write everything that would have been written to the hosts file to somewhere else. There are DNS servers that can read this format directly and the format is trivial to parse with shell scripts to convert into bind9 style zone files or just about anything else you could want.

@bugaevc @mcginty

Just learned of innernet today.

To solve this problem could you utilize the open source tool for Wireguard called WGSD by Jordan Whitehed? or… something similar?

WireGuard Endpoint Discovery and NAT Traversal using DNS-SD

---

First, thanks for your thanks! Second, yeah, you’re absolutely right.

We felt dirty adding the /etc/hosts modification in the first place but the alternatives of trying to interface with the daunting wild west that is DNS configuration on linux felt very flimsy.

At the very least, innernet needs an option to not write to /etc/hosts, so that can be added right away.

---

I use wireguard but up until now I’ve been using bgp, frr (& BGP VRFs), wireguard, vxlan, and vxwireguard-generator to build a vpn mesh internet overlay.

Now that I know about WGSD I may rethink using a routing protocol if I can implement a Wireguard Node Service Discovery tool to find peers in the mesh.

From what I read it seems Wireguard Nodes “register” themselves with WGSD which enables other mesh peers to learn about adds/deletes/changes to the “mesh” and the new Node learns about the Mesh members.

Brian

I’m not exactly the most qualified person to answer this, but here are my thoughts.

• NSS is glibc-specific (though some other systems provide similar interfaces). This is not exactly bad (the users always appreciate when developers provide a specialized, native solution for a specific system!), but you’d still need to support a different solution for non-glibc systems. And yes, this won’t work with software that skips glibc APIs and implements DNS clients itself.

  It may also be a bit non-trivial to make shared libraries — for one thing, you’d need to figure out how to build shared libraries for multiple architectures simultaneously with your buildsystem, and where to install them to (/usr/lib/x86_64-linux-gnu/libnss_xxx.so and /usr/lib32/libnss_xxx.so on my Debian box, /usr/lib64/libnss_xxx.so and /usr/lib/libnss_xxx.so on my Fedora box).

  It also means you need to configure NSS to add your NSS module for hosts. I’m not sure users will appreciate it if installing Innernet would automatically patch in innernet into their /etc/nssswitch.conf (or maybe they will, since apparently distro packages do this), or if you have to asks the user to enable it themselves. And please remember that on at least some systems, /etc/nssswitch.conf is actually managed by yet another configuration system (authconfig, authselect).

• An actual DNS server should be portable to other systems. The downside is the one you mention (there are many tools on different systems and setups that want to manage resolv.conf), and also always running yet another daemon in the background is suboptimal (although I guess it could be implemented inside the existing Innernet daemon). This also means having to actually implement DNS, which is quite a complex protocol with many tricky details (though you could make use of trust-dns-server).

I’m personally liking the proposed hosts path override solution (--write-hosts-to <path> and a convenience --no-write-hosts), it’s simple and flexible (especially now knowing that modern DNS servers like CoreDNS can read the format).

While this can be added as a CLI flag in the mean time, are there any opinions on whether this is a machine-scoped (a new /etc/innernet.conf) vs. interface-scoped (/etc/innernet/[interface].conf) setting?

--write-hosts-to /any/path/youd/like seems like it would address the issue for some cases.

Some options could be:

• an API endpoint which generates a zone file, which can then be used in Unbound, BIND, CoreDNS, etc.
• an API endpoint which outputs JSON file containing the hostname-IP mappings

Both endpoints could, potentially, accept a parameter which would tell the API which CIDRs to output only, ie. if there’s no association between CIDRs A and B, there’s no need for their DNS resolvers to contain the information about the other CIDR.

It would be great if we didn’t rely/depend on any systemd service/mechanism, for compatibility sake.

I like the idea for now of opting out of innernet editing /etc/hosts.

Being an old grey beard I hopefully understand the argument against using /etc/hosts, but the design decision to edit /etc/hosts makes sense to me at the moment. Adding a DNS server element is another cog of complexity that would have to be managed by the project and could create too much drag too early. Also as you mentioned, because windows also has a Windows/System32/drivers/etc/hosts file, it seems a doable entry point when writing a client for that arch to keep moving forward.

FWIW my use-case is an internal SDN.

Anyway, brilliant project, thank you for sharing.