DelphinusDNS Blog(the latest about delphinusdnsd)
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.
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.
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.
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.
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.
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.
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.
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?!"
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.
December 24th, 2022
Let there be manna!
Click here for RSS
On this day in
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