DelphinusDNS Blog
(the latest about delphinusdnsd)
|
Previous Page
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
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
Next Page
|
Search
RSS Feed
Click here for RSS
On this day in
Other links
Have feedback?
By clicking on the header of an article you will be
served a cookie. If you do not agree to this do not
click on the header. Thanks!
Using a text-based webbrowser?
... such as lynx? Welcome back it's working again for the time being.
Older Blog Entries
January, 2021
December, 2020
November, 2020
October, 2020
September, 2020
August, 2020
July, 2020
June, 2020
May, 2020
April, 2020
March, 2020
February, 2020
January, 2020
December, 2019
November, 2019
October, 2019
September, 2019
Powered by BCHS
|