1. README
 1.1 AUTHOR(S)
2. WHY DELPHINUSDNS?
3. INSTALL HINTS
 3.1 FreeBSD
 3.2 Linux
 3.3 OpenBSD
4. COMPATIBILITY
5. EXAMPLES
6. DNSSEC
 6.1 Signing your zone with dddctl sign
 6.2 re-signing with existing keys
 6.3 What to do with the .signed file
 6.4 How can I sub-delegate a zone with DNSSEC
 6.5 What algorithms are supported with dddctl sign
7. WHAT IT CAN'T DO
 7.1 DNSSEC algorithm rollover  
 7.2 RR support missing

1. README 
---------

Delphinusdns is a small authoritative nameserver.  It does not recurse nor 
search.  Since version 1.5.0 it does forwarding (with TSIG security even). 
This program is written to a BSD Style License.  BSD's tree(3) Red Black 
btree macros are used for the main in-memory database.  

You can download delphinusdnsd from github.com for a limited time.

1.1 AUTHOR
----------

Peter J. Philipp <pbug44@delphinusdns.org> who wrote delphinusdnsd while 
residing in Schweinfurt, Germany.

Some contribution came from other people (worldwide) with minor patches.

A website exists, with blog concerning delphinusdnsd.  Please see
https://delphinusdns.org.


2. WHY DELPHINUSDNS?
-------------------

DNS is simple.  Yet, implementation of DNS servers is not so simple.
DelphinusDNS is written for research into the DNS system so that perhaps one
day the author has a better understanding of it.  Delphinusdnsd is developed
on OpenBSD, due to pledge(2) and other security mitigations, it is recommended
that serious delphinusdnsd users also use OpenBSD.  Ports to other OS's exist
for those that cannot do without those platforms, but at the risk of more
attack surface*.  Delphinusdnsd chroots and privseps on all platforms, meaning 
that a direct root exploit is not possible.

Usually the primary branch is for OpenBSD and the other ports are not 
guaranteed to compile until shortly before release time, when testing occurs 
for these platforms.

Use the tool "dig" that comes with bind9 to debug Delphinusdns.  If you like to 
program, then you can fork DelphinusDNS and make your own creation, or you
can send patches to the author who may implement them into the code.  The
current contact mail address is pbug44@delphinusdns.org.

3. INSTALL HINTS
----------------

To install, type ./configure on your platform.  This will copy the proper 
Makefile to ./Makefile and dddctl and delphinusdnsd.  Then you would type 
make, followed by su'ing and make install.  Delphinusdnsd installs to 
/usr/local/sbin.

By default installation the configuration file is not installed you need to
do this manually.  Also by default the config file is specified as 
/etc/delphinusdns/delphinusdns.conf this can be changed by adding the -f 
option to delphinusdnsd.

A sample config file exists with the sources.  example7.conf was a real life
config once. 

3.1 FreeBSD
-----------

# get the libressl package
$ pkg install libressl
## configure the platform
$ ./configure
## add a privsep user (_ddd) with a chroot directory (as root)
$ vipw
## or
$ pw user add _ddd -m
## make the program
$ make
## install the binary (as root)
$ make install
## done, create a config file and start delphinusdnsd

3.2 Linux
---------

In Linux MINT you need to apt-get install build-essential.

## configure the platform
$ ./configure
## this will install the development programs you'll need (as root)
$ apt-get install make bison cvs gcc libssl-dev libbsd-dev
## add a privsep user with a chroot directory (option -m) (as root)
$ useradd -m _ddd
## make the program
$ make
## install the binary (as root)
$ make install
## done, create a config file and start delphinusdnsd


3.3 OpenBSD
-----------

## configure the platform
$ ./configure
## add a privsep user (_ddd) with a chroot directory (as root)
$ useradd -m -s /sbin/nologin _ddd
## or
$ adduser
## make the program
$ make
## install the binary (as root)
$ make install
## done, create a config file and start delphinusdnsd


4. COMPATIBILITY
----------------

------------------+--------------------+---------------------+
Operating System  | makes and compiles | responds to queries |
------------------+--------------------+---------------------+
FreeBSD 14.0      |        yes	       |       yes           |
------------------+--------------------+---------------------+
Linux  (devuan)	  |        yes         |       yes           |
------------------+--------------------+---------------------+
OpenBSD 7.4       |        yes         |       yes           |
------------------+--------------------+---------------------+


