You never see it, but without the DNS, no website would be accessible, no email could be delivered, and no online service would work correctly.

At the heart of this system are DNS records, which structure how services are exposed on the Internet. These records evolve alongside modern web architectures, and at OVHcloud, this has resulted in support for SVCB and HTTPS records.

To better understand these innovations, let’s look at the main types of DNS records and their roles.

The DNS in a few words

The Domain Name System (DNS) translates a domain name into an IP address that is understandable by machines. When a user enters a web address (such as “www.example.com”), a request is sent to identify the corresponding server.

This phase, known as DNS resolution, uses different types of records that each fulfil a specific role.

The most common DNS records

Some records are essential when configuring a domain. Here are the main types present in a DNS zone.

A and AAAA: make a website accessible

For a website to be reachable, its domain name must be associated with an IP address. This is where A (IPv4) and AAAA (IPv6) records come in.

They form the basis of DNS resolution and allow browsers to reach the server hosting the site.

CNAME: creates an alias between two domain names

A CNAME record allows one domain name to point to another, without directly associating it with an IP address. For example, “blog.example.com” can link to “example.com”, which avoids duplicating the configuration.

⚠️ Note: a CNAME cannot be configured at the root of a domain (e.g. “example.com”). It is only used on subdomains, such as “blog.example.com”.

MX: manages the receipt of emails

MX (Mail Exchange) records indicate which servers should handle emails being sent to a domain. They play a central role in distributing messages and in the reliability of messaging.

TXT: verifies a domain and enhances security

TXT records allow additional information to be linked to a domain. They are particularly used to prove ownership to external services and to secure emails.

Mechanisms such as SPF, DKIM, or DMARC rely on TXT records to limit identity theft and spam.

SVCB and HTTPS: what are these new DNS records for?

During DNS resolution, the browser obtains the information needed to contact a server.

SVCB (Service Binding) and HTTPS records enrich this step by indicating more precisely how to access the service.

They may mention the supported protocols (HTTP/2 or HTTP/3), the preferred server, or certain technical parameters intended to optimise the connection.

By transmitting this information during the resolution, they limit certain intermediate exchanges between the browser and the server. This mechanism helps to improve the performance and loading speed of websites.

A key use case: the alias at the root of the domain

As mentioned, a CNAME record cannot be configured at the root of a domain (such as “example.com”). This constraint of the DNS required the use of alternative solutions when it was necessary to point a main domain to an external service.

HTTPS and SVCB records remove this limitation. They offer the option to indicate that a web service located at the root of the domain is provided by another name, similar to a CNAME, while adhering to DNS rules.

Here’s an example: a company broadcasts its site via a CDN accessible at the address “example.cdn-provider.net”, while retaining “example.com” as the access point. Thanks to a HTTPS record, the browser can be directed to the CDN service without a visible redirection for the user or a complex DNS configuration.

⚠️ However, these mechanisms rely on newer features, so their support may vary depending on the browsers and operating systems, particularly in older environments.

What benefits do these new records offer?

By enriching the DNS resolution phase, SVCB and HTTPS records can direct clients more accurately towards suitable services.

This helps to reduce latency, improve perceived performance, and strengthen consistency across browsers, protocols, and infrastructures.

These records also provide greater flexibility in DNS configuration, particularly for environments integrating CDNs, external platforms, or distributed cloud architectures.

How can I configure my SVCB and HTTPS records with OVHcloud?

SVCB and HTTPS records are available from your OVHcloud control panel.

To configure them:

1. Go to the “Domain Names” section
2. Select the relevant domain
3. Access the “DNS Zone” tab
4. Add a new SVCB or HTTPS record

Depending on your situation, you may need to adjust the associated settings (priority, target, service-specific options). For detailed information on managing DNS records, please consult our dedicated guide.

In summary: a more flexible and effective DNS

The DNS remains an essential pillar of the internet and continues to evolve to adapt to newer architectures.

With SVCB and HTTPS records, it is now possible to optimise service exposure, simplify certain configurations (particularly at the root of the domain), and improve performance from the resolution stage.This is a discreet yet strategic technical development in response to the growing demands for speed, security, and flexibility.

