This problem is solved with a chain of trust: every link in this chain has signed DS record(s) in the previous zone, as already mentioned in your question. This emphasizes the significance of an anchor at the root name servers. If this was spoofed, the whole chain of trust was compromised. Therefore, resolvers must be pre-configured with the trust anchor. RFC 6781 explains:
4.2.3. Compromises of Keys Anchored in Resolvers
A key can also be pre-configured in resolvers as a trust anchor.
If trust anchor keys are compromised, the administrators of
resolvers using these keys should be notified of this fact. Zone
administrators may consider setting up a mailing list to communicate
the fact that a SEP key is about to be rolled over. This
communication will of course need to be authenticated by some means,
e.g., by using digital signatures.
End-users faced with the task of updating an anchored key should
always verify the new key. New keys should be authenticated out-of-
band, for example, through the use of an announcement website that is
secured using Transport Layer Security (TLS) [RFC5246].
You can download the Current Root Trust Anchors (bind.keys) directly from the Internet Systems Consortium. The site is protected using TLS & the file is also signed with their signing key.
If you don’t have anything in named.conf and there is no bind.keys
file, named will use the compiled in keys.
Note: these are managed keys, so this is only applies the first time
you execute named. Assuming that the keys are not already expired (in
which case named will log that the key is expired and validation will
not work), named will use RFC 5011 to detect new keys and
automatically roll and maintain keys. Once named is managing the keys,
the current keys will be in managed-keys.bind or *.mkeys, if you use
views.
Another problem is the communication with your resolver, the "last mile". The resolver may be validating the signatures and answering with the DNS Authenticated Data (AD) bit, but as DNS works in plain text, the results could be modified by a man-in-the-middle (MITM) attacker. There are multiple possible solutions to this:
You could have an own local resolver having the anchor keys file, but this is not quite a practical solution for masses. It also causes more traffic to the root name servers, if there's no forwarders configured. It's a trust-no-one solution, where you verify the signatures by yourself.
DNS-over-TLS & DNS-over-HTTPS. E.g. Cloudflare with their 1.1.1.1 supports both:
What's needed is a move to a new, modern protocol. There are a couple
of different approaches. One is DNS-over-TLS. That takes the existing
DNS protocol and adds transport layer encryption. Another is
DNS-over-HTTPS. It includes security but also all the modern
enhancements like supporting other transport layers (e.g., QUIC) and
new technologies like server HTTP/2 Server Push. Both DNS-over-TLS and
DNS-over-HTTPS are open standards.
We think DNS-over-HTTPS is particularly promising — fast, easier to
parse, and encrypted. – – We're hoping that
with an independent DNS-over-HTTPS service now available, we'll see
more experiments from browsers, operating systems, routers, and apps
to support the protocol.
- DNSCrypt authenticates communications between a DNS client and a DNS resolver using cryptographic signatures. This has never been proposed to the IETF (there's no RFC).
