DelphinusDNS Blog

(the latest about delphinusdnsd)
  

Previous Page


The ugly word slave and why I want to avoid it

November 6th, 2019

Slavery is a scandalous human condition, it hasn't brought us further. In DNS there is a primary master server usually that controls when zone changes are made. Any other server that does an AXFR from this master is historically called a slave. I asked the DNS community in #dns freenode channel what some similar names are that would be relevant to get rid of the word slave. We settled on "replicant". A replicant by means of definition is a replicative which when dug further is "Of, pertaining to, or causing replication". This is a good word. However please forgive me if I still use the word "slave" because the s word is so popular in the community and I want to let people know what I'm talking about. Officially though in delphinusdnsd we're using replicant to indicate a replicant daemon.

0 comments

Delphinusdnsd replicant successfully AXFR'ed from NSD

November 4th, 2019

In my test lab delphinusdnsd in replicant mode (in debug mode) successfully got a notify from nsd and subsequently pulled the zonefile from nsd.

adding SOA values to zone petphi.internal.centroid.eu
petphi.internal.centroid.eu -> 2019110304, 3600, 1800, 1209600
on descriptor 3 interface "192.168.177.2" dns NOTIFY packet from 192.168.177.1,\
 replying NOTIFY
request on descriptor 3 interface "192.168.177.2" from 192.168.177.1 (ttl=64, \
region=255) for "petphi.internal.centroid.eu." type=SOA(6) class=1, answering \
"NOTIFY" (149/45)
zone petphi.internal.centroid.eu is being notified now
new higher serial detected (2019110305 vs. 2019110304)
setsockopt: Numerical argument out of domain
scheduling restart at Mon Nov  4 11:59:39 2019
This is another milestone, showing that a delphinusdns replicant (also called a slave) can interoperate with other nameservers.

0 comments

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:
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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

Next Page

Search

RSS Feed

Click here for RSS

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


Powered by BCHS