Add manual pages

[mozzieongit]

Adds manual pages for the six commands based on the help output (of dnst and ldns) and the ldns manuals. I only included arguments actually supported by the dnst reimplementation. Once everything is ready, this will very likely need updating.

This also incorporates and updates the changes from #25.

[AlexanderBand]

Maybe "The manual goes here ..." in index.rst should be replaced with something describing the project. I'm not sure what but perhaps these pages can provide some inspiration:
https://www.nlnetlabs.nl/projects/ldns/about/
https://www.nlnetlabs.nl/documentation/ldns/index.html

[tertsdiepraam]

I think we should merge this because this is fantastic and we can fix all my nitpicky issues later, but...

NITPICK MODE ACTIVATED

I don't like how the synopsis renders as:

dnst [options] command [args]

I'd expect

dnst [options] <command> [args]

The main dnst docs should also mention how the ldns tools fit into this and how to use them with symlinks.

The styling is sometimes inconsistent:

• ldns-nsec3-hash doesn't use <> around values
• ldns-keygen is also missing some <> and uses lowercase
• A few places can put some more in code blocks, like K<name>+<alg>+<id> in ldns-keygen

I think that the ldns tools should refer to the dnst tools to motivate people to update their scripts.

NITPICK MODE DEACTIVATED

That being said, these are all written very well. Amazing!

[tertsdiepraam]

I put yesterdays nitpicks into comments.

Something for later: we should add examples and document exit codes.

[tertsdiepraam]

Throughout the docs it's at least inconsistent whether its [``OPTIONS``] or ``[OPTIONS]``.

In my opinion, it should be like in the uutils docs (which makes sense that I like it because I made it):

Just one big code block with all possible invocations.

[mozzieongit]

Throughout the docs it's at least inconsistent whether its [OPTIONS] or [OPTIONS].

I'll solve the inconsistencies.

The big code block with possible invocations sound nice, but might not be able to implement that today.

[ximon18]

This is correct but perhaps it would be better to say that this is only needed for zones that both contain relative labels AND lack an $ORIGIN directive. I think it also has to be an absolute/fully qualified domain name, not a relative domain name.

[mozzieongit]

Yes. It needs to be an absolute domain name. Also, signzone or rather domain's Name (::from_str?) turns any non-dot-terminated domain into an absolute/dot-terminated domain. So dnst signzone -o origin and dnst signzone -o origin. do the same.

[mozzieongit]

Left over TODOs (though not merge-blocking I would say):

• Add more comprehensive project description (like goals, ...)
• Make ldns tools refer to dnst tools to motivate users to switch
• Maybe add code blocks showing all possible invocations for a command (only for showing "permutations" with optional positional arguments)

Also I left some comments unresolved that could potentially turn into separate issues (for dnst sub commands or domain).

[tertsdiepraam]

If this matches the current main then I'd say we should merge this so we can update it along with other changes.

[mozzieongit]

Hm, the nsec3-hash default iterations for dnst is not yet merged into main. I'll change that to the current defaults in main, and the change would be done in #6 then, I suppose.

[tertsdiepraam]

Alright I'll add it there!