DelphinusDNS Blog

(the latest about delphinusdnsd)

Previous Page

Very large databases

August 26th, 2020

I have filled delphinusdnsd with a dataset of 1.4 million AAAA records. The size in memory for this is 2.4 GB roughly. But the AXFR to such a database with its individual (in my case 1440) zones took close to 2 minutes. I have just committed code to shave this off to 2.4 seconds, a win-win.

However this changes the behaviour of delphinusdnsd. Before you could do:

zone "anything you like" {,a,3600,
This is not the way things work now. You MUST put in the zone name in zone "". Many people were doing this anyhow, but now it's a requirement.
zone "" {,a,3600,
This behavior will be downloadable in tomorrows snapshot (27th of August) and onwards, and will be in 1.5.0 delphinusdnsd.


Canonical sorting still problematic

August 9th, 2020

With in-depth debugging with another person who uses delphinusdnsd, we were able to make out that the canonical sorting in DNSSEC (dddctl sign) is still not right. I'm going to change this in dddctl on all functions. I will do this next week. I have a plan. Hopefully it will be a once and for all result. Many thanks goes to nlnetlabs in the netherlands who created the program ldns-verify-zone. Without you guys I'd have problems. I'm standing on the shoulders of giants.


I have picked my project theme

July 31st, 2020

For the prototype fund (9th round) I have finalized what my project is going to be about.

It will be improvements for delphinusdnsd like I mentioned before, but I have a concrete picture of what I must do. I'm going to make delphinusdnsd an authoritative nameserver for replacing Microsoft DNS server. For that I need to do a few things: GSS-TSIG (RFC 3645), it comes with several depended RFC's that I also have to implement like TKEY (RFC 2930) and possibly KEY RR which comes with the SIG(0) RFC. Also I'm going to implement DNS Updates after RFC 2136 and RFC 3007 (secured), and if there is time left in the project time (6 months) I'll try to implement auto-signing updated records (DNSSEC).

This is all a big task, and there is always the hindthought that Microsoft Active Directory won't allow this. I have found a document from Bluecat Networks that they can do this (on a BIND9 basis). So this will be my outline that I will be working/striving towards. Wish me luck, I'm applying tomorrow, most likely.


Delphinusdnsd 1.4.3 released featuring backpatches

July 30th, 2020

Here is a list of points that I collected for that changed for this release:

  • AXFR poison prevention patch (security)
  • Hangup AXFR corruption prevention patch (reliability)
  • a better description of an error when /etc/delphinusdnsd/replicant is not owned by _ddd or other configured user (DEFAULT_PRIVILEGE)
  • correct use of mkstemp() following it with fdopen() instead of fopen()
  • an uninitialized variable used in accept() which prevented dddctl to restart/stop delphinusdnsd (found on Linux, possibly fixed other OS's too).
This is hopefully the last 1.4.X release, 1.5.0 will be released in two to three months with the major feature of a forwarding mode.


Delphinusdnsd listed at the DNS Institute

July 29th, 2020

While googling I came across the DNS Institute, a site that offers consultings regarding DNS. They listed delphinusdnsd as an authoritative server. Thank you for the exposure! Perhaps pretty soon they'll have to also list delphinusdnsd as a simple forwarder, as well. *smile*. I don't know exactly who is behind this website but I'm grateful they mentioned my work.


Mid-Summer 2020 work coming to an end

July 29th, 2020

Well I had a pretty good spurt this summer. Nice was that this summer wasn't all too warm. Here is a graphic that I got from the insights at github: Here is a list of things from the CHANGES file in the repo:

  • added a "cortex" process for IPC between the processes
  • added a forwarding mode (with cache)
  • changed the config file version from 9 back to 1
  • changed how a question gets parsed (build_question()), hopeing to get more security out of this
  • in dddctl query allow a class to be specified (-c)
  • added RP, HINFO and CAA RR support in all areas except dddctl query
  • added extra security measure to prevent DNS poisoning by AXFR
  • add a SOA constraint on rzone's to constrain SOA refresh/retry/expire values by default these are 60/60/60
  • terminology changes blacklist->blocklist, whitelist->passlist, anything_slave() to anything_ddd(), to keep with the times

I'm going to focus on other things for the month of August and will tidy up things in September for the October or November release (it all depends on when OpenBSD 6.8 gets released). Overall I'm satisfied with the way things are going this year.


CVSweb's last straw

July 28th, 2020

I have removed CVSweb CGI program from the website. The last straw that broke the camels back was that it stopped working displaying what's in the STABLE_1_4 branch that I committed for the upcoming 1.4.3 release that features backpatches for reliability and security. So this puts me in a weird position. I won't have CVSweb (the last feature that I needed it for, like said, broke) anymore and the CVS repo has it's days counted. The 1.5.0 release will likely be tagged on got/git, and branched so the changes will show up in the github and gotweb online repos. Everyone needs to see their history!


Tomorrows snapshot should disallow AXFR poisoning

July 26th, 2020

In this article by DJB he talks about AXFR Poisoning. When you have a replicant that gets a zone from another master, it was possible before this patch to poison extra RR's into the entire database. It's amazing how other DNS servers are similar to mine in this regard. I never had to worry much since I controlled replicant and master, but recently I started replicating for someone else and it opened my eyes to the security aspect of this. Thanks goes to Ricardo Santos for his part in making me think about these security scenarios.

Another thing that's fixed tonight is a hangup attack which would leave an RAXFR'ed zone unparseable killing the server. I believe this patch from this afternoon would fix this. I have thought around other scenarios where someone could hurt me too. One other one is when they manipulate SOA values to values that hurt the operation of a replicant. Such as the undefined value of 0 for a refresh. I'm gonna work on that tomorrow and it will be addressed next week. For now the zone poisoning and hangup problems have been dealt with and will be available in tomorrows snapshots.

Considering the ease of fixing these I may backpatch these into the 1.4 stable branch and roll another 1.4 release. I think that's fair but it will take a few days.


Added three RR's to authoritative mode

July 24th, 2020

I'm gonna call the two modes by their names "authoritative" or "forwarding". I added CAA, HINFO and RP RR's to the authoritative mode in commit 6f87dc2b46b3cbfb71320f535b34a0bb0734604c. For this I mostly picked another RR as a template and just changed the values. It turned out to work. I had to follow up to this commit with a commit to the sign_caa() function because the algorithm to sort canoncial rrsets seems to not be correct in some form or way. I'll be researching this hopefully in august or september (when I find time). Also notice I put https on the gotweb. I'm very sure it will replace the CVSweb in time, so you may as well learn it a little and get used to it if you used my cvsweb to check commits. One positive thing about gotweb/git is that it clumps several files together in one commit so you can see them all at once. A negative thing is that the cvs2gitdump utility doesn't know how to handle tags in branches and discards them so you can't see version 1.4.2 for example (also noticed on github). I do hope that the tag for 1.5.0 will appear in it though as it's tagging is on HEAD.

1 comment

Observed gotcha in the forwarding mode

July 24th, 2020

I put my dns server in forwarding mode on my router on interface cnmac1, this gave it the IP x.x.177.1, but the new code with forwarding seems to have a fallback. A device from interface vlan3 (x.x.199.0/24) could not access the IP x.x.177.1 and DNS ceased working. The workaround is to add vlan3 as an interface and change DHCP to give the DNS server a x.x.199.1 IP. This worked. But I remember thinking that this was not the behaviour before I switched to the raw sockets. Live and learn.


Next Page


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

Powered by BCHS