On ne le voit jamais. Pourtant, sans le DNS, aucun site web ne serait accessible, aucun e-mail ne pourrait être distribué, aucun service en ligne ne fonctionnerait correctement.

Au cœur de ce système se trouvent les enregistrements DNS, qui structurent la manière dont les services sont exposés sur Internet. Ils évoluent avec les architectures web modernes. Chez OVHcloud, cela se traduit notamment par la prise en charge des enregistrements SVCB et HTTPS.

Pour mieux comprendre ces nouveautés, revenons sur les principaux enregistrements DNS et leur rôle.

Le DNS en quelques mots

Le Domain Name System (DNS) traduit un nom de domaine en adresse IP compréhensible par les machines. Lorsqu’un internaute saisit une adresse web (telle que « www.exemple.com »), une requête est ainsi envoyée pour identifier le serveur correspondant.

Cette phase, appelée résolution DNS, s’appuie sur différents types d’enregistrements, chacun remplissant un rôle précis.

Les enregistrements DNS les plus courants

Certains enregistrements sont incontournables dans la configuration d’un domaine. Voici les principaux types présents dans une zone DNS.

A et AAAA : rendre un site accessible

Pour qu’un site soit joignable, son nom de domaine doit être associé à une adresse IP. C’est le rôle des enregistrements A (IPv4) et AAAA (IPv6).

Ils constituent la base de la résolution DNS et permettent aux navigateurs d’atteindre le serveur qui héberge le site.

CNAME : créer un alias entre deux noms de domaine

Un enregistrement CNAME permet de faire pointer un nom de domaine vers un autre, sans l’associer directement à une adresse IP. Par exemple, « blog.exemple.com » peut renvoyer vers « exemple.com », ce qui évite de dupliquer la configuration.

⚠️ À noter : un CNAME ne peut pas être configuré à la racine d’un domaine (« exemple.com »). Il ne s’utilise que sur des sous-domaines, comme « blog.exemple.com ».

MX : gérer la réception des e-mails

Les enregistrements MX (Mail Exchange) indiquent quels serveurs doivent traiter les e-mails destinés à un domaine. Ils jouent un rôle central dans la distribution des messages et dans la fiabilité de la messagerie.

TXT : vérifier un domaine et renforcer la sécurité

Les enregistrements TXT permettent d’associer des informations supplémentaires à un domaine. Ils sont notamment utilisés pour prouver sa propriété auprès de services externes et pour sécuriser les e-mails.

Des mécanismes comme SPF, DKIM ou DMARC reposent sur des enregistrements TXT afin de limiter l’usurpation d’identité et le spam.

SVCB et HTTPS : à quoi servent ces nouveaux enregistrements DNS ?

Lors de la résolution DNS, le navigateur obtient les informations nécessaires pour contacter un serveur.

Les enregistrements SVCB (Service Binding) et HTTPS enrichissent cette étape en indiquant plus précisément comment accéder au service.

Ils peuvent notamment mentionner les protocoles pris en charge (HTTP/2 ou HTTP/3), le serveur à privilégier ou encore certains paramètres techniques destinés à optimiser la connexion.

En transmettant ces informations dès la résolution, ils limitent certains échanges intermédiaires entre le navigateur et le serveur. Ce mécanisme contribue à améliorer la performance et la rapidité de chargement des sites web.

Un cas d’usage clé : l’alias à la racine du domaine

Comme vu précédemment, un enregistrement CNAME ne peut pas être configuré à la racine d’un domaine (comme « exemple.com »). Cette contrainte historique du DNS obligeait à utiliser des solutions alternatives lorsqu’il fallait faire pointer un domaine principal vers un service externe.

Les enregistrements HTTPS et SVCB permettent de lever cette limitation. Ils offrent la possibilité d’indiquer qu’un service web situé à la racine du domaine est fourni par un autre nom, de manière similaire à un CNAME, tout en respectant les règles du DNS.

Prenons un exemple : une entreprise diffuse son site via un CDN accessible à l’adresse « exemple.cdn-provider.net », en conservant « exemple.com » comme point d’accès. Grâce à un enregistrement HTTPS, le navigateur peut être orienté vers le service du CDN sans redirection visible pour l’internaute ni configuration DNS complexe.

