2 Punkte von GN⁺ 2024-07-02 | 1 Kommentare | Auf WhatsApp teilen
  • Doggo ist ein Kommandozeilen-Client, der DNS-Abfrageergebnisse farblich hervorgehoben und im Tabellenformat darstellt und auf gut lesbare Ausgabe im Terminal ausgelegt ist
  • In Automatisierungsumgebungen kann JSON-Ausgabe verwendet werden; mit Messung der Antwortzeit und Debug-Modus eignet sich das Tool auch zur Problemanalyse
  • DNS over HTTPS, TLS, QUIC, TCP, UDP und DNSCrypt sowie weitere Transportprotokolle lassen sich mit einem einzigen Tool nutzen
  • Es unterstützt EDNS-Funktionen wie EDNS Client Subnet, NSID, DNS Cookies, EDNS Padding, Extended DNS Errors sowie die Verarbeitung von Glue Records
  • Es läuft auf Linux, macOS, Windows, FreeBSD und NetBSD und bietet sowohl eine Weboberfläche als auch Shell-Vervollständigung, sodass es lokal per CLI und im Browser genutzt werden kann

Leicht lesbare DNS-Abfragen im Terminal

  • Doggo versteht sich als DNS-Kommandozeilen-Client für Menschen
  • Die Standardausgabe ist farblich hervorgehoben und tabellenbasiert aufgebaut, sodass sich DNS-Antworten schnell überblicken lassen
  • Wenn Scripting oder Parsing benötigt wird, kann JSON-Ausgabe verwendet werden
  • Ein Debug-Modus und die Messung der Antwortzeit zeigen nicht nur das Ergebnis der Abfrage, sondern auch den Ablauf der Verarbeitung

Unterstützte DNS-Protokolle und Daten

  • Es unterstützt mehrere DNS-Transportprotokolle
    • DNS over HTTPS
    • DNS over TLS
    • DNS over QUIC
    • DNS over TCP
    • DNS over UDP
    • DNSCrypt
  • Auch EDNS-bezogene Funktionen sind umfassend enthalten
    • standortbezogene Antworten über EDNS Client Subnet (ECS)
    • Name Server Identifier (NSID)
    • DNS Cookies
    • EDNS Padding
    • Extended DNS Errors (EDE)
  • Glue Records und zusätzliche DNS-Daten aus der Additional Section können verarbeitet werden
  • Für Internationalized Domain Names (IDN) wird die automatische Punycode-Umwandlung unterstützt
  • Auch Reverse DNS Lookup sowie verschiedene DNS-Flags wie AA, AD, CD und DO werden unterstützt

Konfiguration, Resolver und Laufzeitumgebung

  • resolv.conf oder Kommandozeilenargumente können für die Einstellungen ndots und search verwendet werden
  • Es können mehrere Resolver angegeben werden, und auch die Abfragestrategie lässt sich anpassen
  • Sowohl IPv4 als auch IPv6 werden unterstützt
  • Unter doggo.mrkaran.dev steht eine Weboberfläche zur Verfügung
  • Shell-Vervollständigung für zsh und fish ist vorhanden
  • Unterstützte Plattformen sind Linux, macOS, Windows, FreeBSD und NetBSD

