Doggo - un client DNS en ligne de commande convivial

 (doggo.mrkaran.dev)
2 points par GN⁺ 2024-07-02 | 1 commentaires | Partager sur WhatsApp
  • Doggo est un client en ligne de commande qui affiche les résultats des requêtes DNS avec un code couleur et sous forme de tableau, afin d’offrir une sortie facile à lire dans le terminal
  • Dans les environnements d’automatisation, il est possible d’utiliser une sortie JSON ; l’outil peut aussi servir à analyser des problèmes grâce à la mesure du temps de réponse et au mode debug
  • Un seul outil permet de gérer plusieurs protocoles de transport, dont DNS over HTTPS, TLS, QUIC, TCP, UDP et DNSCrypt
  • Il prend en charge des fonctionnalités EDNS telles que EDNS Client Subnet, NSID, DNS Cookies, EDNS Padding, Extended DNS Errors, ainsi que le traitement des glue records
  • Il fonctionne sur Linux, macOS, Windows, FreeBSD et NetBSD, et propose à la fois une interface web et l’autocomplétion du shell, pour un usage aussi bien en CLI locale que dans le navigateur

Des requêtes DNS lisibles dans le terminal

  • Doggo se présente comme un client DNS en ligne de commande pensé pour les humains
  • La sortie par défaut utilise un code couleur et un format tabulaire, ce qui permet de parcourir rapidement les réponses DNS
  • Lorsqu’un script ou un parsing est nécessaire, une sortie JSON est disponible
  • Le mode debug et la mesure du temps de réponse sont fournis ensemble, ce qui permet de vérifier non seulement le résultat de la requête, mais aussi son déroulement

Protocoles DNS et données pris en charge

  • Prise en charge de plusieurs protocoles de transport DNS
    • DNS over HTTPS
    • DNS over TLS
    • DNS over QUIC
    • DNS over TCP
    • DNS over UDP
    • DNSCrypt
  • Les fonctionnalités liées à EDNS sont également largement couvertes
    • Réponses tenant compte de la localisation via EDNS Client Subnet (ECS)
    • Name Server Identifier (NSID)
    • DNS Cookies
    • EDNS Padding
    • Extended DNS Errors (EDE)
  • L’outil peut traiter les glue records de la section additional ainsi que les données DNS auxiliaires
  • Pour les noms de domaine internationalisés (IDN), la conversion en punycode est automatique
  • Il peut aussi gérer les requêtes DNS inversées ainsi que divers drapeaux DNS comme AA, AD, CD et DO

Configuration, résolveurs et environnement d’exécution

  • Les paramètres ndots et search peuvent être utilisés via resolv.conf ou les arguments de la ligne de commande
  • Il est possible de spécifier plusieurs résolveurs et de personnaliser la stratégie de requête
  • IPv4 et IPv6 sont tous deux pris en charge
  • Une interface web est disponible sur doggo.mrkaran.dev
  • L’autocomplétion du shell est fournie pour zsh et fish
  • Les plateformes prises en charge sont Linux, macOS, Windows, FreeBSD et NetBSD

À lire aussi

