Erre con erre cigarro Erre con erre barril Rápido ruedan los carros En el ferrocarril
maradns possède deux types d'arguments, chacun étant optionnel.
Le premier est l'emplacement d'un fichier mararc contenant toute l'information de configuration de MaraDNS. L'emplacement par défaut de ce fichier est /etc/mararci. Ceci est précisé dans l'expression maradns -f mararc_file_location où mararc_file_location est l'emplacement de ce fichier.
Il est également possible de demander à MaraDNS de montrer son numéro de version, puis de se terminer. Ceci s'obtient en invoquant maradns ainsi maradns -v ou maradns --version
Pour que MaraDNS puisse fonctionner en mode autoritaire, il est nécessaire de rédiger au moins deux fichiers de configuration: le fichier mararc et un ou plusieurs fichiers de zone au format "csv1".
Le format de fichiers de zone csv1 est décrit dans la page de manuel csv1(5) Le format du fichier mararc est décrit dans la page de manuel mararc(5)
Si MaraDNS est utilisé comme serveur de noms récursif, le pare-feu doit laisser passer les paquets suivants en provenance et à destination de l'adresse IP utilisée par le serveur :
Lisez le guide de démarrage rapide, dans le fichier 0QuickStart de la distribution MaraDNS.
Aucune, en fait. MaraDNS est produit dans le domaine publique.
La méthode actuelle est de faire tourner plusieurs copies de MaraDNS, chacune avec son propre fichier mararc.
Par exemple:
maradns -f /etc/mararc.1 maradns -f /etc/mararc.2 etc.
Si vous souhaitez simplement faire tourner MaraDNS sur toutes les adresses IP disponibles sur la machine, utilisez l'adresse "0.0.0.0".
Je ne pense pas que ceci soit trop difficile à implémenter correctement, puisque j'ai déjà du code pour spécifier plusieurs adresses IP dans les ACL utilisées par le serveur de zones. En attendant, la FAQ indiquera cette solution.
Avant de rapporter un bogue de MaraDNS, lisez les pages de manuel concernées. Les pages de manuel devraient avoir été installées à l'installation de MaraDNS, et, de plus, sont disponibles dans le répertoire doc/man dans le tarball source de MaraDNS. Il est également possible que vous soyez en train de lire cette page de manuel.
Certaines pages de manuel de MaraDNS (actuellement, les pages pour maradns, askmara, zoneserver, et mararc) disposent d'une section "BOGUES" (BUGS en anglais), qui liste certains bogues déjà connus de MaraDNS que l'auteur ne juge pas assez importants pour être corrigés avant la sortie de la version 1.0 de MaraDNS. Les rapports de bogues concernant l'un de ces bogues mentionnés seront joyeusement ignorés. (NDT: consultez la page de manuel originale en anglais pour être sûr de disposer de la dernière version).
Abonnez-vous à la liste de diffusion en envoyant un courrier à list-subscribe@maradns.org avec "subscribe" comme sujet, et décrivez ensuite le bogue en envoyant un courrier à list@maradns.org.
Ce message d'erreur ne devrait pas être visible. S'il apparaît, abonnez-vous à la liste de diffusion (voir au dessus), et décrivez votre problème en envoyant un courrier. Indiquez :
Les registrars allemands et australiens obligent que l'on renvoie les enregistrements NS et SOA à une requête RR_ANY. MaraDNS peut faire ceci si vous spécifiez dans votre fichier mararc :
default_rrany_set = 15
Les services UDP ne montrent pas un "LISTEN" voyant dans la sortie de netstat.
Lorsque MaraDNS est en fonctionnement, la ligne concernée dans la sortie de netstat ressemble à : udp 0 0 127.0.0.4:53 0.0.0.0:*
Au sujet de netstat, si vous lancez netstat -nap en tant que root, vous verrez les noms des processus faisant fonctionner des services réseaux (sous Linux)
MaraDNS utilise sa propre bibliothèque de manipulation de chaînes, intitulée bibliothèque "js_string". Des pages de manuel pour la plupart des fonctions de la bibliothèque sont disponibles dans le répertoire doc/man de la distribution de MaraDNS.
Afin que l'on puisse intégrer MaraDNS avec Python sans souci. Bien que maintenant Python soit, je crois, compatible avec la GPL, il ne l'était pas au moment où j'ai choisi une licence pour MaraDNS.
Le modèle multi-threadé est, tout simplement, la manière la plus simple d'écrire un serveur DNS récursif qui fonctionne. C'est la raison pour laquelle MaraDNS, pdnsd, et BIND 9 utilisent tous un modèle multi-threadé.
Avant d'envoyer un mail à la liste avec une demande de fonctionnalité nouvelle, lisez la section FONCTIONS NON MISES EN OEUVRE (ou UNIMPLEMENTED FEATURES) de la page de manuel de MaraDNS, qui comporte une liste de ce que des gens ont pu souhaiter comme nouvelles fonctionnalités. Si vous ne voyez pas ce que vous souhaiteriez implémenté, envoyer un courrier à la liste afin que j'ajoute cette demande à la page de manuel.
Des demandes de fonctions nouvelles qui incluent un correctif le mettant en oeuvre peuvent être intégrées à MaraDNS, tant que le correctif mentionne son appartenance au domaine public.
Notez que MaraDNS est désormais "gelé". C'est à dire qu'aucune nouvelle fonctionnalité ne sera ajoutée avant la sortie de la version 1.0.
Oui. Envoyez le patch par email, avec une déclaration de son appartenance au domaine public. Si je trouve que le patch fonctionne bien, je l'intègrerai à MaraDNS.
Oui, mais pas d'une manière traditionnelle.
La philosophie de MaraDNS pour la version 1.0 est : simplicité et sécurité. Parce qu'il est plus simple de faire des programmes séparés pour le rappatriement et la mise à disposition de zones, j'ai choisi cette approche pour la version 1.0
Je trouve que l'une des grandes forces d'UNIX est de pouvoir combiner une série de petits programmes simples ensemble pour réaliser une tâche complexe. C'est l'approche suivie pour MaraDNS 1.0.
Le "coeur" d'un serveur DNS ne devrait idéalement pas faire plus que :
Un serveur DNS récursif est un serveur DNS en mesure de contacter un autre serveur DNS afin de résoudre un nom DNS donné. C'est le genre de serveurs que l'on renseigne dans /etc/resolv.conf.
Un serveur DNS autoritaire répond à ses requêtes émanant de serveurs récursifs en leur donnant la réponse à une requête DNS donnée.
Pour des raisons de sécurité, le client getzone de MaraDNS n'ajoute pas à la zone des enregistrements n'en faisant pas partie. Par exemple, si dans une zone example.com on a un enregistrement du type :
P1.1.1.10.in-addr.arpa.|86400|dns.example.com.
MaraDNS n'ajoutera pas cet enregistrement, car il est en dehors de la zone. En d'autres mots, il ne se termine pas par example.com.
Il y a deux parades à ce problème :
BIND est plutôt exigeant quant à quelle type de données accepter depuis un serveur de zones. Assurez-vous que :
Voici un exemple à ne pas suivre :
Sexample.com.|86400|example.com.|hostmaster@example.com.|1|86400|3600|6048000|86400 Nbad.example.com.|86400|ns1.example.com. Nbad.example.com.|86400|ns2.example.com. Nsubdomain.example.com.|86400|ns.subdomain.example.com. Aexample.com.|12345|10.2.3.4
Et le même exemple, après correction :
Sexample.com.|86400|example.com.|hostmaster@example.com.|1|86400|3600|6048000|86400 Nexample.com.|86400|ns1.example.com. Nexample.com.|86400|ns2.example.com. Aexample.com.|12345|10.2.3.4 Nsubdomain.example.com.|86400|ns.subdomain.example.com.
Même si je compte faire de MaraDNS un serveur portable, qui compilera sur de nombreux Unix, à ce moment même le développement de MaraDNS est fait sous Linux. En termes d'OS propriétaires, je sais que SCO Open Server, SCO Unixware, et Solaris posent des problèmes quand il s'agit de faire fonctionner un serveur UDP ou TCP dans un environnement chroot(). Il semblerait que, sous Solaris ou UNIXware, placer /dev/tcp et /dev/udp dans la cage chroot() permettrait à un serveur comme MaraDNS de fonctionner.
Voir plus bas pourquoi MaraDNS a des problèmes pour fonctionner comme serveur récursif sous Solaris.
Il y a deux manières de faire ceci:
Pour utiliser le support natif des threads vous devez ajouter -pthread à la variable CFLAGS.
Pour utiliser la bibliothèque GNU pthread, vous devez installer le port pth et ajouter -L/usr/local/lib/pth au linker.
(Florin Iucha a fourni ce conseil)
C'est un problème connu de MaraDNS, qui conduit à des fuites mémoire lorsque l'on utilise MaraDNS comme serveur récursif sous Solaris. Ce problème n'existe pas sous Linux, je ne peux donc pas le résoudre. Tant que je n'ai pas accès à une machine Solaris, ou bien qu'un développeur travaillant sous Solaris ne m'envoie pas un patch qui corrige le problème (et me confirme que le patch fonctionne), il ne sera pas possible d'utiliser MaraDNS comme serveur récursif sous Solaris.
Si une résolution demande un enregistrement A, et que cet enregistrement est un CNAME pointant vers un autre CNAME (ou plus), bien que MaraDNS retourne l'adresse IP correcte (tant que le glueless level n'est pas atteint), MaraDNS retournera erronément que le premier CNAME de la chaîne pointe directement vers l'IP.
Si un enregistrement NS pointe vers une liste d'adresses IP, et que l'enregistrement en question est "glueless" (c'est à dire que MaraDNS a du retourner jusqu'aux root servers pour en trouver l'adresse), le resolver récursif de MaraDNS ne listera que la première adresse IP comme serveur de noms.
Lorsque le resolver récursif de MaraDNS reçoit une réponse "host not there", au lieu d'utiliser le SOA minimum comme TTL de la réponse "host not there" (cf. RFC1034 §4.3.4), MaraDNS utilise le TTL de la réponse SOA.
MaraDNS conserve les enregistrements NS dans le cache pendant une journée au lieu du TTL renvoyé par le serveur distant.
MaraDNS n'a qu'un support très limité du transport de données DNS sur TCP. En particulier, MaraDNS n'utilise DNS sur TCP que pour les transferts de zones, gérés par le programme conjoint zoneserver (voir zoneserver(8) pour son usage).
MaraDNS gère la requête "any record" (255) en ne retournant qu'un enregistrement A et MX (optionnellement: enregistrements NS et SOA), au lieu de retourner tout enregistrement associé au nom concerné. Les seuls endroits où j'ai eu connaissance de l'utilisation de la requête "any record" sont les MTAs, et les registrars des TLD .de et .au. En mode récursif, une requête "any record" est traduite en deux requêtes A et MX, que MaraDNS concatène.
MaraDNS ne retourne jamais un NXDOMAIN (rien dans la réponse, SOA dans la section d'autorité, code d'erreur "name error" [3]). Si un label de nom DNS n'existe pour aucun RR, MaraDNS retournera malgré tout un "no host" (rien dans la réponse, SOA, code d'erreur 0), impliquant que le nom d'hôte existe pour au moins un type de RR.
Si un enregistrement wildcard MX existe sous la forme "*.example.com" et qu'il y a un enregistrement A pour "www.example.com", mais pas d'enregistrement MX pour "www.example.com", le comportement correct (RFC1034 §4.3.3) serait de retourner "no host" (rien dans la réponse, SOA présent, code de retour 0) pour une requête MX de www.example.com. À la place, MaraDNS retourne l'enregistrement MX associé à "*.example.com".
Les enregistrements "astérisque" (que la RFC1034 nomme "wildcards") ne peuvent être associés à des RR de type NS.
Le resolver récursif de MaraDNS s'arrête de résoudre lorsqu'il trouve une réponse dans la section AR. Ceci présente un problème dans le cas où on nom d'hôte donné et son adresse sont enregistrés auprès des root servers, et que l'IP n'est plus à jour. Si ceci se produit, un serveur "plus proche" du root server donnera l'adresse IP obsolète, même si les DNS autoritaires pour la zone connaissent l'IP correcte. Notez que résoudre ceci augmenterait le trafic DNS.
MaraDNS, comme toute autre implémentation DNS connue, ne supporte un QDCOUNT que de 0 ou 1.
MaraDNS ne devient pas un démon. Il est possible d'utiliser un shell avec contrôle de tâche pour faire de MaraDNS un processus en mode démon, par exemple :
nohup maradns > /dev/null &
MaraDNS n'utilise pas syslog ou toute autre commodité de journalisation pour les messages générés par MaraDNS. À la place, les messages sont journalisés sur la sortie standard. Il est possible d'utiliser une redirection du shell pour journaliser vers un fichier, par exemple :
MaraDNS n'a pas de support d'une "zone par défaut" qui permettrait d'ajouter ou retirer des zones sans modifier le fichier de configuration de MaraDNS.touch /var/log/maradns nohup maradns >> /var/log/maradns &
MaraDNS, comme tous les autres serveurs DNS connus, n'a pas de support SQL.
MaraDNS n'a pas de support pour autoriser certaines adresses à ne résoudre qu'un certain nombre d'hôtes en interrogeant le serveur DNS, ou bien de résoudre différemment selon l'adresse IP réalisant la requête.
MaraDNS ne supporte pas IPv6.
MaraDNS n'a pas de gestion des signaux. Envoyer un signal HUP à MaraDNS termine le processus au lieu de dire à MaraDNS de relire ses fichiers de configuration.
À l'exception de résoudre certains types de RR non présents dans la RFC1035, MaraDNS ne supporte aucune fonction DNS non présente dans la RFC1034 ou RFC1035.
MaraDNS, conformément à la RFC1035 §4.3.3, n'autorise l'usage de "wildcards" qu'au début d'un nom DNS. Par exemple, un enregistrement comme "foo.*.example.com" ou "www.*" ne fonctionnera pas.
http://www.samiam.org/