DNSSEC (DNS Security Extensions) is a set of extensions to the DNS protocol that allow cryptographically validating DNS server responses.
This means that when we receive a response to a DNS query it may include additional information that allows us to verify its validity,
In turn, this allows us to have additional safeguards against man-in-the-middle attacks or cache poisoning.
To create these safeguards DNS server administrators must sign their zones. Together with the usual records, the signing process inserts additional information in the zones that allow clients (i.e., those querying the DNS) to verify those signatures.
This process is similar to other digital signature procedures in which signature verification involves following a signature chain to a root or trust anchor.
The DNSSEC trust anchor is provided by the signed root zone. The DNS root zone was signed in June 2010.
DNSSEC does not define a new protocol, but instead creates new records and new flags within the framework of existing DNS messages.
The DNS protocol is a critical piece in the operation of the Internet. In fact, it's difficult to imagine the Internet on its current scale without an efficient and scalable name resolution mechanism.
The DNS protocol was originally defined in 1983 (RFCs 882 and 883) and has not undergone significant changes since then. New functionalities have been associated with extensions and new types of records.
Because it was designed when the Internet was still largely limited to the academic environment, the DNS protocol suffers from a few structural weaknesses that make it vulnerable to certain types of attacks.
These attacks include what is known as "The Kaminsky Bug" that made headlines in 2008 and required urgent software updates on all DNS servers.
Replacing all Internet DNS servers is unthinkable, but thanks to the DNS protocol's extensibility it was possible to define extensions that enable DNSSEC to reduce these weaknesses without forcing the immediate replacement of all servers.
DNSSEC is being deployed gradually as different operators are signing zones.
There is a lot of freely available information on DNSSEC in terms of documentation and tutorials.
By way of example, we can mention the following:
Work must be carried out on two levels: on one hand, software that supports zone signing must be installed and operated; on the other, key and signature handling and management policies and procedures must be defined.
In terms of software, the following products can be mentioned:
You can begin validating DNS responses today in your recursive DNS servers. To do this, you must follow the steps specified by the software manufacturer.
BIND 9.7 and higher versions:
As the regional Internet address registry, LACNIC also operates reverse DNS resolution for IPv4 and IPv6 addresses in the region.
This is, for example, among others, the case of 179.in-addr.arpa or 200.in-addr.arpa. In these zones LACNIC members install delegation records (NS records) that allow 'linking' the root of the reverse DNS tree to its lower branches
In the case of DNSSEC, LACNIC's DNS servers must also contain another type of records (DS records) that allow creating the chain of trust mentioned above.
LACNIC members wishing to sign their reverse zones may use LACNIC's registry system to configure the DS records for their DNSSEC keys.
No. Using DNSSEC is up to each operator. However, we believe that it is important to work on deploying this technology.