MaraDNS: A small open-source DNS server(github.com)
github.com
MaraDNS: A small open-source DNS server
https://github.com/samboy/MaraDNS
36 comments
Finally a good looking new entrant in the DHCP space. There's a severe lack of good quality modern DHCP software (as in, there's a usable API available, easy to scale and make redundant, etc.). Good luck with the project!
Sorry to jump in, what do you mean under "severe lack of good quality modern DHCP software"?
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?
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?
That's why I elaborated. I want(ed, it was at a previous job) a DHCP server that has a good usable API (so not the sorry excuse that isc-dhcp-server has), works reliably (isc-dhcp-server is not reliable in HA mode), allows for easy custom integrations/plugins/hooks to third-party systems (recompiling C++ projects is not it, cough Kea). Basically like CoreDNS, but for DHCP.
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.
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.
I like and use it. However if you use it as fully recursive DNS (without upstream server), you may run into some things that resolve differently from BIND, caused by different interpretation of the RFC. Sadly can't find the details right now and the github issue 56 was deleted.
Do you know why the issue was deleted? I find it a bit concerning a project would ever delete an issue unless it was spam or abusive in concept, especially a security critical project like DNS.
> Do you know why the issue was deleted?
It looks as though the entire issue tracker was deleted, not just that specific issue.
It looks as though the entire issue tracker was deleted, not just that specific issue.
Doesn't support EDNS and doesn't implement truncated responses the way the RFCs specify it seems
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...
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...
It's because the RFC is fairly short but DNS as a live system is very very complicated. Plus not everything is BIND anyway and you'll find weird things even from large providers.
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).
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).
Still accessible here: <http://web.archive.org/web/20201029102523/https://github.com...>
FWIW, I've used MaraDNS for a while, about 10 years. It works nicely for my small domains. It is missing some things that require I do some workarounds, but for the most part, it does what it says on the wrapper. Its not hard to configure, no messing around with multiple/many backends and backend configuration. Just simple db files, easy to keep in git, easy to deploy, easy to manage and change.
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.
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.
Can a DNS server be used to fake Android/iOS internet connection tests?
What I'm after is a simple smartphone connection to a local only, no fuss, wifi network --- without any additional setup required.
What I'm after is a simple smartphone connection to a local only, no fuss, wifi network --- without any additional setup required.
On Android: not really. Android's connectivity check will connect to Google.com over HTTPS to verify connectivity.
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.
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.
So basically, it's not practical to do this.
I've done it to monitor my phone for weird traffic, but I wouldn't recommend it unless you're dedicated and willing to deal with janky tooling.
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).
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).
I'm looking to allow users with stock, unmodified software stack to easily connect to a local only wifi network with minimal headaches. Magisk, etc. is not an option.
What's keeping you from connecting to the WiFi? As far as I know, Android and iOS can connect to offline networks just fine. You may need to disable the "network quality" test for that particular network, but I'm pretty sure stock Android stay connected just fine.
It can be done --- just not easily or intuitively.
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.
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.
You need a DNS server and an HTTP server supporting virtual hosts. The list of domains and expected responses by different platforms are listed on Wikipedia [1].
[1] https://de.wikipedia.org/wiki/Captive_Portal
[1] https://de.wikipedia.org/wiki/Captive_Portal
Thank you
Honestly I think I'll be sticking to the big-boys: Knot DNS, Knot Resolver, Unbound and NSD. Those projects are well established, open-source, well maintained, battle-tested and as secure as a DNS server can be. I'm not sure what MaraDNS brings to the table that makes it exponentially better.
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).
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).
I'm fairly confident that MaraDNS, first written in 2001 and still around today, counts as well established. It's a decade older than Knot DNS.
It's old than Knot, NSD, Unbound and the current iteration of Bind (not sure how much they rewrote for Bind 10, but it's a lot I believe.)
Your information may simply be out of date, but: There is no ”BIND 10”. There was an aborted attempt some years ago with that name, but the current BIND is BIND 9, and there is, AFAIK, no current plans for a BIND 10.
Eh, no? BIND 10 was under active development for years before ISC ran out of money. The continued work on BIND 9 is only happening thanks to numerous sponsors and large organizations with maintenance contracts.
You can download BIND 10 release 1.2 here: https://downloads.isc.org/isc/bind10/latest/
You can download BIND 10 release 1.2 here: https://downloads.isc.org/isc/bind10/latest/
That latest release of that “BIND 10” is nine years old. The way I heard it, “BIND 10” was created at a time when BIND 9 development had stagnated, and BIND 10 was one of those “let’s rewrite it all” projects that you should never do¹. Consequently, it was a boondoggle, and was relatively quickly abandoned in favor of restarting BIND 9 development, which has continued very nicely ever since.
There was indeed something called “BIND 10”. There is no BIND 10.
1. <https://www.joelonsoftware.com/2000/04/06/things-you-should-...>
There was indeed something called “BIND 10”. There is no BIND 10.
1. <https://www.joelonsoftware.com/2000/04/06/things-you-should-...>
Semantics I guess. By your logic the Dodge Viper never existed because it was discontinued.
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. :)
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. :)
> By your logic the Dodge Viper never existed because it was discontinued.
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.
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.
Heh. I'd actually be super curious how much of a base linux system is still "actively maintained" by that metric. I gave up tilting at windmills trying to get the default whois clients in any of the major distros updated after a few months of trying.
I know that Debian, as a rule, removes packages which are not maintained “upstream”.
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.
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.
I've been a fan of the powerdns project for many years. I have used it for authoritative, recursive and load balancing projects with great success. These days I use their dnsdist project to have fine grained control of DNS at my house to account for my various homelab shenanigans and provide that 99.99999% uptime the family demands.
> their dnsdist project
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.
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.
My particular "killer app" for dnsdist right now is at my house I have 2 machines running dnsdist, set to forward to my pihole by default with health checks. If the health checks fail, the dnsdist daemons failover to google/cloudflare/etc.
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.
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.
Right but you forgot PowerDNS which is rare to be able to support RDBMS as its native backend with third party web UI and there's also CoreDNS which is pluggable and graduated as a CNCF project.
> you forgot PowerDNS
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. :)
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. :)
Please also consider coredns.
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.