c-ares : la bibliothèque C de résolution DNS asynchrone, entre RFC récentes et releases signées
c-ares/c-ares offre une implémentation open source exploitable en conditions réelles avec une structure réutilisable.
En bref
- De quoi s’agit-il ?
- Analyse du dépôt c-ares/c-ares : résolveur DNS en C89 sous MIT, couverture des RFC 1035 à 9460, durcissement par OSS Fuzz, signatures GPG et provenance SLSA sur chaque tarball.
- À qui s’adresse-t-il ?
- c-ares vise les développeurs C et C++ qui veulent des requêtes DNS sans blocage sur une base portable de Linux à iOS ; il n'a pas d'intérêt direct pour une application de haut niveau qui passe par le résolveur du système. Avant l'intégration, lisez FEATURES.md pour confirmer que les types d'enregistrements dont vous avez besoin sont couverts, et prenez l'habitude de vérifier chaque tarball par la commande gpg --verify documentée avec les clés de Daniel Stenberg et Brad House.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 15 jours.
- En quel langage est-il écrit ?
- Principalement C, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 14 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Un résolveur stub en C89 qui prétend faire mieux que celui du système
c-ares est une bibliothèque C de résolution DNS de type stub, qui expose des interfaces de requêtes asynchrones en masquant les détails du protocole. Le README la destine aux applications qui doivent interroger le DNS sans bloquer ou enchaîner plusieurs requêtes en parallèle. Le projet assume une ambition large : faire un meilleur résolveur que celui du système hôte, quel qu'il soit, et le README recommande même son usage dans toute application réseau, au-delà du seul besoin d'asynchronisme.
Les faits techniques donnent le ton : c-ares se compile avec n'importe quel compilateur C89, ce qui limite fortement les dépendances, et couvre Linux, FreeBSD, OpenBSD, macOS, Solaris, AIX, Windows, Android et iOS. La bibliothèque a plus de vingt ans d'existence et reste activement maintenue. Sous licence MIT, elle s'insère aussi bien dans du logiciel libre que commercial, avec 2184 étoiles et 682 forks au moment de l'indexation.
Couverture RFC 1035 à 9460 : SVCB, HTTPS, TLSA et CAA dans la liste
La liste des RFC et propositions prises en charge est publiée dans le README, et elle dépasse le noyau historique. On y trouve la base RFC 1035, EDNS0 via les RFC 2671 et 6891, l'IPv6 avec les enregistrements AAAA de la RFC 3596, la sélection de serveurs SRV de la RFC 2782 et les pointeurs NAPTR de la RFC 3403.
Les ajouts récents ont leur poids pour des usages modernes : la RFC 6698 apporte TLSA pour DANE, la RFC 9460 couvre les enregistrements SVCB et HTTPS, la RFC 7553 les URI, la RFC 6844 les enregistrements CAA utiles aux politiques de certificats. Le détail des capacités par type d'enregistrement reste dans le fichier FEATURES.md, que le README renvoie explicitement à consulter.
Parseurs sûrs, OSS Fuzz, Coverity et SonarCloud : le dispositif de durcissement
Le projet revendique un accent sécurité assumé : des parseurs et constructeurs de données sûrs sont utilisés dans tout le code pour éviter les pièges classiques des bibliothèques C, là où un excès de confiance dans un buffer se paie cher. Les tests automatisés font tourner des analyseurs statiques et dynamiques en continu.
Les badges du README rendent ce dispositif vérifiable de l'extérieur : OSS Fuzz fuzz le projet en permanence, Coverity et SonarCloud analysent le code, Coveralls suit la couverture, et le projet figure dans le programme CII Best Practices. Pour une bibliothèque destinée à traiter des réponses DNS forgées par des tiers, ce niveau de surveillance continue fait partie du produit, pas du folklore.
Clés GPG de Daniel Stenberg et Brad House : vérifier un tarball avant compilation
Chaque archive c-ares-X.Y.Z.tar.gz possède un fichier détaché c-ares-X.Y.Z.tar.gz.asc. Le README publie les clés GPG primaires des deux release managers : 27EDEAF22F3ABCEB50DB9A125CC908FDB71E12C2 pour Daniel Stenberg et DA7D64E4C82C6294CB73A20E22E3D13B5411B7CA pour Brad House, avec la commande d'import depuis hkps://keyserver.ubuntu.com.
La vérification tient en une ligne : gpg -v --verify c-ares-1.29.0.tar.gz.asc c-ares-1.29.0.tar.gz, l'exemple du README montrant une signature RSA SHA512 correcte assortie de l'avertissement habituel sur la confiance non certifiée. Ces archives signées se trouvent dans les archives de release de c-ares.org, le dépôt GitHub servant de référence pour l'historique complet des révisions.
Provenance SLSA avec slsa-verifier : le second chemin d'intégrité
Au-delà des signatures GPG, le projet génère une provenance SLSA pour ses releases, ce qui permet de vérifier que l'artefact téléchargé provient bien du dépôt prévu et d'une construction conforme. Le README donne la marche à suivre avec slsa-verifier.
L'exemple est concret pour la v1.34.3 : télécharger c-ares-1.34.3.intoto.jsonl et c-ares-1.34.3.tar.gz depuis les releases GitHub, puis lancer slsa-verifier verify-artifact avec --provenance-path, --source-uri github.com/c-ares/c-ares et --source-tag v1.34.3. La sortie attendue confirme la signature contre une entrée du registre Rekor et identifie le builder GitHub. Deux mécanismes indépendants pour un même objectif, c'est suffisamment rare pour être noté.
De v1.34.6 à v1.34.8 : lire le rythme des releases avant de figer une version
Les releases visibles dans les métadonnées dessinent un rythme irrégulier : v1.34.6 le 8 décembre 2025, puis un trou de sept mois, puis v1.34.7 et v1.34.8 les 6 et 7 juillet 2026, à un jour d'intervalle. Ce profil plaide pour figer une version précise côté intégration plutôt que de suivre main, les patchs successifs pouvant modifier le comportement entre deux tags.
Le dépôt affiche 70 tickets ouverts, ce qui reste modeste pour une bibliothèque de cette diffusion. Le README précise que les évolutions suivent à la fois les RFC DNS récentes et les pratiques de codage C contemporaines, signe que le projet considère la modernisation du code comme une tâche de fond, pas comme une refonte.
GitHub Issues, liste haxx.se et adresse sécurité : où parler du projet
La communication passe par trois canaux distincts. Les anomalies et demandes de fonctionnalités vont sur GitHub Issues, les discussions d'usage sur GitHub Discussions ou la liste de diffusion c-ares hébergée chez haxx.se, dont l'archive est publique. Le README demande explicitement de ne pas contacter en privé les volontaires pour des questions ordinaires.
Les failles de sécurité suivent une procédure dédiée dans SECURITY.md, avec l'adresse c-ares-security chez haxx.se. La séparation stricte entre canaux publics, liste d'usage et divulgation de vulnérabilités évite le scénario où un rapport de sécurité se perd dans un ticket ouvert à tous.
Conclusion éditoriale
c-ares vise les développeurs C et C++ qui veulent des requêtes DNS sans blocage sur une base portable de Linux à iOS ; il n'a pas d'intérêt direct pour une application de haut niveau qui passe par le résolveur du système. Avant l'intégration, lisez FEATURES.md pour confirmer que les types d'enregistrements dont vous avez besoin sont couverts, et prenez l'habitude de vérifier chaque tarball par la commande gpg --verify documentée avec les clés de Daniel Stenberg et Brad House.
Notes de la communauté