DelphinusDNS Blog
(the latest about delphinusdnsd)||
|
Previous Page
March 6th, 2020
I just wrote a little in the handbook regarding
verifying what
dddctl sign produces. It's often a good idea to take this step in order
to unearth any unintended bugs. Thanks!
0 comments
March 4th, 2020
I have changed the default key creating algorithm to alg 13 from alg 8, in
the -current code. Alg 13 is ECDSAP256SHA256. This is generally recommended
in IRC #dns. It will not affect 1.4.x release which still uses alg 8.
0 comments
March 3rd, 2020
I have some uncommitted code to allow the double-signature method for rollovers.This should allow algorithm rollovers eventually. I was stuck trying to make
this work though. My main source of dns programming advice was able to help
me out again interpreting RFC 4034 right. It turns out in the scenario of
introducing a different sized key (3072 bits vs. 1024 bits) I was not sorting
the RR's right in canonical mode. The problem lies in my interpretation of
RFC 4034, section 3.1.8.1 where the signature is produced by going over the
RRset. In my code (not changed yet) I ordered around the wire format of
RR(i), but instead the ordering is done first around the RDATA instead. Thanks
goes to Habbie once again! Since algorithm rollovers aren't supported in
Delphinusdnsd 1.4.x I don't feel I need to backport changes here. But we'll
likely see a different sorting algorithm for 1.5.0.
1 comment
March 3rd, 2020
When you do a dig for "+dnssec delphinusdns.org A" you will see something
like this:
; <<>> dig 9.10.8-P1 <<>> +dnssec delphinusdns.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53016
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;delphinusdns.org. IN A
;; ANSWER SECTION:
delphinusdns.org. 86385 IN A 85.10.199.4
delphinusdns.org. 86385 IN RRSIG A 10 2 86400 \
20200502072347 20200218072347 64280 delphinusdns.org. ...
I have added a ... in place of the signature in the RRSIG record. What I'm
most concerned with is the signature expire fields and the signature inception
fields.
20200502072347 20200218072347
Those two. If a DNSSEC zone goes beyond the date of the "signature expiration"
the zone is marked as expired thus bogus and remote recursive nameservers may
reply with SERVFAIL. Obviously one doesn't want that so there must be a timely
maintenance to up the signature expiration. I do this semi-automatically with
a script and some typing (the tab expansion in the shell is great help here).
I call this "re-signing the zone".
It is done with dddctl sign command and
dddctl will take the current time and go back 2 weeks in order to create a
small overlap. This is needed to prevent unsynched clocks to always recognize
the window between inception and expiration. The new inception was 18th of
February and is exactly 2 weeks in the past. The new expiration is roughly
2 months in the future (by default in delphinusdns) so this zone has ample
time (after a month perhaps) to do a zone re-sign. Re-signs are easy, you
take the previous keys and just resign the zone (with a new SOA serial value
so that the replicants can pick up the change).
In the past while being the only sysadmin at an operation I discouraged the
use of DNSSEC because of this. With just one sysadmin there is no backup,
and if you fall sick for over 1 month time the business will suffer. So either
automate this and hope that the automation never ever fails or don't do DNSSEC
and open your domain to forgeries (as DNSSEC has cryptographic integrity).
It's a choice one must make, and it isn't easy. DNSSEC really requires two
hostmasters who know what they're doing, to have a backup when the other falls
sick or is unavailable for whatever reason.
BTW you can't use re-signing to do key rollovers, they have to be done
seperately. See the handbook for how to do this.
1 comment
February 20th, 2020
Earlier today I was approached on split-horizon dns and whether I can
implement something like this. The short answer is no, but you can still
do split horizon DNS with delphinusdnsd with pf. It requires setting up
2 or 3 delphinusdnsd bound on several interfaces including localhost
on their own port. With pf rules you would then do an rdr-to 127.0.0.1
port X where X is the delphinusdnsd that it should speak to. You would have
the same setup on both replicant and master and they would axfr on their
own unique axfr port. A large list of IP's can be assembled from this
website (iana.org).
The reason I'm hesitant on bringing back split horizon to delphinusdnsd is
that it doesn't really fit well with AXFR, it's a mess there. The hack that
I explained it the first paragraph keeps it on a boundary though and could
be done well. Debugging split horizon dns is a pain too, but I think with
regions configured in all running delphinusdnsd's you can have an overview
of which delphinusdnsd was hit. You just gotta watch the logs closely and
follow up to complaints. Good luck!
0 comments
February 14th, 2020
Happy Valentines day. Delphinusdnsd is programmed on OpenBSD which is
Y2038 safe, but the ports may break on January 19th, 2038 or after. I don't
know what will happen actually. I'll keep an eye on this. 2035 is likely
the last year when I will work on this code, perhaps there will be more
light, then.
0 comments
February 4th, 2020
This is a fix for Linux platform. From the commit log on the STABLE_1.4
branch:
This is the first STABLE_1_4 commit leading to release 1.4.1, changes:
-replace linux's TAILQ macros with libbsd's
-replace TAILQ_FOREACH for linux with libbsd's TAILQ_FOREACH_SAFE
-increase buffer buf in struct tcpentry by 1 more byte to prevent possible
overflow
-change lookup_zone to take another argument to indicate size of buffer
-remove length variable in tcploop to squelch warning
-replace a casting pointer with an unpack16() in tcploop
-fix formatting of serial log in raxfr.c (this fixes my output in linux).
This effort fixes formatting and crashes on Linux/arm and fixes a general
off-by-one (not sure if it's exploitable).
Hope this will be OK, the downloads are available all I have left to do is
signify the SHA256.sig file (will be done shortly). Enjoy.
0 comments
January 31st, 2020
What tools did I use? What experience did I have to have?
When I started writing wildcarddnsd/delphinusdnsd I had 10 years of experience
with the UN*X Operating System. I had a lot of sysadmin experience and some
C programming experience. I started in 2005 (it was autumn) originally
the source code was checked in at sourceforge I believe. I personally felt
I was "ready" to lay down this code.
UNIX tools I used to write and debug delphinusdnsd
- vi - to enter the code from scratch (lots of fun!)
- tcpdump - to debug answers that delphinusdnsd gives
- hexdump - to debug dddctl's signing functions
- less/more - to paginate outputs and to look at zonefiles and code
- gdb - to debug crashes
- irssi - to share my enjoyment of writing on a DNS server on IRC and to get
support from people who have already done so.
- BSD - what I started using to write delphinusdnsd, up to this day
- Linux - what I ported delphinusdnsd to, up to this day
- make - to execute the makefiles which executed the compiler, assembler and
linker.
- dig - used mostly to query the server
- drill - used on FreeBSD instead of dig
- ldns-tools - helped a lot finding problems with the DNSSEC code
- Other DNS servers (BIND,nsd) - to compare their output from mine.
Literature used
Countless books about DNS, Unix network programming and YACC guided me
along the way, 10 years experience with UN*X OS's in 2005 started me on
this journey.
It's 2020 now, why did I decide to keep doing this?
I have put 15 years under my belt with this, I intend to do another 15
(god willing). It is a lot of fun steering my own project.
If I could turn back time would I do it again?
Yes.
0 comments
January 31st, 2020
1.3.0 was an oddball release because I applied to funding from the federal
german government in a program called Prototypefund.de, shifting the release
date early by half a year. I didn't get selected with delphinusdnsd.
Meaning, I paid out of my own pocket to work on version
1.4.0 and 1.4.1 (January 2019 through February 2020). In 2018 between
summer and christmas I had another project (OpenBSD powerpc64 port which
ultimately failed) while waiting on the selection results of prototypefund.
All releases before 1.3.0 were also constructed from my spare time as I could
find it. I'm glad 1.4.X is out and I'm looking forward to programming on
1.5.0 (expected to be released in late December). Someone I met is working
on an OpenBSD port for me and I'm looking forward to featuring him on the
Credits section of the delphinusdns.org site once the work is committed at
OpenBSD. The porting work is no easy feat and I'm glad someone is doing this
for me.
0 comments
January 26th, 2020
I believe the fixes I made to delphinusdnsd (on linux) were good. I'm going
to backport the code to the STABLE_1_4 branch soon and then tag it
RELEASE_1_4_1. I'm gonna run the code as it is now for another week on the
particular Linux computer that had problems throughout december and early
january and if I don't see any more crashes then it's a done deal. Sorry
for inconveniences. This I believe did not affect BSD versions of this
code, only Linux although and off-by-one was fixed (I think), that should
have impact on all platforms.
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
July, 2020
June, 2020
May, 2020
April, 2020
March, 2020
February, 2020
January, 2020
December, 2019
November, 2019
October, 2019
September, 2019
Powered by BCHS
|