Provided by: maradns_1.0.35-1_i386 bug

NOM

       maradns - Serveur DNS

RÉSUMÉ

       maradns [ -v | -f mararc_file_location ] >> /var/log/maradns &

DESCRIPTION

       maradns est un serveur DNS écrit en conservant sécurité, simplicité, et
       performance à l´esprit.

       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_locationmararc_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

UTILISATION

       Si MaraDNS fonctionne seulement en mode récursif, un seul fichier de
       configuration est nécessaire, le fichier mararc.

       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)

CONSIDÉRATIONS DE FILTRAGE

       Si MaraDNS est utilisé en serveur de noms autoritaire, autoriser les
       flux UDP depuis tout hôte sur Internet vers le port 53 en UDP sur
       l´adresse IP utilisée par le serveur autoritaire.

       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 :

       * Autoriser les flux UDP depuis le serveur MaraDNS vers toute machine
         sur Internet avec 53 comme port de destination.

       * Autoriser les flux UDP depuis toute machine sur Internet vers l´IP du
         serveur récursif, avec un port source de 53 et un port de destination
         compris entre 15000 et 19095 (inclus).

       * Autoriser les flux USP depuis les adresses utilisant le serveur
         MaraDNS comme serveur récursif à destination du port 53.

       MaraDNS utilise un générateur de nombres aléatoires cryptographiquement
       fort pour générer à la fois la requête (16 bits d´entropie) et le port
       source de la requête (12 bits d´entropie). Ceci rend les réponses
       contrefaites à un serveur MaraDNS plus difficile, l´attaquant n´ayant
       qu´une chance sur 250 millions qu´une réponse contrefaite donnée soit
       considérée comme valide.

FOIRE AUX QUESTIONS

    Comment puis-je essayer MaraDNS ?

       Lisez le guide de démarrage rapide, dans le fichier 0QuickStart de la
       distribution MaraDNS.

    Sous quelle licence MaraDNS est-il produit ?

       Aucune, en fait. MaraDNS est produit dans le domaine publique.

    Comment puis-je faire fonctionner MaraDNS sur plusieurs adresses IP ?

       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.

    Comment puis-je faire un rapport de bogues sur MaraDNS ?

       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.

    Lorsque je lance MaraDNS, j´obtiens un message Fatal error: Error running
    populate_main program or a Faral error: init_cache() failed error message.

       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 :

       * Le contenu de votre fichier /etc/mararc

       * Le contenu de tout fichier de /etc/maradns

       * La sortie complète de MaraDNS
      Je cherche à enregistrer un domaine sous le TLD .au ou .de, et le
      registrar refuse mon nom de domaine.

       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

    Après avec lancé MaraDNS, je ne vois pas le processus dans netstat -na

       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)

    Quelle bibliothèque de manipulation de chaînes utilise MaraDNS ?

       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.

    Pourquoi MaraDNS est-il dans le domaine public, plutôt que sous licence
    GPL ou BSD ?

       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.

    Pourquoi MaraDNS utilise un modèle multi-threadé ?

       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é.

    Je trouve que telle et telle fonctionnalité devrait être ajoutée à MaraDNS

       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.

    Y a t´il une marche à suivre pour demander l´incorporation d´un patch à
    MaraDNS ?

       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.

    MaraDNS peut-il servir de serveur de noms secondaire ?

       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 :

       * Convertir des données externes dans le format interne du serveur DNS
         en utilisant des modules.

       * Conserver les données chargées de sources "lentes" (serveur DNS
         externes, serveurs SQL, etc.)

       * Convertir les paquets DNS en des requêtes de données pour les sources
         en question.

       * Convertir les données de ces sources en paquets DNS.  (Maintenant,
         vue la manière dont j´ai codé la résolution récursive de MaraDNS,
         j´ai dévié de cet idéal, mais c´est une autre histoire.

      Quelle est la différence entre un serveur DNS autoritaire et un serveur
      récursif ?

       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.

    Le client getzone ne m´autorise pas à ajouter certains noms de ma zone

       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 :

       * Créer un fichier de zone 1.1.10.in-addr.arpa., pour les
         enregistrements PTR.

       * Utiliser rcp, rsync, ou toute autre méthode, pour synchroniser les
         fichiers de zone concernés.
      Je rencontre des problèmes en transférant des zones depuis le serveur de
      zones de MaraDNS vers un client de transfert BIND.

       BIND est plutôt exigeant quant à quelle type de données accepter depuis
       un serveur de zones. Assurez-vous que :

       * Les enregistrements NS autoritaires sont tout en haut de votre zone,
         juste après l´enregistrement SOA.

       * Les enregistrements NS autoritaires sont bien des NS de votre zone.

       * Afin de pallier un bogue connu de MaraDNS, assurez-vous d´avoir au
         moins un enregistrement non-NS entre les enregistrements NS
         autoritaires de la zone et un enregistrement NS de délégation qui
         existerait dans votre zone.  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.

      MaraDNS est-il portable ?

       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.

    Comment compiler MaraDNS sous OpenBSD ?

       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)

BOGUES

       Si une résolution demande un enregistrement A, et que l´entregistrement
       est un CNAME pointant vers une liste d´adresses IP, le resolver
       récursif de MaraDNS retourne la première IP listée avec le CNAME.

       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.

FONCTIONS NON MISES EN OEUVRE

       Les fonctions suivantes ne seront pas mises en oeuvre dans la prochaine
       version 1.0 de MaraDNS :

       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 :

       touch /var/log/maradns
       nohup maradns >> /var/log/maradns &

       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.

       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.

LEGAL DISCLAIMER

       THIS SOFTWARE IS PROVIDED BY THE AUTHORS ´´AS IS´´ AND ANY EXPRESS OR
       IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
       WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
       DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR
       ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
       DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
       OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
       HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
       STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
       IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
       POSSIBILITY OF SUCH DAMAGE.

AUTEUR

       Sam Trenholme

       http://www.samiam.org/

TRADUCTEUR

       Traduit en français par Thomas Seyrat <thomas@glou.net>