Add authoritative zone handling

[karolyi]

Hey,

so this would address #116.

I've changed using getopts to getopt that allows for long option parameters (see the commented out lines as to why). I don't use it right now but the time may come so why not put it in ahead of time. Also I fixed a startup error.

The way it works is, when you mount the /etc/dnscrypt-server/auth-zones directory, it gets picked up by the startup script and generate a different configuration in terms of what interfaces to listen on, and what queries to answer to, depending on where they arrive from.

I've tested this variant on my local VM, seems to be working.

Documentation is still missing; this is just a WIP version. Add your input if you'd like, but to my taste this is already good enough to go. If nothing else, I'll add the documentation part, and then you can merge (and hopefully release ASAP).

[karolyi]

The documented part is for local-zones directives, that is very different from authoritative zones (auth-zone). They're not even handled on the same configuration level. I saw it from the get-go but unfortunately it's not what I need, as the server should be able to act authoritative for zones it gets IXFR/AXFR-ed.

getopt is available at every POSIX platforms, that includes linux, macos and freebsd (my choice). the parsing is basically the same thing implemented in getopt, as you can see from the diff.

The chmod was necessary because that file it chmods, wasn't readable to the user it needed for some reason. It is put with that permission into the git repo as well, so I did the change.

The leftovers are for documentation and testing purposes, just ignore them, don't be too picky about them.

IFS is changed so multi-line configuration snippets aren't parsed as arrays. As you can see, when the setup is done, IFS is changed back.

[karolyi]

Interesting, I thought I defined an empty IFS which I didn't. At some point I got errors because they were parsed as arrays. I'm too tired for today (was working today the entire day on this) but I'll check tomorrow if that OIFS/IFS can be removed.

On second thought, that could've been because I was testing restarting the service from within the container, where the default IFS can be different. I'll test tomorrow.

[jedisct1]

But couldn't auth-zone lines be added to files in /etc/dnscrypt-server/zones, just like local-zone?

[karolyi]

But couldn't auth-zone lines be added to files in /etc/dnscrypt-server/zones, just like local-zone?

Not that I know of. local-zone belongs to under server: whereas auth-zones are their own levels. See https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#authority-zone-options and https://github.com/NLnetLabs/unbound/blob/master/doc/example.conf.in

[karolyi]

Okay, so did a test now. I can't recall for what reason, but sometimes the IFS value was making my modification with the multi-line string behave as an array, so just to be sure, I've added setting/resetting its value before setting the proper variables.

If you agree this is acceptable, I'll make the documentation changes in hopes of a timely merge and release.

[karolyi]

Hey,

I'm abandoning this PR. It turned out that unbound is unable to transfer zones with using TSIG signatures and so the only method is to restrict by IP that is insecure: IPs can be faked by a powerful enough adversary.

Feel free to integrate or close this PR.