5. EXAMPLES
-----------

in the directory "examples" are a few examples from working configs.  The
author uses example8.conf often to test functionality and compatibility
on any platform.

6. DNSSEC
---------

DNSSEC is added hostcontact responsible person commitment.  You will have to 
re-sign your zone at periodic intervals.  This can be automated though.

6.1 Signing your zone with dddctl sign
--------------------------------------

The very first time you'll want to create ZSK and KSK keys.  They are the
zone signing and key signing keys respectively.  Every DNSSEC zone has at
least one of these.  To create these with dddctl sign I use -Z and -K
options.  Here is an example:

	dddctl sign -Z -K -i example.com -n example.com -o example.com.signed

What this does is it creates the keys and signs the zone 'example.com' with
the zonename example.com.  No trailing dots are needed.  The output will be
called example.com.signed and the keys will be created and look like this:

alpha$ ls K*
Kexample.com.+008+04815.key             Kexample.com.+008+40405.key
Kexample.com.+008+04815.private         Kexample.com.+008+40405.private

This is a compatible output format of dnssec-keygen utility from BIND and 
format is simple:

K for key, example.com. for the zone name, +008 for the algorithm used in
this case it's rsasha256 and lastly a unique identifier for the key.  

Keep these keys in a private place and only pull them out when you are going
to re-sign the zone, as shown in #6.2.  The K* files should say inside which
is the ZSK and which is the KSK.

6.2 re-signing with existing keys
---------------------------------

In order to do the monthly re-signing you must know which key is the ZSK and
which is the KSK.  The K*.key files will tell you which is the ZSK and which
is the KSK.

	dddctl sign -z Kexample.com.+008+04815 -k Kexample.com.+008+40405 \
		-i example.com -n example.com -o example.com.signed

Note, this will overwrite any example.com.signed file.


6.3 What to do with the .signed file
------------------------------------

Install the .signed file as your zone.  I personally use include's in my 
configfile so that this is managed easy.  Then restart delphinusdnsd after
setting the 'dnssec' option.  Your zone should talk DNSSEC, after you upload
the KSK to your registrar.  They'll likely want the DNSKEY and in some cases
grab it themselves over the insecure channel.  My registrar joker.com did 
this.  Other than that dddctl sign creates a dsset-example.com. file which 
has the uploadable DS keys in it.

It's up to you to upload DS or DNSKEY (which can derive DS keys) to your 
registrar and from there to your parent zone.


6.4 How can I sub-delegate a zone with DNSSEC
---------------------------------------------

This was recently fixed.  When delegating to a signed zone be sure to copy
back the DS file (dsset-zone. file), it is in RFC1034/BIND format so you'll
have to convert it to delphinusdnsd format most likely.  You then sign over
this and publish the delegation (restart delphinusdnsd).  That should be all.
Here is an example zone entry for ip6.example.com:

 ip6.example.com,ds,86400,35905,13,2,"CB0EC7995E5223BC823A0AF96180613C7B24295F47E066E690EE448626995044"


6.5 What algorithms are supported with dddctl sign
--------------------------------------------------

The following algorithms are supported since version 1.8:

RSASHA256 (alg 8), RSASHA512 (alg 10), ECDSAP256SHA256 (alg 13),
and ECDSAP384SHA384 (alg 14), lastly ED25519 (alg 15) is supported.

The default algorithm is alg 13 the others have to be specified by number (int).


7. WHAT IT CAN'T DO
-------------------

7.1  DNSSEC algorithm rollover  
------------------------------

This is undefined.  I don't know how well we could do this.  Do all recursors 
support the methods described per RFC?

7.2  RR support missing
-----------------------

In terms of RR support there is only a few missing by now from the generally
acceptable list of RR's

a) AFSDB(18) - andrew file system db record
b) APL(42) - Address prefix list record
d) CSYNC(62) - child to parent synchronization
e) DHCID(49) - DHCP identifier
f) DLV(32769) - DNSSEC Lookaside Validation record
g) DNAME(39) - Delegation name record
h) HIP(55) - Host Identity Protocol 
j) OPENPGPKEY(61) - OpenPGP public key record
k) SMIMEA(53) - S/MIME cert association
l) TA(32768) - DNSSEC trust authorities
m) TKEY(249) - transaction key record
n) URI(256) - Uniform Resource Identifier

Perhaps at 1.8 time a few of these will be supported.