1 Kommentare

 
GN⁺ 2024-07-02
Hacker-News-Kommentare
  • Sieht wirklich großartig aus. Kannst du mehr darüber erzählen, warum du es gebaut hast, welche Designentscheidungen dahinterstecken und welchen Hintergrund es gibt?

    • Ich habe es als Lern- und Hobby-Side-Project gebaut. 2021 habe ich viel mit K8s-Clustern gearbeitet und dabei ndots kennengelernt. Dadurch wollte ich einen einfach zu bedienenden DNS-Client bauen, der sich nicht wegen der Host-Umgebung unerwartet verhält.
      Ich habe ihn in Go geschrieben, das ich hauptsächlich nutze, und wollte keine externen Abhängigkeiten hinzufügen, wenn es nicht unbedingt nötig ist; deshalb habe ich kein CLI-Framework verwendet. Besonders gefällt mir, dass ich ein kleines help.go-Utility gebaut habe, das Hilfetexte mit Farben und Formatierung rendert.
      Mit der Zeit gab es auch gute externe Beiträge, besonders wichtig war, dass @jedisct1 DNSCrypt-Support hinzugefügt hat. Das v1.0-Release wurde über ein Jahr lang immer wieder verschoben; das lag an Leben, anderen Projekten und etwas Prokrastination. Erst letzte Woche habe ich mir eine Deadline gesetzt und es durchgezogen.
      Artikel zu ndots: https://mrkaran.dev/posts/ndots-kubernetes/
  • Die Namenswahl ist großartig. Ein Hund (doggo) liebt es schließlich zu graben (dig)

    • Habe heute erfahren, dass es auch dog gibt. Vermutlich ist das auch ein häufiger Tippfehler von dig
  • Schön, dass es auch ein Docker-Image gibt. In der Doku wären --rm zum Aufräumen nach der Ausführung und die Option -t für Farben eine gute Ergänzung.
    docker run --rm -it ghcr.io/mr-karan/doggo:latest mrkaran.dev MX

    • Aus Neugier: Warum sollte man sich die Mühe machen, ein DNS-CLI-Utility ohne Abhängigkeiten extra in einen Docker-Container zu packen?
  • Vielleicht eine etwas dumme Frage, aber warum erscheint die Ausgabe komplett zweimal?
    Wenn ich doggo google.com ausführe, bekomme ich denselben A-Record jeweils von 127.0.2.2:53 und 127.0.2.3:53; bei doggo news.ycombinator.com werden ebenso die Ergebnisse von zwei Nameservern ausgegeben.

    • Sieht so aus, als würde für jeden konfigurierten Nameserver jeweils einmal ausgegeben. Vermutlich, weil sie tatsächlich unterschiedliche Antworten liefern könnten, auch wenn das selten ist.
    • Bei meinem AdGuard-DNS-Server bekomme ich nur einen Eintrag. Es scheint mit der Nameserver-Konfiguration zusammenzuhängen.
      Kannst du das mit einem benutzerdefinierten Nameserver wie @1.1.1.1 reproduzieren? doggo google.com --short hat bei mir nur 142.250.185.238 zurückgegeben.
  • Es wäre wirklich schön, wenn dieses Tool einen Abfragetyp unterstützen würde, der ANY entspricht.

  • Tolles Projekt. Ich habe es letztes Jahr kennengelernt, als ich x-cmd pkg entwickelt habe; damals war die neueste Version 0.5.7, jetzt ist es 1.0.2, daher sieht es so aus, als wäre ein Versionsupgrade nötig.
    Es gibt auch ein Demo-Video: https://x-cmd.com/pkg/doggo

  • Erinnert mich an https://github.com/ogham/dog

    • Laut dem GitHub-README von doggo wurde es vollständig von dog inspiriert, das in Rust geschrieben ist. Da der Autor kein Rust kannte, aber Features hinzufügen wollte, sah er darin eine gute Gelegenheit, einen DNS-Client in Go von Grund auf zu schreiben.
      Daher auch der Name: dog + go => doggo
    • Leider scheint dog nicht mehr gewartet zu werden.
  • Gibt es einen Grund, warum so viele solcher Tools in Go geschrieben werden? Liegt es an der Standardbibliothek, oder ist das einfach Zufall?

    • Go erzeugt standardmäßig meist statisch kompilierte Binaries. Keine Runtime, kein Interpreter, keine Abhängigkeiten.
      Bei Python, Java, JavaScript, C# usw. kann man das schwerlich genauso sagen.
    • Es könnte auch kulturelle Gründe haben. Go ist im Bereich DevOps/Cloud-Infrastruktur sehr präsent.
      Viele Tools wie k8s, Terraform und dessen Provider sind in Go geschrieben, und bei internen Tools konkurriert es in der Beliebtheit oft mit Python.
    • In diesem Fall sieht es so aus, als hätte der Entwickler Go verwendet, weil er es bereits kannte.
      Laut README wurde es von dog inspiriert, das in Rust geschrieben ist. Da der Autor kein Rust konnte, aber Features hinzufügen wollte, schrieb er selbst einen DNS-Client in Go. Daher auch der Name: dog + go => doggo.
      https://github.com/ogham/dog
    • Go lässt einen Dinge fertigstellen, und das Ergebnis hält auch auf lange Sicht.
    • Natürlich, weil man damit ein Wortspiel aus dem Namen machen kann.
  • Hat das etwas mit Dog zu tun? Die Funktionalität sieht fast identisch aus.
    Beide verlangen, dass man eine konkrete Abfrage angibt, die ausgeführt werden soll (A, AAAA usw.). Warum ist die Voreinstellung nicht, alle Records abzufragen? Zumindest bei einer einzelnen Domain scheint das möglich.
    https://github.com/mr-karan/doggo

    • Was genau meinst du hier mit allen Records? dig zeigt standardmäßig nur A-Records an, und ich habe das Verhalten gleich gehalten.
      Ich frage mich, ob du wirklich alle möglichen Record-Typen meinst oder eher ein paar gängige wie MX, AAAA, A, CNAME, TXT.
  • Glückwunsch zum 1.0-Release. doggo ist schon seit einer Weile mein wichtigstes DNS-Tool, und ich mag es wirklich sehr.