DelphinusDNS Blog

(the latest about delphinusdnsd)

Six weeks development cycle left

October 20th, 2019

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:

modify the axfr process for receiving notifies
add a new process for receiving new AXFR's
any code that implements replication/slave functionality

I'm going to spend some weekends at home perhaps once or twice to get more coding done, I think I can scrape the curve. It'll be a challenge, but not impossible. Do note that this is likely the only feature left that I'm putting into delphinusdnsd in 2019. If I don't make it I may consider moving the release date from New Years 2020 to a day in January 2020. Thanks!

0 comments

Backwards compatibility in snapshots

October 18th, 2019

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.

2 comments

Tomorrows snapshot should fix TSIG with dddctl

October 10th, 2019

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.

3 comments

Still EDNS Compliant

October 4th, 2019

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!

0 comments

Compartmenting Delphinusdnsd

September 30th, 2019

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:

a root owned master process, this process is used for signaling the entire set of processes to restart or die. Because port 53/tcp and 53/udp require root priviliges this process is always around.
a _ddd owned process that has no setproctitle is the main UDP answering daemon, the reason it has no setproctitle is that the operator can see what flags it was started with.
a _ddd owned process with a unix controlling socket, this allows the program dddctl to talk to delphinusdnsd for restart for example. Direct signals (HUP, TERM) to the master owned process should still work though.
a _ddd owned AXFR process, this is the only process that handles zone transfers (at time of writing this article). The TCP process can pass descriptors for AXFR to this process.
a _ddd owned udp parse engine. This is a big security plus process. When a query comes into the UDP process it passes the query to this process which can only parse it and nothing else. A pledge rule in OpenBSD makes this extra restricted so if a query was problematic in that it takes over this program there is not much it can do within the bounds of a "stdio" pledge.
A _ddd owned TCP process. This much like the main UDP process takes on TCP queries. It does minor things differently, otherwise is the same as the UDP process.
A _ddd owned TCP parse engine. This does things exactly the same as the UDP parse engine. Security is the keyword here.

So as you can see I have compartmented this process quite a bit. I hope it pays off in the end. It makes development quite a bit harder and this will likely show itself between version 1.4 and later versions. I have quite a bit planned but I shy away from the work :-). Thanks, -peter.

0 comments

The name delphinusdns, why that name?

September 23rd, 2019

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.

0 comments

The main configfile now is in the /etc/delphinusdns/ directory

September 20th, 2019

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.

0 comments

Ubuntu needs 'make' to compile delphinusdnsd

September 15th, 2019

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.

1 comment

An example delphinusdnsd log, examined

September 13th, 2019

Here is a real log taken from my log file, this is how to read it:

2 comments

Let cooler temperatures prevail

September 11th, 2019

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.

0 comments