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é.

Comprendre l’utilité passée et les risques actuels du fichier xmlrpc.php, ainsi que les bonnes pratiques pour sécuriser votre site.

Le fichier xmlrpc.php est un composant historique de WordPress. Bien qu’il ait été essentiel il y a quelques années, son utilité a largement diminué avec l’évolution de la plateforme. Ce fichier est aujourd’hui souvent perçu comme une porte dérobée pour les attaques informatiques, rendant sa gestion cruciale pour la sécurité de votre site.

Cependant, ce cas n’est pas isolé. De nombreux outils ou fonctionnalités peuvent devenir obsolètes ou présenter des risques avec le temps. Il est donc indispensable de maintenir une vigilance constante pour identifier et traiter ces failles potentielles.

Dans cet article, nous allons décrire brièvement le rôle historique de xmlrpc.php, examiner les risques qu’il représente et mettre en lumière des solutions pour le désactiver ou le sécuriser. Ceci, tout en soulignant l’importance de l’adoption d’alternatives modernes.

Qu’est-ce que xmlrpc.php ?

Le fichier xmlrpc.php est une interface permettant à WordPress de communiquer avec d’autres services ou applications via le protocole XML-RPC. À l’origine, il facilitait des fonctionnalités comme :

• la publication de contenu via des outils tiers (logiciels de bureautique, scripts automatiques, etc.) ;
• la gestion mobile des sites, à l’image de l’ancienne application WordPress pour smartphones.

Depuis la création de l’API REST de WordPress, plus moderne et sécurisée, le fichier xmlrpc.php a perdu son utilité. Pour la majorité des personnes administrant un site WordPress, il est même désormais considéré comme obsolète.

Pourquoi xmlrpc.php est-il problématique ?

Ce fichier présente aujourd’hui des failles qui en font une cible privilégiée pour les cyberattaques.

• Attaques par force brute : des individus malintentionnés peuvent exploiter le fichier pour tenter un nombre illimité de connexions, en combinant des noms d’utilisateur et mots de passe.
• Amplification des attaques DDoS : certaines fonctionnalités de xmlrpc.php permettent d’envoyer de nombreuses requêtes en un seul appel, multipliant ainsi la charge sur le serveur.
• Exploitation des failles logicielles : si votre WordPress ou vos extensions ne sont pas à jour, ce fichier peut être utilisé pour exécuter des commandes malveillantes.

Comment désactiver xmlrpc.php ?

Heureusement, désactiver ce fichier est à la fois simple et sans impact pour la majorité des sites WordPress. Voici différentes méthodes adaptées à vos besoins.

1. En modifiant le fichier .htaccess (solution préférée)

Si vous avez accès aux fichiers de votre site, vous pouvez empêcher les requêtes vers xmlrpc.php en ajoutant les lignes suivantes dans le fichier .htaccess (situé à la racine de votre site) :

Avantage : méthode directe et légère.

Inconvénient : nécessite une certaine prudence, car une erreur dans le fichier .htaccess peut affecter l’ensemble du site.

• Via un plugin

Vous recherchez une solution clés en main ? Des extensions comme Disable XML-RPC-API permettent de désactiver rapidement xmlrpc.php sans toucher au code.

Avantage : facilité et gain de temps.

Inconvénient : dépendance à un plugin supplémentaire.

• En configurant votre serveur

Pour les personnes administratrices disposant d’un hébergement dédié ou d’un VPS, il est possible de bloquer l’accès à xmlrpc.php au niveau du serveur. Par exemple, sur Apache :

Ou sur Nginx :

Avantage : solution idéale pour les environnements à forte charge.

Inconvénient : requiert des connaissances techniques.

Quelles sont les alternatives à xmlrpc.php ?

Plusieurs solutions simples peuvent être envisagées si vous avez besoin des fonctionnalités offertes par xmlrpc.php.

1. Utiliser l’application mobile WordPress moderne

L’application officielle WordPress pour iOS et Android utilise désormais l’API REST au lieu de xmlrpc.php. Assurez-vous que votre site est configuré correctement pour permettre cette transition. La plupart des hébergements récents, comme ceux proposés par OVHcloud, supportent cette fonctionnalité par défaut.

• Adopter des outils compatibles avec l’API REST

De nombreuses solutions de publication à distance ont été mises à jour pour utiliser l’API REST, qui est plus sécurisée et mieux adaptée aux besoins actuels. Vérifiez si vos outils favoris offrent cette compatibilité et, le cas échéant, mettez-les à jour.

• Sécuriser xmlrpc.php en cas de besoin spécifique (en dernier recours)

Si vous ne pouvez vraiment pas vous passer de xmlrpc.php, il est crucial de limiter son exposition aux menaces. Voici quelques bonnes pratiques :

• restreindre l’accès à certaines adresses IP via .htaccess ou la configuration serveur ;
• utiliser un plugin de sécurité pour limiter les requêtes XML-RPC (ex. le nombre de connexions en un temps donné) ;
• mettre en place une authentification forte, comme l’authentification à deux facteurs, pour renforcer la sécurité des connexions.

