DelphinusDNS Blog
(the latest about delphinusdnsd)
|
Previous Page
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
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
|