DNSSEC

Domain Name System Security Extensions (DNSSEC) allow domain owners to digitally sign their DNS records. By doing this, users are protected from DNS data that has been corrupted, either accidentally or maliciously.

Two things are required for DNSSEC to work: 1. DNS servers that publishes the DNS records must ensure that the DNS data is signed 2. The devices that fetch information from that domain needs to ensure that they validate the records and display errors if they cannot be validated

A great deal of pain is taken out of this process by Cloudflare.

How it works (ICANN)

Every DNS zone has a public/private key pair. The zone owner uses the zone's private key to sign DNS data in the zone and generate digital signatures over that data. As the name "private key" implies, this key material is kept secret by the zone owner. The zone's public key, however, is published in the zone itself for anyone to retrieve. Any recursive resolver that looks up data in the zone also retrieves the zone's public key, which it uses to validate the authenticity of the DNS data. The resolver confirms that the digital signature over the DNS data it retrieved is valid. If so, the DNS data is legitimate and is returned to the user. If the signature does not validate, the resolver assumes an attack, discards the data, and returns an error to the user.

DNSSEC adds two important features to the DNS protocol: - Data origin authentication allows a resolver to cryptographically verify that the data it received actually came from the zone where it believes the data originated. - Data integrity protection allows the resolver to know that the data hasn't been modified in transit since it was originally signed by the zone owner with the zone's private key.

Trusting DNSSEC keys (ICANN)

Every zone publishes its public key, which a recursive resolver retrieves to validate data in the zone. But how can a resolver ensure that a zone's public key itself is authentic? A zone's public key is signed, just like the other data in the zone. However, the public key is not signed by the zone's private key, but by the parent zone's private key. For example, the icann.org zone's public key is signed by the org zone. Just as a DNS zone's parent is responsible for publishing a child zone's list of authoritative name servers, a zone's parent is also responsible for vouching for the authenticity of its child zone's public key. Every zone's public key is signed by its parent zone, except for the root zone: it has no parent to sign its key.

The root zone's public key is therefore an important starting point for validating DNS data. If a resolver trusts the root zone's public key, it can trust the public keys of top-level zones signed by the root's private key, such as the public key for the org zone. And because the resolver can trust the public key for the org zone, it can trust public keys that have been signed by their respective private key, such as the public key for icann.org. (In actual practice, the parent zone doesn't sign the child zone's key directly--the actual mechanism is more complicated--but the effect is the same as if the parent had signed the child's key.)

The sequence of cryptographic keys signing other cryptographic keys is called a chain of trust. The public key at the beginning of a chain of trust is a called a trust anchor. A resolver has a list of trust anchor_s_, which are public keys for different zones that the resolver trusts implicitly. Most resolvers are configured with just one trust anchor: the public key for the root zone. By trusting this key at the top of the DNS hierarchy, a resolve can build a chain of trust to any location in the DNS name space, as long as every zone in the path is signed.

Please note

Please visit this site for more information: https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en