⚠️ Ces mécanismes reposent toutefois sur des fonctionnalités récentes. Leur prise en charge peut donc varier selon les navigateurs et les systèmes d’exploitation, en particulier dans des environnements plus anciens.

Quels bénéfices pour ces nouveaux enregistrements ?

En enrichissant la phase de résolution DNS, les enregistrements SVCB et HTTPS permettent une orientation plus précise des clients vers les services adaptés.

Ils contribuent ainsi à réduire la latence, à améliorer la performance perçue, ainsi qu’à renforcer la cohérence entre navigateurs, protocoles et infrastructures.

Ils offrent également davantage de souplesse dans la configuration DNS, notamment pour les environnements intégrant des CDN, des plateformes externes ou des architectures cloud distribuées.

Comment les configurer chez OVHcloud ?

Les enregistrements SVCB et HTTPS sont disponibles depuis votre espace client.

Pour les configurer :

1. rendez-vous dans la section « Noms de domaine » ;
2. sélectionnez le domaine concerné ;
3. accédez à l’onglet « Zone DNS » ;
4. ajoutez un nouvel enregistrement de type SVCB ou HTTPS.

Selon votre situation, il peut être nécessaire d’adapter les paramètres associés (priorité, cible, options spécifiques au service). Pour des informations détaillées sur la gestion des enregistrements DNS, consultez notre guide dédié.

En résumé : un DNS plus flexible et performant

Le DNS reste un pilier essentiel d’Internet et continue d’évoluer pour s’adapter aux architectures récentes.

Avec les enregistrements SVCB et HTTPS, il devient possible d’optimiser l’exposition des services, de simplifier certaines configurations (notamment à la racine du domaine) et d’améliorer la performance dès la phase de résolution.Il s’agit d’une évolution technique discrète, mais stratégique, face aux exigences croissantes de rapidité, de sécurité et de flexibilité.

DNS (Domain Name System) is the “phone book” of the internet – meaning that it translates a human-readable domain name (like ovhcloud.com) into a computer-readable IP (54.39.46.56).

The DNS was designed when the internet first started. At that time, the Internet was not as big, or critical as it is today.
DNS, therefore, was designed on a principle of trust. As a result, DNS is not really secure and has vulnerabilities; such as DNS cache poisoning.

This kind of attack allows the attacker to enter invalid information into a DNS resolver cache, so that following DNS queries
return invalid data. This enables the attacker to redirect you to a fake website.

To secure the DNS zone, the DNSSEC (Domain Name System Security Extensions) has been designed – based on public key encryption – to verify and validate the integrity and the origin of DNS data.

How DNSSEC works

The goal of DNSSEC is to allow resolvers to check the origin and integrity of a DNS answer. DNSSEC has been
designed with the following constraints:

• It has to be an extension of DNS so a non-DNSSEC client can work with a DNSSEC server and vice-versa.
• The data is protected, but the communication channels are not.
• It must be based on public key encryption

Since DNSSEC, by design, should not change the DNS protocol, new types of DNS records, Resource Records, have been added to handle cryptography.

RRSIG

RRSIG contains the cryptographic signature of a record set. With DNSSEC, each record set is followed by a RRSIG containing,
among others, the signature in base64 of the record set.

For example:

$ dig A +dnssec dnstests.ovh
dnstests.ovh.        3600    IN  A   213.186.33.5
dnstests.ovh.        3600    IN  RRSIG   A 8 2 3600 20200925080215 20200826080215 50238 dnstests.ovh. AUz7u4Sq0EkSUq5kR0beowmMuscbzGdb3NI/OhCG8Ow0Z3CqgG0/94eR     6pbG7YJwvCFBU1bQDklLYEfc4mg41VeAVY4xPSv0O76/hEZsVKcBOGlT nKy3wV4ft8ykV1Jl+5q2eJAaZRoBSvHuRItbM2HCyghhDW0gKBy5rqOq BlM=

The RRSIG record contains common DNS fields (domain name, ttl, etc.), but also other fields

• A: Type covered
• 8: Algorithm used to sign
• 2: Number of labels of the RRSET (here 2: 1 for dnstests and 1 for OVH)
• 3600: Original TTL
• 20200925080215: Signature expiration date
• 20200826080215: Signature inception date
• 50238: KeyTag (non uniq indentifier)
• dnstests.ovh.: Signer’s name
• AUz7u4Sq0EkSUq5k…: => The Signature

