DelphinusDNS Blog

(the latest about delphinusdnsd)

False alert, code refactored anyhow

March 08th, 2023

I made a mistake there was no buffer overflow. There was 5 variables to watch and a buffer which was 0xffff + 3 bytes big. The one variable I did not watch close enough was tcpnp->bytes_expected, which limits how much can be read and is decreased. I'm sorry for the heartthrob, I won't backport the refactored code just yet.

0 comments

Potential buffer overflow on the heap, please upgrade

March 8th, 2023

I have found a potential buffer overflow in the TCP and TLS code. I think the TCP code was around for a number of years. Since June 2019 at least. The best way to go about this is to upgrade to the master branch with git and recompile. Then wait for a 1.7.2 patch release, the code hasn't changed much since 1.7.1 and thus this is OK.

0 comments

AXFR (for primary) needs to be re-written

January 31st, 2023

The quest to give the source of a notify packet a bound IP had me going off on a trail to fix it. However..., I have realised I need to rewrite this code partially. It was first implemented in the predecessor of delphinusdnsd under the wildcarddnsd name. This was in 2011 and before I moved into this nice apartment. I don't really know what I was on (self admittance). So I'm going to adjust the TODO file accordingly and plan out this code. Important to me is, that this code is readable, and not jammed. As in that you cannot really move it forwards or backwards and gain what you want from it. This takes time out of my day unfortunately that I would otherwise use to relax. Maybe a bit of work is good for me though.

0 comments

Preventing Burn-out

January 30th, 2023

The TODO's for this year will likely not be achieved. The usage of delphinusdnsd will have to be watched by me and some parts will have to be rewritten as they are just impossible to maintain. This means that this year there will likely not be a dns update functionality. I'm not saying this in spite but rather want to prevent a burn out of myself. I deserve a break and if anyone wants to contribute the best way is to send me patches first before we both consider adding you to the commit list.

Also there have been some breakthroughs with the got (game of trees) program that I might make use of. This may mean that I'm possibly taking development from github back to a got repo. However. Since we're on version 1.7.1 now and the last release will be before 2.0.0 for me this may not happen. It's something to consider though. Eventually I'll have to let go graciously.

0 comments

TODO's building up

January 28th, 2023

I found another issue with delphinusdnsd as an AXFR primary. When on a host with IP aliases it will sometimes pick the wrong IP (IPv6). I have a patch but it does wrong things which I have to debug first before I commit it. The TXT RR problem is also by now on the back burner, the emotional blockage that I have hasn't fully healed and I lack the concentration to sit down and do this right now. If anyone wants to step up and help that would be grand. If not, it will take its natural time.

0 comments

Delphinusdnsd 1.7.1 released

January 26th, 2023

This is just a patch release fixing a single error condition. A segfault was found a few days ago and this should be the right fix.

0 comments

TSIG, error condition found

January 22nd, 2023

If you use tsig to protect queries and answers there is a segfault condition that I found today when there is a DNS BADTIME reply (ie. the query has a bad time outside of the TSIG fudge). In particular when the queryname is "." the delphinusdnsd server quits with segfault. For now I recommend anyone using 1.7 to go to the git HEAD (latest commit) and wait for 1.7.1 to come out. I'm still feeling unwell to do major changes (as per the last problem found) and I just started a new medication so it may take a bit until I get delphinusdnsd in a great shape again.

0 comments

Regarding the TXT RR problem

January 3rd, 2023

I've been holding off doing any work as I'm trying to overcome an emotional blockage. It's like I said, you're only affected if you use a primary (master) other than delphinusdnsd and only if the TXT RR is greater than 255 bytes. What happens in detail is that the non-delphinusdnsd master may give a TXT RR in an AXFR which may have different offsets between segments than what delphinusdnsd expects. As the AXFR takes place delphinusdnsd writes it to a replicant file as a reassembled TXT RR and then restarts assuming that the segments are exactly 255 bytes maximally and fragments the segments on that. If the segments are not exactly like on the primary (master) the RRSIG which signed this TXT Record with on-the-wire byte orderings will not match what delphinusdnsd gives out. It should result in a SERVFAIL or the recursive nameservers may try another nameserver but it's not guaranteed that it will recover for you.

Luckily the setup of a replicant is easy enough for any alternative DNS server and the dddctl bindfile mode gives you the chance to convert your delphinudsnsd zones to BIND format. This bug has been with us since the beginning (when we started replicating) and like I said as the sole programmer I'm facing a emotional blockage right now. The fix is in parse.y and how it parses TXT records, similarily raxfr.c would need to write TXT RR's in exactly the segments that it was given them in the AXFR. This also deviates the whole parsing for a TXT record and I'll have to examine if I have to do much work in parse.y for this. Finally I'll end with a nice saying. "DNS how hard can it be?!"

0 comments

New found bug: delphinusdnsd as replicant/secondary

December 25th, 2022

In this commit here, I fixed the dddctl bindfile, today. I've come to the realisation that delphinusdnsd serving TXT's as a replicant when the primary (aka master) is NOT delphinusdnsd _could_ cause a conflict and the query answered from delphinusdnsd may not check out in DNSSEC. And this is only in DNSSEC. I'm thinking around a fix for this and it may take a few days due to the holidays. One logical way of doing this is to let delphinusdnsd know it is a replicant zone when it reads out of /var/delphinusdnsd/replicant and then expect a split TXT record when the size is over 255 bytes. In plain english it has to do with the partitioning of a TXT message that is larger than 255 bytes. I'll be working on that. In the meanwhile if you're affected (using TXT and DNSSECed zones with delphinusdnsd) dump the delphinusdnsd temporarely and look for a 1.7.1 release to pick up where you left it.

0 comments