Earlier today I was approached on split-horizon dns and whether I can implement something like this. The short answer is no, but you can still do split horizon DNS with delphinusdnsd with pf. It requires setting up 2 or 3 delphinusdnsd bound on several interfaces including localhost on their own port. With pf rules you would then do an rdr-to 127.0.0.1 port X where X is the delphinusdnsd that it should speak to. You would have the same setup on both replicant and master and they would axfr on their own unique axfr port. A large list of IP's can be assembled from this website (iana.org).
The reason I'm hesitant on bringing back split horizon to delphinusdnsd is that it doesn't really fit well with AXFR, it's a mess there. The hack that I explained it the first paragraph keeps it on a boundary though and could be done well. Debugging split horizon dns is a pain too, but I think with regions configured in all running delphinusdnsd's you can have an overview of which delphinusdnsd was hit. You just gotta watch the logs closely and follow up to complaints. Good luck!0 comments
Happy Valentines day. Delphinusdnsd is programmed on OpenBSD which is Y2038 safe, but the ports may break on January 19th, 2038 or after. I don't know what will happen actually. I'll keep an eye on this. 2035 is likely the last year when I will work on this code, perhaps there will be more light, then.0 comments
This is a fix for Linux platform. From the commit log on the STABLE_1.4 branch:
This is the first STABLE_1_4 commit leading to release 1.4.1, changes: -replace linux's TAILQ macros with libbsd's -replace TAILQ_FOREACH for linux with libbsd's TAILQ_FOREACH_SAFE -increase buffer buf in struct tcpentry by 1 more byte to prevent possible overflow -change lookup_zone to take another argument to indicate size of buffer -remove length variable in tcploop to squelch warning -replace a casting pointer with an unpack16() in tcploop -fix formatting of serial log in raxfr.c (this fixes my output in linux). This effort fixes formatting and crashes on Linux/arm and fixes a general off-by-one (not sure if it's exploitable).Hope this will be OK, the downloads are available all I have left to do is signify the SHA256.sig file (will be done shortly). Enjoy. 0 comments
What tools did I use? What experience did I have to have?
UNIX tools I used to write and debug delphinusdnsd
It's 2020 now, why did I decide to keep doing this?
If I could turn back time would I do it again?
1.3.0 was an oddball release because I applied to funding from the federal german government in a program called Prototypefund.de, shifting the release date early by half a year. I didn't get selected with delphinusdnsd. Meaning, I paid out of my own pocket to work on version 1.4.0 and 1.4.1 (January 2019 through February 2020). In 2018 between summer and christmas I had another project (OpenBSD powerpc64 port which ultimately failed) while waiting on the selection results of prototypefund. All releases before 1.3.0 were also constructed from my spare time as I could find it. I'm glad 1.4.X is out and I'm looking forward to programming on 1.5.0 (expected to be released in late December). Someone I met is working on an OpenBSD port for me and I'm looking forward to featuring him on the Credits section of the delphinusdns.org site once the work is committed at OpenBSD. The porting work is no easy feat and I'm glad someone is doing this for me.0 comments
I believe the fixes I made to delphinusdnsd (on linux) were good. I'm going to backport the code to the STABLE_1_4 branch soon and then tag it RELEASE_1_4_1. I'm gonna run the code as it is now for another week on the particular Linux computer that had problems throughout december and early january and if I don't see any more crashes then it's a done deal. Sorry for inconveniences. This I believe did not affect BSD versions of this code, only Linux although and off-by-one was fixed (I think), that should have impact on all platforms.0 comments
Sorry to bring these bad news... I have noticed segfaults on Linux but not on OpenBSD, in the TCP engine (tcploop()). I have for the time being reinstalled nsd on the linux replicant and I'll have to see what's causing this. I know of one possible off-by-one buffer overflow but I couldn't exploit it with my test program. I'm still looking. I suspect that the problem may be with the linux TAILQ macros as I remove a member from the tailq and it wasn't _SAFE (which is only found in libbsd) so there is some room for corruption there. I'll look at replacing the TAILQ macros with their libbsd equivalents for 1.5.0 and possibly backport it to 1.4.1. Still deciding what to do and how to it correctly. I haven't seen the OpenBSD delphinusdnsd with this behaviour, and that is what I care most about.2 comments
I have released delphinusdnsd 1.4.0. More info is found in the news.html entry. I'd like to thank everyone that contributed to this release (special thanks to FreeLogic and PiRATA).0 comments
Revision 1.98 of reply.c does more reply length checks and truncates when appropriate. Before it gave weird answers because it excluded RRSIG's and fit NSEC3's which was bogus. PowerDNS recursor noticed this as bogus and would mark all zones on those nameserver as bogus (as tested). Of course PowerDNS was right in this, and my code was wrong. Much thanks to Peng_ in #dns on freenode who helped me debug this problem.0 comments
I found some problems with delphinusdnsd and I'd like a week of testing before tagging it a release. I'm hoping for a release around or on January 2nd, 2020.0 comments
By clicking on the header of an article you will be served a cookie. If you do not agree to this do not click on the header. Thanks!
Using a text-based webbrowser?
... such as lynx? Welcome back it's working again for the time being.
Older Blog Entries