RRSIG signature

The signature is calculated according to the following formula:

signature = sign( RRSIG_RDATA | RR(1) | RR(2)... )

where

|  is used for concatenation
RRSIG_RDATA is the RRSIG in wire format
RR(*) = owner | type | class | TTL | RDATA length | RDATA

DNSKEY

In order to validate, a RRSIG resolver needs to know the public key used to sign the record set.

This is stored in a record named DNSKEY

$ dig DNSKEY +multi dnstests.ovh
dnstests.ovh.        3458 IN DNSKEY 256 3 8 (
                    AwEAAc9juwZVMUrdjPIxMPuOk+ZnVhv+i16B3TTxj1Ft
                    5ABDEbiXyfljJopTCQgmJ4EcNDubhZKezTqGsbpaErw8
                    8yqFwzviv2/U9Mw+Vq1zbS29Hl6XzyWPlnYryXcyVDEw
                    OZlsK0hw6d7A6Xcjjf2srnxpQHpO9pG+etFZxSSEV49j
                    ) ; ZSK; alg = RSASHA256 ; key id = 50238
dnstests.ovh.        3458 IN DNSKEY 257 3 8 (
                    AwEAAZ5F0TSR8PWTrADtdlTcuGWBZ1ehOHy7RtX/ZyA6
                    WQSU+59I8PFWQ6ddD4FX7LfNcaPSd10vjZKmGT9fB8uf
                    IY9xHHrH2zGc6jEI7TkqDOjutVRsBhhis+AO/HDjL9i0
                    tpyoCX3/wHVZ9U0iOIHaR4+vlVJfja6EvuL4s0zhzaY0
                    amP1R8af0E1Rcvyi9S6fFOtECZOrqKlwI9OPQneQ2gD4
                    uXWg97o1kuBvxSg/Ze5NsAIsJu3oShxBPUNmW6hwP8FM
                    tbmft4MqpJ3xiI03FN2t2PwgO3cvCYlyBJRZqo9nqLAz
                    yYheVdoMuBP024bXF1HFDo2n7jZMuDrW7mMfPK8=
                    ) ; KSK; alg = RSASHA256 ; key id = 44329

DNSKEY record contains common DNS fields (domain name, ttl, etc.), but also other fields.

• 256 or 257: Flags. A value of 256 indicates that the DNSKEY contains a ZSK and a value of 257 indicates that it contains a KSK.
• 3: Protocol (Must be equal to 3 otherwise record is not valid)
• 8: Algorithm
• AwEAAc9…; Public key

In summary, when a resolver requests a given record type, it receives the set of records and the associated RRSIG. It then had to request the DNSKEY to validate the response.

ZSK

Each zone signed with DNSSEC has a key named ZSK used to sign the whole record set.

If we trust the ZSK, we know that we can trust all records in the zone. But how do we validate the ZSK?

KSK

In the same way that the ZSK is used to sign the record set, the DNSSEC use another key – the KSK (Key Signing Key) – which is used to sign the ZSK DNSKEY.

So let’s imagine we want to retrieve and validate an A record for domain name dnstests.ovh.

First we ask for A:

$ dig A +dnssec dnstests.ovh
dnstests.ovh.        3283    IN  A   213.186.33.5
dnstests.ovh.        3283    IN  RRSIG   A 8 2 3600 20200925080215 20200826080215 50238 dnstests.ovh. AUz7u4Sq0EkSUq5kR0beowmMuscbzGdb3NI/OhCG8Ow0Z3CqgG0/94eR 6pbG7YJwvCFBU1bQDklLYEfc4mg41VeAVY4xPSv0O76/hEZsVKcBOGlT nKy3wV4ft8ykV1Jl+5q2eJAaZRoBSvHuRItbM2HCyghhDW0gKBy5rqOq BlM=

Then we ask for DNSKEY:

