Installer/configurer/exploiter Bind 9.4.x

Posté par  (site web personnel) . Modéré par j.
Étiquettes :
0
26
jan.
2008
Doc
Après beaucoup de travail sur le projet, voici une documentation sur Bind, logiciel serveur de DNS, qui peut intéresser la communauté. Cette documentation est orientée sur un autre travail que je compte réaliser. Elle n'aborde pas les technologies comme : Bind + DHCP, Bind + Lwres... mais vous avez tout de même tout (à mon avis) pour faire en sorte que "votre" Bind soit à la hauteur, et sécurisé.

Pour ce sujet, je trouve dommage après X années d'existence de Bind, que le monde francophone n'est pas publié le même style de document. Les meilleurs documents récents restent en anglais, c'est dommage pour un service important que représente le DNS, et encore plus Bind.

Bon voilà, bonne lecture... et comme beaucoup toutes les critiques "positives" sont acceptées. Pour information, la licence de cette documentation est la GFDL.

Aller plus loin

  • # Crédit

    Posté par  (site web personnel) . Évalué à 4.

    Les crédits sur le rédacteur original sont passés à la trappe, zut.
    La dépèche n'est pas de moi, mais de Laurent ARCHI qui ne pouvait pas poster de dépèche.
    (je n'y connais rien moi à BIND, ne me posez pas de questions dessus :) )
  • # Une autre doc

    Posté par  (site web personnel) . Évalué à 3.

    J'avais utilisé cette doc de valaurea:
    http://valaurea.free.fr/documents/sig11_bind9_1.html
    Si cela peut servir :)
  • # Des nouveautés, mais...

    Posté par  . Évalué à 2.

    Le DNS est un des protocoles les plus anciens et sûrement un des moins maîtrisés par les "informaticiens", quoi que le nombre de vrais passionnés tend à rejoindre la limite de un sur l'infini.

    Toujours est-il que la documentation semble très complète, cependant, je me suis arrêté très rapidement sur deux ou trois passages, entre autre celui sur DNSsec.L'auteur nous apprend que DNSsec est peu comparable à TSIG, voire pas du tout : heureusement, il sont complémentaires.

    Pour avoir un point d'horizon beaucoup plus élevé, donc beaucoup plus léger, qui vient en complément de ce travail, ne pas hésiter à lire le chapitre concernant le DNS dans le document suivant :

    http://ferry.eof.eu.org/~jop/memoire.pdf
  • # Petites Notes

    Posté par  (site web personnel) . Évalué à 4.

    Petit résumé de ce que j'ai vu sur le début du document:

    FORWARD C'est la correspondance adresse IP vers un nom; c'est aussi la base du DNS. Exemple 127.0.0.1 doit donner localhost...etc.


    La définition est bonne, malheureusement l'exemple décrit exactement l'inverse.

    Résolution ITERATIVE : Ce n'est pas le mode de requête le plus rencontré car il est très spécifique. A ce sujet, il est important de savoir, qu'un « résolver » (niveau client ou application) ne peut agir autrement qu'en posant une question ...


    Amha il y a plus de serveurs dns Iteratifs que récursifs.
    A voir aussi les virgules me semble mal placées dans la 2me phrase.

    Attention à ne pas activer cette option par erreur, son action peut-être catastrophique.

    Heu catastrophique a quel point ? au pire tu n'a pas de résolution dns vers l'extérieur. Ce qui est catastrophique c'est d'activer le récursif sur un serveur public par contre.
    Sinon les serveurs racines c'est "ROOT SERVERS" et pas ROOT.

    Les deux adresses IP correspondent aux 2 DNS de mon FAI Iinternet.

    un petit 'l' en trop, voire un internet en trop tout court.

    Sans cet ordre, mes DNS auraient demandé à l'un des ROOT, par sécurité ils sont protégés de la RECURSION, la réponse aurait été négative.


    Non sans cet ordre ton serveur dns aurait effectué lui-même la récursion en commençant par les ROOT SERVERS, et en descendant dans l'arbre dns zone après zone, avec cet ordre tu charge les dns cache de ton fai de faire ce travail (ou de récupérer l'information depuis leur cache).
    C'est une bonne pratique, mais cela ne te permet pas de te protéger des dns wildcards (type noos pour le cas du wildcard au niveau FAI ou type verisign pour le cas du wildcard de zone).

    allow-recursion .... Ce paramètre allow-recursion { localhost ; localnets; }; est identique, et reste valable pour les paramètres suivants.
    .

    Problème de formulation ? "L'exemple précédent peut aussi s'écrire: <<allow-recursion { localhost; localnets; };>>"

    allow-recursion ....Ceci reste valable pour les autres paramètres similaires; il est possible d'interdire globalement, ou d'autoriser/interdire ceci au niveau des zones...

    Nope, cela n'aurait aucun sens de spécifier cela sur une zone.
    Cette option n'est valide que dans les contextes "options" et "view".

    allow-query -cache { 127.0.0.1; 192.168.1.0/24; }; Qui vis à vis de Bind peut interroger mon DNS via les caches... Cette option est inactive pour les DNS relié directement vers internet, vis à vis des clients potentiels de ce réseau.


    Un espace en trop "allow-query-cache".
    Et attention a ce parametre (ainsi qu'a allow-recursion), les valeurs par défaut pouvant être permissives (http://www.frsirt.com/bulletins/11191).

    Pour la suite, pas le temps de tout lire ce soir.
    • [^] # Re: Petites Notes

      Posté par  (site web personnel) . Évalué à 1.

      Bonjour et merci pour ces nombreuses remarques. Elles vont être evidemment reprises 1/1 pour modifier soit la phrase, soit la rendre plus explicite.
      Egalement merci à tout les autres personnes qui font que ce document avance ...
  • # Autre article sur une architecture DNS d'entreprise sécurisée

    Posté par  . Évalué à 2.

    Bonjour,

    Je vous soumets un autre article décrivant une architecture DNS d'entreprise sécurisée.

    Cet article a été co-écrit par Jean Michel Farin et moi même et est paru dans le numéro de MISC de Jan/Fév 2006.

    URL : http://brocas.org/blog/post/2006/06/22/14-de-la-securite-d-u(...)

    Bonne lecture !
    Christophe Brocas

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.