Conflicts:
	management/daemon.py

Tell Flask to log to syslog

The updated instruction is not very user-friendly. I think the right
solution is to wrap the `/dns` commands in a `tools/dns.py` style
script, along the lines of `tools/mail.py`.

Intended to be the simplest auth possible: every time the service
starts, a random key is written to `/var/lib/mailinabox/api.key`. In
order to authenticate to the service, the client must pass the contents
of `api.key` in an HTTP basic auth header. In this way, users who do not
have read access to that file are not able to communicate with the
service.

- Writes Flask warnings and errors to `/var/log/syslog`
- Helps to debug issues when running in production

Don't check NS records for now because they will only appear on zones.
If a hostname is a subdomain on a zone and not itself a zone, it will
lack NS records.

Also stop testing for ADSP, which we dropped in 126ea94c.

It just echos back the subject given to it.

manage the nginx conf in the management daemon too so we can have nginx operate on all domains that we serve mail for

drop support for ADSP which since last November is no longer recommended per http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/

use DANE when sending mail: if the recipient MX has a DANE TLSA record in DNS then Postfix will necessarily encrypt the mail in transport

Postfix has a tls_security_level called "dane" which uses DNS-Based Authentication of Named Entities (DANE)
to require, if specified in the DNS of the MX host, an encrpyted connection with a known certificate.

This commit adds TLSA records.

run bind9 on the loopback interface for ensuring we are using a DNSSEC-aware nameserver to resolve our own DNS queries (i.e. when sending mail) since we can't trust that the network configuration provided for us gives us a DNSSEC-aware DNS server

see #71

dont create a separate zone for PUBLIC_HOSTNAME if it is a subdomain of another zone (hmm, this is a general principle that could apply to any two domains the box is serving)

* sign zones
* in a cron job, periodically re-sign zones because they expire (not tested)

two more cases of shelling out external programs in a more secure way, see cecda9ce

Now that dns_update is a part of the management daemon, we no
longer are using STORAGE_ROOT/dns for anything.

Duplicity will manage the process of creating incremental backups for us.
Although duplicity can both encrypt & copy files to a remote host, I really
don't like PGP and so I don't want to use that.

Instead, we'll back up to a local directory unencrypted, then manually
encrypt the full & incremental backup files. Synchronizing the encrypted
backup directory to a remote host is a TODO.

Support dual-stack IPv4/IPv6 mail servers