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
- Installer/configurer/exploiter Bind 9.4.x (25 clics)
- Le journal de référence (7 clics)
- BIND sur Wikipédia (3 clics)
# Crédit
Posté par Zenitram (site web personnel) . Évalué à 4.
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 :) )
[^] # Re: Crédit
Posté par BAud (site web personnel) . Évalué à 3.
donc merci à https://linuxfr.org/~AmT/ pour sa dépêche (et sa doc' libre).
[^] # Re: Crédit
Posté par Ellendhel (site web personnel) . Évalué à 2.
Bah, tu n'as pas lu la doc dont parle la dépêche ?
[^] # Re: Crédit
Posté par Laurent ARCHI (site web personnel) . Évalué à 3.
# Une autre doc
Posté par Nitchevo (site web personnel) . Évalué à 3.
http://valaurea.free.fr/documents/sig11_bind9_1.html
Si cela peut servir :)
# Des nouveautés, mais...
Posté par jean-philippe gaulier . Évalué à 2.
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 -=[ silmaril ]=- (site web personnel) . Évalué à 4.
La définition est bonne, malheureusement l'exemple décrit exactement l'inverse.
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.
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.
un petit 'l' en trop, voire un internet en trop tout court.
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).
.
Problème de formulation ? "L'exemple précédent peut aussi s'écrire: <<allow-recursion { localhost; localnets; };>>"
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".
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 Laurent ARCHI (site web personnel) . Évalué à 1.
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 Christophe Brocas . Évalué à 2.
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.