The DNS system is insecure
If you want to access any website, your browser needs a unique number of the server on which the website is stored, the so-called IP address, similar to a telephone number. It queries this IP address from a DNS server. Similar to a telephone book, this DNS server maintains a list that links domain names to IP addresses. For example, when you ask your browser for the IP address for the domain www.dotplex.com, it receives 2a0c:5f00:1:10b:: after the new IPv6 addressing and also the answer 185.231.124.11 after the old IPv4 addressing.
This answer of the name server is usually transmitted unencrypted over the internet and can easily be manipulated on the way to your computer by hackers, the provider, network operators or secret services. This method of attack, where someone stands between you and the actual server, is called Man-in-the-Middle (MITM). Your browser is given a false IP address that belongs to another server and on which, for example, a manipulated version of the website that you actually wanted to visit is stored. Many other attacks are also possible in this way, e.g. reading or redirecting e-mails. What is particularly treacherous is that you will not even notice this attack.
Securing DNS with DNSSEC
To make these MITM attacks more difficult, the administrator of a domain can sign the DNS records. This allows to check that the answer from the name server is correct and has not been tampered with on its way through the Internet. This works reliably since the root zones (e.g. .de) are signed and a verification of the signatures is possible across all authoritative name servers. You can read more about DNSSEC on Wikipedia.
Domains at dotplex are secured with DNSSEC at no extra charge.
Validate SSL certificates with DANE
To ensure that information is not passed through the cables and devices of the internet in a way that is readable by everyone, SSL is used to make these connections secure through encryption. This is particularly important, for example, when accessing websites (the address line in the browser shows https:// instead of just http://) or connections to mail servers.
To establish an SSL-encrypted connection to a server, the server needs an SSL certificate issued by a certification authority (CA), e.g. Let's Encrypt. In the browser or operating system the root certificates of a multitude of CAs are stored, which are automatically trusted. If the CA of the certificate is not known, the browser displays an error message that the connection is not trusted.
Now there have been some cases in the past where CAs were hacked and certificates could be issued for any domain name. Probably some authorities and secret services are generally able to do this. With such a forged certificate, man-in-the-middle attacks on encrypted connections can then be carried out and the transmitted data read out. Until now, the only protection against this was to delete all CAs from the browser and to trust all certificates only after a manual check, which is usually not practicable.
For this reason, the DANE standard has been available for some time now, with which a hash of the valid certificate can be stored as a TLSA record in the DNS entry of the domain. This DNS entry can of course only be trusted if the domain is also signed with DNSSEC. But then the validity of a certificate can be checked and MITM attacks can be made more difficult.
Until today, DANE has unfortunately only become widely accepted for SMTP connections between mail servers, although the standard would also work for HTTPS connections to websites. However, this would require the validation to be implemented in browsers.
At dotplex, TLSA entries for DANE are provided for all mail servers. Since we also sign all customer domains with DNSSEC, your mails are automatically secured with DANE at dotplex. You can verify this with the DANE Validator at dane.sys4.de.
DNS over HTTPS, DNS over TLS
In recent years, another standard for securing the DNS has also become widespread and is already activated by default by some browsers. Up to now, the browser or operating system has queried the DNS data via the DNS protocol, usually from the DNS server of the Internet access provider. On the one hand, this has the disadvantage that the query is not encrypted, i.e. it can be monitored. On the other hand, the answers can be manipulated by the provider or other attackers at will, especially if the domain is not signed with DNSSEC. This is also extensively used for censorship in some countries.
With DNS over HTTPS, the DNS query is encrypted via HTTPS, with DNS over TLS via an encrypted form of the DNS protocol, in both cases tamper- and tap-proof bypassing the internet provider. Although this makes censorship and MITM attacks more difficult, there is primarily a shift in control. It is foreseeable that most Internet users will use DoH/DoT servers from large providers, e.g. in Firefox the servers of the US provider Cloudflare are preset. Even if the connection from browser to Cloudflare is secure and protected against manipulation and interception, a manipulation of the DNS data by the operator of the DoH/DoT server would not be detectable by the internet user himself, especially because DNSSEC is not validated by the client.
DNS over HTTPS and DNS over TLS are therefore no substitute for DNSSEC, as only the problem of encryption is solved and not the missing end-to-end authenticity of the DNS data from the domain holder to the internet user.