What ?
Foghorn is a sender/listener pair that periodically sends UDP packets to a destination/subnet , and listens for any other utilities sending such same UDP packets.
It's a toy project, for a non-IT person to do IT-adjacent things.
Why ?
Because I needed my arbitrary boxes to tell eachother who and where they are.
I have worked in the technical operations for software testing teams, and the very common scenario is that there are N bespoke devices (build towers, raspberry Pis, SoC POCs, etc) that need to be managed.
IT does not want to track them (and shouldn't need to), and only occasionally might acknowledge their device names for DNS purposes - but usually not.
When ?
Foghorn is the "poor-sod's not-DNS tool" when you don't have control of the network infrastructure and still need to herd the cats.
It is 100% shadow-IT
How ?
At its simplest, foghorn is comprised of a sender and a listener; the sender takes an IP or subnet which it will periodically send UDP packets to, with a JSON payload specifying its name and an optional alternative name; the receiver listens for UDP packets on the same port, and registers the names from the JSON payload against the IP it sees the packet as coming from.
Note that this means that if the sender is behind a NAT, only the "external" IP will be visible to the receiver.
Where ?
https://github.com/taikedz/foghorn
Currently this is written for and supported on Linux. The installer supports systemd services, and foghorn can thus be made to start on-boot.
It is possible to run this on Windows as well with Python 3 installed, but no service code is written. You can run foghorn in a window and leave it running, but Windows is prone to rebooting without your consent so this is still an issue.
Other thoughts
DNS propagation on corporate LANs
You may think this is a poorly reinvented wheel , but I have used it effectively in scenarios where names were not propagating to IT's DNS. This is sensible - you don't want some random box clashing with a real corporate server on the network and causing MITM havoc!
Let's say there's a payroll service at https://payroll.lan . If you allow arbitrary machines to declare their own hostnames, you run the risk of someone "mistakenly" (...) naming their machine payroll and causing an IP resolution clash... where visitors trying to get to the real payroll server can't get to it...
Of course, the proper solution is to set up a testing network for arbitrary machines, and give them their own DHCP+DNS space. If you are in the IT department, then this is absolutely the direction to go. If you're not in IT and you've reached this point, then this is a moot point. The real world is about compromises, and often developers need infrastructure faster than IT can provision, directors push for action, and ... here we are. A non-IT person needing an IT-like solution.
NAT and firewall traversal
I wanted to see if I could send a ping from a Windows client machine into the foghorn network, and get responses back. Unfortunately, this does not seem to be an easy feat: even if I can ping out to the boxes, their responses would usually be lost on the way back. I am wondering if this is indeed a firewall issue - when a socket sends a packet, it does so from an arbitrary port, which allows the server end to respond to that particular port.
This is sensible - say two processes both query server.lan:80 ; each process wants to receive the data relevant to its own request. If they're both somehow tied to the same origin port (say, they were to re-use 80), then there would be a data clash.
In TCP I can see how a firewall would handle the flow: once the connection is established, the identified connection can send and receive packets as needed.
But for UDP, which is connectionless, any packet incoming can carry no metadata relative to what it is responding to. It relies on the network recognising the port as being recently used for outgoing to a given server, so reasonably should let any response from that server to the same port back through - but that's the responsibility of the NAT, if any, and... the firewall? Testing from Linux behaved as expected, but on Windows I was continually marred by issues where packet responses would just not come back home.
Top comments (1)
I like that you called it a “poor-sod’s not-DNS tool.”
A lot of engineering solutions aren’t about finding the perfect architecture. They’re about solving today’s problem within today’s constraints. Sometimes the interesting part isn’t the technology itself. It’s the organizational problem that created the need for it.