MaraDNS VS comfydns

You could potentially host a dns server in docker (https://mpolinowski.github.io/docs/DevOps/Provisioning/2022-01-25--installing-bind9-docker/2022-01-25/) (https://4sysops.com/archives/configure-a-private-dns-server-in-docker/) or even on windows (https://maradns.samiam.org/) and point the system doing the lookups to use that server. Put in your own records, and then have it do forward lookups for anything else.

While you haven’t used egrep that much, I used it a whole lot, well over 20 times for the automated test setup I have for my open source project. I had to spend most of an hour this morning updating the code to no longer use egrep, and it was non-trivial to update. Here’s the amount of hassle breaking egrep has given me:

https://github.com/samboy/MaraDNS/commit/afc9d1800f3a641bdf1...

This is just one open source project. I’ve seen fgrep in use for well over 25 years and egrep apparently has been around for a very long time too. Just because it didn’t get enshrined in a Posix document—OK, according to Paul Eggert it was made obsolete by Posix in 1992, but apparently no one got the telegram and it’s been a part of Linux since the beginning and is also a part of busybox—doesn’t mean it’s something which should be removed.

I’m just glad I caught this thread and was able to “update” my code.

That is very true, and I do my utmost to avoid any kind of vendor lock in.

Testing is done in a Docker container, so the CI/CD pipeline is available in a Dockerfile and the scripts the Dockerfile imports in to the testing container. In my case: https://github.com/samboy/MaraDNS/tree/master/Docker-stuff

Bug reports and support requests are handled using Github, mainly because that’s what is widely used in the industry right now, but bugs actually fixed are usually described in Git commits, where the information can easily be mirrored.

I think it’s irresponsible to let bugs languish like this. The way I handle bug reports is to say “Hey, look, I just can’t fix this right now because I’m working full time and don’t know when I’ll be able to get around to fixing this without getting paid for my work.” E.g. https://github.com/samboy/MaraDNS/issues/84

I can see why a lot of people don’t do that: It’s a little rude, and there’s a small but significant chance it’ll become a flame war. I have only once had someone get rude in a ticket when I told them “That’s not a bug report, but a support issue”; I ended up deleting the ticket. GitHub also allows you to edit or delete other people’s comments in your tickets, as well as locking the conversation.

Since I write a Lua-parsed DNS server which works with IPv6, even when compiled for an ancient version of MINGW on Windows XP (which has IPv6 support but no built-in IPv6 parser), I had to write an IPv6 address parser.

No, I did not add dotted quad notation to the parser. No, you can not have more than four hex digits in a single quad; 00000000 becomes 0000:0000 with the parser. It supports “normal” stuff like ::, ::1, 2001:db8::1, and even non-normal stuff like “2001-0db8-1234-5678 0000-0000-0000-0005” (to be compatible with the really basic IPv6 parser I put in MaraDNS’s recursive resolver nearly two years ago), but none of the corner cases in the linked article.

The IPv6 test cases in the automated test for the parser are at: https://github.com/samboy/MaraDNS/blob/master/deadwood-githu...

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