MaraDNS: A small open-source DNS server
github.com
github.com
Shameless plug in related space that I was able to get open sourced is Dora a rust written DHCP server.
https://github.com/bluecatengineering/dora
Disclaimer: Opinions mine. Work at a DNS, DHCP, IPAM company.
There is no shortage of amazingly reliable DHCP servers that work for many years without restarts. It's an old, well tested reliable technology, that just works. What "modern" stuff you would like to bring?
What we do have is isc-dhcp-server (obsolete technically, horrific "API" that is downright unusable), Kea (made from the same people, better but much heavier, and plugins are in C++ so need recompiling with lack of documentation around it; API is pretty bad too), and Windows DHCP which I'm not sure even has an API, but it doesn't matter anyways because nobody sane would run Windows just for DHCP. Am I missing anything?
The scenario was as follows: DHCP server that needs to run in HA across multiple DCs, have an API that allows for stuff such as setting reservations based on leases (necessary with isc-dhcp-server because leases aren't shared between an HA pair, really, so if the "wrong" one answers the IP can change), but also querying list of leases by MAC, etc. etc. Also, being able to easily say reliably run this script/plugin after each lease/reservation so that it can be registered in other systems such as IPAM, monitoring, inventory, etc. etc. Neither isc-dhcp-server nor it's replacement Kea really cut it.
A single-maintainer project DNS server is not something I would be comfortable leaving exposed on the internet. Perhaps especially as there appear to be a few odd coding decisions, such as rolling your own crypto (RNG).
Wow. Never heard of dnsdist, that looks cool. I will shortly be embarking on an infra-refresh that is due to include DNS, so will be sure to evaluate it !
Thanks for highlighting it.
This lets me run a single instance of pihole (avoiding all the issues with trying to replicate configs across multiple pihole instances) and still having a solid backup if my pihole server goes down as it is by far the most likely piece of infra to just stop working.
I also use it to route requests to my internal authoritative servers and failover to my external secondary authoritative mirrors as needed. This lets me keep all my local traffic local and still have my external failover as a catch all if my homelab infra is down to my own screw ups or some hardware failures.
I didn't forget it, I know the name, however from the comments received thus-far I've not had the (genuine) pleasure of using it.
I will make an effort to ensure that changes. :)
You can download BIND 10 release 1.2 here: https://downloads.isc.org/isc/bind10/latest/
There was indeed something called “BIND 10”. There is no BIND 10.
1. <https://www.joelonsoftware.com/2000/04/06/things-you-should-...>
ISC was heavily invested in BIND 10, to the point I even got a sticker. That combined with a 1.x release are what make a software project production ready.
I'm sure everyone remembers history differently, but had ISC not gone into cost cutting mode Shane wouldn't have been laid off and we'd all be arguing over what BIND 10 alternative is best. :)
It existed, and even still exists, since people still buy and drive it. But nobody would use that “BIND 10” release today.
This is because software is different from cars, in that you need to use an up-to-date version. You therefore depend on there being a current development branch.
In this way, software is not like cars; it’s more like something like a TV channel or a magazine subscription. If a magazine stops publishing issues, or a TV channel stops transmitting, you wouldn’t say “Omni Magazine is…” or “The Festival TV channel is…”, even though video recordings and magazine issues still exist.
Regarding Whois clients specifically, it seems that Debian maintains its own Whois client: <https://github.com/rfc1036/whois> This is something which Debian usually does not do, and when it happens, it usually means that there is no updated maintained version available, but the software is too important to remove.
It looks as though the entire issue tracker was deleted, not just that specific issue.
What is it about DNS that causes devs to build servers / libraries that incorrectly implement functionality purely based on their own opinion of how it should work? (musl only added tcp dns support recently because they thought it was not worth the effort)
[1] https://web.archive.org/web/20201029102525/https://github.co...
I wrote https://github.com/jmhertlein/comfydns from scratch, just using the RFCs, and what I got when I was "done" was something that mostly worked. Like surprisingly well. But then I just kept finding a small trickle of issues for certain sites.
One that got me was console.aws.amazon.com. It has 4 CNAMEs in the resolution path and (iirc) one weird but was somewhere along there, you get an NXDOMAIN response but still get a CNAME record back. Is thus allowed by the rfc? IMO, no. I was discarding anything that came back with NXDOMAIN (really, NAME_ERROR - Nxdomain is bind parlance). But alas, it's AWS, and 8.8.8.8 resolves it fine, so what am I to do?
So I added a heuristic thats similarly not-incorrect per the RFC where if I get a NAME_ERROR back, as long as the message has records that match my SNAME, I still treat it as a successful query, cache the records, and continue my search.
So... yeah. Lots of weird shit like that. Just mixes of being too defensive in what you accept and then in some cases not defensive enough - I've found searches that resolve for 8.8.8.8 but if I comb through it manually in DIG, I get back results that are clearly a misconfiguration and then I have to come up with some heuristic that rejects them while still being universally applicable.
So yeah. Fun times. I love DNS. (not sarcasm! I promise).
If you are running a large SaaS this might not be the right package for you. But if you are putting together a small site (blog, single page webapp, etc.) this is a great, simple, and easy to deploy tool.
What I'm after is a simple smartphone connection to a local only, no fuss, wifi network --- without any additional setup required.
You can fake DNS and redirect some apps to local servers, but you'll quickly run into issues with HTTPS connections.
If you want to fake an Internet connection on Android using just DNS and HTTP, you'll probably end up bypassing some checks and failing others. Google's apps will likely all report that you don't have an internet connection and won't even try to connect, social media won't work, and other apps will get very confused but will probably still try to operate.
You can work around some of these issues by becoming your own certificate authority and setting up TLS certificates for every website you need to mock, but on Android that'll be difficult to pull off in most apps. Browsers should work fine if you load up your own root certificate (though you need a special secret setting on Firefox for Android because of Mozilla reasons).
For apps, you'd need to root your phone and place your root certificate in the right place on the system image (there are Magisk modules that can help you here). This will fix apps that opt out of user store certificates, but it will break Chrome, since Chrome requires certificates to be recorded in the certificate transparency logs, which you can't do. You can install the certificate in both stores to work around this issue.
Most apps on either iOS or Android implement certificate pinning, which means even if you get your root certificate into the system trust store, you'll still see failed connections. You can hack those apps (for example, using Frida to patch the applications) but you'll have to do each app individually.
I don't know the current status on the connectivity check on iOS, I believe you can get that to work with basic DNS and an HTTP server, but it's possible Apple has gone the HTTPS route too.
Magisk + mitmproxy + Frida + an isolated WiFi network works pretty well for traffic monitoring. With mitmproxy you can also write scripts to fake APIs (which can help you with your attempt to fake the network connectivity status).
To start, you have to enable "airplane mode" on your android phone. This shuts down all communication. If you don't do this your phone will try to use your wireless service for all communication.
Next, you have to selectively enable wi-fi. If there are any other wireless networks in the area that you connect to automatically, you have to disable them, otherwise, your phone will connect and use one of them first.
Finally, with all other communication options disabled, you can connect to and force your phone to reluctantly use the local network with no internet access.