10 ms·

MaraDNS: A small open-source DNS server

88 points by axiomdata316 3y ago

rini17 3y ago
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.
- Daviey 3y ago
  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.
  - duskwuff 3y ago
    > Do you know why the issue was deleted? It looks as though the entire issue tracker was deleted, not just that specific issue.
- teddyh 3y ago
  Still accessible here: <http://web.archive.org/web/20201029102523/https://github.com/samboy/MaraDNS/issues/56 http://web.archive.org/web/20201029102523/https://github.com...>
- bogantech 3y ago
  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.com/samboy/MaraDNS/issues/54 https://web.archive.org/web/20201029102525/https://github.co...
  - joshcafe 3y ago
    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 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).
jqpabc123 3y ago
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.
- mschuster91 3y ago
  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 https://de.wikipedia.org/wiki/Captive_Portal
  - jqpabc123 3y ago
    Thank you
- jeroenhd 3y ago
  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.
traceroute66 3y ago
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).
- kanisae 3y ago
  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.
  - traceroute66 3y ago
    > 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.
    - kanisae 3y ago
      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.
ckdarby 3y ago
Powerdns and dnsdist are incredible projects with a lot of features. Dnsdist has particularly added a lot of flexibility with ebpf/lua support. 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 https://github.com/bluecatengineering/dora Disclaimer: Opinions mine. Work at a DNS, DHCP, IPAM company.
- sofixa 3y ago
  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!
  - jesterson 3y ago
    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?
    - sofixa 3y ago
      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.
hpcjoe 3y ago
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.

88 points by axiomdata316 3y ago

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.

Daviey 3y ago
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.
- duskwuff 3y ago
  > Do you know why the issue was deleted? It looks as though the entire issue tracker was deleted, not just that specific issue.
teddyh 3y ago
Still accessible here: <http://web.archive.org/web/20201029102523/https://github.com/samboy/MaraDNS/issues/56 http://web.archive.org/web/20201029102523/https://github.com...>
bogantech 3y ago
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.com/samboy/MaraDNS/issues/54 https://web.archive.org/web/20201029102525/https://github.co...
- joshcafe 3y ago
  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 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).

jqpabc123 3y ago

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.

mschuster91 3y ago
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 https://de.wikipedia.org/wiki/Captive_Portal
- jqpabc123 3y ago
  Thank you
jeroenhd 3y ago
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.

traceroute66 3y ago

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).

kanisae 3y ago
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.
- traceroute66 3y ago
  > 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.
  - kanisae 3y ago
    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.

ckdarby 3y ago

Powerdns and dnsdist are incredible projects with a lot of features. Dnsdist has particularly added a lot of flexibility with ebpf/lua support. 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 https://github.com/bluecatengineering/dora Disclaimer: Opinions mine. Work at a DNS, DHCP, IPAM company.

sofixa 3y ago
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!
- jesterson 3y ago
  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?
  - sofixa 3y ago
    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.

hpcjoe 3y ago

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.