c-ares: asynchrone DNS-Auflösung in C, von der API bis zur Release-Prüfung
c-ares/c-ares bietet eine praxistaugliche Open-Source-Implementierung mit stabiler Einsatzbarkeit für reale Anwendungsfälle.
Auf einen Blick
- Was ist das?
- Die C-Bibliothek c-ares löst DNS-Anfragen nicht blockierend auf. Was sie gegenüber dem Systemresolver bieten will, wie sie sich absichert und wie man Releases verifiziert.
- Für wen ist es gedacht?
- c-ares passt zu Anwendungen, die DNS-Abfragen parallel oder ohne Blockieren ausführen müssen und eine schlanke C-Bibliothek mit MIT-Lizenz suchen. Wer DNSSEC-Validierung braucht oder ein vollständiges Resolver-Framework mit Caching-Schichten erwartet, stößt an Grenzen, denn die DNSSEC-Unterstützung ist auf Parsen und Schreiben beschränkt.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 15 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich C, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
c-ares als Stub-Resolver: nicht blockierend und parallel
c-ares ist eine moderne DNS-Stub-Resolver-Bibliothek, geschrieben in C. Sie stellt Schnittstellen für asynchrone Abfragen bereit und abstrahiert dabei die Feinheiten des DNS-Protokolls. Ursprünglich war sie laut README für Anwendungen gedacht, die DNS-Abfragen ohne Blockieren durchführen oder mehrere Abfragen parallel stellen müssen. Genau das ist der Unterschied zum Systemresolver: Während getaddrinfo den Aufrufer einfriert, bis eine Antwort kommt oder ein Timeout greift, liefert c-ares Rückmeldungen über Callbacks und erlaubt viele gleichzeitige Queries.
Die Autoren gehen einen Schritt weiter und empfehlen die Bibliothek für alle Netzwerkanwendungen, selbst wenn asynchrone Auflösung nicht das Hauptziel ist. Das Argument lautet, c-ares wolle ein besserer DNS-Resolver sein als der, den das jeweilige Betriebssystem mitbringt. Ob man diese Empfehlung folgt, ist eine Abwägung: Der Vorteil liegt in konsistentem Verhalten über Plattformen hinweg, der Nachteil darin, dass man die Systemkonfiguration nicht mehr automatisch erbt.
C89-Kompatibilität und Plattformliste von AIX bis iOS
Portabilität ist ein erklärtes Bauprinzip. c-ares lässt sich mit jedem C89-Compiler bauen, was die Einbindung in ältere Toolchains, Embedded-Umgebungen und strenge Build-Pipelines erlaubt. Das README listet Linux, FreeBSD, OpenBSD, macOS, Solaris, AIX, Windows, Android, iOS und weitere Betriebssysteme als unterstützte Plattformen auf.
Die MIT-Lizenz macht die Bibliothek für freie und kommerzielle Software nutzbar, Build-Informationen stehen in der Datei INSTALL.md des Repositories. 2184 Sterne und 682 Forks zeigen eine etablierte, wenn auch keine modische Codebasis. Wer c-ares statt des Systemresolvers einsetzt, sollte im Build prüfen, welche Konfigurationsquellen die Bibliothek übernimmt, etwa resolv.conf unter Unix oder die Windows-Systemeinstellungen, denn genau dieser Pfad unterscheidet sich je nach Plattform und ist die häufigste Überraschung beim ersten Integrationstest.
Sichere Parser, OSS Fuzz und die CI-Signale im README
Das README betont einen starken Fokus auf Sicherheit. c-ares implementiere sichere Parser und Datenkonstruktoren im gesamten Code, um die typischen Fallstricke anderer C-Bibliotheken zu vermeiden, also Pufferüberläufe und Parsing-Fehler bei manipulierten DNS-Antworten. Die Validierung läuft automatisiert: Ein umfangreiches Test-Framework, statische und dynamische Analyzer und kontinuierliches Fuzzing durch OSS Fuzz.
Die Badge-Leiste im README verweist auf weitere Signale: GitHub-Workflows für Ubuntu und Windows, Testabdeckung bei Coveralls, ein Best-Practices-Badge der Core Infrastructure Initiative, SonarCloud und das Coverity-Scan-Projekt. Für vermutete Schwachstellen gilt ein eigenes Verfahren, beschrieben in SECURITY.md, mit Kontakt über c-ares-security at haxx.se. Issues und Feature-Wünsche gehören in den GitHub-Issue-Tracker, Diskussionen in GitHub Discussions oder auf die Mailingliste, Privatmails an die Freiwilligen sind ausdrücklich unerwünscht.
GPG-Schlüssel von Stenberg und House: Signaturprüfung Schritt für Schritt
Releases werden mit GPG signiert. Das README nennt zwei Hauptschlüssel: Daniel Stenberg, erreichbar unter daniel@haxx.se, mit Fingerabdruck 27EDEAF22F3ABCEB50DB9A125CC908FDB71E12C2, und Brad House mit DA7D64E4C82C6294CB73A20E22E3D13B5411B7CA. Beide lassen sich über den Keyserver hkps://keyserver.ubuntu.com importieren, etwa mit gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys gefolgt vom jeweiligen Fingerabdruck.
Zu jedem Archiv c-ares-X.Y.Z.tar.gz existiert eine Datei c-ares-X.Y.Z.tar.gz.asc mit der abgetrennten Signatur. Die Prüfung läuft über gpg -v --verify auf beide Dateien; das README zeigt als Beispiel eine erfolgreiche Verifikation des Pakets c-ares-1.29.0 mit Stenbergs RSA-Schlüssel. Zwei Punkte sollte man dabei kennen: Eine Good-Signature-Meldung mit dem Zusatz unknown sagt nur aus, dass die Signatur zum Schlüssel passt, nicht dass der Schlüssel dem richtigen Menschen gehört, deshalb das.WARNING im gpg-Output. Und einige Releaser signieren mit Subkeys, das importierte Schlüsselset sollte daher vollständig sein.
SLSA-Provenienz mit slsa-verifier gegen Release v1.34.3
Neben den GPG-Signaturen erzeugt das Projekt SLSA-Provenienz für seine Releases. Damit lässt sich prüfen, dass die heruntergeladenen Artefakte tatsächlich aus dem vorgesehenen Repository gebaut wurden, nicht nur, dass sie signiert wurden. Das README zeigt den Ablauf am Beispiel der Version 1.34.3: Zuerst curl -sO auf die Datei c-ares-1.34.3.intoto.jsonl aus dem GitHub-Release, dann auf das tar.gz-Archiv, anschließend slsa-verifier verify-artifact mit --provenance-path, --source-uri github.com/c-ares/c-ares und --source-tag v1.34.3.
Die Ausgabe bestätigt die Signatur gegen einen Eintrag im Rekor-Log von sigstore.dev und den Builder auf GitHub. Damit stehen zwei unabhängige Verifikationswege bereit, die unterschiedliche Fehlermodelle abdecken: GPG sichert die Herkunft vom Releaser, SLSA die Herkunft vom Build-System. Der aktuellste Release im Repository ist v1.34.8 vom Juli 2026, davor v1.34.7 und v1.34.6, die Patchfolge zeigt eine kontinuierlich gepflegte Versionslinie.
RFC-Spektrum von AAAA bis SVCB und die DNSSEC-Grenze
Die unterstützten Standards listet das README einzeln auf: RFC1035 als Basis, EDNS0 über RFC2671 und RFC6891, AAAA-Records für IPv6 nach RFC3596, SRV-Records zur Serverauswahl nach RFC2782, NAPTR nach RFC3403, TLSA im Rahmen von DANE nach RFC6698, SVCB- und HTTPS-Records nach RFC9460, URI-Records nach RFC7553 und CAA nach RFC6844. Weitere Einträge betreffen SIG0, DNSSEC-Recordtypen, NSEC3, SSHFP, DNS-Cookies und die 0x20-Zufallsverteilung der Groß- und Kleinschreibung in Query-Namen.
Wichtig sind die Einschränkungen: SIG0 hat laut README nur einen grundlegenden Parser, und die DNSSEC-Recordunterstützung dient dem Parsen und Schreiben, ohne Validierung. Wer DNSSEC-konform validieren muss, braucht also eine andere Schicht. Weiterhin behandelt die Bibliothek .onion-Abfragen mit NXDOMAIN, erkennt localhost besonders, unterstützt negatives Caching, IPv6-Adresssortierung und TCP FastOpen. Die vollständige Funktionsliste steht in FEATURES.md, die man vor einer Entscheidung gelesen haben sollte, denn dort liegen die Details, über die das README nur hinwegspringt.
Redaktionelles Fazit
c-ares passt zu Anwendungen, die DNS-Abfragen parallel oder ohne Blockieren ausführen müssen und eine schlanke C-Bibliothek mit MIT-Lizenz suchen. Wer DNSSEC-Validierung braucht oder ein vollständiges Resolver-Framework mit Caching-Schichten erwartet, stößt an Grenzen, denn die DNSSEC-Unterstützung ist auf Parsen und Schreiben beschränkt. Vor dem Einsatz lohnt ein Blick in INSTALL.md und FEATURES.md, um zu prüfen, ob die eigenen Record-Typen und Plattformen abgedeckt sind.
Community-Notizen