DelphinusDNS Blog(the latest about delphinusdnsd)
April 10th, 2023
Until I give the word please don't run the newest delphinusdnsd from the
github master branch. It will fail if you have more than one zone. With
that I'm going to do some more coding, happy easter monday!
April 9th, 2023
Happy Easter. Just sitting here reading a bit through
Sometimes they have good stories. The stories that I like particularily at
this time are:
- Analysis of 7.5 trillion
- DNS4EU plans
to onboard 100 million users...
- 350 million domain names on earth (of which I have four)...
The circleid blog is more about the business aspect of DNS in particular
registrations, which isn't exactly what I do at delphinusdns.org. But there is
the DNS Sexy blog aggregator
that I often
read. It hasn't updated in 40 odd days right now but there is other informative
links from there to (say) the PowerDNS technical blog. This interests me a
whole lot. Other than that wikipedia is one of my favourite sources of DNS
specifics and of course rfc-editor. On top of that I have a bunch of books on
DNS but I haven't bought much books since 2019. I do like hanging out on
#dns IRC channels but they are mostly idling these days.
April 8th, 2023
3.7.2 was released today adding Ed25519 support. This means that I can
start adding alg 15 to delphinusdnsd/dddctl. I can also start removing some
older algorithm like alg 7 which is not recommended anymore according to RFC
8624 section 3.1. Thanks to all the teams at LibreSSL for this wonderful
April 5th, 2023
I'd just like to mention the maintenance for tuesday was done on monday
evening. I was able to retire the OpenBSD/octeon router and give the
raspberry pi 4b the task of routing. Apparently everything works as you
can read this. I did a speed test for 100 Mbit and saw cpu idleness go
down to 55% on one core. Since at the same time there was a sshd brute
force attempt that took a bit of the load as well. So I'm in a much better
position to upgrade my ISP plan (perhaps next year?). I put the raspberry
on one of my switches 10 gbit ports so in theory the device on that port
can route up to 5 Gbit/s, or 10 Gbit/s if it has 2 ports. I'm not counting
on this until in five years perhaps when I will expect 1 Gbit/s speeds.
For that my building will need some upgrades though, hopefully before 2030.
April 2nd, 2023
I'm going to have two maintenances in the next two weeks. One is the
retirement of my OpenBSD/octeon router, which I will replace with vlan
plumbing on my switch and the raspberry pi 4b. I hope it works. This
may be on tuesday, thursday or friday of this week. I'm not going to do
this in off-hours since this is the Internet and I have a worldwide
The other maintenance will be for the new version of OpenBSD (7.3) which will
probably not constitute as much downtime. This will likely be after easter
monday. Hoping on tuesday or wednesday.
March 31st, 2023
In C programming if you have a pointer named pbuf and another pointer on pbuf
called p and increase that p by one, the difference of p - pbuf is one. C
programmers use this often to calculate lengths. But it may so happen that
they sometimes have a confusion on what has the lower address. In that regard
pbuf - p becomes really large. OpenBSD
recently had this fixed in skeylogin.c. So it does happen to
other programmers. I have now made a helper function called plength() that
allows one to give it an upper limit, (usually for delphinusdnsd plength() has
an upper limit of 65536). If the program then bumps into a violation, it will
abort() and hopefully create a corefile for analysis. I've been running this
for a while now and I think it's good to go. But a rare condition may be
lurking somewhere. In that case you know what to do now.
March 30th, 2023
Pretend someone forges (spoofs) a packet to a DNS server. If that server
is delphinusdnsd it will add, to a hash of the source address, a timestamp
in order to calculate the ratelimiting (definable between 1 and 127 pps or
alternatively off). If that forged packet claims to be from a valid recursive
nameserver like 220.127.116.11 (google) and does this at the ratelimit, the real
google nameserver will never get through, because it was denied (dropped) in
the ratelimit. It will have to resort to using TCP and what if that protocol
is also denied? So I have changed the algorithm a little bit. It will add
not just the timestamp to the hash of the source address, but also a ttl value
of the received ttl. This value is always the same which is the case for
most hosts hop distances on a stable Internet, it may differ by a few hops
occasionally as routing changes but it doesn't always do this for most
networks. So a spoofing denier will have to guess the exact ttl that 18.104.22.168
has to my nameserver in order to deny it, and that's a bit intense. It may
work with tracerouting but chances are that this is not accurate. Anyhow
this is new and I wanted to tell you about it. Thanks to the PowerDNS blog
which had a different mitigation, which gave me this idea.
March 29th, 2023
I have worked like a madman on this, and finally I have succeeded. The gist
of the matter is that AXFR will need a rewrite anyhow but I was just getting
familiar with this a bit more. Anyhow AXFR now forks a child helper that has
the "inet" pledge still and both of them exchange filedescriptors back and
forth until all notifies are done. Then the AXFR can't send anything anymore.
It can only receive and serve zone files. This is more secure I'm glad I took
the time to do this. This will not be backported to 1.7.x branch so you'll
have to wait until december for the 1.8.0 release. Or you run on the master
branch aka -current. But it's a work in progress.
March 26th, 2023
Since 2019 at least I knew about them, it took four years to fix it. I always
said to be careful with these. This article is now a historic relic as escaping colour for
christmas trees is not allowed anymore. Yay for security! Thanks to OpenBSD,
tcpdump, and David Leadbeater who all have prodded me with incredible bugs and
bugfixes to get this fixed.
Also you can use the debug console now without worry. I fixed that too.
spica# dddctl query -Q22.214.171.124 vis.dtschland.eu txt
; COOKIE: D8F12F7C99B6B4CC
;; QUESTION SECTION:
; vis.dtschland.eu. IN TXT
; SERVER COOKIE: D8F12F7C99B6B4CC0100000064203822171FFA01B6DAD552 (good)
;; ANSWER SECTION:
vis.dtschland.eu.,txt,86400,"\^[[32m;green green green oh lovely green"
;; ADDITIONAL SECTION:
;; QUERY TIME: 22 ms
;; SERVER: 126.96.36.199#53
;; WHEN: Sun Mar 26 14:18:42 2023
;; MSG SIZE rcvd: 125
I won't be backporting this unless I'm backporting another bugfix, if you want
this you'll have to track the master branch (commit 193373f).
March 25th, 2023
I'm guessing anytime before now and Easter OpenBSD 7.3 will be released.
Pretty soon after that I'll upgrade my systems to this. I do develop on
OpenBSD so if you follow my development in the master branch of github and
git pull often, I want to give you a small warning. Very soon after the
7.3 version is released I'm going to add mimmutable() to my sources to
protect the shared memory, which has guard pages between each slot. This
will tighten our security parallel to OpenBSD's mitigations. For more
about this topic, check out Theo de Raadt's talk at CANSecWest. The
is here (undeadly.org). So mimmutable() will likely be #if __OpenBSD__
in the sources but I won't try to #if versions of OpenBSD. This is open
source, and you're expected to be up to date. So if you're on OpenBSD 7.2
or lower after I commit mimmutable() you'll either have to remove them with
#if 0 in the source yourself or be forced to upgrade if you want to run the
latest greatest. The 1.8.0 release will also come with this
mimmutable() change for the
first time. The 1.8.0 release will be around Christmas time as usual (or
likely a few weeks before/after depending on how I feel). Happy happy.
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