DelphinusDNS Blog

(the latest about delphinusdnsd)

Upgraded delphinusdnsd on the centroid.eu nameservers

April 1st, 2020

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.

3 comments

Delphinusdnsd replicant for Microsoft DNS server with AD

March 10th, 2020

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!

0 comments

A signing script

March 10th, 2020

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!

2 comments

Regress files fixed

March 6th, 2020

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.

0 comments

Verifying delphinusdns signed zones

March 6th, 2020

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!

0 comments

Default key creating algorithm has been changed

March 4th, 2020

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.

0 comments

What am I currently working on?

March 3rd, 2020

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.

1 comment

Monthly DNSSEC maintenance

March 3rd, 2020

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 20200218072347

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

1 comment

Split Horizon DNS

February 20th, 2020

Earlier today I was approached on split-horizon dns and whether I can implement something like this. The short answer is no, but you can still do split horizon DNS with delphinusdnsd with pf. It requires setting up 2 or 3 delphinusdnsd bound on several interfaces including localhost on their own port. With pf rules you would then do an rdr-to 127.0.0.1 port X where X is the delphinusdnsd that it should speak to. You would have the same setup on both replicant and master and they would axfr on their own unique axfr port. A large list of IP's can be assembled from this website (iana.org).

The reason I'm hesitant on bringing back split horizon to delphinusdnsd is that it doesn't really fit well with AXFR, it's a mess there. The hack that I explained it the first paragraph keeps it on a boundary though and could be done well. Debugging split horizon dns is a pain too, but I think with regions configured in all running delphinusdnsd's you can have an overview of which delphinusdnsd was hit. You just gotta watch the logs closely and follow up to complaints. Good luck!

0 comments

Delphinusdnsd is probably not 2038 safe

February 14th, 2020

Happy Valentines day. Delphinusdnsd is programmed on OpenBSD which is Y2038 safe, but the ports may break on January 19th, 2038 or after. I don't know what will happen actually. I'll keep an eye on this. 2035 is likely the last year when I will work on this code, perhaps there will be more light, then.

0 comments