$ dig DNSKEY +multi +dnssec dnstests.ovh
dnstests.ovh.        2954 IN DNSKEY 257 3 8 (
                AwEAAZ5F0TSR8PWTrADtdlTcuGWBZ1ehOHy7RtX/ZyA6
                WQSU+59I8PFWQ6ddD4FX7LfNcaPSd10vjZKmGT9fB8uf
                IY9xHHrH2zGc6jEI7TkqDOjutVRsBhhis+AO/HDjL9i0
                tpyoCX3/wHVZ9U0iOIHaR4+vlVJfja6EvuL4s0zhzaY0
                amP1R8af0E1Rcvyi9S6fFOtECZOrqKlwI9OPQneQ2gD4
                uXWg97o1kuBvxSg/Ze5NsAIsJu3oShxBPUNmW6hwP8FM
                tbmft4MqpJ3xiI03FN2t2PwgO3cvCYlyBJRZqo9nqLAz
                yYheVdoMuBP024bXF1HFDo2n7jZMuDrW7mMfPK8=
                ) ; KSK; alg = RSASHA256 ; key id = 44329
dnstests.ovh.        2954 IN DNSKEY 256 3 8 (
                AwEAAc9juwZVMUrdjPIxMPuOk+ZnVhv+i16B3TTxj1Ft
                5ABDEbiXyfljJopTCQgmJ4EcNDubhZKezTqGsbpaErw8
                8yqFwzviv2/U9Mw+Vq1zbS29Hl6XzyWPlnYryXcyVDEw
                OZlsK0hw6d7A6Xcjjf2srnxpQHpO9pG+etFZxSSEV49j
                ) ; ZSK; alg = RSASHA256 ; key id = 50238
dnstests.ovh.        2954 IN RRSIG DNSKEY 8 2 3600 (
                20200925080215 20200826080215 44329 dnstests.ovh.
                k/huKVd5Skc8PE1CgHl1/MCEjZs6hH1DlLYGHZxG97YK
                YBSwvWQoXGG6ObZKJYCWVqDJWvdz81K7XHLvK34g3AwB
                NyI62Aw00GiaJzpFCkKU+jTVPeVvDKpAKGQxPziWCL/4
                Buj230YyDm38V4amxAeBOz5FcvD8eDu6XYMx4ygvJ3XF
                M7zojtsbqwg7IBJPJUURNfpQi8MbJivelXbh2CJACteB
                8zd2dsj0eZRTLulC15qr7R7zBQqJ8CVuPAVHBYfy2Nu/
                VE2QSe2Q4zzns9TUH/6/g9f8RDMNDhT+Z1lbsaJg9EzH
                x4bqLfjEjnqhrzdS/Fc02e7bILe9YGQ5SQ== )
dnstests.ovh.        2954 IN RRSIG DNSKEY 8 2 3600 (
                20200925080215 20200826080215 50238 dnstests.ovh.
                nrA3yOddNl3695pl8JAwDkjV8oL5VdKyJO2fIrOPSFVr
                EbEVHHxwxSXqlvhV8J2NmB80oV4mM+bzzZUToIWbKd0p
                XOUDz38lu7Ye4uYrJi4/tMSqMy2HUP96xGQUze96riMo
                hiGmOJp6jd+J3LRmO4dOLXW7WB+Q9dwEANjH4/M= )

We are able to validate the record set with RRSIG and ZSK DNSKEY, then we are able to validate ZSK DNSKEY with RRSIG and KSK DNSKEY.

We are now able to trust records from our DNS zone, but we need to be able to transfer the trust of our child zone to its parent.

Delegation Signer Records

An essential characteristic of DNS is its hierarchical structure. DNSSEC uses this particularity to transfer trust from parent
zone to child zone. This record, named DS (Delegation Signer) contains the hash: KSK DNSKEY.
If the resolver finds DS records in the parent zone, they know that the child-zone must be DNSSEC signed, and will be able to validate
DNSSKEY on the child zone using the DS record.

$ dig DS dnstests.ovh
dnstests.ovh.        172800  IN  DS  44329 8 2 6BDEC6C046B608077A198E19F2C241EB6B05565DE9B0C63DA718DCA2 8F012979

DS records contains common DNS fields (domain name, ttl, etc) but also other fields.

• 44329: KeyTag
• 8: Algorithm
• 2: Digest Type
• 6BDEC6…: Digest

DS Digest

digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);

where

| is used for concatenation
DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key

The Chain of Trust