1 commentaires

 
GN⁺ 2024-07-02
Avis sur Hacker News

  • Ça a vraiment l’air super. Peux-tu en dire plus sur pourquoi tu l’as créé, les décisions de conception et le contexte en coulisses ?

    • Je l’ai créé comme projet secondaire d’apprentissage et de loisir. En 2021, je travaillais beaucoup avec des clusters K8s quand j’ai découvert ndots, et j’ai eu envie de créer un client DNS facile à utiliser, qui ne se comporte pas de manière inattendue à cause de l’environnement hôte.
      Je l’ai fait en Go, que j’utilise principalement, et comme je ne voulais pas ajouter de dépendances externes sauf nécessité, je n’ai pas utilisé de framework CLI. J’aime particulièrement le petit utilitaire help.go que j’ai écrit pour rendre le texte d’aide avec couleurs et mise en forme.
      Avec le temps, j’ai aussi reçu de bonnes contributions externes, notamment celle de @jedisct1, qui a ajouté la prise en charge de DNSCrypt, ce qui a beaucoup compté. La sortie de la v1.0 a été repoussée pendant plus d’un an, à cause de la vie, d’autres projets et d’un peu de procrastination ; ce n’est que la semaine dernière que je me suis fixé une date limite et que je suis allé au bout.
      Article sur ndots : https://mrkaran.dev/posts/ndots-kubernetes/

  • Excellent choix de nom. Les chiens (doggo) adorent creuser (dig), après tout.

    • J’ai appris aujourd’hui qu’il existe aussi dog. C’est sans doute aussi une faute de frappe courante de dig.

  • C’est bien qu’il y ait aussi une image Docker. Ce serait bien d’ajouter dans la doc l’option --rm pour le nettoyage après exécution et -t pour les couleurs.
    docker run --rm -it ghcr.io/mr-karan/doggo:latest mrkaran.dev MX

    • Par curiosité, pourquoi se donner tant de mal pour mettre dans un conteneur Docker un utilitaire CLI DNS sans dépendances ?

  • Question peut-être un peu bête, mais pourquoi toute la sortie apparaît-elle deux fois ?
    Quand je lance doggo google.com, j’obtiens les mêmes enregistrements A depuis 127.0.2.2:53 et 127.0.2.3:53, et avec doggo news.ycombinator.com, les résultats de deux serveurs de noms sont aussi affichés.

    • On dirait que c’est affiché une fois par serveur de noms configuré. En pratique c’est rare, mais ils pourraient donner des réponses différentes, d’où ce comportement.
    • J’ai essayé avec mon serveur DNS AdGuard et je n’obtiens qu’une seule entrée. Ça semble lié à la configuration des serveurs de noms.
      Peux-tu reproduire en indiquant un serveur de noms personnalisé comme @1.1.1.1 ? doggo google.com --short ne m’a renvoyé qu’un seul résultat : 142.250.185.238.

  • Ce serait vraiment bien que cet outil prenne en charge un type de requête équivalent à ANY.

  • Beau projet. Je l’ai découvert l’an dernier en développant le pkg x-cmd ; à l’époque la dernière version était la 0.5.7, et maintenant que c’est la 1.0.2, il semble qu’une mise à jour de version soit nécessaire.
    Il y a aussi une vidéo de démo : https://x-cmd.com/pkg/doggo

  • Ça me fait penser à https://github.com/ogham/dog

    • D’après le README GitHub de doggo, il est entièrement inspiré de dog, écrit en Rust ; l’auteur ne connaissait pas Rust mais voulait ajouter des fonctionnalités, et il y a vu une bonne occasion d’écrire un client DNS en Go à partir de zéro.
      D’où le nom : dog + go => doggo.
    • Malheureusement, dog semble ne plus être maintenu.

  • Y a-t-il une raison pour laquelle tant d’outils de ce genre sont écrits en Go ? Je me demande si c’est à cause de la bibliothèque standard, ou si c’est juste une coïncidence.

    • Go produit en général par défaut des binaires compilés statiquement. Pas de runtime, pas d’interpréteur, pas de dépendances.
      On peut difficilement dire la même chose de Python, Java, JavaScript, C#, etc.
    • Cela peut aussi être culturel. Go est très présent dans le domaine DevOps / infrastructure cloud.
      Beaucoup d’outils comme k8s, Terraform et ses providers sont écrits en Go, et pour l’outillage interne il rivalise assez bien avec Python en popularité.
    • Dans ce cas, on dirait que l’auteur l’a utilisé parce qu’il connaissait déjà Go.
      D’après le README, il s’est inspiré de dog, écrit en Rust ; il ne connaissait pas Rust mais voulait ajouter des fonctionnalités, alors il s’est mis à écrire lui-même un client DNS en Go. D’où le nom : dog + go => doggo.
      https://github.com/ogham/dog
    • Go permet de finir le travail, et le résultat tient dans la durée.
    • Évidemment, parce que ça permet d’en faire un jeu de mots.

  • Est-ce lié à Dog ? Les fonctionnalités semblent presque identiques.
    Les deux demandent une requête précise à exécuter (A, AAAA, etc.) ; pourquoi ne pas interroger tous les enregistrements par défaut ? Au moins quand on interroge un seul domaine, ça semblerait possible.
    https://github.com/mr-karan/doggo

    • Qu’entends-tu exactement par tous les enregistrements ici ? dig affiche par défaut uniquement les enregistrements A, et j’ai gardé le même comportement.
      Je me demande si tu parles de tous les types d’enregistrements possibles, ou seulement de quelques types courants comme MX, AAAA, A, CNAME, TXT.

  • Félicitations pour la sortie de la 1.0. doggo est mon principal outil DNS depuis un moment, et je l’aime beaucoup.