* For non-ASCII domain names, we will keep the Unicode encoding in our users/aliases table. This is nice for the user and also simplifies things like sorting domain names (using Unicode lexicographic order is good, using ASCII lexicogrpahic order on IDNA is confusing).
* Write nsd config, nsd zone files, nginx config, and SSL CSRs with domains in IDNA-encoded ASCII.
* When checking SSL certificates, treat the CN and SANs as IDNA.
* Since Chrome has an interesting feature of converting Unicode to IDNA in <input type="email"> form fields, we'll also forcibly convert IDNA to Unicode in the domain part of email addresses before saving email addresses in the users/aliases tables so that the table is normalized to Unicode.
* Don't allow non-ASCII characters in user account email addresses. Dovecot gets confused when querying the Sqlite database (which we observed even for non-word ASCII characters too, so it may not be related to the character encoding).
Relative hostnames have a fall-back lookup with the machine's hostname appended, which makes no sense. Add a period, e.g. "my.hostname.com" => "my.hostname.com.", to prevent that.
This caused false positive Spamhaus checks. Fixes#185.
The problem was that custom records defined for a subdomain where implicit
records are otherwise defined (e.g. A/AAAA records for the root) were ignored.
Though additional_records for a subdomain are processed in the base call to
build_zone (the call for the parent domain), and so custom records that don't
override implicits were working fine, those that overrode implicits were
ignored.
This was because the recursive call to build_zone for the subdomain creates the
implicit records (including A/AAAA records for the root), and so by relying on
the base call to add the additional_records fails because has_rec returned
true.
Adding a subdomain's additional_records in the child call works because has_rec
returns false when testing whether to add an e.g. A/AAAA override for the root,
as the defaults have not yet been added.
The dns_update script didn't generate IPv6 (AAAA) glue records for the name servers.
This caused http://dnscheck.pingdom.com to complain about a mismatch between the glue records reported by the parent name server and mailinabox nsd.
Here's the failing dnscheck output for reference:
> Checking glue for ns1.my.domain.tld (1.2.3.4).
> Child glue for bgwe.eu found: ns1.my.domain.tld (1.2.3.4)
> Checking glue for ns1.my.domain.tld (1234::1).
> Missing glue at child: ns1.my.domain.tld
> Checking glue for ns2.my.domain.tld (1.2.3.4).
> Child glue for bgwe.eu found: ns2.my.domain.tld (1.2.3.4)
> Checking glue for ns2.my.domain.tld (1234::1).
> Missing glue at child: ns2.my.domain.tld
I'm not very familiar with Python and DNS, please verify ;)
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.
