DNSSEC Compatibility

When typing a URL (Uniform Resource Locator) in the address bar of a web browser, you generally use a text pattern that is easy to read and remember, such as www.azion.com. Based on the provided URL, a request then occurs to a server located on the Internet, such as a postal address.

If the request is correct, the server responds with a web page or some other resource that was requested by the computer that made the request, called a client. This repetitive process is known as the request and response cycle.

However, this pattern of writing addresses based on URLs, although easy for us to understand, is incomprehensible to computers in web communications, as they use an address based on numbers, known as IP address (Internet Protocol). Therefore, whenever you type a URL into the address bar, a conversion is required so that the URL is transformed into an IP address.

This works the same as when you make a traditional phone call to another person: phones can’t understand names. They only recognize sequences of numbers that follow a specific protocol, with the country code, the region, and finally, the number associated with the recipient of the call. Therefore, catalogs are needed to relate the names of people, easily recognizable by the caller, to the respective telephone numbers to be used by the telephone system.

In the case of the Internet, it’s necessary to convert a domain from a URL to a certain IP address so that communication is possible. This conversion takes place on special servers that work with the specific purpose of keeping the Domain Name System (DNS) in operation, which is a hierarchical system with the purpose of allowing the conversion of URL domains into IP addresses in a decentralized way, as can be seen in the diagram below.

This process is completely transparent to the user who accesses a page on the internet. It happens in several steps using different DNS servers and caching systems to speed up the responses.

In order to simplify the understanding, consider that a request to convert the domain of a URL originates from a computer connected to the internet. Then, it arrives at a server in the DNS system that is capable of fulfilling the requested task. However, at this point a question arises: how to ensure that this domain conversion from a URL to an IP address actually originated from a DNS system server?

It’s possible for malicious intermediaries to modify the response IP address provided by the DNS system midway to the client that requested the conversion. This interference can lead the client’s navigation to another destination than the one requested by the requested URL, opening the possibility of fraudulent actions, as shown in the diagram below.

To prevent this harmful interference, an extra layer of security can be added to the URL domain to IP address conversions in the DNS system, known as Domain Name System Security Extensions (DNSSEC).

To understand DNSSEC in a simple way, imagine that, in the physical world, you received a correspondence by traditional mail. How to ensure that the text contained in the letter was, in fact, created by the sender? You can include a signature in the document that is recognized by the recipient. This way, unsigned letters would be disregarded, and only those signed would be considered legitimate and with the content intact.

This is exactly how DNSSEC prevents fraudulent DNS responses from being used by client computers. Digital signatures sign the IP address responses coming from the DNS server, which are then verified by the recipient, ensuring the authenticity and integrity of the information, as shown in the diagram below.

Compatibility between DNSSEC and the Azion platform

Azion Web Platform is compatible with the DNSSEC specification, supporting its use on websites and applications accelerated by Azion.

DNSSEC uses digital signatures to provide:

• Cryptographic authentication of data.
• Authenticated denial of existence.
• Data integrity.

By verifying the signature associated with existing DNS records such as A, AAAA, CNAME, PTR etc., it’s possible to validate that the requested DNS record originates from the authoritative DNS server and that its original content has been preserved, unchanged along the way.

Unlike the cryptographic security provided by HTTPS over HTTP, the confidentiality of responses isn’t guaranteed by DNSSEC. Data and keys travel in plain text, following the DNS protocol specifications, and are able to be cached, thus preserving the high performance of the service.

For an effective use of DNSSEC:

1. Your Top-Level Domain (TLD) must support the use of DNSSEC.
2. Your zone must be configured with DNSSEC-related resource records.
3. DNSSEC must be enabled at your domain registrar; for example, your DNSSEC should be working.

Hosting a DNSSEC zone with Azion

If your contracted services specify that Azion is responsible for publishing the zone with DNSSEC (authoritative DNS), new records (RRs or Resource Records) will be added to the existing ones. In addition, the following information will be provided:

• Public key (DS).
• Algorithm used in key generation.
• Address of DNS servers.

This way, you can proceed with DNSSEC activation at the competent domain registrar, for example registro.br, establishing a chain of trust.

Each DNS zone has a public/private key pair. The zone’s private key is used to sign DNS data in the zone and generates digital signatures on that data. The private key is kept secret and the public key is available in the DNS zone itself for anyone to retrieve.

To enable signature verification, DNSSEC requires the administration of new Resource Records (RR), in addition to those already in use:

• DNSKEY contains the public key to be used in the verification.
• DS (Delegation Signer) contains the HASH of a DNSKEY record. This record is used by recursive DNS servers to verify the authenticity of the DNSKEY itself.
• RRSIG contains the digital signature of a record.
• NSEC and NSEC3 enable the non-existence response of a queried record, known as authenticated denial of existence, preventing a malicious actor from falsifying a non-existent address response.

General recommendations and considerations

• Before contracting the service, make sure that the TLD registry supports DNSSEC.
• A few days before the scheduled change, it’s recommended to reduce the TTLs of the DNS zone to be transferred, as well as using the TTL of a few minutes in the DNSSEC records (DS and DNSKEY) in order to enable a quick recovery if necessary.
• For the new settings to become effective, wait for a new publication by the person responsible for the TLD.
• Effective propagation and global visibility of the change may take a few days, as it depends on updating the cache of resolvers administered by third parties.

Contact the Sales team to host a DNS zone previously configured with DNSSEC at Azion.