I have modified the centroid.eu blog (found at centroid.eu) to be working for delphinusdns.org's website. I will be covering any news here, that are of short term nature including announcements. If you come across this you may wonder why I didn't have this since the beginning, and well, I didn't think I'd have so much news at first. I hope this will keep you informed. There is an RSS feed if you're interested in subscribing it. It's shortened and you still have to click on it for the full article but it's better than no RSS feed. Enjoy.
I'm back after a 2 months pause. It was simply too hot to be coding this summer. We had 3 heatspell periods this year and since delphinusdnsd is written on my spare time I wasn't willing to kill myself on it. I did commit a minor fix (a log in a return, more on that later perhaps) in the daemon yesterday and I'm trying to aquaint myself with the code again so that I can work towards the release at New Years 2020. What needs to be done is an axfr'ing slave mode to delphinusdnsd. I'm curious whether I'll make it. Also I'm currently unemployed looking for work but the chances are I will not find any work until next year. If I do find work, this codebase will suffer unfortunately, it's a matter of priorities. I'd rather be making money and code on delphinusdnsd on the side than the alternative. Also I'd like to point out that I have left IRC chat until October some time so that I can focus on this work. Otherwise I'd be chatting along and the code would suffer.
Here is a real log taken from my log file, this is how to read it:
The other day I installed delphinusdnsd as a test, on a vanilla ubuntu. All the packages that the README file listed worked, except the 'make' package was not listed. I added that with apt-get install make (or apt install make would work too). This was an error that was so early that it didn't even attempt to compile delphinusdnsd because make was missing. I will examine this on another vanilla debian system and if it needs make there too, I'll add 'make' to the list of packages to install in the README hints.
I did this change earlier, and changed where the default configfile is expected to be by the daemon. Before this change the default config file was just /etc/delphinusdns.conf. This change was made to keep things a bit cleaner. I have updated everything in the source and will look at the website in the near-future.
The name was picked in honor of the constellation delphinus (the dolphin) in the summer night sky. While it has to do with dolphins I don't want this to become the symbol for it. I want it to be the area known as "Job's coffin" with extension for the entire known constellation. Why it was called Job's coffin I do not know, and I didn't pick it for that. Here is a cut out from xephem program how it looks:
As you can see in the starchart there is to the right of delphinus the star Altair (in constellation Aquila). The star Altair makes up an area in the summer night sky known as the summer triangle. Delphinus is not inside this triangle but somewhat to the left of it. Left of Delphinus is Pegasus, above it is Cygnus, and below it is Aquarius. To the right as I said is Aquila constellation. Size mattered when I picked delphinus. This constellation is not a large constellation, much like my daemon which is not that big.
If anyone ever finds Alien contact out of delphinus I'd be humbled but it isn't part of what I had in mind with delphinusdnsd. Inside Job's coffin there is two stars named after an astronomer and they are the latinized name of him backwards Sualocin and Rotanev. Easy to remember. But has nothing to do with this nameserver daemon. But they are names :-).
In the past I've used dolphin names such as goldflipper.de and goldflipper.net but I'm moving away from that. The .net is expired and the .de will be expired in 2020. So again there is little to be associated with dolphins. But they thank you for all the fish! ;). So I wanted to be perfectly clear on the naming of this dns server, just so that someone doesn't claim "I like dolphins or something". Nice animals, but I have little in common with dolphins. I live inland from the coast and never had contact with a dolphin other than seeing them at a Marineland-like water exhibition. The star Sualocin is centered around RA 20:39:40 or so, if you're looking for it with a scope. OK I hope this didn't turn out to be a rant but rather a lecture on what inspired the name of delphinusdnsd.
Much in the style of modern-built software around security (opensmtpd is one example), delphinusdnsd does compartment it's tasks. Here is a sample and massaged ps output:
# ps auxww | grep delphinusdns |\
awk '{ printf("%s\t", $1); for (i = 11; i <= NF; i++) \
printf("%s ", $i); printf("\n"); }'
root delphinusdnsd: master (delphinusdnsd)
_ddd /usr/local/sbin/delphinusdnsd -l
_ddd delphinusdnsd: unix controlling socket (delphinusdnsd)
_ddd delphinusdnsd: AXFR engine on port 10053 (delphinusdnsd)
_ddd delphinusdnsd: udp parse engine 0 (delphinusdnsd)
_ddd delphinusdnsd: TCP engine 0 (delphinusdnsd)
_ddd delphinusdnsd: tcp parse engine 0 (delphinusdnsd)
The processes are as follows:
Occasionally I use the EDNS compliance tester to test my zone(s) to see if I'm still good. The result said "All OK" this morning. Happy joy!
Before tonights snapshot, a 'dddctl query' AXFR was able to authenticate with TSIG. But it wasn't able to verify what came back with TSIG. Now it can. and I can only test it so much because I don't know how to MITM in a quick enough time. TSIG is explained in RFC 2845. It stands for "This #### Is Good!". I'm very happy, as the routines I changed pave the way for slave server mode.
OpenBSD 6.6 was released yesterday, and my only production delphinusdnsd server will get an upgrade likely next week. It uses delphinusdnsd snapshots, and I have some patches waiting for using the malloc_conceal method. However this will break backwards compatibility in delphinusdnsd snapshots for the OpenBSD architecture, when I apply them, and I will. So if you're tracking snapshots, and you use OpenBSD, you want to upgrade to version 6.6 by next week. Thanks! This also means that the 1.4 release in new years time, will also require OpenBSD 6.6 if you prefer using OpenBSD.
Realistically there is only six weeks left for development. This gives some outtime for christmas and a few days for testing. I have thought about what I still have to do:
I fixed two things since yesterday. The biggy that will be noticed is the REFUSED answers. They were broken all along because they didn't tag on the question in the REFUSED answer. I noticed OpenBSD doing many repeated questions on this, so there is no savings anymore. REFUSED is refused now. Another change I did was in the notify code on axfr.c. This is the most recent change. It fixes IPv6 notifies which were probably never tested. I tested it this morning.
I have spun up two vm's on my servers to take a test sub-zone and noticed that the code for delegation/referrals was broken in delphinusdnsd. I have done most of the grunt work today, but there is still a condition with RFC 5155 Referrals that I must get right. I left it for tomorrow afternoon. Hopefully that will be done for Hallowe'en. Many thanks to Habbie and hawk on #dns for helping me find the bugs and having explanations at hand. Since this is only a small side-track I think we're on track for having a replicant/slave mode for the new years release.
I'm writing you this because it's a historic moment. About one hour ago Delphinusdnsd on an internal IP (192.168.177.40) did a zone transfer from another internal host (192.168.177.2) also running Delphinusdnsd. It did check with a TCP query checking for an SOA, determined it needed to AXFR and got the remote zone. It then scheduled a reboot to reread this zone file into its database. I'm happy to report everything went well. I have committed the code where I am now so it's out there, but perhaps not working for any OS other than OpenBSD. My next steps are fixing the plumbing associated with DNS Notifies, making sure TSIG works across the set of procedures and pondering what I should do in case of an SOA expiry event.
I never would have dreamed I was so close to the bacon. I'm gonna try to put this in production tomorrow on the ip6.centroid.eu sub-zone. Cheers! I think I'm on track for the new years release, given testing.
In my test lab delphinusdnsd in replicant mode (in debug mode) successfully got a notify from nsd and subsequently pulled the zonefile from nsd.
adding SOA values to zone petphi.internal.centroid.eu petphi.internal.centroid.eu -> 2019110304, 3600, 1800, 1209600 on descriptor 3 interface "192.168.177.2" dns NOTIFY packet from 192.168.177.1,\ replying NOTIFY request on descriptor 3 interface "192.168.177.2" from 192.168.177.1 (ttl=64, \ region=255) for "petphi.internal.centroid.eu." type=SOA(6) class=1, answering \ "NOTIFY" (149/45) zone petphi.internal.centroid.eu is being notified now new higher serial detected (2019110305 vs. 2019110304) setsockopt: Numerical argument out of domain scheduling restart at Mon Nov 4 11:59:39 2019This is another milestone, showing that a delphinusdns replicant (also called a slave) can interoperate with other nameservers.
Slavery is a scandalous human condition, it hasn't brought us further. In DNS there is a primary master server usually that controls when zone changes are made. Any other server that does an AXFR from this master is historically called a slave. I asked the DNS community in #dns freenode channel what some similar names are that would be relevant to get rid of the word slave. We settled on "replicant". A replicant by means of definition is a replicative which when dug further is "Of, pertaining to, or causing replication". This is a good word. However please forgive me if I still use the word "slave" because the s word is so popular in the community and I want to let people know what I'm talking about. Officially though in delphinusdnsd we're using replicant to indicate a replicant daemon.
I have marked off Replicant/Slave mode off my TODO file as DONE. Now all that remains is testing, refactoring and minor changes.
For 1.4.0 release - a github mirrored copy - fix the DNSSEC code so that a KSK key rollover is allowed [DONE] - TSIG support would still be nice [DONE] - CAA RR support - More ciphers for signing (GOST, ECDSA, Elliptic Curves) [ECDSA DONE] - Slave AXFR mode (with TSIG) [DONE] - Redo TCP support [DONE]You may remember that I applied for a grant last year and this disturbed the release cycle with the 1.3 release being done in summer. So I didn't get the grant, but I did get more time to write on delphinusdnsd (1.5 release cycles) in order to get back to ta winter release cycle. These are the major goals set and (mostly) completed. If you want to see where things were and where we're going then look up the TODO file in the CVS repo.
Also I may put this out now, the 1.5 release will be mostly bug fixes but little new features as I'm catching a breather. It may also be a time for others to contribute patches and possibly join development. The 1.6 release will be much stronger as I plan to add the feature of DNS Updates and possibly fix replicant mode so that delphinusdnsd doesn't have to restart upon a successful AXFR. It also depends how much time I got I guess. That's what's on the menu though. I plan to be writing on delphinusdnsd until I'm 59, so there is still time to perhaps get it done some day this adds another 15 years to development life.
The CVS stuff gets rsync'ed to the webserver. It just so happens that the time when the snapshot is created conflicted with the time when this was done. I have manually fixed this now as it made a corrupted tarball for downloading snapshots. Sorry for inconvenience. In future the snapshot script will sleep a bit before executing a cvs checkout.
I have roughly one month and a half to test delphinusdnsd replicant and the overall stability of the soon to be 1.4 release. You can help by sending some queries to the following nameservers:
You can test the following zones on wedge: ip6.centroid.eu, otherzone.centroid.eu. And the following zones should work on trapezoid port 9053: centroid.eu, dtschland.eu, solarscale.de, goldflipper.de, schweinfurtdating.de, delphinusdns.org, virgostar.net, mainrechner.de, freifunk-schweinfurt.de. The trapezoid server is currently still running NSD on port 53, but I plan to change that in time, when I feel secure that I can run delphinusdnsd in its place.
Thanks for any help and one or two queries to port 9053 on trapezoid. Do report back any errors too please.
In order to test delphinusdnsd on other platforms I had to install a Microsoft Hyper-V FreeBSD instance. I couldn't download from delphinusdns.org though because of this:
It seems to affect only the Hyper-V resolver behind a BIND. The BIND serves the root-servers.net's as AUTHORITY data, and this resolver sticks it together as an answer. Bad things result. Please Microsoft, fix Hyper-V's DNS!
In the meanwhile i've taken the freebsd instance out of the extern LAN area (which is 192.168.127.0/24, I suspect) and everything works now. PS sorry for the blurry photo, I couldn't make a screenshot because I couldn't figure it out with a Macintosh keyboard (how to print, I was told F13 but it doesn't work.. PEBCAK in that case).
I have synced delphinusdnsd snapshots along all operating systems that this daemon supports. It works on Linux, OpenBSD, NetBSD and FreeBSD. If you want to test, you can test. But please, be careful as things have changed. The snapshots were updated at 8:30 CET this morning which is outside the usual window of midnight. I did this to expedite this a bit.
As a test I have put delphinusdnsd in replicant mode on trapezoid.centroid.eu. This is a bold move and I hope nothing breaks. I'm looking forward to running this indefinitely until the 1.4 release at which point I'll update it. As a backup I have an NSD on rhombus.centroid.eu but it lacks an IPv6 address.
PiRATA is someone from Portugal I think who I helped getting delphinusdnsd going on IRC. It was a pleasure, learning what the issues were. One thing that stood out is, that 1.3 is quickly becoming old. Although the 1.4 release is still five weeks away, I'd recommend anyone going to try out this daemon, to use a snapshot. What you're seeing in the snapshots right now is basically 1.4 without testing and minor bug fixes. I'd say PiRATA was an advanced user hence going through the configfile issues was easy. I'm still trying to make it easier for a newbie, any feedback is welcomed.
Remotelog was added in June 28, 2011 and thus is over 8 years old. It's time to remove it as since then syslog on openbsd has been improved a lot. The OpenBSD syslogd got TCP support in december 2014 and improved since then. So our remotelog was much older and is superfluous now. On top of that it used SHA1 HMAC which is outdated. I'll do the changes this week.
In tomorrows snapshot there will be a change in delphinusdnsd. It was a change that took 2 hours of inspecting, changing the code, and additional 30 minutes was spent to test this. It's not a big change but it for the first time allows multiple TXT records in a dns name.
;; QUESTION SECTION:
;centroid.eu. IN TXT
;; ANSWER SECTION:
centroid.eu. 86400 IN TXT "v=spf1 ip4:5.9.87.75 ip6:2a01:4
f8:162:1167::2 ~all"
centroid.eu. 86400 IN TXT "My DNS Server is delphinusdnsd
on kite and trapezoid, I hope this was helpful!"
Like so, on the production nameservers kite and trapezoid at centroid.eu. Much
thanks to a user named PiRATA who lightly prodded this because I'm trying to
help with getting DKIM records going. This is likely the last "major" change
that I'M willing to do for this until 1.4, unless something urgent pops up.
Seasons greetings! I'm on the end run for testing 1.4. The version 1.3 is totally outdated and it doesn't make sense anymore to install it. Be part of the testing and install a snapshot if you want to try delphinusdnsd. The 1.4 release will be on or before december 31st. Next week I'm going to try to run delphinusdnsd entirely off all my nameservers. If it unearthes any bugs, I'll be fixing those within reasonable time. Have a merry season!
December means there is only about 2-3 weeks of testing left before I package it all into a tarball and checksum it for the 1.4 release. This doesn't mean I sit here waiting for that moment. Currently I'm patching the delphinusdnsd against unaligned accesses as found on a MIPS64 machine of mine. In the process it revealed that there is a problem with TSIG signing on the server side. I've spent 24 hours on this problem already, it seems to be a byte order translation problem because it pops up on another big endian host but I haven't pinned it down yet. On little endian architectures the problem doesn't show up. Which is weird because all values involved in the signing process have to be big endian anyhow. Odd. This problem will take me into next week. Thats the status update on the "testing".
Have a merry first advent as we count down the weeks to christmas.
Yesterday I got my Raspberry Pi (v1) out and did some changes to the Linux port of delphinusdnsd. This morning when testing the snapshot changes I noticed I broke it. So tomorrows snapshot should work again. Fixes include:
Revision 1.89 in delphinusdnsd.c broke descriptor passed AXFR's. Tomorrows snapshot should have the fix. If you used a different port than 53 as an AXFR port then it would have still worked. Unearthed when I wanted to try out drill on FreeBSD/arm with my raspberry pi. This took the entire morning in debugging and code reading to find the bug. I finally found it with a diff between December 5th snapshot and todays snapshot.
Seasons Greetings! We're on schedule for the 1.4.0 release in exactly three weeks. There is stuff that I'm aware isn't working right (like proper tsig responses), and if they don't make it in for 1.4.0 then they won't be in until 1.5.0. That's just the matter of fact. I'm testing delphinusdnsd on as many platforms and architectures as possible and every time I do I find something new that's either a bug or lacking. Realistically I don't have time to start any grand new things in these last three weeks. In exactly 2 weeks is christmas eve. This will be an interruption of a few days too.
Christmas is in 12+1 days (depending where you live). It's only proper that we provide a christmas tree to lay our presents under. I got one! It exploits the fact that dddctl query does not filter escape codes (will be fixed in 1.5.0 hopefully). Here is the xmas zone in case you wanted to use it:
zone "xmas" {
xmas,soa,86400,omega.virgostar.net.,hostmaster.centroid.eu.,2019122401,3
600,1800,1209600,86400
xmas,ns,86400,beta.internal.centroid.eu.
xmas,txt,86400," ^[[32m^[[31;1m*^[[32m^[[0m"
xmas,txt,86400," ^[[32m***^[[0m"
xmas,txt,86400," ^[[32m**^[[31;1m*^[[32m**^[[0m"
xmas,txt,86400," ^[[32m*^[[31;1m*^[[32m*****^[[0m"
xmas,txt,86400," ^[[32m******^[[31;1m*^[[32m**^[[0m"
xmas,txt,86400," ^[[32m***^[[31m*^[[32m*******^[[0m"
xmas,txt,86400," ^[[33m*^[[0m"
}
Have a merry time! And please, don't drink and drive!
Due to some family commitments I have to move the release closer to christmas and the 29th which is what I would have chosen is a sunday. So it'll be the 27th (a friday). So the 26th and 27th will be final tests, next week the 16th throughout the 21st will be any last minute coding changes.
Today I installed NetBSD and noticed I don't really know too much about this BSD. It was sorta hard. But I finally managed to install Delphinusdnsd to it and it prompted for some makefile changes. So then I'll be revisiting all test platforms tomorrow and on the 26th and 27th after which I will tag a release in the tree and make the tarball available. Unfortunately christmas is in the way or else I'd have a few more days. And commitments after the 27th until new years take away also a few more days. If you want to try out Delphinusdnsd grab a snapshot and test. It's likely not going to change in a big way in these last three days. If you'd rather wait for the 1.4 tarball, there is eight days left to wait for that.
I'd like to wish you a happy december solstice and a merry christmas. I'm going away for 6 days from my work setup until the 26th when I'll be back in my apartment and doing the final check for delphinusdnsd and then releasing it.
Here is a patch, if you're using the daemon. Unfortunately this won't be available until the release day. I'm mindsearching if I'm going to put this release off until next year (2020).
Sorry to bother you again, the last patch was wrong, I had edited the article directly but you wouldn't see it if you didn't reload it. Here it is again.
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.
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.
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).
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.
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.
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.
What tools did I use? What experience did I have to have?
When I started writing wildcarddnsd/delphinusdnsd I had 10 years of experience
with the UN*X Operating System. I had a lot of sysadmin experience and some
C programming experience. I started in 2005 (it was autumn) originally
the source code was checked in at sourceforge I believe. I personally felt
I was "ready" to lay down this code.
UNIX tools I used to write and debug delphinusdnsd
Literature used
Countless books about DNS, Unix network programming and YACC guided me
along the way, 10 years experience with UN*X OS's in 2005 started me on
this journey.
It's 2020 now, why did I decide to keep doing this?
I have put 15 years under my belt with this, I intend to do another 15
(god willing). It is a lot of fun steering my own project.
If I could turn back time would I do it again?
Yes.
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.
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.
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!
When you do a dig for "+dnssec delphinusdns.org A" you will see something
like this:
; <<>> dig 9.10.8-P1 <<>> +dnssec delphinusdns.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53016
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;delphinusdns.org. IN A
;; ANSWER SECTION:
delphinusdns.org. 86385 IN A 85.10.199.4
delphinusdns.org. 86385 IN RRSIG A 10 2 86400 \
20200502072347 20200218072347 64280 delphinusdns.org. ...
I have added a ... in place of the signature in the RRSIG record. What I'm
most concerned with is the signature expire fields and the signature inception
fields.
20200502072347 20200218072347Those two. If a DNSSEC zone goes beyond the date of the "signature expiration" the zone is marked as expired thus bogus and remote recursive nameservers may reply with SERVFAIL. Obviously one doesn't want that so there must be a timely maintenance to up the signature expiration. I do this semi-automatically with a script and some typing (the tab expansion in the shell is great help here). I call this "re-signing the zone".
It is done with dddctl sign command and dddctl will take the current time and go back 2 weeks in order to create a small overlap. This is needed to prevent unsynched clocks to always recognize the window between inception and expiration. The new inception was 18th of February and is exactly 2 weeks in the past. The new expiration is roughly 2 months in the future (by default in delphinusdns) so this zone has ample time (after a month perhaps) to do a zone re-sign. Re-signs are easy, you take the previous keys and just resign the zone (with a new SOA serial value so that the replicants can pick up the change).
In the past while being the only sysadmin at an operation I discouraged the use of DNSSEC because of this. With just one sysadmin there is no backup, and if you fall sick for over 1 month time the business will suffer. So either automate this and hope that the automation never ever fails or don't do DNSSEC and open your domain to forgeries (as DNSSEC has cryptographic integrity). It's a choice one must make, and it isn't easy. DNSSEC really requires two hostmasters who know what they're doing, to have a backup when the other falls sick or is unavailable for whatever reason.
BTW you can't use re-signing to do key rollovers, they have to be done seperately. See the handbook for how to do this.
I have some uncommitted code to allow the double-signature method for rollovers.This should allow algorithm rollovers eventually. I was stuck trying to make this work though. My main source of dns programming advice was able to help me out again interpreting RFC 4034 right. It turns out in the scenario of introducing a different sized key (3072 bits vs. 1024 bits) I was not sorting the RR's right in canonical mode. The problem lies in my interpretation of RFC 4034, section 3.1.8.1 where the signature is produced by going over the RRset. In my code (not changed yet) I ordered around the wire format of RR(i), but instead the ordering is done first around the RDATA instead. Thanks goes to Habbie once again! Since algorithm rollovers aren't supported in Delphinusdnsd 1.4.x I don't feel I need to backport changes here. But we'll likely see a different sorting algorithm for 1.5.0.
I have changed the default key creating algorithm to alg 13 from alg 8, in the -current code. Alg 13 is ECDSAP256SHA256. This is generally recommended in IRC #dns. It will not affect 1.4.x release which still uses alg 8.
I just wrote a little in the handbook regarding verifying what dddctl sign produces. It's often a good idea to take this step in order to unearth any unintended bugs. Thanks!
In 1.4.1 the regress hierarchy may be broken. I never checked this before release time. In fact I know it is because starting a zone without SOA and NS records will exit the daemon, afaik. I just corrected this in case anyone is using this (the regress only works on OpenBSD), while taking out mention of solarscale.de which as an old domain name of mine that isn't in my possession anymore.
Here is a signing script I constructed over the last few months.
#!/bin/sh
DOMAIN="centroid.eu"
TODAY=`date +"%Y%m%d01"`
SERIAL=`dddctl query -Q127.0.0.1 soa $DOMAIN | grep -v '^;;' | awk -F, \
'{print $6}'`
SIGN_ARG1="-x $SERIAL -k K${DOMAIN}.+008+48082 -z K${DOMAIN}.+008+57861 \
-i $DOMAIN -n $DOMAIN -o ${DOMAIN}.signed"
SIGN_ARG2="-X -k K${DOMAIN}.+008+48082 -z K${DOMAIN}.+008+57861 \
-i ${DOMAIN} -n ${DOMAIN} -o ${DOMAIN}.signed"
echo signing for $DOMAIN ...
if [ $SERIAL -ge $TODAY ]; then
SERIAL=`expr $SERIAL + 1`
dddctl sign ${SIGN_ARG1}
else
dddctl sign ${SIGN_ARG2}
fi
echo checking result for domain $DOMAIN ...
dddctl configtest ${DOMAIN}.signed
if [ $? -ne 0 -o -z ${DOMAIN}.signed ]; then
echo something is wrong with configtest, exit.. 1>&2
exit 1
fi
dddctl bindfile ${DOMAIN} ${DOMAIN}.signed > ${DOMAIN}.bindfile
if [ $? -ne 0 ]; then
echo something is wrong with bindfile, exit.. 1>&2
exit 1
fi
ldns-verify-zone ${DOMAIN}.bindfile
if [ $? -ne 0 ]; then
echo something is wrong with ldns-verify-zone, exit.. 1>&2
exit 1
fi
echo cleaning up
rm -f ${DOMAIN}.bindfile
echo copying zonefiles to /etc/delphinusdns/
cp ${DOMAIN}* /etc/delphinusdns/
echo now all you need to do is a dddctl configtest and reload
exit 0
I ran this one once and it unearthed a bug with notifies on a timezone. I'll
try to address that bug today. Enjoy the script!
I just tried out if Microsoft DNS Server is compatible with delphinusdnsd and it seems it is. While there I unearthed and fixed a segfault condition when someone doesn't specify a tsigkey in an rzone entry. Here is a sample rzone entry that I used against the MS DNS Server.
rzone "petphi.centroid.eu" {
;tsigkey "NOKEY";
masterport 53;
master 192.168.197.254;
zonename "petphi.centroid.eu.";
filename "/etc/delphinusdns/replicant/petphi.centroid.eu.repl";
}
Notice that in delphinusdnsd version 1.4.x, the tsigkey is a MUST or you'll
get a segfault. After 1.5.x it will be optional. I don't want to backpatch
this, so please keep this in mind.
The Microsoft DNS server serves a small Active Directory zone and all default values are supported with delphinusdnsd. This surprised me and I love it!
The centroid.eu nameservers are the servers hosting DNS for delphinusdns.org. I have taken them to todays snapshot on rhombus and trapezoid. What my intention is is to check the double signature dnskey rotation method. I'll likely be using dtschland.eu domain name which is my test zone. If you're looking for progress you may want to follow its history on dnsviz.net which has now a history again. So you'll be seeing progress. I don't think I'm going to start today, but I might.
As you may know I attempted this yesterday and the code wasn't ready. So now it's in Progress. The test zone is called "dtschland.eu" which is a test zone of mine that I got on a reduced deal with joker.com years ago. I got this domain for 10 years at the time. It's paying off now. I'm trying to roll the ZSK from alg 10 to alg 13 as well. So this should be interesting.
I just put this on the news.html:
Development is ongoing. You should know that a delphinusdnsd before the month of April (that includes 1.4.1) cannot do a double-signature key rollover, even if the master is PowerDNS or similar, due to a bug with RRSIG's that was fixed on April 1st. If you don't plan on doing a key rollover until next year then go ahead with 1.4.1 otherwise use a snapshot.I thought it was worthy of stressing this.
I have been talking a bit with DNS folks and they said it's probably best to go insecure and then secure again if an algorithm needs to be rolled. Sucks I know. There is recursive dns software that can't follow an alg rollover. So I'm planning on taking my zones insecure so that I can give them a new algorithm. When that will be I don't know yet.
Everyone uses DNS when they use the Internet, so I have been using DNS since 1994. But I used DNS on Open Source Operating Systems since Autumn 1995 (where I installed Linux while being in College).
At work starting in Autumn 1997 I was confronted working my first DNS server. It was BIND4 I believe. This prompted me to get my first DNS book which I still have today "DNS and BIND - Paul Albitz and Cricket Liu". A very helpful book, but at edition 3 it is outdated today.
The first DNS server i wrote was wildcarddnsd the predecessor of delphinusdnsd (in name only, same codebase). I started this in 2005, the first 15 years have passed.
In 2015 I first experimented with DNSSEC. The concept is super simple if you understand simple cryptography, but to me it was a learning curve. And this is my history (in short form) of using and implementing DNS.
I have just committed this new feature, tcp-on-any-only, from commitlog:
Add the tcp-on-any-only flag to options. This replies with a TC (truncate) on any non-tcp request, causing determined clients to retry in TCP mode. It is long overdue to have this option, and the fix was very simple to do.Basically I'm throwing more TC's in the UDP way of resolving. It will force some to retry with TCP.
Tomorrows snapshot should have the fix. It affected signing with dddctl only. It wasn't easy to find the location of code, but eventually I found it.
I have finally done the work to synchronize the delphinusdnsd CVS repo with GITHUB's git. This takes down one TODO. The script to synchronize is run per crontab at the top of the hour.
You can find the GITHUB page here: delphinusdnsd@GITHUB. Much thanks to YASUOKA Masahiko for his cvs2gitdump python script. It took me a while to figure out, but it's so simple really.
I just did some commits that, if they have a mistake, could be detrimental to the operation of delphinusdnsd. If you read this on the 7th of may and you want an up to date copy you can download a snapshot in the next 8 hours. and it will not have this change. If however you have nothing to lose, you can continue getting the newest. It takes me some time, as noticed on april 27th after two weeks roughly, to noticed bugs. I tested this change on centroid.eu so if anything breaks it will break big time for me. We'll see I guess.
I've been thinking of making an iodine-like feature in delphinusdnsd. Only I don't know when and if DNS Updates takes precedence. I was thinking of this for version 1.6 perhaps, or higher. So next year. So what's iodine? Iodine is a substance they give out to radiation victims in the vicinity of a nuclear disaster :-|. It has the atomic number 53 in the periodic table of the elements as far as I can remember. So it has something in common with DNS which uses the ports 53 (tcp and udp) for communication. The program iodine is a way to tunnel IP over DNS.
This in effect, if implanted into delphinusdnsd , would be going against the reason why delphinusdnsd was first created. Let me explain. When I first programmed wildcarddnsd (I was living in frankfurt at the time) it was to make a secure portal, and fake websites answers. But it didn't work because of DNS caching in solaris and windows. So you could say that delphinusdnsd is in a transformation from good to evil. The way I was envisioning doing the iodine-functionality would be with a tunnel connecting more than one nameservers to the master so that only the master answers the end-point. It won't be an IP tunnel but rather a tty tunnel and it would use /usr/bin/login for an operator of this tunnel to log in and get a pseudo terminal. This is just thoughts, I hope I can implement this some day.
Really interested to what people are observing out there. Here is what I saw on a delphinusdnsd that was up 11 days:
_ddd 77316 0.0 0.1 18368 21128 ?? Sp 14May20 \ 0:03.99 /usr/local/sbin/delphinusdnsd -lWhen restarting it and ps auxwww again, this is what I see:
_ddd 69292 0.0 0.1 16852 18192 ?? Sp 5:32PM \ 0:00.04 /usr/local/sbin/delphinusdnsd -lThe OS currently is OpenBSD 6.6 with all patches. I don't know if I have the energy in the next month to seriously look into this, right now I don't want to do the work. But it looks like there is a slight memory leak since this is the parent process and there can be no CoW (copy on write) paging. Hmm anyhow. That particular delphinusdnsd runs 10 zones. So rather small.
Just a test. Ignore please.
As you may know delphinusdnsd is spread over several processes and the plumbing for the IPC is hard to do. So I'm introducing the CORTEX process. Here is a rough chart on how it looks like:
Each connection between the cortex is called a neuron. It is sorta like the brain of the human :-). I haven't lost my mind. This is just a way of making sense for me, so I don't fall asleep to it. I hope to have the cortex work finished and tried in around three weeks to a month.
I'm hoping to be putting in a forwarding feature to delphinusdnsd. This is the next closest thing to having a recursive server but not really. My goal is to have TSIG protection and different ports as the forwarding destination. So a sample entry may look like:
forward "to these hosts" {
incoming-key pass;
destination 1.1.1.1 port 53 key NOKEY;
destination fcfc:fcfc:8::1 port 5353 key routerpass;
}
So this forces incoming questions to only reply when the incoming key pass
matches (a TSIG key), and the destinations either have NOKEY or a set key.
I hope I can get this finished in July, then there is a priority to do something
else in August and I'll be back for September, October, November and December
to get started on the Dynamic DNS Updates. The DNS Updates won't be finished
for 1.5.0 but will be aimed for 1.6.0 release. I'm hoping to make use of
the cooler months to get ahead. Perhaps to get non-DNSSEC Updates for 1.5.0
and work on the DNSSEC part in 2021.
I have added a "Donate" link to the main delphinusdns.org page. If you use delphinusdnsd and can donate a little bit I'd be grateful. I chose what I do with this money (it mostly goes to my living), and I chose what to with the development of delphinusdnsd, in other words, the donation would be a gift, with no strings attached. If you donate over 100 EUR I'm going to allow you to link to a hyperlink with your name or your corporation. The link has to be in taste with this site. You can go to the donate page directly through here. Thanks!
I have made a fix for reply_refused() it was giving bogus answers. here is a diff for the fix. As you can see it was a misplaced memset() and then it didn't answer authoritatively which I added.
I have just check in my work, it will be in tomorrows snapshot or you can github it in 3 minutes. The work is far from finished but I got a working forwarding with a TSIG secure channel, utilizing 2 delphinusdnsd's and one unbound (bound to localhost). One delphinusdnsd takes on queries for forwarding and send them to the second delphinusdnsd upstream at my server. It's forwarding config looks something like this:
forward "to these hosts" {
incoming-tsig no;
destination 5.9.87.75 port 8053 key newsecret;
; destination 2a01:4f8:162:1167::2 port 8053 key newsecret;
destination 85.10.199.4 port 8053 key newsecret;
; destination 2a01:4f8:a0:5135::2 port 8053 key newsecret;
}
So on port 8053 at the upstream server(s) is another delphinusdnsd that has
a similar config only incoming-tsig is set to yes, and it will forward to
localhost (some port). Thus far it works and it is quick too. I'm sure I'll
iron out the bugs next week though. I'm very proud I got this working so far,
I dedicated the entire month of july for this, so there is plenty of time to
test this.
Even though the 1.4.2 tarball doesn't update the internal version string to 1.4.2 (I forgot this rolling it this morning), it does feature a slight DNS header query flags fix to REFUSED answers. This bug was found 6 days ago, so I finally was able to backport it. So, only 1 source file is different from 1.4.1 featuring a 3 line diff.
In delphinusdnsd -current..
40146 totalThis number will go up and down, but wow, what a bloat. I'm currently enjoying the last incarnation of the forwarding code. I finally fixed it I hope (in the cache). The work is committed tomorrows snapshot may be stable for enabling the cache. It is activated in the forward "" {} with a "cache yes;" line. Off I go, see you later.
Due to the Dynamic DNS work that I have planned for 1.6.0 I'm considering committing the 1.5.0 release a few months early. Perhaps just after the OpenBSD 6.8 release which will come out between october and november some time. This way I give myself a bit more time for 1.6.0. I kinda dislike floating releases and prefer set dates but this is sorta a special event. I'll keep pondering around this and you may see a november release.
Yesterday I did porting work of -current to Linux. It didn't make todays snapshot but it should make tomorrows. In the following days/weeks I'm also going to make sure FreeBSD and NetBSD work. OpenBSD is my developing platform and it works there.
If you know delphinusdnsd config files you may have run into the 'version "9";' at the top of the config file. It's required.
I have just rolled back the version 9 to version 1, meaning after today (or on tomorrows snapshot forward) it will be at version 1. All examples and manpages have been updated.
When I forked delphinusdnsd from wildcarddnsd (which I also wrote), the first version was version 7. So there won't be a conflict until version 2.1.0 in 7 years. By that time I don't think anyone will have delphinusdnsd-1.0.0's running, it has too many bugs. Also it will be a major release bump then and we'll see how the versions can be done. The version "1"; will likely stay until the release of 1.6.0 in 2021, unless you track the snapshots/-current at which point it will be sooner.
The idea of versioning in the configfiles is that it creates administrative overhead to make sure that a config is backwards compatible if you go back in versions. I think this is a good thing, and I first saw it I think in syslog-ng config files.
I have just replaced the foundation in delphinusdnsd. In fact I have replaced 15 year old code (code that was there at initial checkin at wildcarddnsd) and replaced it with a function called expand_compression(). I programmed expand_compression() a few years back where I made sure that nothing could exploit it. In fact something could have and I have improved on it today. But let me start with a function written in 2005 build_question() and here is a snippet of the first executable code:
/* find the end of name */
for (i = sizeof(struct dns_header); i < len; i++) {
if (buf[i] == NULL) {
end_name = &buf[i];
break;
}
}
What was there still this morning was similar to this. Obviously it was
bogus. The struct dns_header looks something like this:
/* RFC 1035 - page 26 */
struct dns_header {
u_int16_t id; /* ID of header */
u_int16_t query;
u_int16_t question; /* # of question entries */
u_int16_t answer; /* # of answer RR's */
u_int16_t nsrr; /* # of NS RR's */
u_int16_t additional; /* # additional RR's */
};
So when a question came in it would skip the header, to parse the first
DNS name (the question name), and it knows that the name is terminated with
a 0-byte so it said: go to this zero byte and that's the length of the
question name. Of course it was bogus. Someone can insert 0's into the
labels contents and this would bomb. So I downright replaced this with
expand_compression() which also tries to expand compression, but it can
only go to compression offsets looking to the beginning of the packet
otherwise it would open an infinite compression loop opportunity.
/*
* parse a domain name through a compression scheme and stay inside the bounds
* returns NULL on error and pointer to the next object;
*/
char *
expand_compression(u_char *p, u_char *estart, u_char *end, u_char *expand, int *
elen, int max)
{
...
This function stays within the bounds of the packet thus it has a estart, and
and end which indicates start and end of the packet. It has an extra buffer
called expand which is like a digest pad where the compressed name is
uncompressed to. And p is the offset where it's parsing from. So going
into the first parsing of the
packet the DNS Header is parsed, (or allocated), then it sits at offset 0x0C
or decimal 12 which is the size of the DNS Header. You guessed it that 0x0C
which is part of 0xC00C. Many answers use that compression offset because it
saves on writing out the dns name that was in the question (and was
requested).
Before today expand_compression() was faulty because it would take on any ID value that can be crafted to be 0xC000 or at offset 0 of the packet which is the ID. From there one can control up to 63 bytes offset, but one cannot go compressing forwards due to restriction of the algorithm for that. So I just put a stop in for that, that the dns header is off limits for compression. This stops compressing in the 0x0C offset completely. Good for the first dns question.
All in all I'm very happy I took a look today what build_question() did. It will pay itself off, with better security, I think (and hope).
Here is a story about the arctic code vault (the story is in german) where programs are safe for 1000 years. The github snapshot was made in February 2020 so before I joined GITHUB. I guess delphinusdnsd will be living on the edge without repos in ice to fall back on.
I allocated the entire month of July for the forwarding work but it seems to be nearing completion. I got stalled on porting it to NetBSD and that will take a few weeks more, so I'm thinking I'll use the momentum I got the first half of this month to implement CAA RR's in the authoritative mode.
This is a lot of work these days because the delphinusdnsd ecosystem has spread over dddctl programs and needs to be checked in several places. I have the entire workweek next week to work on that. It will make a fine addition to the 1.5.0 release. I can't guarantee that I will do much work between August and the release time, I have a lot of job applications to do, as I'm below zero so to speak. But coding on delphinusdnsd keeps my spirits high. I have been applying to companies in the last few weeks but only sparingly.
On with it!
Dear Delphinusdns blog reader,
If you haven't heard of the prototypefund.de it's a fund in Germany that supports open source. They pay up to 47K EUR to teams.
I am applying to the 9th round (between January and July, 2021) of this prototype fund, on August 1st, for the work of "DNS Updates" in delphinusdnsd. I did apply to the 5th round (2018) before also for delphinusdnsd improvements, but did not secure the grant. I was turned down in November of 2018, and similarily this year I'll find out in November likely if I'll be selected.
This will pretty much be for the entirety of the 1.6.0 release which will be sped up to be done by July, 2021.
So here's my reaching out. If you're german and living in Germany, know how to code in C, and want to help me with this for the work of DNS Updates (with DNSSEC signing) send me an email before August 1st. I'll apply with your name as a team member. Mind the dates I listed above (August 1st, November, January-July 2021) and commit to them. If it doesn't get through November there is no money, and no team. But if we do get selected in November, I need you to commit 6 hours per weekday between January-July 2021.
I think it would be fun! And don't worry, if you do get selected I won't expect you to work on this at the pace that I'm working. In fact I'll give you a related small work first to get to know the delphinusdnsd, before asking you to do heavy lifting. As long as we get the work done by June/July. Let me know if you qualify with an email.
So far so good. We have 80 articles written by me on this site. That's roughly 7 to 8 articles per month. On September 11th is the anniversary and I plan on celebrating this by turning a feature of the blog software on that allows looking back on that day. There is still too little backlog though to have it make big impact but it may turn out to be fun!
I heard that got (gameoftrees.org) has a gotweb interface now. And I had to try it out with my git repo that I convert from CVS (the one that is being pushed to github). I think it looks great! I want to replace cvsweb that I currently use with something possibly more secure (on the web) and gotweb has me impressed. Much like this blog it's running on kcgi.
So the question then arises whether I will dump CVS entirely for got/git. I wouldn't go that far, do note that the tags that I put on the STABLE_1_4 branch do not appear in the git repo, which is a shame. I'm going to be watching got from the sidelines and watching what OpenBSD does in the next year perhaps. In the meanwhile I'm probably going to replace cvsweb with gotweb.centroid.eu and make the cvsweb private only. Please excuse the non-https there was a problem with the acme-client or letsencrypt, at least it didn't update. I'll fix this in time after figuring out the error.
I put my dns server in forwarding mode on my router on interface cnmac1, this gave it the IP x.x.177.1, but the new code with forwarding seems to have a fallback. A device from interface vlan3 (x.x.199.0/24) could not access the IP x.x.177.1 and DNS ceased working. The workaround is to add vlan3 as an interface and change DHCP to give the DNS server a x.x.199.1 IP. This worked. But I remember thinking that this was not the behaviour before I switched to the raw sockets. Live and learn.
I'm gonna call the two modes by their names "authoritative" or "forwarding". I added CAA, HINFO and RP RR's to the authoritative mode in commit 6f87dc2b46b3cbfb71320f535b34a0bb0734604c. For this I mostly picked another RR as a template and just changed the values. It turned out to work. I had to follow up to this commit with a commit to the sign_caa() function because the algorithm to sort canoncial rrsets seems to not be correct in some form or way. I'll be researching this hopefully in august or september (when I find time). Also notice I put https on the gotweb. I'm very sure it will replace the CVSweb in time, so you may as well learn it a little and get used to it if you used my cvsweb to check commits. One positive thing about gotweb/git is that it clumps several files together in one commit so you can see them all at once. A negative thing is that the cvs2gitdump utility doesn't know how to handle tags in branches and discards them so you can't see version 1.4.2 for example (also noticed on github). I do hope that the tag for 1.5.0 will appear in it though as it's tagging is on HEAD.
In this article by DJB he talks about AXFR Poisoning. When you have a replicant that gets a zone from another master, it was possible before this patch to poison extra RR's into the entire database. It's amazing how other DNS servers are similar to mine in this regard. I never had to worry much since I controlled replicant and master, but recently I started replicating for someone else and it opened my eyes to the security aspect of this. Thanks goes to Ricardo Santos for his part in making me think about these security scenarios.
Another thing that's fixed tonight is a hangup attack which would leave an RAXFR'ed zone unparseable killing the server. I believe this patch from this afternoon would fix this. I have thought around other scenarios where someone could hurt me too. One other one is when they manipulate SOA values to values that hurt the operation of a replicant. Such as the undefined value of 0 for a refresh. I'm gonna work on that tomorrow and it will be addressed next week. For now the zone poisoning and hangup problems have been dealt with and will be available in tomorrows snapshots.
Considering the ease of fixing these I may backpatch these into the 1.4 stable branch and roll another 1.4 release. I think that's fair but it will take a few days.
I have removed CVSweb CGI program from the delphinusdns.org website. The last straw that broke the camels back was that it stopped working displaying what's in the STABLE_1_4 branch that I committed for the upcoming 1.4.3 release that features backpatches for reliability and security. So this puts me in a weird position. I won't have CVSweb (the last feature that I needed it for, like said, broke) anymore and the CVS repo has it's days counted. The 1.5.0 release will likely be tagged on got/git, and branched so the changes will show up in the github and gotweb online repos. Everyone needs to see their history!
Well I had a pretty good spurt this summer. Nice was that this summer wasn't
all too warm. Here is a graphic that I got from the insights at github:
Here is a list of things from the CHANGES file in the repo:
I'm going to focus on other things for the month of August and will tidy up things in September for the October or November release (it all depends on when OpenBSD 6.8 gets released). Overall I'm satisfied with the way things are going this year.
While googling I came across the DNS Institute, a site that offers consultings regarding DNS. They listed delphinusdnsd as an authoritative server. Thank you for the exposure! Perhaps pretty soon they'll have to also list delphinusdnsd as a simple forwarder, as well. *smile*. I don't know exactly who is behind this website but I'm grateful they mentioned my work.
Here is a list of points that I collected for that changed for this release:
For the prototype fund (9th round) I have finalized what my project is going to be about.
It will be improvements for delphinusdnsd like I mentioned before, but I have a concrete picture of what I must do. I'm going to make delphinusdnsd an authoritative nameserver for replacing Microsoft DNS server. For that I need to do a few things: GSS-TSIG (RFC 3645), it comes with several depended RFC's that I also have to implement like TKEY (RFC 2930) and possibly KEY RR which comes with the SIG(0) RFC. Also I'm going to implement DNS Updates after RFC 2136 and RFC 3007 (secured), and if there is time left in the project time (6 months) I'll try to implement auto-signing updated records (DNSSEC).
This is all a big task, and there is always the hindthought that Microsoft Active Directory won't allow this. I have found a document from Bluecat Networks that they can do this (on a BIND9 basis). So this will be my outline that I will be working/striving towards. Wish me luck, I'm applying tomorrow, most likely.
With in-depth debugging with another person who uses delphinusdnsd, we were able to make out that the canonical sorting in DNSSEC (dddctl sign) is still not right. I'm going to change this in dddctl on all functions. I will do this next week. I have a plan. Hopefully it will be a once and for all result. Many thanks goes to nlnetlabs in the netherlands who created the program ldns-verify-zone. Without you guys I'd have problems. I'm standing on the shoulders of giants.
I have filled delphinusdnsd with a dataset of 1.4 million AAAA records. The size in memory for this is 2.4 GB roughly. But the AXFR to such a database with its individual (in my case 1440) zones took close to 2 minutes. I have just committed code to shave this off to 2.4 seconds, a win-win.
However this changes the behaviour of delphinusdnsd. Before you could do:
zone "anything you like" {
centroid.eu,a,3600,192.168.0.1
...
}
This is not the way things work now. You MUST put in the zone name
in zone "". Many people were doing this anyhow, but now it's a requirement.
zone "centroid.eu." {
centroid.eu,a,3600,192.168.0.1
...
}
This behavior will be downloadable in tomorrows snapshot (27th of August) and
onwards, and will be in 1.5.0 delphinusdnsd.
Between July 6th and today there has been a countdown timer for AXFR zone TTLs. This wasn't immediately noticed because my zones are less than 1 second apart notification wise and I simply didn't notice it. Tools that I use didn't mark it either. If you need the fix you should grab tomorrows snapshot.
September is almost around. Two things need to be done before I roll the 1.5.0 release.
OpenBSD 6.8 is in beta. That gives around 1 month of testing for this OS before it is released. I checked and OpenBSD 6.2 was in beta on August 20th, 2017 and it was released on October 9th, 2017, so judging by how long this takes it took them 40 days. So given the release mid October for OpenBSD, delphinusdnsd will be about 2 weeks later, but before November. We'll see. This pegging to OpenBSD is only for this year, I don't plan on doing this too often. Delphinusdnsd is developed on OpenBSD for what it's worth.
Please update your configs starting with tomorrows snapshots. Commit comment here.
On friday of this week you'll see the first "on this day" entries. Happy Anniversary Delphinusdns blog!
With this commit I took out old backward compatibility for OpenSSL before 1.0.1. Since LibreSSL is portable across many platforms and we rely on that for NetBSD and OpenBSD there is not much need for this compatibility code anymore. It will be reflected in the 1.5.0 release by next month.
I'm changing the algorithm on delphinusdns.org to alg 13. To do this I have to take the zone out of DNSSEC for a day or two, which is the easiest way because there is recursive servers out there that can't do an algorithm rollover correctly. I already tested this with a test zone (dtschland.eu). These changes will be done next week, possibly starting tomorrow. The steps are 1. remove the DS entry at .org level, 2. wait 86400 seconds (TTL) 3. remove DNSKEY 4. wait 86400 seconds (TTL) 5. install new keys and sign. 6. upload new DS entry to registrar for .org level insertion. I'm also doing this for three other zones in parallel. Extra caution has to be done at the centroid.eu zone because it has a DANE setup which I may have to disable for these two days.
I have added an AXFR bytelimit (configured within an rzone) to delphinusdnsd in replicant mode. The default bytelimit is 64 MB which should be enough for most zones. Maximum bytelimit is 4GB. Keep this in mind when using delphinusdnsd as a replicant.
I have written down which issues delphinusdnsd fails on here is the list:
I'm considering whether I want to continue delphinusdns project for another five years or longer. I'll be nearing 50 y.o. in 2025 and I'm itching to do another project before I die. Continuing until age 59 as I had previously thought would work I'm putting my doubts on it. So I'm gonna say that I'm going to pass the torch possibly before the 2.0 release. I will maintain delphinusdnsd as a download but may not actively work on it as a single entity after 1.9. I still want to put secure dns updates into this, and continue putting cool stuff into this. Five years is a long time and twenty years for the entire project length is a human generation. We'll see I have five years to consider this. I may start parallel projects next year to test the water what I can do and what is possible. We'll see.
It's week 42 now...
$ date +"%W" 42In week 45 I'm likely going to release delphinusdnsd 1.5.0. It may happen on the friday the 13th of November. But that isn't a definite date. It could happen before that.
I've been stressing out lately. The release is delayed until further notice. If the snapshots work for you that's basically it. There is small bug that I could not find (have been reinstalling OS's lately that took up most of my time), which is associated with the TSIG and the forwarding code. For some odd reason a packet (particularily a DNS lookup for a NTP destination) does not get the right signature (so it says). I've been tcpdump'ing but didn't see a diff in packets. I don't have time for this right now, it's a bug but I haven't been able to locate it.
I have switched the delphinusdnsd source repo to got/git from CVS. This seems to be the way of 2020. It's a little hard because CVS was simple and I loved its simplicity. But this is what I need to learn now I guess.
Also the github and gotweb web mirror are now synced every five minutes. So that no change will take another hour or so.
The release for 1.5.0 will likely happen tomorrow if everything looks clear. I have moved some files over to say 1.5.0 already internally.
I'm proud to release delphinusdnsd 1.5.0 today. You can find the source in the Source link on the main site (main site). I have been going through some obstacles lately so if there is anything amiss I'll probably roll a 1.5.1 release in time, right now I can't find anything amiss.
Special thanks goes out to ''Ricardo M. Santos'' who not only donated a little bit of money but really tried to work with me during the time 1.4.0 Release to 1.5.0 Release. Also thanks goes to all the people who supported me during this time.
Sorry to hear, and to relay the news. I'd like to quote the rejection mail partially:
der Auswahlprozess der 9. Runde des Prototype Funds wurde mit der Jurysitzung nun abgeschlossen und wir können dir die Entscheidung mitteilen: Leider gehört dein Projekt “Die letzte Lücke, Delphinus DNS anstatt Microsoft” nicht zu den zur Förderung ausgewählten Projekten. Wir haben fast 300 Einreichungen erhalten und mit Begeisterung gelesen. Wir schätzen jede einzelne Idee und das große Engagement dahinter sehr. Deshalb möchten wir dir herzlich für deine Bewerbung danken und die Absage noch etwas einordnen:
Well so much for that. I applied on the 5th round, and the 9th round I'll reapply for the 11th round, probably.
Here is the original submission for prototypefund:
Bewerbt Ihr Euch als Team um die Förderung?
nein
Namen der Teammitglieder:
Peter J. Philipp (ich)
Projekttitel:
Die letzte Lücke, Delphinus DNS anstatt Microsoft
Ordne das Projekt einem Bereich zu:
Datensicherheit
Beschreibe Dein Projekt kurz.
DelphinusDNSd ist ein Authoritativer DNS Server der in Deutschland gebaut
wurde. Es hat angefangen in Frankfurt um 2005. Es ist auf dem OpenBSD
Betriebssystem geschrieben, und portiert nach Linux und den restlichen
grossen BSD's (FreeBSD und NetBSD). Das Homepage von delphinusdnsd ist
https://delphinusdns.org.
Ich möchte Delphinusdnsd 1.5.0 erweitern so das man es mit Microsoft
Active Directory benutzen kann im verfahren DNS Updates. Die
unterstützung bringt eine neue version hervor und zwar 1.6.0.
Welches gesellschaftliche Problem willst Du mit dem Projekt lösen?
Buffer Overflows sind ein Problem generell seit Aleph One's Artikel "Smashing
the Stack for Fun and Profit", 1996 (https://en.wikipedia.org/wiki/Elias_Levy).
Datensysteme sollten Sicher sein besonders im Jahr 2020. Microsoft DNS server
war anfällig auf genau so ein Problem mit CVE-2020-1350
(https://support.microsoft.com/de-de/help/4569509/windows-dns-server-remote-code-execution-vulnerability).
Es ist Zeit alternativen zu Microsoft DNS zu haben: DelphinusDNS kann das
machen. Mit ein bissle Aufwand kann man Delphinusdnsd zum DNS Server in
einer Active Directory Domäne machen. Das das geht ist (auf Englisch)
hier beschrieben von einer Firma die Bluecat heisst.
(https://bluecatnetworks.com/blog/active-directory-dns/)
Wie willst Du Dein Projekt technisch umsetzen?
Delphinusdnsd ist technisch bereit jetzt einen weiteren Schritt zu machen,
und zwar DNS Updates zu inkorporieren. Als ich mich zuletzt beim
Prototypefund beworben hatte in der 5. Runde war es noch nicht so weit,
grosser Baustein der fehlte war TSIG nach dem RFC 2845 verfahren. Das ist
der grundliegende Baustein für DNS Updates (aka Dynamischen DNS).
Microsoft Active Directory redet mit dem DNS server über ein GSS-TSIG
das etwas anders ist, es beruht auf RFC 3645 so wie mit dem TSIG von RFC 2845.
Die DNS Updates sind nach dem verfahren von RFC 2136 und 3007 gestaltet. Ich
will einen Monat am GSS-TSIG arbeiten was mir reichlich Zeit dafür gibt
es beinhaltet auch kompatibilitaet mit dem TKEY RR zu schaffen. Zwei Monate
hab ich mir für DNS Updates gegeben, am ende dieses zeitpunktes sollte
man DNS daten in den Server mit TSIG einfügen können. Der
Löwen anteil ist dann das GSS-TSIG mit GSSAPI von der Heimdal Kerberos
Library zu inkorporieren und es mit Active Directory kompatibel machen. Das
enspricht 3 Monate Zeit der 6 Monate langen Project phase. Da es komplex ist
lege ich mir lieber so viel zeit offen.
Welche ähnlichen Lösungen gibt es schon, und was wird dein
Projekt anders bzw. besser machen?
Wie erwähnt macht Bluecat dieses basierend auf BIND9. Andere
Lösungen können mit anderen DNS Servern gemacht werden,
für die Server die DNS Updates beherschen. Aber DelphinusDNS ist
anders im Security Umfeld (besonders wenn eingesetzt mit OpenBSD).
Es würde bestimmt sicherer sein. Und es wird eine Deutsche
Lösung sein. DNS Server sind hart zu implementieren, deswegen beruhe
ich schon auf Delphinusdnsd weil es schon geht.
Wer ist die Zielgruppe, und wie soll Dein Tool sie erreichen?
Kleine und Grosse Firmen und Privat Personen können davon profitieren.
Ein Delphinusdnsd läuft auf OpenBSD, Linux und *BSD im generellen.
Also ist das Betriebssystem dafür erhältlich. Ich habe eine
webseite die delphinusdnsd zum download bereit macht.
Hast Du schon an der Idee gearbeitet? Wenn ja, beschreibe kurz den aktuellen
Stand und erkläre die Neuerung.
Ja. Zur 5. Runde war Delphinusdnsd 1.3.0 fertig, zur 9. Runde ist version
1.4.3 fertig und 1.5.0 kommt wohl noch während der evaluierungs Phase.
Ich habe bereits die C Header datei bereit gemacht für DNS Updates,
aber der Code muss noch geschrieben werden. Link zum bestehenden Projekt
(falls vorhanden): https://delphinusdns.org
Wie viele Stunden willst Du (bzw. will das Team) insgesamt in den 6 Monaten
Förderzeitraum an der Umsetzung arbeiten?*
720
Skizziere kurz die wichtigsten Meilensteine, die Du (bzw. das Team) im
Förderzeitraum umsetzen willst.
Meilensteine sind GSS-TSIG im ersten Monat. Zu diesem Zeitpunkt funktioniert
noch nichts. Dann DNS Updates vom ersten Monat bis dritten Monat. Hier
sollte der DNS Server Updates annehmen auf sicherer Basis (TSIG)
können. Dies ist der grosse Meilenstein und eine vorraussetzung
für den letzten Meilenstein der 3 Monate lang dauert nämlich
das einbinden der GSSAPI mit der Heimdal C Library um das gebrauchte
Kerberos mit dem Windows Server 2019 funktionierten zu lassen. Innerhalb
dieser 3 Monate hab ich vielleicht 2 weitere Meilensteine, 1. Monat wird
sein die Schnittstelle zu verstehen, 2. Monat es zu Implementieren und
3. Monat das ganze zusammenzuschnüren mit einem dokument das
beschreibt wie es funktioniert.
Wenn meine Projektidee nicht gefördert wird, darf sie trotzdem auf
prototypefund.de und in wissenschaftlichen Publikationen rund um das Programm
veröffentlicht werden?
ja
What this means is that there will be no windows support in delphinusdnsd in the near term. Version 1.5.0 is out since a few days ago, 1.6.0 will likely have DNS Updates when I get time to work on it. Next release is likely in December 2021. As I pasted this mail I got a little sad. Oh well shit happens, disappointment is nothing new.
I've got some things to do in 2020, so I won't be coding much this year on delphinusdnsd. New code will likely appear next year in January or February.
I noticed this earlier and twice now. After 3 weeks uptime the forwarding process consumed 100 MB, where I expected it to only consume 20 MB or so. It is with this forward configuration:
forward "to these hosts" {
incoming-tsig no;
cache yes;
destination x.x.x.x port XXXX key somesecret;
destination y.y.y.y port YYYY key somesecret;
}
I have doctored it a little to anonymize it. So then, next year is busy for
me, but I hope to have this found by August. I'm starting a new hobby project
in January and I may not get DNS updates into delphinusdnsd next year. We'll
see. I'm not stressing about it whether we get the updates in 1.6.0 or in
1.7.0 either way. I have been fantasizing in making the forwarding work with
a TLS which obviously will take away from the DNS Update work. We'll see how
2021 unfolds.
I would like to take this opportunity (3 days before christmas) to wish you a happy time. Maybe you saw a grand conjunction and a little up and right from it was the star Altair. maybe you saw it. From there it's not far to the constellation Delphinus, which I have named this DNS daemon after. It's in the same neighbourhood anyhow. World, peace be unto thee!
Yesterday I was code-reading a bit in delphinusdnsd and improved/hardened it a little particularily in the compress_label() function. It seems there is no functional change with small zones. So I'm quite sure that this change won't negatively impact anything. I'll do the commit when I get home from my parents house where I spent new years.
Possibly in a month or two. I have identified the memory leak last year. This year I found a pretty big chunk that wasn't released. I need to test that over time and hope that that was it. It will cause a bit of inconvenience but let me assure you, it's only in expiring records thus in the forwarding cache.
With this commit a long standing bug may have been fixed. In 1.5.0 I made it mandatory to give each zone "zonename.tld" {} a name (such as zonename.tld). I took this further and gave these zonenames a unique number which gets compared when it gives answers. With this it is able to differentiate between glue data and normal data at detriment of a few cpu cycles. Right now a test zone of mine with 1.2 million AAAA records and many many zones (1440) took 3 minutes to process on one core (it's single threaded) before the daemon started up answering queries. An individual zone took about 5 seconds to answer. This is acceptable to me. If you run delphinusdnsd in an operation/production then you may want to use several servers in a sort of high available setup. There isn't too many zones out there for 1.2 million AAAA records so this is somewhat out of the ordinary.
I noticed filters crashed the delphinudsnsd server. I thought a little about whether these are still needed, but remained with them. This commit fixes it.
I strongly urge people to upgrade to tomorrows snapshot if they use the forwarding in 1.5.0. The followup 1.5.1 release is still a month away or so and I need to give it testing. I finally found the reason for the spurious TSIG failures in the forwarding code. While there I found a pretty bad security hole. Basically a packet could be queried and a non-authenticated packet could be sneaked into the cache before it was checked against TSIG. I'm somewhat disappointed I released so early, but it was because I tried to get funding. It was a stressful time for me in november and since then I pretty well calmed myself down. So that's an update on things. DNS is hard to get right, as we've seen with the dnspooq exploit on dnsmasq. It's complex code. Let's look forward.
The european commission is hard at work trying to stifle freedom on the Internet. I'd like to point you to annex 5 of the NIS2 directive found here. The annex states:
Electronic communications networks or services are subject to security and incident notification obligations laid down in Article 40 of the European Electronic Communication Code. At the same time, these providers are subject to almost identical type of obligations under the NIS Directive as far as they also provide services included in the NIS scope such as Internet Exchange Points, Domain Name Servers or cloud computing services. The repeal of these obligations from the European Electronic Communication Code and their inclusion under the revised NIS Directive would streamline the legal obligations for those entities.
This basically says that you have follow obligations such as registering your domain name server (authoritative and recursive) with the EU's security body, and reporting abuse. You may even be denied usage of your own DNS servers, and may be forced to relinquish control of your servers. As someone who loves freedom, programs an authoritative nameserver I am dead set against this. This can't be happening!
For record keeping here is the original NIS directive from 2016 which it has been said in the so-called NIS2 directive to be embodied into the laws of each Union member country.
I am against the EU commission of "tightening the chokehold" on netizens freedom, in fact I'm pro-exit of this European Union and it's Security (read Soviet) Union Strategy.
I have just put the final version on my test servers. I suspect there is still a tiny memory leak but it's reasonable (ie. minimal). I ran this server for two weeks or so and didn't have a problem, that was with a -current server. Now I'll try to do the same with a -stable server and watch the memory signature intently. After that I want to make a tarball for 1.5.1 and release it. Thanks for your patience in this.
I got a lot of packets in the past that I suspected of being abused for a reflection attack. The attack would use me to send REFUSED answers to a unknown source. I am testing a patch currently that will mitigate this:
Feb 7 12:16:04 spectral delphinusdnsd[54227]: request on descriptor 12 interfac e "49.12.10.87" from 98.219.134.50 (ttl=238, region=1, tta=0.438ms) for "." type =ANY(255) class=1, edns0, answering "REFUSED" (33/28) Feb 7 12:16:04 spectral delphinusdnsd[54227]: short circuiting multiple refused from 98.219.134.50, drop Feb 7 12:16:04 spectral last message repeated 8 timesIt basically detects that there is multiple queries that would let one through and drops the other 9 packets. I don't know why it was always in bursts of 10 packets but only 1 is getting through now. I may commit this patch next week.
I was going to release 1.5.1 this week but it will be delayed a week. The reason is that my developing workstation (a raspberry pi) was offline due to a hardware failure. Now everything is fixed and I'm hoping to release 1.5.1 by next friday. 1.5.1 is just a bit of bugfixes on the -stable branch. It also addresses some leakage in memory, though not fixing all leakage it seems. I'm calling the leak pluggage good enough for now.
I have over the last few months created a stats collection script (utilizing
AWK and shell scripting). I want to share it.
#!/bin/sh
#
# dnsstats.sh collect some statistics from a /var/log/delphinusdnsd logfile
#
echo DNS stats so far collected `date`
echo -------------------------------------------------------
echo
awk ' \
{ for (i = 1; i <= NF; i++) if ($i ~ /type=/) { print $i; next; } } \
' /var/log/delphinusdnsd | sort | uniq -c | sort -rn
awk '\
/VERSION/ { version[$1] += 1; } \
/NXDOMAIN/ { nxdomain[$1] += 1; } \
/NOERROR/ { noerror[$1] += 1; } \
/NODATA/ { nodata[$1] += 1; } \
/REFUSED/ { refused[$1] += 1; } \
END { \
printf("\n\nMonth,\tVERSION,\tNXDOMAIN,\tNOERROR,\tNODATA,\tREFUSED\n"); \
printf("----------------------------------------------------------------------
--\n"); \
for (i in version) { total[i] = i "\t" version[i] "\t\t" nxdomain[i] \
"\t\t" noerror[i] "\t\t" nodata[i] "\t" refused[i]; \
printf("%s\n", total[i]); \
} \
printf("----------------------------------------------------------------------
--\n"); } \
' /var/log/delphinusdnsd
echo
echo
echo TOP TEN
echo -------
awk '\
{ if ($0 ~ /answering/) print $(NF - 1); } \
' /var/log/delphinusdnsd | sort | uniq -c | sort -rn | head
echo -------------------------------------------------------
exit 0
Enjoy.
I have tagged the STABLE_1_5 branch for the 1.5.1 release. It is a bug fixes only release. Some memory leaks were removed. Development continues on -current.
I'm so angry at myself for released 1.5.1 too early. I did not compile it on an OpenBSD-current host and I got stuck on compiling there. I will release 1.5.2 for OpenBSD-current shortly. Sorry about this. Short lived release.
This fixes the compiling on OpenBSD-current (which had enabled -fno-common by default in it compiler going forward). There is no other fix since the botched and little tested 1.5.1 release. OS's this was tested on were: OpenBSD-6.9-beta/arm64, OpenBSD-6.8/amd64, FreeBSD/amd64, NetBSD/amd64 and Linux on amd64. Enjoy!
Before I start programming on another thing, I'd like to understand what I'm
doing. So it happens to be that I've been studying RFC 1876. With a possibly
slight learning disability this was hard to decipher, but I've finished with
some notes. Here they are
MSB LSB
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0| VERSION | SIZE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2| HORIZ PRE | VERT PRE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4| LATITUDE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6| LATITUDE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8| LONGITUDE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10| LONGITUDE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
12| ALTITUDE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
14| ALTITUDE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
(octet)
The LOC record has a VERSION which is always 0, a SIZE which is the size of
the location (described as entity in the RFC) as a sphere. Here if you want
to indicate a place you can give it 0x12 (1e2 cm or 1 meter). There is a
Vertical and Horizontal precision of data which is a circle of error instead
of a positive/negative value. Here you can say 0x16 for horizontal and
0x13 (1e3) for vertical precision. 0x16 would be 10km and 0x13 would be 10
meters.
Then comes latitude and longitude expressed as a 32 bit integers.
Altitude is interesting. As you stand on the oblate spheroid of earth your
altiude is 100,000 meters if you were standing on the water (sea level). If
you were below sea leavel say -2.30 meters you would be at an altitude of
9,999,770 cm or 99,997.70 meters. It is a value in centimeters represented in
the packet.
An example LOC RR reply:
09:40:28.182941 192.168.177.2.53 > 192.168.177.8.19583: [udp sum ok] 8633 1/0/1
nlnetlabs01.ring.nlnog.net. LOC(83) (ttl 255, id 17634, len 111)
0000: 4500 006f 44e2 0000 ff11 933f c0a8 b102 E..oD......?....
0010: c0a8 b108 0035 4c7f 005b 7278 21b9 8180 .....5L..[rx!...
0020: 0001 0001 0000 0001 0b6e 6c6e 6574 6c61 .........nlnetla
0030: 6273 3031 0472 696e 6705 6e6c 6e6f 6703 bs01.ring.nlnog.
0040: 6e65 7400 001d 0001 c00c 001d 0001 0000 net.............
0050: 012f 0010 0012 1613 8b3c 05b1 8110 3903 ./.......<....9.
0060: 0098 959a 0000 2910 0000 0000 0000 00 ......)........
This is what it looks like in dig:
;; QUESTION SECTION:
;nlnetlabs01.ring.nlnog.net. IN LOC
;; ANSWER SECTION:
nlnetlabs01.ring.nlnog.net. 600 IN LOC 52 21 22.993 N 4 57 20.387 E \
-2.30m 1m 10000m 10m
The output here gives:
latitude, longitude, -2.30meter below sealevel (giving 98959A == 9999770 cm),
1 meter (1e2 = 0x12) entity, 10km (1e6 = 0x16) horizontal precision, and
10 meters (1e3 = 0x13) vertial precision.
So it may very well be that I'll start writing LOC support into delphinusdnsd in the future.
Pirata is away and the website isn't working so I feel that I should take control again and give people something to let you know that we're not gone. Sorry for disappearing a while ago. The official website is still on pirata's site which leads you to the GITHUB. There you can download and clone delphinusdnsd.
We're still on track for a delphinusdnsd 1.6.0 release in mid December 2021.
Your friendly DNS programmer, Peter.
Here is the current APEX of the zone delphinusdns.org as queried with dig any delphinusdns.org @pod.delphinusdns.org (pod is one of the nameservers of delphinusdns.org). I also ran this through a grep -v RRSIG since those are machine like signatures that serve no real human purpose.
;; Truncated, retrying in TCP mode. ; <<>> dig 9.10.8-P1 <<>> @pod.delphinusdns.org delphinusdns.org any ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48222 ;; flags: qr aa rd; QUERY: 1, ANSWER: 26, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;delphinusdns.org. IN ANY ;; ANSWER SECTION: delphinusdns.org. 86400 IN SOA arda.delphinusdns.org. \ ici.delphinusdns.org. 2021112101 3600 1200 1209600 86400 delphinusdns.org. 3600 IN DNSKEY 256 3 13 \ QJRb5mSQZxmSd1N1QvAboRUh8vk4J1H25SKvtYlun8msxs/l9LXb9I97 QKZZ9oBWVfCiWKB6FCQqfFM45UjSEQ== delphinusdns.org. 3600 IN DNSKEY 257 3 13 \ Jr2jhZF/5IWshQKN+pINgjN4nHumie/TR+w7W3pvZRzUMgSBi8mc9K/1 GMl9l01r2vggrzYqaV0TVY680GXSDg== delphinusdns.org. 86400 IN LOC 50 4 3.600 N 10 15 4.600 E 350.00m 1m 0.00m 0.00m delphinusdns.org. 86400 IN RP dns-admin.delphinusdns.org. ops.delphinusdns.org. delphinusdns.org. 0 IN NSEC3PARAM 1 0 10 - delphinusdns.org. 86400 IN NS pod.delphinusdns.org. delphinusdns.org. 86400 IN NS sky.delphinusdns.org. delphinusdns.org. 86400 IN MX 5 postbox.delphinusdns.org. delphinusdns.org. 86400 IN MX 10 mail.delphinusdns.org. delphinusdns.org. 86400 IN MX 20 smtp.delphinusdns.org. delphinusdns.org. 86400 IN TXT "v=spf1 ip4:159.69.184.253 ip4:46.23.94.170 \ ip6:2a01:4f8:c010:71dd::1 ip6:2a03:6000:6f68:631::170 ip6:2003:a:60f:ce01::108 ~all" delphinusdns.org. 86400 IN TXT "the latest dns server is available at github.com., \ https://pirata.dev/delphinusdnsd is the softwares maintainer site hosted by Ricardo Santos" delphinusdns.org. 86400 IN A 46.23.94.170 delphinusdns.org. 86400 IN AAAA 2a03:6000:6f68:631::170 ;; Query time: 30 msec ;; SERVER: 2a01:4f8:c010:71dd::1#53(2a01:4f8:c010:71dd::1) ;; WHEN: Tue Nov 23 02:27:00 CET 2021 ;; MSG SIZE rcvd: 2028I'm especially proud of the LOC addition just a few weeks ago. update: I line wrapped the output a little...
I have put delphinusdns.org back on my servers since Ricardo's server was down for a full week. I have still left him as a mirror site from this blog. I hope he's not too sad, I'm very happy he helped me out, but I guess the downed server was a message that I'd have to take my baby back.
I have tagged the tree to 1.6.0. It was the first time doing it with git I think and it was uneventful and just worked. Please consult the CHANGES file to see what changed. It makes no sense to run anything below 1.6.0 unless you have custom hacks that need to be ported first. Enjoy and have a happy solstice, christmas and new year!
As I sit here in my parents living room, and drinking coffee, I wish you a: Happy New Year 2022. May you have a great year ahead of you!
In 2019:
In 2022:
The sum is important to cross-reference CACHEHITS which is a small cache in
Delphinusdnsd 1.6.0 to speed up answers.
According to this article which has deeper hyperlinks linking to here, the EU is planning on providing DNS infrastructure for everyone. This is similar to efforts of government taking back the Internet from corporations. As you may recall telephone access fees became a lot more affordable when corporations built the Internet which surpassed the POTS (plain old telephone network). It was a fight between ITU and corporations that united in a great big network, the Internet. The corporations won, but government wants it back because they realised that communications is control over citizens. What they plan on doing is also building an extensive filtering system into their DNS system. This provides opportunity to be abused by government for censorship, for corruption. Delphinusdnsd isn't related to this project and I'm glad I don't have to lift a finger to help the government see this through. It's just disgusting though, and I wanted to make DNS enthusiasts aware of this. Yes it is political.
For those that expect to see major code additions I have to disappoint you. Development is stalled on a project for my dad, which i hope to have done by mid-March. I also had to shuffle a lot of computers around at home in order to make electricity savings. That shuffle is pretty much done. I'm craving for doing additions to delphinusdnsd though and this spring when it commences will be great. A damper to that will be a new job but I haven't been accepted to any outstanding resumes, so my hopes aren't very high on that.
Starting in OpenBSD 7.1, the OpenBSD team has rolled select into a wrapper of kqueue. This will unlock the kernel from a select big lock and make in the end the result may make it faster to run delphinusdnsd on OpenBSD.
Here is a comparison of two top(1) outputs:
OpenBSD 7.0:
PID USERNAME PRI NICE SIZE RES STATE WAIT TIME CPU COMMAND 47844 _ddd 2 0 29M 32M sleep select 0:00 0.00% delphinusdn
PID USERNAME PRI NICE SIZE RES STATE WAIT TIME CPU COMMAND 78016 _ddd 2 0 59M 62M sleep/0 kqread 0:09 0.00% delphinusdnNotice the change in the WAIT state from select to kqread.
I have always developed delphinusdnsd on OpenBSD as the primary OS. Ports to Linux, NetBSD and FreeBSD exist (in no particular order). But testing for these other OS's does not occur until a bit of time before a release.
I have seen no fallout to the OpenBSD select->kqueue change, good work!
Proudly I am releasing delphinusdnsd 1.6.1. This is a minor bugfix around more safety in the sandboxes. The source/release can be found at github.
Did you know that the name delphinus in delphinusdnsd already contains the word "DNS"? Here is a doodle of mine:
It also contains traces of the first (and second) initials of my parents and prefix of our last name "Philipp" (liker of horses). Only until last week some time did I open my eyes to this and it fit. It seems like delphinusdnsd was the name for my program and DNS was my protocol. Anyhow I wanted to share this to you. If the ddd debugger ever requires a "_ddd" user I'll have to change it on my systems and "_delphinus" doesn't look too bad now.
I had picked delphinusdns arbitrarily after a constellation in the sky back when. Who knew what my subconcious thought?
Milestone: On April 22nd, 2022 we have 1000 commits under the delphinusdns name. The project in total is 5988 days old (as commit records show), 2716 days under the delphinusdns name. We have 50667 lines of C and YACC code currently and it is big enough to fit just about on a 1.44MB floppy (C and YACC code are 1210956 bytes, some images would have to be discarded). We have two committers currently. We were developed since day one on OpenBSD (then version 3.8, now version 7.1) and we always tried to include the latest OpenBSD mitigations against attackers.
I'm very glad to be giving you this news! :-)
I'm almost ready to start coding on DNS Updates (RFC 2137 and 3007) and I'm making plans on that. Here you will see an behind the scenes look of how I plan this out:
My NOTES on making DNS Update functionality
I) when an update comes in:
1. check TSIG pass on to update process via cortex
a) an inserted RR can't be of DNSSEC kind (this gets calculated on fly)
2. in update process perform the following task
a) sign with ZSK (which must be made available in
/var/delphinusdnsd/keys) to create an RRSIG
b) insert into a new (in-memory) db after a copy from orignal db
c) update SOA serial (we can only support time_t serials check for that)
d) sign apex record replacing existing RRSIG
e) delete all NSEC3 entries of that zone and their corresponding RRSIG's
f) recalculate all nsec3's of that zone creating an NSEC3 and sign
with RRSIG
g) dump entire database to file, this file will get precedence on
restart over anything already existing except when the
SOA's serial is behind at which point it gets deleted or moved
h) the database is now complete, send to all processes to update via
cortex process
i) merge in-memory database with new in-memory database
Notes)
- this makes NSEC with updates impossible but it's ok we're master
- we must have access to /var/delphinusdnsd/{master,keys,dynamic}/*
- perhaps we need a global setting for serial choice (choices between
arbitrary, time_t and YYYYMMDDXX) for updates we must have
time_t serials which gives us second granularity to
Sun Feb 7 07:28:15 CET 2106 (at which point DNS will explode)
((but I'll be long dead then))
II) on startup
1. read the configuration file
2. if a dynamic update file exists read it into a second database and merge with
original zone database.
3. continue starting up
Hopefully I'll get this in the way I have foreseen. Do note that RFC 4033
says in section 12 (Security Considerations): An attacker may also be able to
consume resources in a security-aware name server that supports DNS
dynamic update, by sending a stream of update messages that force the
security-aware name server to re-sign some RRsets in the zone more
frequently than would otherwise be necessary. This is indeed a problem
but I hope I can set up a kind of queue system in the update process.
Over the weekend I put in RFC 7043 support. It seemed pretty easy and I did it over 2 days. I hope I didn't forget anything it seemed a little too easy, but dddctl query support works, axfr works, raxfr works, querying eui48 and eui64 works and it appears in any queries. In logs I also noticed it is logged. Signing eui48/64 works. So perhaps I didn't forget anything.
This work was inspired by Lory (an ex-schoolmate) who appeared in a dream of mine and asked me to put this support in. With the DNS Updates delphinusdnsd will have the functionality that she described to me in the dream. I know it's weird that I dream about the DNS server. Anyhow, the idea is that MAC addresses can now be put into delphinusdnsd and reading the RFC 7043 one case of Canadian Cable ISP's doing it is mentioned.
I came across this image chart and needed to add delphinusdnsd to it.
The image is made by Ruurtjan Pul on Wikipedia and is under the CC license. I have filled out the non-support in red and the supported records in green, other than IXFR and AXFR which the latter is supported in full. To see this chart closer you can select it with "open image in new tab" in your browser.
I have released 1.6.2 as backpatches from the master branch. The fixes affect SRV, NAPTR and ANY replies. Enjoy!
I'm planning on starting the DNS Updates work in around June, since this is major work, I can't promise I'll be done in December. It may go beyond into 2023 and when finished I'll roll the 1.7 minor release. Until then you'll see patch releases in the 1.6.X patch series, for whatever comes up.
I noticed someone forked delphinusdnsd meaning that my code is getting eyeballs or intend to add more features. I welcome that. I don't know the intend of this someone but I hope to find out more about them in the near-future.
What about the major releases? There is none for me, another team (if one forms) will continue on doing delphinusdnsd 2.x. But this will be beyond 2025, so there is some time left still to change my mind or set this back in time. It's two and a half years so I feel comfortable with this. What do I plan on doing after delphinusdnsd? I was thinking of doing something with VOIP but not sure yet.
I had a bit of a shocker the other day. I made a 12,000 RR zone and wanted it to be axfr'ed. But the replicant would not take it. I was stunned. I hoped that I wouldn't have to repair code in this moment. After a few tries and nothing. Then I remembered I had put in a hack around to a peculiar change in AXFR and called it "replicant-axfr-old-behaviour" and similar on the primary "primary-axfr-old-behaviour". This behaviour had something to do with copying back the question of the AXFR. Judging by the comment in the code it seems that new behaviour is not to copy the question header. Anyhow needless to say I had this flag set on the primary but not the replicant thus it failed copying. When synced it worked immediately. Yes I admit I totally forgot about this feature. I will remove it in the future release (probably at 1.7 time, granted I don't forget *smile*).
I'll be adding probably another 20,000 RR's to this particular zone and it'll be a great test to see how well AXFR's work.
Today I put in guard pages between slots in the three major shared memory regions. These shared memory regions usually transfer packet metadata, cache and full packet data. They are contiguous regions that I changed guard pages on between slots (I hope slots is the right term here). It looks a little like this:
start of memory ------> +------------------------+
//slot #0 //
// //
guardpage (pagesize) -> +------------------------+
+------------------------+
//slot #1 //
// //
guardpage (pagesize) -> +------------------------+
+------------------------+
//slot #2 //
... (to slot 199 or 399)
This ensures that at no time you can overrun a slot's boundary as you'll hit a guard page. I changed the page protection with mprotect() to PROT_NONE, so even reading from this area is akin to reading from non-allocated memory and will signal 15 afaik.
I worked on this today because I previously worked on send_to_parser() which is a routine to send a DNS raw packet to the sandbox'ed parser process. Right now we have a limitation of 16K or something in the imsg framework to send data to this parser process. I plan on increasing this to the DNS maximum of 64K and do it with shared memory which will speed up things (memory is the fastest way of IPC (when shared)). We just gotta get the locking right, right now we have a ghetto lock which isn't really a lock. I think I may create a file where delphinusdnsd will serialize around a file lock. This should be ultra safe.
Anyhow this relates to the DNS Updates work that I'm slowly easing into.
I just want you to know that I haven't given up. We're approaching the warmest part of the year and for me that means little coding. I wrote to someone recently that I center my best coding around the equinoxes with some additional coding near the winter solstice. In the summer the trend is to chill on IRC or whatever and wait out the heat. I do have some minor things to do which aren't really DNS Updates related (forwarder giving me gripes) so you may see something there in the next few weeks. Have a great summer!
I'm sitting here in my parents living room writing this. It's been two weeks since I committed any code and it'll likely be anoter two weeks before I start committing again. The outside temperatures are sheerly too hot and as most germans I do not, and my family does not own an air conditioner. The temperatures are expected to hit 36C soon and have been doing so in the past two weeks. Though while I'm not coding I can think around what I want to do and write a blog article or something. So I thought I'd write about my inspiration for writing this DNS server.
Back around 1996 I bought a book by W.R. Stevens on UNIX Network Programming and bought followup books ever since. The 2 volume set of the 2nd edition was what inspired me directly to write a DNS server. All the foundations were laid in the book and I occasionally used the book (one is already falling apart) as a reference on socket code. So who is W.R. Stevens? He was a professor and worked at an observatory for astronomy. All the things pretty well that interest me, he did it. Unfortunately he died before Y2K which made his books so much more a legend.
After partially reading his books on network programming I concluded that this is the foundation for building a dns server with udp, tcp and even raw sockets. Which is what delphinusdnsd uses, it explains well known ports and ephemeral ports, it explains connecting UDP sockets and so on. Thanks Mr. Stevens for guiding me maybe we'll meet some day in the after-life.
Just so you know I have replaced my profile picture with a self portrait.
Enjoy!
Whenever I code I build up stress with it. Right now I don't need more stress as I'm soaking in serenity. Maybe in the future I'll get back at doing DNS Updates, but it isn't in the foreseeable future. To those who have been looking forward to this, I hate to disappoint you, but the program is good as it is even without DNS Updates, I feel it's nearly finished and doing the last few touches won't affect it much. Have a happy holiday season all, stay safe.
I just skimmed over this RFC. I think everything is done right. Drop me an email if you see something from the implementation aspect that is wrong.
Before a configspecifying an axfrport would look like this:
options "some options" {
...
}
axfrport "10053";
...
This has been changed:
options "some options" {
axfrport 10053;
...
}
...
So I moved this option into the proper options block. There is also another
change called "strictaxfr;" in options. If you set this, you must have an
authenticating key before it spits back anything. If you don't it will hang up.
Otherwise the behaviour is as before plain non-authenticated (non-TSIG) AXFR's
would go through.
A config change took place, anything downloaded and built after this date needs new configs. Check out the commit message. Some will rejoice perhaps at this. I'm glad I listened to Ricardo.
I have added cookies to dddctl query and committed the code. If you are using dddctl to sign zones make sure you adjust this script if you're using it. It greps (with -v) for '^;;' and with this change it will possibly produce misoutput. It should grep -v for '^;'. I had to update all my signing scripts too. Cheers!
Today I checked in the SVCB and HTTPS support. But it's broken. As long as you don't use these RR's in your delphinusdnsd zone config files it should be fine. I need some time to fix these up, maybe by next week.
I have added KX RR (RFC 2230) and IPSECKEY RR support (RFC 4025) these are both related to IPSEC and I hope to ignite some more DNS and DNSSEC interest in the IPsec programming community. I did have someone point out to me that Free/Libre/Open S/WAN's are all able to use the IPSECKEY RR. I did check in OpenBSD and there is use of a KEY RR in isakmpd in a file called dnssec.c. Perhaps now someone can hack this up to use IPSECKEY instead of KEY. It wasn't enabled dnssec.c code though. I'm glad there is more functionality in Delphinusdnsd and it will release with the 1.7 release in possibly December.
We're not going to see DNS Updates this year, in fact I've been on a spree adding RR's because I need some fairly easy work until the release. I'm hoping next year will be a good year for DNS Updates, so for 1.8 release.
In this article I visually showed what RR's we support compared to ones we don't support. Here is a september 2022 update:
The new RR's are in a lighter shade of green. Green is supported, red is not supported (yet). I'll likely not add any more this year...
So over last week I have implemented DoT on delphinusdnsd. It is still in the experimental stage. However having said that I have implemented a padding feature using OPT code 12 (padding), which pads out dns answers by 1024 bytes. However the RFC's disallow sending an EDNS payload to someone who didn't request it. So my call out to recursor implementors is to make sure you are sending EDNS0 through TLS (you can give it size 0xffff like is standard for a TCP DNS packet). My implementation of RFC 7830 uses arc4random_buf() which is a MAY instead of a 0-stream SHOULD. But you MUST accept it if you request it. The benefit of arc4random_buf() in this is that cryptanalyists can't find a block that is full of zeros and thus they can't guess what's behind the ciphertext. I value that as a bonus.
On the centroid.eu blog (predecessor to the delphinusdns blog) I wrote proudly that wildcarddnsd (former name of delphinusdnsd and built on a fork of this) was over 10,000 lines of code. Well...that was then, and this:
echo$ wc -l *.[chy] | grep total 59146 totalis now. Almost 60K lines, and more planned. Though I've written delphinusdnsd with a lot of copy/pasting from other functions and haven't compacted a lot of redundancy into their own functions. Whether I do that before I "retire", will be seen. I plan on going into in-active development after version 1.9 if you don't know yet. Delphinusdnsd doesn't have programmers other than me and if I continue on with a 2.x version it will be as a team.
An AAAA reply could send two packets in UDP and (possibly) double the answer in TCP. I have a patch made but won't commit until later when my developing workstation is back online. I had this to say about the bug:
09:37:29So it was with us for almost a year and throughout the 1.6 release. I don't think I'm going to make a backpatch unless you absolutely want me to. An email will do and I'll make a backpatch to 1.6.x version. Other than that the November/December release of 1.7 will have this fixed. So for now happy holiday.almost a year with this bug 09:37:38 Oct 19th, 2021 09:38:25 d6a64d50049b4c39755a0c875a6ddd7fbd63bbbd is the offending commit
On the 27th of February in 2019, I did a commit with a few dubious changes. The commit is 88e1f5170fea07586416f9ba2de5f36b99985cc7, and a dubious commit looked something like this:
@@ -276,7 +279,7 @@ out:
u_int16_t *plen;
tmpbuf = malloc(outlen + 2);
- if (tmpbuf == NULL) {
+ if (tmpbuf == 0) {
dolog(LOG_INFO, "malloc: %s\n", strerror(errno));
}
plen = (u_int16_t *)tmpbuf;
As you can see it replaced a NULL with a 0. I can't explain why I would do
this. I fixed it up in commit 6b8ba22a0ecdf078798e64d13af67a48b45a9fc1,
yesterday. I went back to seeing what I did in that February 2019. It was
when Delphinusdnsd was in 1.3 still and I was at that time putting TSIG code
into it. I had correspondence with people from the west and from the east.
I also bought a lot of Windows books back then, did online shopping.
I find it very odd, though I dimly remember something with compiling linux
caused me to write out something to prevent compile errors. Perhaps it was
a file that accidentally slipped in?
My systems have changed twice over since then and I don't have evidence for any breach. Though there was a rather big smtpd vuln between OpenBSD 6.4 and now. Anyhow I can only learn from this. I need to write conciser commit log messages with every commit detailing everything. I also need to examine every commit after committing (partially doing that already) it helps in finding bugs that slip through.
I just saw that Theo de Raadt committed mimmutable(2) support into OpenBSD 7.2-current. Unfortunately I don't run any -current systems at the moment so it's hard for me to put support for this in and test it for the 1.7 Delphinusdnsd release which is scheduled for after the FreeBSD release which says December 7th on some document I saw @freebsd.org. Too bad, but on the other hand it gives the OpenBSD code some time to be tested and it will be in Delphinusdnsd probably after the 7.3 OpenBSD release so look for it in our -current after April/May some time and Delphinusdnsd 1.8 in december 2023 should have the systemcall supported.
A DNS server is never finished(tm). It's an ongoing effort all the time, but here are two construction sites in delphinusdnsd that stick out rather.
(some cut for a query that went to sky.delphinusdns.org) (ttl=TLS, region=1, tta=NA) for "sky.delphinusdns.org." type=SOA(6) class=1, answering "NOERROR" (bytes=38/120, sum=NA)Also I can't forward TLS code like one does a descriptor passing. This is a limitation with the LibreSSL tls library, so forwarding code and AXFR won't work with DoT. I removed the code for this in tlsloop(). AXFR's will have to have their own ports in order to do TLS and I don't know if it'll happen in 2022.
In possibly July 2002 I wrote the first header files in C for DNS programming. Back then I had intention to write exploits, today I don't have those intentions anymore. DNS work straightened me out. To be exact in 2002 I wanted to write reflection and amplifier tools. It's perhaps coincidental that I'm working with pf today to filter the "sl." botnet which seemingly has 1 spoofing master ,(14 hops away from my dns server), to reflect off my DNS server. Some of you may have come across the "sl." queries by looking at your logs, I know one of you has mentioned to me before that this is an attack. It is an attack but not on us. It's more using our infrastructure to contact zombies from the master. Or so I believe.
So 20 years DNS work, and soon the codebase to delphinusdnsd will also be 20 years old (in 2025). When you look at the first checkin of wildcarddnsd there still is similarities, but with DNSSEC additions I have changed the concept of this DNS server software immensely. I enjoy the work but before 2025 it's over with the 1.9.0 release for me (being the sole programmer). I want to do other things and there is some ideas on the table already. I can't do them all so in 2024 I'll have to make a decision what I want to focus on. Otherwise I'll likely do little projects one after the other but somehow I won't find enjoyment with that. Go big, I think! Thanks for reading my thoughts here.
I looked at my commit record on github just now and my commits are based around the equinoxes. March, April, May...August, September, October is where the Lions share was. The climate of 2022 had a lot to do with this, where in the summer centred around the solstice there I did nothing. It as too hot. Call it a long siesta. Also I noticed I did around 200 commits this year.
I'm calling it over for coding any more in C on delphinusdnsd this year. Of course any major bugs I'm gonna work on. I have a job interview this week and depending whether I get the job or not I will only be able to do things on weekends. We're on track for a mid december release. The only thing I will have to do still is update the web documentation, which is not hard but it requires a bit of time.
Also this job, if I get it, will change things. The version 1.7 may be the best version yet but don't expect big things for 1.8 next year and beyond for as long as I am professionally employed full time. This puts DNS Updates on the back burner indefinitely. I will get holidays but I haven't been away on holidays in ~10 years so I may not be doing code for a while, but instead go somewhere perhaps.
Do mail me with your wishes for 1.8 and if they are small enough I may just get them in.
I have released delphinusdnsd 1.7.0. More about this can be found on the mainsite under news.html. Enjoy!
I read somewhere that Elon Musk wants to charge 8.00 USD for twitter users. That amount of money is cheap enough to get you a vps for 5 EUR/mo and if you're lucky the remaining 2.60 EUR might give you a really cheap vps or pay toward a domain name. A VPS is a cloud computer, a virtual private server (VPS). Two VPS's is what's required for a minimal setup with a DNS authoritative server such as delphinusdnsd.
These VPS's are cloud servers from providers such as Hetzner, DigitalOcean, Vultr, OpenBSD.Amsterdam, TransIP, these are just to name a few providers, and with exception to DigitalOcean they will allow you to install OpenBSD OS. On these same VPS's you can run a webserver with your favourite blog software. Though I urge you to look into kcgi blogs as these are C based and you don't have to even install a PHP program and if run on OpenBSD you can pledge these to a stdio only pledge. This makes it rather ultra secure. Then you can also set up a SMTP server on your VPS and you have DNS, SMTP and HTTPS (if with letsencrypt). Alas you have a setup like I have it almost.
This is all available as Open Source, meaning you invest in your skills manageing this system rather than paying for the software. Delphinusdnsd works well with this sort of setup and it too is pledged. But you can also pick from other DNS programmers programs such as nsd, powerdns authoritative, BIND. So once you have one server running you need a second one for the authoritative DNS. You may invite a spouse, partner, friend, sibling to host to you this second VPS. It will cost them exactly as much as it cost you, and between the two of you you share 2 DNS domains.
This could be a come-back for the old-style blogs where you have full control of logging who visits your blog and thus you have full stats for which also some programs exist that are open source. I'm not promising you would become as big a google, but for a site serving 2-20 TB (able to do so at Hetzner 20 TB) you would be quite popular judging by traffic. It's low budget and it could help you shape your online site. If I just opened a door for you, it was my pleasure, otherwise keep it in mind for others. It may help your social status too. Who needed twitter anyhow?
In the OpenBSD system there is a nice feature in syslogd to have a circular buffer log (meaning when it's full it jumps back to the beginning). This speeds up logs because they are in memory only and I can still find the last few logs if there is a crash. My logs look something like this:
!!delphinusdnsd #*.* /var/log/delphinusdnsd *.info :64:delphinusdnsd !*notice the hashed out file log. You should be happy about this as it gives you temporarily more privacy. Though I wonder if I should collect dumps of syslogc delphinusdnsd periodically. This would be for stats collection only. Another way would be an internal stats counter to delphinusdnsd that could be dumpable with dddctl. I'll think about it.
Having admitted I collected logs for a long time for statistic purposes I'll put forward a statement of assureness that I did not correlate this data with my weblogs for example. I don't have the time of day and the nerves to go through with something like that. Guess I'll just have to disappoint you that I found your preferred nameservers to IP. Though I did see there is a MX lookup from microsoft's nameservers whenever I log into linkedin. It makes me think this is careless on part of microsoft, but I'm not going to try any- thing with it because I do like my account there. Anyhow, happy 3rd advent time, may you come to terms with christ being born those many many years ago.
Let there be manna!
In this commit here, I fixed the dddctl bindfile, today. I've come to the realisation that delphinusdnsd serving TXT's as a replicant when the primary (aka master) is NOT delphinusdnsd _could_ cause a conflict and the query answered from delphinusdnsd may not check out in DNSSEC. And this is only in DNSSEC. I'm thinking around a fix for this and it may take a few days due to the holidays. One logical way of doing this is to let delphinusdnsd know it is a replicant zone when it reads out of /var/delphinusdnsd/replicant and then expect a split TXT record when the size is over 255 bytes. In plain english it has to do with the partitioning of a TXT message that is larger than 255 bytes. I'll be working on that. In the meanwhile if you're affected (using TXT and DNSSECed zones with delphinusdnsd) dump the delphinusdnsd temporarely and look for a 1.7.1 release to pick up where you left it.
I've been holding off doing any work as I'm trying to overcome an emotional blockage. It's like I said, you're only affected if you use a primary (master) other than delphinusdnsd and only if the TXT RR is greater than 255 bytes. What happens in detail is that the non-delphinusdnsd master may give a TXT RR in an AXFR which may have different offsets between segments than what delphinusdnsd expects. As the AXFR takes place delphinusdnsd writes it to a replicant file as a reassembled TXT RR and then restarts assuming that the segments are exactly 255 bytes maximally and fragments the segments on that. If the segments are not exactly like on the primary (master) the RRSIG which signed this TXT Record with on-the-wire byte orderings will not match what delphinusdnsd gives out. It should result in a SERVFAIL or the recursive nameservers may try another nameserver but it's not guaranteed that it will recover for you.
Luckily the setup of a replicant is easy enough for any alternative DNS server and the dddctl bindfile mode gives you the chance to convert your delphinudsnsd zones to BIND format. This bug has been with us since the beginning (when we started replicating) and like I said as the sole programmer I'm facing a emotional blockage right now. The fix is in parse.y and how it parses TXT records, similarily raxfr.c would need to write TXT RR's in exactly the segments that it was given them in the AXFR. This also deviates the whole parsing for a TXT record and I'll have to examine if I have to do much work in parse.y for this. Finally I'll end with a nice saying. "DNS how hard can it be?!"
If you use tsig to protect queries and answers there is a segfault condition that I found today when there is a DNS BADTIME reply (ie. the query has a bad time outside of the TSIG fudge). In particular when the queryname is "." the delphinusdnsd server quits with segfault. For now I recommend anyone using 1.7 to go to the git HEAD (latest commit) and wait for 1.7.1 to come out. I'm still feeling unwell to do major changes (as per the last problem found) and I just started a new medication so it may take a bit until I get delphinusdnsd in a great shape again.
This is just a patch release fixing a single error condition. A segfault was found a few days ago and this should be the right fix.
I found another issue with delphinusdnsd as an AXFR primary. When on a host with IP aliases it will sometimes pick the wrong IP (IPv6). I have a patch but it does wrong things which I have to debug first before I commit it. The TXT RR problem is also by now on the back burner, the emotional blockage that I have hasn't fully healed and I lack the concentration to sit down and do this right now. If anyone wants to step up and help that would be grand. If not, it will take its natural time.
The TODO's for this year will likely not be achieved. The usage of delphinusdnsd will have to be watched by me and some parts will have to be rewritten as they are just impossible to maintain. This means that this year there will likely not be a dns update functionality. I'm not saying this in spite but rather want to prevent a burn out of myself. I deserve a break and if anyone wants to contribute the best way is to send me patches first before we both consider adding you to the commit list.
Also there have been some breakthroughs with the got (game of trees) program that I might make use of. This may mean that I'm possibly taking development from github back to a got repo. However. Since we're on version 1.7.1 now and the last release will be before 2.0.0 for me this may not happen. It's something to consider though. Eventually I'll have to let go graciously.
The quest to give the source of a notify packet a bound IP had me going off on a trail to fix it. However..., I have realised I need to rewrite this code partially. It was first implemented in the predecessor of delphinusdnsd under the wildcarddnsd name. This was in 2011 and before I moved into this nice apartment. I don't really know what I was on (self admittance). So I'm going to adjust the TODO file accordingly and plan out this code. Important to me is, that this code is readable, and not jammed. As in that you cannot really move it forwards or backwards and gain what you want from it. This takes time out of my day unfortunately that I would otherwise use to relax. Maybe a bit of work is good for me though.
I have found a potential buffer overflow in the TCP and TLS code. I think the TCP code was around for a number of years. Since June 2019 at least. The best way to go about this is to upgrade to the master branch with git and recompile. Then wait for a 1.7.2 patch release, the code hasn't changed much since 1.7.1 and thus this is OK.
I made a mistake there was no buffer overflow. There was 5 variables to watch and a buffer which was 0xffff + 3 bytes big. The one variable I did not watch close enough was tcpnp->bytes_expected, which limits how much can be read and is decreased. I'm sorry for the heartthrob, I won't backport the refactored code just yet.
Today I finished the code to the new txt parsing, and backported it to the STABLE_1_7 branch. This addresses the problems I identified on this blog on December 25th, 2022 and explained it a little more on January 3rd. I'm happy I found time to do this as this month I had lots of appointments for non-coding related things. Please enjoy this change!
I've found a bug with my memory allocation code, it has been stalling efforts to get some things encrypted in the shared memory. There is several factors involved but I think unwind(8) plays a major role in this.
So I mailed Otto who gave me some helpful hints and having looked at his malloc code I was able to piece together what could have happened. If another network looks up for '.' it causes a 1 byte allocation to occur, the length is saved in a struct and a NUL byte is put in that 1 byte. This is the represent ation of the root zone. It's a hack because it really is 0 length. So then I have a second allocation for the human readable representation of the root zone which will be 2 bytes for the '.' and the NUL terminator (it's a string). The problem I found in the function convert_name() which is supposed to short circuit the root zone and return a length of 2. Unfortunately I had a wrong check in this function that checked for a NUL byte on the 1st element (starting at zeroth), which was a bug, it should check the zeroth element. I was able to track down this commit done in 2020 . So what is there to know? And how does this bug occur? I suspect that build_question() built the root question name with one byte and one byte length and then freed it. Whenever a free occurs Otto's malloc writes a magic called deadfree's (0xdfdfdfdfdfdfdfdf) which account for 8 bytes over the freed area. The actual freeing is delayed until next free actually which gives the code a chance to detect 'write after free\'s'. Once the chunk is freed another one byte allocation comes along and sets NUL byte, but the adjacent bytes are still from the freeing so 0x00dfdfdfdfdfdfdf. At this point when the convert_name() is called the bug is that the short circuit fails and the rest falls through due to passing 0 to memcpy (which too is erroneous). The 2 byte allocation will then be zero filled (2 NUL's) makeing the human representation flawed. This would reflect on the logs most likely. There is a cascading effect taking off for this NUL, NUL in fact turning into just a NUL in the (so-called) engine process.
If this isn't the bug, then it's one of many. I also made sure I 8 byte aligned the shared memory slot for struct parsequestion. So far looking at it the code has held up longer than other times. I'll be backporting the fixes for this into the 1.7.3 release. Good night!
After I wrote this the forwarding delphinusdnsd crashed again. I guess I'm bug hunting when I find the time. This is weird! I'll get to the bottom of it one day though.
I likely found the culprit. It was wrongly added on March 19th. Here is the fix to this. Whew! Thanks to Otto for some great hints!
In this commit (github) I have changed the TCP structure a little bit. I now fork an extra child that is an "accept engine". All it does is select on the listening descriptors and accept(2)'s the socket. Once it has this it passes the socket off to the main TCP engine that used to do this task. I was able to lose the "inet" pledge in the main TCP engine and this made it worth it. However now the setup is a bit weird because the main tcp engine passes this descriptor to the parsing engine which now has comparable pledges. That's what's weird about it. But the UDP main process still needs the parser process in order to do safe parsing, why not give the tcp process it's own parser too right? It's just a bit more overhead but is acceptable to me. On my test workstation the latency of a lookup was around 1 ms on tcp.
What's next? The acceptloop() will likely see adoption in the AXFR engine as well so that it can lose it's inet pledge too. But I'm gonna take it easy for the rest of the day. I did mostly programming today.
For some eye-candy this is what a box with delphinusdnsd looks like in a process listing:
root@stern# ps ax|grep delphin 45039 ?? Spc 0:00.42 delphinusdnsd: cortex [] (delphinusdnsd) 21925 ?? Spc 0:00.64 delphinusdnsd -f /var/delphinusdnsd/etc/delphinusdns 54020 ?? Spc 0:00.02 delphinusdnsd: cortex [] (delphinusdnsd) 26945 ?? SpU 0:00.05 delphinusdnsd: primary [] (delphinusdnsd) 64451 ?? SpUc 0:00.02 delphinusdnsd: unix controlling socket [] (delphinus 40668 ?? Spc 0:00.03 delphinusdnsd: AXFR engine on port 10053 [] (delphin 81060 ?? SpUc 0:00.03 delphinusdnsd: Replicant engine [] (delphinusdnsd) 97802 ?? Spc 0:00.30 delphinusdnsd: FORWARD engine [] (delphinusdnsd) 53973 ?? Sp 0:00.13 delphinusdnsd: TCP engine 0 [] (delphinusdnsd) 78173 ?? Sp 0:00.03 delphinusdnsd: TCP parse engine 0 [] (delphinusdnsd) 60256 ?? Sp 0:00.04 delphinusdnsd: TCP accept engine 0 [] (delphinusdnsd 13609 ?? Sp 0:00.04 delphinusdnsd: udp parse engine 0 [] (delphinusdnsd) 13864 ?? Sp 0:00.04 delphinusdnsd: forward parse engine [] (delphinusdns 86423 p0 R+/1 0:00.01 grep delphinLots of processes...
I'm guessing anytime before now and Easter OpenBSD 7.3 will be released. Pretty soon after that I'll upgrade my systems to this. I do develop on OpenBSD so if you follow my development in the master branch of github and git pull often, I want to give you a small warning. Very soon after the 7.3 version is released I'm going to add mimmutable() to my sources to protect the shared memory, which has guard pages between each slot. This will tighten our security parallel to OpenBSD's mitigations. For more about this topic, check out Theo de Raadt's talk at CANSecWest. The link is here (undeadly.org). So mimmutable() will likely be #if __OpenBSD__ in the sources but I won't try to #if versions of OpenBSD. This is open source, and you're expected to be up to date. So if you're on OpenBSD 7.2 or lower after I commit mimmutable() you'll either have to remove them with #if 0 in the source yourself or be forced to upgrade if you want to run the latest greatest. The 1.8.0 release will also come with this mimmutable() change for the first time. The 1.8.0 release will be around Christmas time as usual (or likely a few weeks before/after depending on how I feel). Happy happy.
Since 2019 at least I knew about them, it took four years to fix it. I always said to be careful with these. This article is now a historic relic as escaping colour for christmas trees is not allowed anymore. Yay for security! Thanks to OpenBSD, tcpdump, and David Leadbeater who all have prodded me with incredible bugs and bugfixes to get this fixed.
Also you can use the debug console now without worry. I fixed that too.
spica# dddctl query -Q159.69.184.253 vis.dtschland.eu txt ; COOKIE: D8F12F7C99B6B4CC ;; QUESTION SECTION: ; vis.dtschland.eu. IN TXT ; SERVER COOKIE: D8F12F7C99B6B4CC0100000064203822171FFA01B6DAD552 (good) ;; ANSWER SECTION: vis.dtschland.eu.,txt,86400,"\^[[32m;green green green oh lovely green" ;; ADDITIONAL SECTION: ;; QUERY TIME: 22 ms ;; SERVER: 159.69.184.253#53 ;; WHEN: Sun Mar 26 14:18:42 2023 ;; MSG SIZE rcvd: 125I won't be backporting this unless I'm backporting another bugfix, if you want this you'll have to track the master branch (commit 193373f).
I have worked like a madman on this, and finally I have succeeded. The gist of the matter is that AXFR will need a rewrite anyhow but I was just getting familiar with this a bit more. Anyhow AXFR now forks a child helper that has the "inet" pledge still and both of them exchange filedescriptors back and forth until all notifies are done. Then the AXFR can't send anything anymore. It can only receive and serve zone files. This is more secure I'm glad I took the time to do this. This will not be backported to 1.7.x branch so you'll have to wait until december for the 1.8.0 release. Or you run on the master branch aka -current. But it's a work in progress.
Pretend someone forges (spoofs) a packet to a DNS server. If that server is delphinusdnsd it will add, to a hash of the source address, a timestamp in order to calculate the ratelimiting (definable between 1 and 127 pps or alternatively off). If that forged packet claims to be from a valid recursive nameserver like 8.8.8.8 (google) and does this at the ratelimit, the real google nameserver will never get through, because it was denied (dropped) in the ratelimit. It will have to resort to using TCP and what if that protocol is also denied? So I have changed the algorithm a little bit. It will add not just the timestamp to the hash of the source address, but also a ttl value of the received ttl. This value is always the same which is the case for most hosts hop distances on a stable Internet, it may differ by a few hops occasionally as routing changes but it doesn't always do this for most networks. So a spoofing denier will have to guess the exact ttl that 8.8.8.8 has to my nameserver in order to deny it, and that's a bit intense. It may work with tracerouting but chances are that this is not accurate. Anyhow this is new and I wanted to tell you about it. Thanks to the PowerDNS blog which had a different mitigation, which gave me this idea.
In C programming if you have a pointer named pbuf and another pointer on pbuf called p and increase that p by one, the difference of p - pbuf is one. C programmers use this often to calculate lengths. But it may so happen that they sometimes have a confusion on what has the lower address. In that regard pbuf - p becomes really large. OpenBSD recently had this fixed in skeylogin.c. So it does happen to other programmers. I have now made a helper function called plength() that allows one to give it an upper limit, (usually for delphinusdnsd plength() has an upper limit of 65536). If the program then bumps into a violation, it will abort() and hopefully create a corefile for analysis. I've been running this for a while now and I think it's good to go. But a rare condition may be lurking somewhere. In that case you know what to do now.
I'm going to have two maintenances in the next two weeks. One is the retirement of my OpenBSD/octeon router, which I will replace with vlan plumbing on my switch and the raspberry pi 4b. I hope it works. This may be on tuesday, thursday or friday of this week. I'm not going to do this in off-hours since this is the Internet and I have a worldwide audience (you).
The other maintenance will be for the new version of OpenBSD (7.3) which will probably not constitute as much downtime. This will likely be after easter monday. Hoping on tuesday or wednesday.
I'd just like to mention the maintenance for tuesday was done on monday evening. I was able to retire the OpenBSD/octeon router and give the raspberry pi 4b the task of routing. Apparently everything works as you can read this. I did a speed test for 100 Mbit and saw cpu idleness go down to 55% on one core. Since at the same time there was a sshd brute force attempt that took a bit of the load as well. So I'm in a much better position to upgrade my ISP plan (perhaps next year?). I put the raspberry on one of my switches 10 gbit ports so in theory the device on that port can route up to 5 Gbit/s, or 10 Gbit/s if it has 2 ports. I'm not counting on this until in five years perhaps when I will expect 1 Gbit/s speeds. For that my building will need some upgrades though, hopefully before 2030.
LibreSSL 3.7.2 was released today adding Ed25519 support. This means that I can start adding alg 15 to delphinusdnsd/dddctl. I can also start removing some older algorithm like alg 7 which is not recommended anymore according to RFC 8624 section 3.1. Thanks to all the teams at LibreSSL for this wonderful release!
Happy Easter. Just sitting here reading a bit through circleid.com/topics/dns. Sometimes they have good stories. The stories that I like particularily at this time are:
Until I give the word please don't run the newest delphinusdnsd from the github master branch. It will fail if you have more than one zone. With that I'm going to do some more coding, happy easter monday!
The new code achieves an AXFR without needing to restart the replicant. It's probably too early to run it in production, though I'm gonna do it on one nameserver probably. If you have problems with this new code go back to revision 84c26f8ad169706f2633cd573367c13e3de23b4e that's from first of april. This one works well and I have it in production. So please test it out first then consider putting it in production.
Please, if you run below 1.7.3 it's time to upgrade. 1.7.3 and master branch have the fix as of today. A few weeks ago my amsterdam vps did an AXFR. What was weird about this AXFR that it was blank, but it went through. This caused my nameserver to die. I can't rule out that someone mitm'ed the transfer. It was highly odd. So last night I had the idea and this morning and afternoon I implemented custom code to see if my hypothesis was right. It was correct, the replicants axfr did not check whether the answer even had any TSIG's in it. In a mitm the TSIG's could have been removed and new or replaced records could have been put in, it would have passed it. Now then, the fix is that we require a TSIG to be seen if we use TSIG authentication. Also if there is trailing data after the TSIG this constitutes as an error. On the master branch the fix has signature e5a3d3828452127df428a47c77f8b3a8a4722451 and on the STABLE_1_7 branch it has signature a798b07e20065050c6178ae69f0fdd3e3899d199. Feel free to use either one. Though the master branch has some new code, it hasn't seen much production use yet. So, the sureshot use should be 1.7.3 release.
I found the vulnerability, but was I the first one ever? The mind boggles.
So I just put the commits for mimmutable(2) into delphinusdnsd. This means that you MUST be at version 7.3 or on -current (snapshots). In order to run it on version below 7.3 you have to edit the code and #if 0 (deaden) the mimmutable() code. The benefits outdo the drawbacks here. It's a great security addition.
For a friend who wants to run delphinusdnsd on FreeBSD I tested this out in 10 minutes. FreeBSD compiles delphinusdnsd with some warnings but it links. Also checking whether tcp and udp work (with the drill program) worked.
I tested this out today and there is some problems with AXFR's still. What I had done was a forest-wide update (4 zones) a few days ago and then did one update to the delphinusdns.org zone and noticed centroid.eu lost it's DNSSEC zonedata. This is the symptom. I'll be looking for the cause soon. One working newer but old version was from april 1st. (84c26f8). Use that if you have to have stability. When I find time next week I'll look into this.
I just committed some code to fix the issue I reported on April 23rd. I don't see the symptoms anymore now. If you do decide to go with delphinusdnsd-current please keep an eye on the database for corruption.
Normally I don't say this here, but since I used pod.delphinusdns.org in an example, I'd just like to say I've retired the server as a nameserver and will likely turn it off permanently (delete the instance) come friday or saturday. The replacement is a new arm64 vps called superpod.delphinusdns.org. It is almost as fast but has twice the memory which made it appealing to me.
The EU's Cyber Resilience Act is said to harm open source developers. Like me. What are we dealing with here and why can't I vote someone who makes these acts legal out of office? I can, but who do I vote for? Will I make an impact with my vote? I've been writing open source for a very long time. Since the 90's at least. Some of the stuff though is not offered anymore and you can't find it. I've sticked to delphinusdnsd working on it like a second job during my time at Enhancedvoip.net. In the mornings I'd write on delphinusdnsd and in the afternoon's I'd do my job for 6 hours a day. More was not allowed by the doctors, and it matched the Eastern American time zone working from 2PM until 8PM. Some time later I worked full time on delphinusdnsd while looking for work. I applied for government grants via the prototype fund during this time as well. I did not get that money but they always wished me good luck for the future (thanks!). Now, currently I'm writing sparingly, delphinusdnsd has become a serious hobby. But where exactly does it stand? Can I share the code even? I'm a hobby programmer. This should be answered and clarified, and there needs to be unbiased discussion what Open Source really is to the voting population.
On april 28th I gave the green light for -current again. That was nearly 20 days ago. I've been running delphinusdnsd since the 29th of April without restart:
_ddd 96881 0.0 4.8 58768 49252 ?? Spc 29Apr23 0:36.12 \ delphinusdnsd -f /var/delphinusdnsd/etc/delphinusdns.conf \ -s /var/run/delphinusdnsd.sockI have done changes perhaps three times since that start. What I'm noticing is that there is perhaps a memory leak that I introduced with changing the databases. I'll have to look into that in the future.
I haven't touched the code in a few weeks so I'm gonna take up on that soon again. Last I was working on a patch to get statistics working, but it was error prone and I need to improve it. After that I'm gonna start working on new algorithm in dddctl with Ed25519 perhaps.
I have done so twice already in the past at a project called prototypefund.de. I applied there in 2018 for the fifth round of funding (delphinusdnsd 1.3), once in 2020 for the 9th round of funding (delphinusdnsd 1.5/1.6). And now again for the 14th round of funding. Both times I had applied I got turned down. I'm gonna try one more time, also because it is my last year alone in 2024 to be working on version 1.9 delphinusdnsd. What I would plan for this release, if I get funding I'd work towards (signed) DNS Updates.
So August 1st is the first day to apply for the funding and put forth my idea. If I get funding, it may propell delphinusdnsd into version 2.x with me. If not I may call it quits after december 2024.
Delphinusdnsd started under another name in 2005 and has been open source from day one. Back then it was at sourceforge, inbetween I took it to my own CVSweb, and then latest I use github.com to share this creation. I'm very proud of this server software, and it helped me through some odd times in life (writing it). It is a genuine german project having been written in Frankfurt (2005) and Schweinfurt (after 2007). What do you think? Does the world need another authoritative nameserver? Does the world need a german DNS server? Does Germany need a project where DNS talent resides? Things that make you go hmm. So far in europe there is only four Projects that I can think of right now that do DNS. PowerDNS and NLNetlabs in the Netherlands, Knot DNS in the Czech Republic and Yadifa which was written at EUrid (possibly in spain). I've always filled a niche with delphinusdnsd it is unlike any other DNS server software I've seen. I trust its design a great deal. Anyhow... more on this later.
It's wonderful that it's not too hot, I was able to code a little for two hours today. I made a patch to implement (without testing) ED25519 algorithm (15) for signing. However my main workstation is sleeping and I'm not home so I can't commit it just yet. I might just test it first before committing as well. Much thanks to LibreSSL project for making this API available!. While I was there I removed algorithm 7 (RSA-SHA1-NSEC3), so what this means is that if you use dddctl to sign with algorithm 7 you will have to change the algorithm at 1.8 release time. What I'm doing is switching off alg 13 from my test zone some time this weekend and then give algorithm 15 to it. Hope it works without much fiddling around.
I have a self-imposed limit on when I want to change projects from delphinusdnsd. This will be in 1.5 years so it's not too far off in the future. I am considering going closed source for a windows port, among other things. This means I will still maintain delphinusdnsd 1.9.x as open source, but will in parallel have a for-cost closed source windows port. This is a good way that I can start a business around delphinusdnsd and it may put some money in my pockets. So far I may have gotten one or two donations not surpassing 50 EUR and I had expenditures of 200 EUR for sponsoring someone for a ruby framework. That was in the year 2015 or 2016, and since then I've replaced the ruby program with a C program of what would eventually become the dddctl(1) program.
Now I'm a fool but not a big fool, and I know what happens when you go closed source. The open source world will fork what you have and compete against your model. This is what happened in the legal case Tatu Ylonen vs. OpenSSH. However Tatu Ylonen still managed to raise a multi-million dollar company. I don't think he was in poverty since his ssh creation. I on the other hand am in poverty and noone is to blame for that but me. It took a lot of years to get this program to a level where I can possibly compete it to other DNS programs. So going away now may not be in my best interests, it is just getting good.
Also, I am taking a look around what I can do with DNS. I had considered a "nextdns" service before but it would really help if I had a windows forwarder. So that's where I'm shaping it up. Also I'm considering a closed source Solaris 10/11 port, for those oracle people. Either way, I plan on writing about delphinusdnsd on wikipedia near the 1.8 release, so near december. The remaining year will see how people are receptive to yet another dns server.
So E.D.W.I.N. stands for "Enhanced Delphinusdnsd (for) WINdows", I'm giving it a closed source shot after december 2024. In preparation of this I'm going to rent a windows server cloud computer where I'll be developing on. Probably starting in Q4 of 2023. I'm going to use bitlocker or something similar to encrypt the source code on the cloud and use OpenBSD as the firewall for the gateway.
Edwin is the best of both worlds (both open and closed source models). It will be used to commercially profit off delphinusdnsd and to reach as many people as possible in order to maximise the profit margin. I am very excited about the idea, but not really about the hard work to port delphinusdnsd to windows. But c'est la vie, noone ever got paid for dreaming. I'm trying to get out of poverty and until I retire or die edwin will be closed source. By then people will have to evaluate whether they want the open source version or the closed source version anyhow.
PS: To be honest something snapped in me, I need money, and I'm putting down the framework to do so. The foundation has already been laid with open source of delphinusdnsd, it will always be free. So I'm not selling out completely. Also edwin project is dedicated to the Edwin Hubble telescope which has given me a lot of joy in the past 25 years or more looking at NASA's APOD. The photo you see here is NGC 7006 which is 140,000 light years in the constellation delphinus. This means it's beyond the milky way galaxy too. As we're only 120,000 light years in diameter afaik.
I just committed the code. A test zone worked perfectly. I'm somewhat happy.
I have added this algorithm based on algorithm 13. Here is the RFC 6605.
I pledged 5 EUR if LibreSSL team implements ED448 which is used for alg 16 in DNSSEC. The value of this is almost ridiculous but I can't afford more currently. The timing for this call for this feature is almost perfect since the new OpenBSD release is in roughly 4 months and the 1.8 delphinusdnsd release is in end of november/early december. Also since LibreSSL implemented ED25519 framework, the concept of ED448 is just using a different ED algorithm and a bit of copy pasting I gather, I just need ED448_keypair(3), ED448_sign(3) and ED448_verify(3) similar to the ED25519 equivalents found in the X25519(3) manpage.
Through a mixup I donated 60 EUR to the OpenBSD Foundation. So the 5 EUR that I pledged below will cover this. Even if I don't get ED448 support the money is wired. So perhaps for 7.4 or so, if not, no big deal.
I have come across a servfail where an NXDOMAIN answer should have been the case. I'll have to look at the algorithm, but I suspect it has to do with canonical sorting. For example riscv64.delphinusdns.org doesn't work, but nonexist.delphinusdns.org works, and so does nonexist101.delphinusdns.org. I updated my TODO yesterday in the master branch and I'll be looking at that. At the same time I have a partial patch to introduce NSEC support and I'll likely be dropping both these at nearly the same time. It's been a good summer break, and unfortunately I'm not making use of the low temps this year. I could be coding in other words, but I decided to follow some other hobbies of mine instead. Everyone needs breaks *smile*.
On June 5th, I blogged about getting a VPS for the "enhanced delphinusdnsd (for) windows" port. Well I got it now (in mid Q3 not Q4). I'll be keeping this for around 4 years. The EDWIN project is slated for porting work after january 2025 and should be finished by 2027. The VPS costs 10.95 a month and funny thing is that it is cheaper than if I ran windows 24/7 at home on my ol' xeon. Due to the cost of electricity no doubt.
OK I fixed the DNSSEC issues with the negative validation on the closest encloser of NSEC3. The issue has been around for at least 2 years (going back to 1.6) so I'm asking if anyone needs a backport to 1.7.4? The last release of 1.7.3 was in April, it's August now almost and November or December will be the 1.8 release. That's 4 months roughly. Let me know with email.
I'll have to take a look on this on monday. While ''riscv64.delphinusdns.org'' has no SERVFAIL. The ''a.b.c.delphinusdns.org'' does have a SERVFAIL. This code is feisty to get right.
I just put the code in and compared it with nsd outputs and dnsviz.net. The dnsnames I checked too were c.delphinusdns.org, nonexist.delphinusdns.org and riscv64.delphinusdns.org. Sorry for the seven day wait on this.
This weekend I was able to pull out and complete old patches and relive deadened code. It looks like by next week (perhaps on sunday) we'll have full NSEC support in both the daemon and the signer. I'm hoping that someone can then use delphinusdnsd from the master branch as a secondary/replicant. I have limited time next week but the weekend next weekend looks good.
From the start DNSSEC signing in dddctl was done with NSEC3 records to prove NXDOMAIN and such things as NOERROR and NODATA for proof of nonexistance. I avoided NSEC purposely then because I didn't want to use it. Now though I see domains such as isc.org use NSEC still and it makes me want it too. Soon we'll get it!
It seems to have implemented faster than I had imagined. There you go!
A friend added the OPENPGPKEY RR to his zone, so I want to eventually support that for him. I also added the SMIMEA and CERT RR's onto my TODO which I'll be doing in parallel. The work is about 2-7 days and I'll start next friday when temperatures are to my liking. Until then I'll work on something else. Did you notice I improved the not-well-known dddctl dumpcache command for forwarded and cache'd RR's? I also added a wrap6to4 option to forwarding for my Samsung TV, but I don't know if it made it much better. Basically I see the TV making AAAA lookups when it's not even IPv6 capable. Odd thing.
So I'm very excited that there is only 1 year and roughly 3-4 months left in the Open Source portion of delphinusdnsd. I'll be turning 48 years old in march 2024 and here is my plan for the future.
I'm planning ahead and it's almost september. There is roughly 13 weeks left of development for this year. The TODO still has three or four things so I'm pretty well set for things. 1.8 is gonna rock!
There is some concern about 2FA on Github. All I know is that if I am required to have a smartphone or do any other 2FA beyond my ssh key that I'll be leaving github. This isn't just yet, but how it'll go down is that a preliminary release will be made. (either 1.7.x or 1.8.0) and then another 1.8 release in december. All eyes are on Microsofts github now. We'll see what happens next. If this scenario falls true I'll set up a gotwebd on one of my servers and continue development there.
Just want to say I haven't disappeared and not writing DNS stuff in September is rare. I actually am trying to port OpenBSD to Mango Pi hardware. And this took a good 2 weeks of my time right now. I also got another RISCV computer and I'll be setting it up shortly. I have a new image on the website and moved the credits image to about.html, I like it very much.
There is still a little bit to do until November/December (6th at latest) for the 1.8 release. I'm very happy we've come this far. I'll probably use up September for some maintenance tasks and get coding again in early October. Also I'm very anxiously awaiting on Jury decision of this Prototypefund. Search the blog, this is my third time applying. Fingers crossed!
I noticed this on stern, after running a forwarder for 31 days since august.
_ddd 61913 0.0 1.2 117548 99700 ?? Spc 30Aug23 2:36.88 delphinusdns d: FORWARD engine [forward] (delphinusdnsd)
It is nearly 100 MB large, but doesn't have RR's to match that:
root@stern# dddctl dumpcache -I forward|wc -l
dumping cache
195
Next week I'm slowly starting to look into delphinusdnsd again and may take a look at this then.
I'm back after a month of working on another project. I have some sysadmin stuff to do at home (backups, shifting of hardware) which will take it until the 9th or so until I'm ready to roll. I have enough TODO's to work on including three RR's that I'd like to add. Glad to be back!
On August 31st, 2023 libressl released libressl 3.8.1. Unfortunately my hopes that they include Ed448 algorithms weren't implemented. So for 2024 there won't be an algorithm 16. Maybe next year for the 2025 release (1.9.x). Now I tried bribing OpenBSD a little by pledging money, which I've paid, but they don't work like that. Too bad I already overpaid it by 55 EUR otherwise I wouldn't pay that pledge. :P. One can only hope for next year.
The raspberry pi 4b is on my desk and the starfive visionfive 2 is my router. This is what I wanted since summer. Unfortunately I'm sorta 10 days behind where I wanted to be. I have some uncommitted code that I need to finish and then at least we have 1 more RR. It's the CERT RR. I'll probably start with that again tomorrow afternoon as I have some stuff to do in the morning. I'm looking forward to the energy savings with this setup too.
There is roughly 7 weeks left in the development cycle. I have plans to do about 1 feature per week on average so there is 7 more things to come. I'm currently working on CERT RR, but there is 2 more RR's that will make it before release time. So there is 4 more things that I could be adding or improving.
I'm also patiently waiting out the jury on the prototypefund whether I'll get funding for TKEY and DNS Updates next year. The decision will be made in early december 2023, so I'll know more around release time of 1.8. Let's pretend they fund me 19K EUR for the period between march and october 2024, I would be more than happy with that. I also know what I'll buy with some of the money that i don't need to live. It will be a tesla powerwall for my apartment in order to participate in the green revolution that's partaking in Germany. If everything works out, I'll have the tesla powerwall in mid september 2024.
My apartment is on the north side of my building so I don't get enough sunlight for installing a balcony kraftwerk (powerplant). But using electricity wisely for periods when there is a lot of solar electricity makes societal sense. It would offload the grid and I'd pay the investment off in around 10 years by means of savings. Coupled with a electricity provider like "tibber.com" for example. Even if i don't get funding I'm gonna try to persue this for next year. It would rock!
So that's the plans.
Yesterday I checked in CERT RR support. One down, two RR's to go and I fulfilled this weeks code. I will probably code today as I have some more ideas.
Today I wrote code to send a truncate reply (size is as much as question), on UDP when a ratelimit is in effect. I'm forcing these to TCP instead of just dropping. It will be less energy intensive on the resolvers part if these are legitimate packets. If unlegitimate packets I do not believe a TCP query will be done. Also someone being a reflection target will be able to discern what is happening by seeing a truncate reply after a large payload set of replies.
I submitted an article to wikipedia and it was not accepted. This is the reality. I intended to make it well known in december for the 1.8 release but like I told some buddies... I'll probably have to buy advertising to get the word out. Here was the draft at wikipedia. It just seems backwards that an Open Source project is not allowed on an idealistic open source dictionary. Well I'm going closed source for a bit anyhow. Should we open our own dictionaries?
I've been invited to an open dialogue with Hubertus Heil the German Minister of Employment and Social Issues, on December 5th. I do plan to attend there even though it is a lengthy conference on that day. The release for delphinusdnsd, thus, is delayed by two days to the 8th of December which is a Friday. Sorry if this causes any inconveniences.
I noticed I had another website misconfigured and IP's misconfigured on httpd. It would have given wrong results for the past two days. Sorry.
There is too much going on in my life which prevented me from coding. So I'm gonna buy some time by moving the release to the 22nd of december. This is a perfect date as it coincides with the december solstice (long nights!). And it's three days before christmas day. So it's a busy december for me.
Lately I have been thinking about what I want to finish in delphinusdnsd, but have been doing more personal healing like meditation and exercise (walking). I hope I can bend my energy around doing more work this year :-). Also if things don't work out in december, there is always a new years release window perhaps. We did this in the past, nothing is static. As long as we get our plans done by mid winter.
