DNSSEC - what is it and how it works

Every time a device connected to the internet wants to communicate with another
device (e.g. your computer and A/I servers) it must do so by contacting said
device on its IP address. It would be unconvenient to do all of that manually
and remember IP addresses, thus the DNS has been invented to translate names
(e.g. www.autistici.org) into IP addresses (e.g. 82.221.99.153).

DNS itself doesn't provide any guarantee over authenticity of its replies. This
means that anybody controlling your traffic is capable of changing the IP
addresses your computer sees. This scenario is exploited for example for very
simple censorship: if the site is censored then your ISP DNS servers will
return no IP addresses instead of the real ones.

The DNSSEC protocol has been introduced to provide an additional layer of
security by making sure that replies can be authenticated.
DNSSEC is not perfect
(see for example the problem of zone
enumeration and criticism by
D. J. Bernstein) however we think that it is important to provide users and additional validated channel.

How do I use it?

One of the simplest ways to use DNSSEC is to use a public DNSSEC-validating DNS
(such as google public dns). However this solution assumes that the
communication between your device and the DNS server is to be trusted.

Instead, you can run locally a validating DNS server that will do the
validation. There are pre-packaged solutions to ease this task such as dnssec-trigger
oriented to installation on roaming laptops.

Is it working?

You can verify that DNSSEC is working properly by assessing whether it is
working or not. Specifically, there are websites that are broken on
purpose (e.g. dnssec-failed.org)
and your device won't be able to use them. In particular your device won't be
able to know the website's IP address. The command below can be used to verify
using the terminal (if for example you are using a local resolver as explained
above). Notice the command resuts no results (status: SERVFAIL):

$ dig +dnssec +noauth +noquestion +nocmd +nostats dnssec-failed.org @localhost
;; Got answer:
;; ->>HEADER<
On a valid domain however be the valid answer flag "ad" will be set by the
local resolver:

How to validate using the command line?

If you are using a local validating DNS, all answers directed to that server
will be already validated. In cases where this isn't possible you can still
manually validate a request (in a slighly convoluted way):

Other uses

The hierarchial nature of DNS is also reflected in the DNSSEC deployment, this
means that each entity in the DNS tree can autonomously publish and generate
its keys. Compare this to the existing CA infrastracture for https certificates
with a few valid entities that are globally trusted. With DNSSEC it is possible
to freely change the keys by simply publish them to your parent zone. (e.g.
autistici.org publishes its keys towards org.)

DNS supports other data types other than IP addresses, e.g. you could publish
SSL certificate information for a given domain. The DANE
protocol aims at specifying the details of TLS certificate fingerprints over
DNS and bypassing the root CA system altogether. Our CA verification page uses this protocol to
establish a chain of trust via DNS.