DelphinusDNS Blog

(the latest about delphinusdnsd)

Delphinusdnsd did an AXFR from another Delphinusdnsd

November 2nd, 2019

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.

3 comments

A side-track

October 29th, 2019

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.

2 comments

A change in behaviour

October 26th, 2019

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.

0 comments

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