We are now able to fully validate a DNS answer, up to the root DNS servers:

Denial of existence

Imagine we want to resolve “doesnotexist.dnstests.ovh.”. The resolver will send us back to: domain doesn’t exist. So, how can we
validate this denial of existence?

DNSSEC solves this problem by adding two new types of record: NSEC and NSEC3.

Let’s imaging our dnstests.ovh. has this content

$TTL 3600
@    IN SOA dns10.ovh.net. tech.ovh.net. (2020082603 86400 3600 3600000 60)
        IN NS     ns10.ovh.net.
        IN NS     dns10.ovh.net.
        IN A      213.186.33.5
subdomain        IN A      213.186.33.5
subdomain        IN TXT      dnssec
www        IN A      213.186.33.5

NSEC

NSEC works by returning the “next secure” record.

$ dig A +dnssec doesnotexist.dnstests.ovh
;; status: NXDOMAIN
dnstests.ovh.        18  IN  NSEC    subdomain.dnstests.ovh. A NS SOA RRSIG NSEC DNSKEY

The NSEC record contains common DNS fields (domain name, ttl, etc), but also other fields:

• subdomain.dnstests.ovh: next domain name (in alphabetical order)
• A NS SOA RRSIG NSEC DNSKEY: types associated with the current request. It tells us that a current domain name
  dnstests.ovh. only have A NS SOA RRSIG NSEC DNSKEY records.

The problem with NSEC is that it’s possible to enumerate all entries in a zone. Let’s have a look:

$ dig A +dnssec a.dnstests.ovh
dnstests.ovh.        60  IN  NSEC    subdomain.dnstests.ovh. A NS SOA RRSIG NSEC DNSKEY

It tells us that the next subdomain is subdomain.dnstests.ovh., so we can get the next subdomain by adding a letter to the subdomain.

$ dig A +dnssec subdomaina.dnstests.ovh
subdomain.dnstests.ovh.        60  IN  NSEC    www.dnstests.ovh. A TXT RRSIG NSEC

In this way, we can obtain the complete contents of the zone.

NSEC3

NSEC3 was added to prevent an attacker from walking the zone. It works the same way as the NSEC, but it constructs a chain of hashed and not plain text resource records. In the case of NXDOMAIN, it returns the hash before and after (in alphanumerical order) the hash of a requested domain name.

$ dig A +dnssec doesnotexist.dnstests.ovh.
;; status: NXDOMAIN
dnstests.ovh.        60  IN  SOA dns10.ovh.net. tech.ovh.net. 2020082604 86400 3600 3600000 60
E9NLBQ2G28AO5L4JR8UBJR3QODN9PE63.dnstests.ovh. 60 IN NSEC3 1 0 8 1981905ED56A6CE2 SA9BM55PF37IOPN95F1PCIG733K2SQIJ A TXT RRSIG
SA9BM55PF37IOPN95F1PCIG733K2SQIJ.dnstests.ovh. 60 IN NSEC3 1 0 8 1981905ED56A6CE2 BKF3VT8D74NQJVTR798OI8E6TP8C70F2 A NS SOA RRSIG DNSKEY NSEC3PARAM

NSEC3 record contains common DNS fields (domain name, ttl, etc), but also other fields:

• 1: Hash algorithm
• 0: Flags
• 5: Number of iterations for hash
• C149E2F3213D3F51: Salt value
• SA9BM55PF37IOPN95F1PCIG733K2SQIJ: Next hashed domain name
• A TXT RRSIG: Types associated with current request

When a resolver asks for a domain and received a NXDOMAIN they can compute the hash of the requested domain and compare it (alphanumerically) to the hashes received in NSEC3.

For example, for dnstests.ovh. we have:

hash(dnstests.ovh.) = SA9BM55PF37IOPN95F1PCIG733K2SQIJ
hash(www.dnstests.ovh.) = BKF3VT8D74NQJVTR798OI8E6TP8C70F2
hash(subdomain.dnstests.ovh.) = E9NLBQ2G28AO5L4JR8UBJR3QODN9PE63
hash(doesnotexist.dnstests.ovh.) = KSR3B14N7QTGS3536MR6N1AOA97LORK3

If we look at NSEC3 records we got during dig:

