I opposite to use the `.zz`. Instead, I think this should be assigned as new TLD domain for all people live in any country, because it is a reserved ISO 3166-1 alpha-2 code, and will not be assigned to any country. It's the best convenient TLD for human on the earth.
There is not much to gain from having a new two-letter gTLD instead of existing all-purpose three-letter TLDs (say, `.com`, `.ooo` or `.xyz`). Especially given that every TLD needs a registry, and `.zz` would be a particularly extra-special gTLD that needs a special procedure to select the registry. Better to make it a reserved TLD if it is ever going to be used.
If someone wants to send e-mail to user@example.net, they first look up the MX records of example.net. Say, for example, that the MX record for example.net contains the mail server “mailserver.example.com”. (Note the different domain name.) The e-mail sender then looks up the TLSA records of the DNS name “_25._tcp.mailserver.example.com”. The TLSA records contain hashes of keys. The communication to the mail server must support TLS, and must use one of the keys which are listed by the TLSA records, otherwise the communication is regarded as insecure or under attack, and is considered to have failed, similar to if a server cannot be reached.
Also, for DANE to work, both the MX lookup and the TLSA lookups must support DNSSEC! Note well that this means that, in this example, both the domains “example.net” and “example.com” must be signed by DNSSEC for DANE to work.
One wrinkle is that if you use ACME to renew your certificates, you have to add a step in your process so that every time a new certificate is generated, the TLSA records in the DNS are also updated. Note also that DNS TTL values make it so that you should not use a new certificate until it’s guaranteed that everybody has had a chance to see the new TLSA record corresponting to that certificate in the DNS. The normal method for dealing with this is to always have two TLSA records, one for the certificate which you are using, and one for a new certificate which you are not using yet, and make sure that the times are set so that you don’t use the new certificate until the TTL has expired for the resource record set which did not have the TLSA record for that new certificate.
EDIT: Actually, read the response from user “mjl-”; it has more detail, and is obviously from a person which has more practical experience.
First, DANE requires that your DNS is protected with DNSSEC. Your MX records need to be DNSSEC-protected because otherwise any attacker that can give a sender fake MX records can cause an email message to be delivered to a mail server of their choice. The IP lookups to connect to your MX host needs to be DNSSEC-protected, and your TLSA records need to be DNSSEC-protected. For self-hosters, this is usually all the same domain.
Second, your MX host needs DNS records of type TLSA that specify the public keys that are in your TLS certificates that your MX host (mail server) offers during STARTTLS. This is the most common mode for DANE, called DANE-EE (EE = end entity). In this mode, only the public key of the certificate matters. Expiration, hostname match, issuing party of certificates: all ignored. If your MX target is mx.example.com, the TLSA record(s) must be under: _25._tcp.mx.example.com. They will look like this:
Where spki means "subject public key info", i.e. only the public key matters. So, the last component is the sha2-256 hash of the public key.
A mail server can have multiple certificates (e.g. RSA and ECDSA). Each must have a TLSA record.
Keep in mind that when you renew your certificate, you could be reusing your private key or be generating a new private key. A new private key brings a new public key. A new public key requires an updated TLSA record. Keep in mind DNS TTLs in that case. You would have to keep both the old and new TLSA records during the TTL period. I would recommend you don't generate a new private key for each new certificate. If the private key stays the same, the TLSA records don't need to be changed.
MTA-STS requires that the MX host TLS certificate can be verified against the common pool of certificate authorities, i.e. PKIX/WebPKI. DANE and MTA-STS can cooexist. I would recommend setting up both DANE and MTA-STS, using ACME with Let's Encrypt with fixed private keys (not newly generated when fetching a new certificate, I know certbot has an option for this mode), and publishing TLSA records (with the hashes of the public keys of those fixed private keys).
Keep in mind some sending mail servers only implement DANE, and others only MTA-STS. Implementing both gets most protection. Some mail servers implement neither, and are sending email without protection.
> The IP lookups to connect to your MX host needs to be DNSSEC-protected
Really? It does not seem necessary to require this. I mean, the security is guaranteed by the public keys in the TLSA records, right? Yes, the MX lookup and the TLSA lookups must be DNSSEC signed, but does DANE actually require the A/AAAA lookup of the server name in the MX record to also be DNSSEC signed? It does not seem necessary from a security standpoint.
You are correct that it is not needed for security. It is also not required for plain DANE. But it is for DANE for SMTP. The reason is interoperability.
Apparently, some DNS servers would not respond at all to requests for TLSA records (probably fixed in the software by now, but some infra may still run old software). If a sending mail server would request TLSA records, not receive a response, it would have to assume DANE _may_ be required, and abort the delivery attempt. This would lead to mail being undeliverable due to those old DNS servers. Such old DNS servers probably wouldn't be set up for DNSSEC, and with this workaround, the TLSA records wouldn't be requested, so there would be no lookup failure that blocks delivery.
No I did not, but I dont host my mail on their servers either. I still used it quite extensively and it's far more reliable than 99% of cheap cloud providers.
I mostly use them as my personal build server and VPN.
The API also has support for things like custom vibrations, urgency, icons, and action URLs. But- these are minimally supported by Safari Desktop and Safari Mobile today.
I hope Safari iOS adds support for actions and shortcut workflows when clicking a notification.
