dhcp + dns = dnsmasq

[danmons]

Already mentioned in IDEAS.md, although this is part of a larger scope.

Eventually I would like to offer RetroNAS as a full firewall system (optional, of course) - either with 2x network cards (x86 machine with 2x NICs, RPi with 1x NIC and 1x USB-NIC, or 1x NIC and 1x WiFi back to a home network), and splitting the "home" network from the "retro' network for added security, with only specific protocols as the bridging point (say, only allowing SMB and SSH for modern systems to access).

But to start with, a DHCP server would be of use. There are users who want to use RetroNAS in a standalone capacity - i.e.: RetroNAS isn't connected to a home network, but is direct wired (no switch, just Ethernet cable between it and a host system). In that case a DHCP server may be useful to simplify the remote side (whether that's a console like the PS2 or GameCube, or a computer with network card and DHC or bootp client). It then becomes "plug and play" to simply attach these devices to RetroNAS via a direct Ethernet cable link and have them autoconfigure themselves.

At this stage I'm thinking dnsmasq. It's extremely lightweight, simple to configure (and should allow ".d" style config directories with files broken out individually, which is very Ansible and Jinja friendly).

It can also handle DNS as well, taking in a home network's DNS options and caching them. One thing that really bothers me about many projects that need to handle DNS (DreamPi for example) is that they force users to point to external DNS (typically Google's 8.8.8.8 or CloudFlare's 1.1.1.1), which I don't think is something that should be forced on users. If they have their own DNS at home (perhaps configured DNS over HTTPS for security/privacy reasons), adopting that from their existing household DHCP server and sending it down to the retro network would be nicer. If they don't care, then it should still work anyway, again supplied by the household/ISP-provided Internet gateway device.

As an added bonus, we can inject a DNS A record for RetroNAS itself (so that it always responds to the short "retronas" DNS name for any IP based service). Similarly we can pre-bake reverse DNS entries for the given subnet so that reverse lookups are fast (the "SSH connection is slow" problem when reverse DNS doesn't exist for the subnet).

The challenge is making it easily customised. We can bake in some templates (say, a 192.168.99.0/24 subnet or something that is uncommon in home routers that are typically 192.168.0.0/24 or 10.0.0.0/24 or /8). But offering a simple way to change this if the user wants, either via dialog forms or via Cockpit if possible (Webmin is still an option too) might work.

Long term as well there's the possibility of RetroNAS existing in IPv6 networks, allowing the retro network to access modern websites via WebOne.

How dnsmasq/dhcp then interacts with things like tcpser (in development) and pppd (planned) is worth finding out too. If possible, using that one tool for all of those projects would be nice (although I have a feeling pppd needs client side IP values hard-set on service startup).

[sairuk]

yeh agreed dnmasq would be the best solution here, with a local.d directories

I run it against 3 nics with individual configs here all modular and all symlinks in a /etc/dnsmasq.d/nic(n)/ directory that is then loaded as part of the cli params in the systemd unit file.

I think whatever the installer looks like for RetroNAS it needs to separate out DHCP and DNS modes, in DNS mode we can run with wildcard overrides, upstream dns, addn-hosts, dreampi hosts, nwn, openspy hosts etc and make it nice and modular in *.conf files that are installed from specific menu items, if could essentially be made a pihole alternative as well. Could offer a template to kill call home services etc. Its effectively what my setup did/does long before there was pihole.

DHCP is a beast i haven't tackled in dnsmasq in years but should be easy enough, support for configurable static DHCP leases is a must imo.

Dreampi (at a quick glance) just have a custom resolv.conf which should be easy enough to workaround, its the wifi utility that has what looks like hardcoded interface layout, but even that could be ansibled once installed as a handler

[sairuk]

tcpser should work fine as long the dns name resolves, shouldn't be anything more complex than that. If dnsmasq is functioning correctly (i.e resolving hosts through an upstream server, or a local host record) it shouldn't impact functionality.

[birdybro]

For the raspberry pi (and any Debian setup) this sort of thing is already done to make them into wifi2eth bridges.

https://gist.github.com/glenselle/880cedfe25490a6d3f9bf51756e4e4bd

This uses dnsmasq as well so you can probably get some good info from here.