E9NLBQ2G28AO5L4JR8UBJR3QODN9PE63.dnstests.ovh. 60 IN NSEC3 1 0 8 1981905ED56A6CE2 SA9BM55PF37IOPN95F1PCIG733K2SQIJ A TXT RRSIG

Means than subdomain.dnstests.ovh. has A, TXT and RRSIG record types and that next subdomain is dnstests.ovh.

SA9BM55PF37IOPN95F1PCIG733K2SQIJ.dnstests.ovh. 60 IN NSEC3 1 0 8 1981905ED56A6CE2 BKF3VT8D74NQJVTR798OI8E6TP8C70F2 A NS SOA RRSIG DNSKEY NSEC3PARAM

Means than dnstests.ovh. has A, NS, SOA, RRSIG, DNSKEY and NSEC3PARAM record types and that next subdomain is www.dnstests.ovh.

So we have received the information telling us that doesnotexist.dnstests.ovh. does not exist (NXDOMAIN),
the hash just before (in alphanumeric order): E9NLBQ2G28AO5L4JR8UBJR3QODN9PE63, the hash just after SA9BM55PF37IOPN95F1PCIG733K2SQIJ, so we know that NXDOMAIN is valid.

To conclude

DNSSEC is an extension of the DNS used to secure the DNS data, not the communication channel. It means that DNSSEC does not encrypt the zone, but it ensures that the received zone was sent, and has not been modified, by its owner. DNS records are cryptographically signed, so DNSSEC introduces the new DNS record types for cryptography.

One of the biggest advantages of DNSSEC is that it’s compatible with the DNS – but to be secure the whole chain of trust must mean using the DNSSEC from child to root.

A bit of Context

DNS protocol has been a key component of the functionality of the Internet for the last 30 years, and still is. It associates domain names (e.g. www.ovh.com) to the numerical IP addresses (e.g. 198.27.92.1) needed for locating and identifying websites or other computer services. This protocol is usually described as the web directory.

As the Internet, and technologies running it, are quickly evolving, of course the DNS protocol has already evolved many times along its 30 years of existence.

Today, we especially have a look on its first extension, called EDNS [2], which is at the heart of the so-called DNS Flag Day.

EDNS, What’s this thing ?

This extension added new functionalities to the ones bring by the DNS protocol.

Ten years ago, this extension was key to give birth to the DNSSEC [3] which is solving some security issues around DNS protocol by securing certain kinds of information provided by the DNS through cryptographically signed responses.

Unfortunately, many DNS servers in the world don’t have this EDNS extension. Sometimes, the extension doesn’t correctly comply with the standards, or, even worst, is simply blocked !

To guarantee the stability of the domain names resolution (i.e. the translation of a domain name into an IP address), resolver’s infrastructures had to heap up numerous modifications to manage all known exceptions.

2019 February 1st – Day one

These exceptions degrade significantly Domain Names resolution, and therefore directly the user experience. Moreover, it’s complicated to maintain so many patches over time.

For all these reasons, the DNS Flag Day has been created. From the first day of 2019 February, exceptions implemented in the resolvers will progressively be removed.

You will probably not notice much difference on D-day, but as updates are made to the DNS servers, resolutions may be compromised.

Who will be impacted?

OVH infrastructures are compatible with EDNS, no impact is to be expected if you use the DNS services managed by OVH.

If your DNS zone is not hosted on OVH DNS, we recommend you to ensure your service provider has done the necessary.

In case you are not able to be ready by February 1st, you still have the possibility to migrate your DNS zone on our infrastructure.

Our guides:

• Editing the DNS servers for an OVH domain name
• Editing an OVH DNS zone

Am I being impacted?

The easier way for you to be sure is by checking if your domain name is compatible via the tools provided by DNSFlagDay. An online tool is available :DNS Flag Day is a cross organization effort and can be trusted.

To go further

The .cz extension registry has put online a tool to scan any extension and check its compatibility with resolution using EDNS:

The AFNIC has carried out a test for the .fr TLD. In their results, available here, we see that 3.49% of .fr domains will probably be impacted.

• [1] DNS, RFC1034 & RFC1035
• [2] EDNS, RFC2671 & RFC6891
• [3] DNSSEC, RFC4033