Cette solution est considérée comme non recommandée, car elle laisse tout de même une surface d’attaque accessible. Elle doit être réservée aux cas où l’utilisation de xmlrpc.php est indispensable. Gardez aussi à l’esprit que ces ajustements ne remplacent pas une migration vers des outils modernes comme l’API REST.

Protégez votre site WordPress tout en restant à jour

Vous connaissez désormais mieux le rôle historique et les enjeux de sécurité liés au fichier xmlrpc.php. N’oubliez pas que la sûreté de votre site repose sur une vigilance constante : surveillez les mises à jour de WordPress et de ses extensions, lisez attentivement leurs notes de version pour repérer tout changement susceptible d’affecter la sécurité de votre environnement.

Besoin d’un coup de main supplémentaire ? Rejoignez notre communauté sur Discord ou consultez notre documentation WordPress pour aller plus loin dans la sécurisation et l’optimisation de votre site.

Understanding the past usefulness and current risks of the xmlrpc.php file, as well as best practices for securing your website.

The xmlrpc.php file is a historical component of WordPress. Although it was essential a few years ago, its usefulness has greatly diminished as the platform has evolved. This file is now often perceived as a back door for cyberattacks, meaning that it is crucial to manage it to ensure that your website stays secure.

However, this is not an isolated case – many other tools or features can become obsolete or risky over time, so it is important to stay alert to identify and address any potential vulnerabilities.

In this article, we will briefly describe the historical role of xmlrpc.php, examine the risks it poses, and highlight solutions for disabling or securing it. We’ll also emphasise the importance of embracing modern alternatives.

What is xmlrpc.php?

The xmlrpc.php file is an interface for WordPress to communicate with other services or applications via the  XML-RPC protocol. Initially, it facilitated features such as:

• Publishing content via third-party tools (e.g. desktop software, automated scripts)
• Mobile website management, such as the old WordPress app for smartphones

Since the creation of the more modern and secure WordPress REST API, the xmlrpc.php file has lost its usefulness. For most people who manage a WordPress website, it is now even considered obsolete.

Why is xmlrpc.php problematic?

This file now has vulnerabilities that make it a prime target for cyberattacks.

• Brute-force attacks: individuals can exploit the file to attempt an unlimited number of connections, using a combination of usernames and passwords.
• Amplification of DDoS attacks: certain features of xmlrpc.php allow multiple requests to be sent in one go, thus increasing the load on the server.
• Exploitation of software vulnerabilities: if your WordPress or plugins are not up to date, this file can be used to run malicious commands.

How do I disable xmlrpc.php?

Fortunately, disabling this file is simple and does not affect most WordPress websites. Here are some different methods, depending on your needs.

1. Modify the .htaccess file (preferred solution)

If you have access to files on your site, you can prevent queries to xmlrpc.php by adding the following lines to the .htaccess file (located at the root of your site):

Advantage: direct and light-handed method.

Disadvantage: requires some care, as an error in the .htaccess file can affect the entire website.

• Via a plugin

Looking for a turnkey solution? Extensions like Disable XML-RPC-API allow you to quickly disable xmlrpc.php without touching the code.

Advantage: easy and time-saving.

Disadvantage: reliance on an additional plugin.

• Configure your server

For administrators with a dedicated hosting plan or a VPS, it is possible to block access to xmlrpc.php at the server level. For example, on Apache:

Or on Nginx:

Advantage: ideal solution for high-load environments.

Disadvantage: requires technical knowledge.

What are the alternatives to xmlrpc.php?

There are several simple solutions you can consider if you need the functionality offered by xmlrpc.php.

1. Use the modern WordPress mobile app

The official WordPress application for iOS and Android now uses the REST API instead of xmlrpc.php. Make sure your site is configured correctly to allow this transition. Most recent web hosting plans, such as those offered by OVHcloud, support this feature by default.

• Adopt tools compatible with the REST API

Many remote publishing solutions have been updated to use the REST API, which is more secure and better suited to current needs. Check if your favourite tools offer this compatibility, and update them if necessary.

• Secure xmlrpc.php in case you specifically need it (as a last resort)

If you really can’t do without xmlrpc.php, it’s crucial to limit its exposure to threats. Here are some best practices:

• restrict access to certain IP addresses via .htaccess or server configuration
• use a security plugin to limit XML-RPC requests (e.g. the number of connections in a given time)
• implement strong authentication, such as two-factor authentication, to enhance connection security

This solution is not recommended, as it still leaves an accessible attack surface. It should be reserved for cases where the use of xmlrpc.php is still essential. Also keep in mind that these adjustments are not a substitute for migrating to modern tools like the REST API.

Protect your WordPress website while staying up to date

Hopefully, you are now more familiar with the historical role of xmlrpc.php and its associated security issues. Keep in mind that keeping your website safe requires constant vigilance – so check for updates to WordPress and its plugins, and read their release notes carefully for any changes that could affect the security of your environment.

Need some extra help? Join our community on Discord, or check out our WordPress documentation to go even further in securing and optimising your site.