Un nouveau serveur DNS libre : PowerDNS

Posté par  (site web personnel) . Modéré par Fabien Penso.
Étiquettes :
0
2
déc.
2002
Internet
Après les nouvelles failles découvertes récemment dans Bind, nombreux sont ceux qui cherchent une solution libre, efficace et sûre pour mettre en place ou migrer un serveur DNS. Hélas, DjbDns n'est pas libre, et la plupart des autres solutions DNS sont incomplètes.
C'est donc à point nommé que tombe la mise sous licence GPL de PowerDNS, qui est conçu pour remplacer Bind tel quel (mêmes fichiers de configuration), tout en offrant une interface pour MySQL (tel mydns), mais aussi Oracle et PostgreSQL.

NdR: il semblerait que ce serveur ne soit pas utilisable en tant que cache DNS, mais on préfèrera peut-être s'orienter vers des logiciels spécialisés dans cette tâche.

Aller plus loin

  • # authoritative-only

    Posté par  . Évalué à 8.

    authoritative-only = pas récursif = pas pour les FAI = au revoir.
    • [^] # Re: authoritative-only

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

      Et hop : http://doc.powerdns.com/recursion.html(...)
      Là tu mets par exemple un pdnsd ou autre logiciel du genre, et tu as ta récursion.
      • [^] # Re: authoritative-only

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

        Avant que la réponse n'arrive : oui, je suis bien conscient que ce n'est pas optimal comme solution, et que Bind 9 ou DjbDns resteront plus adaptés pour certains cas (typiquement les gros FAI).
        • [^] # Re: authoritative-only

          Posté par  . Évalué à 4.

          Dans quelle cadre le lecteur de linuxFr a l'occasion d'administrer un serveur DNS ?

          Je ne suis pas un gros FAI, mais j'ai besoin d'un DNS
          - qui soit récursif pour mon réseau interne,
          - qui fasse du cache parce que ma liaison n'est qu'une liaison ADSL pas très stable
          - qui soit autoritaire pour héberger mon nom de domaine.
          - qui soit léger parce que je n'ai pas que lui à faire tourner et surtout que j'ai des besoins ridicules, (moins de 10 req/minute)

          Qu'est ce qu'il reste en rayon ?
          • [^] # Re: authoritative-only

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

            ...tous les DNS Libres à qui il manque ces fonctionnalités, mais que tu peux rajouter parceque c'est Libre ?

            "récursif" ? "autoritaire" ?
            Tu peux expliquer stp ? ou lien ?
            • [^] # Re: authoritative-only

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

              Récursif, ça veut dire qu'il sait aller chercher la ressource sur le réseau des serveurs DNS s'il n'en dispose pas. Autoritaire, ça veut dire qu'il fait « autorité » concernant un domaine, c'est donc à lui que sont adressées les requêtes concernant ce domaine.
          • [^] # Re: authoritative-only

            Posté par  . Évalué à 2.

            Je ne suis pas un gros FAI, mais j'ai besoin d'un DNS

            DjbDNS sans aucun doute. Il est excellent en sécurité et en performances sûrement. Je crois qu'il ne fait pas tout ce que fait BIND, je ne suis pas un expert, mais j'ai un copain qui a monté sa boîte d'hébergement et autres et qui ne jure que par DjbDNS. Il y a probablement des extensions disponibles sur des sites dédiés (comme pour qmail du même auteur).
      • [^] # Re: authoritative-only

        Posté par  . Évalué à 4.

        En gros c'est le même principe que les forwarders de bind, qui est pratique quand on a un serveur DNS local derrière une ADSL et qu'il est plus efficace de profiter du cache DNS de son FAI que de faire demander directement en récursif à son DNS.
        Mais pour une utilisation de DNS standard qui fait de la récursivité, ça rajoute une couche, c'est un peu lourd. Autant avoir un DNS récursif différent des DNS autoritaires... ce qui n'est pas nécessairement ce qu'on veut.
  • # MaraDNS

    Posté par  . Évalué à 5.

    Si je ne me trompe pas, MaraDNS, bien que ne supportant pas des interfaces avec des bases de données mais il est probablement plus sûr que bind et fonctionne en primaire, secondaire et cache.

    http://www.maradns.org/(...)
    • [^] # Re: MaraDNS

      Posté par  . Évalué à 1.

      Je confirme, il est excellent, très léger, très rapide. Par contre, il aurait besoin d'une base d'utilisateurs plus large pour se faire un nom...
  • # Re: Un nouveau serveur DNS libre : PowerDNS

    Posté par  . Évalué à 2.

    Je vois pas trop en quoi le fait qu'on ai trouve des failles dans BIND pose un probleme.
    C'est un logiciel libre et elles ont aussitot ete corrigees il me semble.
    On a aussi trouve des failles ds le kernel Linux c'est pas pour ca que tlm cherche a passer a autre chose non ?
    • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

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

      Je vois pas trop en quoi le fait qu'on ai trouve des failles dans BIND pose un probleme.
      En soi, ce n'est évidemment pas un problème. Le problème, c'est que ça pendait au nez : bind n'a pas été écrit avec la sécurité comme but. Qui plus est, les auteurs ont méprisé ouvertement la communauté en sortant leur patch sans aucune concertation avec les distributeurs. Donc si une faille est à nouveau découverte, ça va être le même cirque.
      • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

        Posté par  . Évalué à 1.

        Ah bon ? Je ne vois pas en quoi ils nous ont méprisé...
        As-tu de quoi rafraîchir la mémoire ?
        • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

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

          En gros, il s'est écoulé 3 semaines entre le moment où l'ISC a été informé et le moment où le patch a été diffusé. 3 semaines pendant lesquelles personne n'a été prévenu, ni le CERT, ni les distributeurs. Le premier a été prévenu 12 heures avant la diffusion du correctif et de l'exemple d'exploitation, il a prévenu les seconds, mais il était trop tard. Les distributeurs ont du sortir des patchs en catastrophe, sans les tester correctement (heureusement, tout s'est bien passé).
          N'oublions pas la participation de l'ISS, qui a découvert la faille et n'a pas jugé bon de prévenir qui que ce soit non plus. Rappelons que ce sont déjà eux qui ont découvert la faille d'OpenSSH, qui a été corrigée avec le même manque de sérieux.
          • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

            Posté par  . Évalué à 4.

            Justement, je jetterais plus volontiers la pierre à l'ISS qui a pris un malin plaisir à crier sur tous les toits qu'ils avaient découverts des failles sur des logiciels Libres célèbres et , ce, sur leur dos...
            • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

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

              l'ISS qui a pris un malin plaisir à crier sur tous les toits qu'ils avaient découverts des failles sur des logiciels Libres célèbres et , ce, sur leur dos...

              Je ne vois pas ce que représent le fait de "touver des failles de sécurité 'sur le dos' de l'auteur". Et j'ai justement l'impression qu'ils ne l'ont pas crié sur tous les toits (vu que ce que tu leur reproche c'est de ne pas l'avoir dit à des gens concernés).

              Perso je n'ai rien à leur reprocher. Ils ont choisi de ne pas le crier sur tous les toits , ce qui n'est pas forcément un mal. Qui avertir si je trouve une faille de sécu dans un soft majeur ? perso je préviendrai les mainteneurs du softs (et uniquement eux). Non pas que je ne veuille pas que les diffuseurs soient au courant, mais je n'ai pas de liste des ces diffuseurs, je vais forcément en oublier et je ne gagne justement rien à jouer le mariole en disant "j'ai trouvé une faillleuuxxxx". Alors si ca m'arrivait je préviendrai les mainteneurs, charge à eux de prévenir tout le monde si ils trouvent que la faille / le patch le nécéssite.

              Non, la faute revient effectivement à ceux qui ont recu la faille (les mainteneurs de Bind et Openssh dans ce cas).
              • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

                Posté par  . Évalué à 1.

                J'ai plus senti un besoin de plublicité à chercher des trous de sécurité à tout va sur plusieurs logiciels Libres annoncés à la suite qu'autre chose...
                Quant à savoir lesquels ont mal communiquer avec les autres,
                il y a quand même un point commun: les deux projets ont eu du mal avec ISS.
                Est-ce pour autant que les développeurs de Bind et OpenSSH manquent d'ouverture ?...
              • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

                Posté par  . Évalué à 2.

                Non, la faute revient effectivement à ceux qui ont recu la faille (les mainteneurs de Bind et Openssh dans ce cas).

                Justement le probleme ce qu'ils ont uste dit "y une faille" et n'ont rien fourni de precis au maintainers.
                En ce qui concerne OpenSSH, ISS a dit comblez la faille avant que nous publions des details a son propos et ceci sans fournir de precisions sur la dite faille, charmant non ?
                Heureusement l'utilisation des privsep a permit de limiter les degats.
    • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

      Posté par  . Évalué à 1.

      http://www.holland-consulting.net/tech/ocep/index.html#BIND(...)

      Sur cette page, on a l'explication du fait que ce soit BIND 4 qui est installé par défaut sur OpenBSD.
      On y apprend que le code de bind 8 est completement crade et que dans la version 9 ils n'ont pas fait le nettoyage necessaire et qu'il est par conséquent difficilement auditable.

      Bind a aussi un lourd passé historique (cf. http://linuxfr.org/2002/11/15/10309.html(...) ).

      J'ajouterais que la diversité ne fait pas de mal (tant que c du LL of course ;-), ainsi lorsqu'une faille est découverte, la majorité des dns n'est pas compromise.
      • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

        Posté par  . Évalué à -1.

        > On y apprend que le code de bind 8 est completement crade ...

        Mais ils disent aussi que "BIND 9 -- it was supposed to be a complete rewrite with security in mind".

        Et bind en est à la version 9.2.1 dans la référence que tu donnes doit être assez vieille.

        > Bind a aussi un lourd passé historique

        Fort ta référence. Je pense que l'on trouve facilement autant de bugs de sécurité dans apache ou php. A une certaine époque il n'y avait pas un mois sans un trou de sécurité dans Linux.
        • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

          Posté par  . Évalué à 2.

          > Je pense que l'on trouve facilement autant de bugs de sécurité dans apache ou php. A une certaine époque il n'y avait pas un mois sans un trou de sécurité dans Linux.

          Ton argument revient à dire que cela n'a pas d'importance vu que d'autres logiciels possèdent aussi des failles !

          Sérieusement, bind9 est sans doutes un bon programme et vu sa complexité, il est plus probable qu'il y aie des failles. C'est pour çà que un serveur dns moins complet, plus adapté dans certains cas et moins lourd sera plus sécure, ne fut-ce que par une configuration plus simplifiée.

          La diversité est un plus dans le monde des logiciels libres et de la sécurité.
          • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

            Posté par  . Évalué à 1.

            « Ton argument revient à dire que cela n'a pas d'importance vu que d'autres logiciels possèdent aussi des failles ! »

            On peut le voir ainsi. Et dans ce cas, il est peu pertinent.

            Mais on peut penser que FM ne désirait pas dire que ces bugs n'ont « pas d'importance » mais qu'il cherchait plutot à répondre à l'argument du « lourd passé historique ». En effet, si le « passé historique » est un argument valable, que penser d'apaches, php ?
    • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

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

      Quand un soft a des failles à répétition, libre ou pas, qu'il corrige ou pas, on est en droit de se poser des questions quand à la pertinence de son installation.

      Qu'il soit libre n'empeche pas de penser à d'autres possibilités peut etre plsu adaptées pour certaines utilisations.
  • # PowerDNS : pourquoi le libérer ?

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

    "C'est donc à point nommé que tombe la mise sous licence GPL de PowerDNS [...]"

    Je me suis donc posé la question : pourquoi ont-ils libéré+copylefté sous GPL un produit propriétaire ?
    ...heureusement, la news a été bien rédigée+modérée :
    http://doc.powerdns.com/powerdns-company-faq.html(...)
    Copier-coller :
    Q: Is the open source version crippled?
    A: It is not. Not a single byte has been omitted.

    Q: Is the nameserver abandoned?
    A: Far from it. In fact, we expect development to speed up now that we have joined the open source community.

    Q: Why is the nameserver now open source?
    A: In the current economic climate and also the way the Internet is built up right now, selling software is very hard. Most potential customers had never before bought a piece of software for their UNIX internet setup. Even though we know (from the recent survey) that nameserver operators love PowerDNS, their suggested price for it is in the $100 range.

    For us, it makes far more sense to open source PowerDNS than to ask $100 for it. It is expected that open sourcing PowerDNS will lead to far higher adoption rates. We hope that PowerDNS will soon be included in major Linux and UNIX distributions.

    Q: How does PowerDNS.COM BV expect to make money now that the nameserver is free?
    A: In fact, we don't expect to in the near future. We also don't have a lot of expenses, basically some hosting and a few domain names.
    However, we are available for consulting work, for example to help a large registrar or registry migrate to PowerDNS, or to help integrate our software in existing provisioning systems.
    Furthermore, non-GPL licenses are available for those needing to do closed source modifications, or for customers uncomfortable with the GPL. This is much like what MySQL AB is doing now.
    In fact, their strategy is a lot like ours in general.

    Q: Can I buy support contracts for PowerDNS?
    Sure, to do so, please contact us at <sales@powerdns.com>

    Q: Will you accept patches? We've added a feature
    Probably - in general, it is best to discuss your intentions and needs on the <pdns-dev@mailman.powerdns.com> (subscribe) mailinglist before doing the work. We may have suggestions or guidelines on how you should implement the feature.

    Q: PowerDNS doesn't work on my platform, will you port it?, Q: PowerDNS doesn't have feature I need, will you add it?
    Be sure to ask on the <pdns-dev@mailman.powerdns.com> (subscribe) mailinglist. You can even hire us to do work on PowerDNS if plain asking is not persuasive enough. This might be the case if we don't currently have time for your feature, but you need it quickly anyhow, and are not in a position to submit a patch implementing it.

    Q: Will PowerDNS Express be open sourced? PowerMail?
    Perhaps, we're not yet sure. PowerMail most probably.

    Q: We are a Linux/Unix vendor, can we include PowerDNS?
    A: Please do. In fact, we'd be very happy to work with you to make this happen. Contact <ahu@ds9a.nl> if you have specific upstream needs.


    Doit-on donc citer cette conversion comme référence ?

    Peut-on espérer convertir d'autres produits logiciels de la même manière ?
    • [^] # Re: PowerDNS : pourquoi le libérer ?

      Posté par  (Mastodon) . Évalué à 1.

      D'un autre côté, prendre comme exemple "ça ne se vend pas, alors on a libéré les sources et on le donne gratuitement", ça ne va peut être pas attirer des millions d'entreprises ;-)
      • [^] # Re: PowerDNS : pourquoi le libérer ?

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

        Quand tu es éditeur proprio d'un produit qui est très peu utilisé sur un marché saturé, tu peux te permettre de le "vendre" gratuitement... donc augmenter un peu tes parts de marché, et globalement ton volume... tes revenus dû à tes services ne pourront que s'améliorer dans la même mesure que l'augmentation de diffusion du produit.

        Ici, ils vont augmenter la diffusion du produit du fait de la gratuité, mais en plus du fait qu'il est Libre.

        Ils espèrent en plus obtenir de l'aide d'une communauté du Libre d'une part, et une plus grande implication des utilisateurs d'autre part (bug report, feature requests, ...). Tout ça va sans doute catalyser le développement et augmenter sa vitesse (une des conditions réussite : l'ouverture, ce à quoi ils ont apparemment pensé).

        Donc les services vont augmenter d'autant plus...
        • [^] # Re: PowerDNS : pourquoi le libérer ?

          Posté par  (Mastodon) . Évalué à 1.

          Je ne critique pas leur décision, qui était sûrement bonne, je fais juste remarquer que, formulé comme c'est, ce n'est pas très séduisant pour illustrer la réussite du modèle "open source" comme modèle économique. À moins d'être déjà convaincu de ses bienfaits.

          Le présenter comme une alternative quand on n'arrive pas à vendre, ben euh... oui, c'est aussi applicable à Netscape->Mozilla et StarOffice->OpenOffice.org, voire Blender. Mais ça fait toujours un peu solution de rechange.
  • # Cache DNS ?

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

    il semblerait que ce serveur ne soit pas utilisable en tant que cache DNS, mais on préfèrera peut-être s'orienter vers des logiciels spécialisés dans cette tâche.

    Justement, quel logiciel existe-t-il pour faire office de cache DNS ?

    Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment

  • # Re: Un nouveau serveur DNS libre : PowerDNS

    Posté par  . Évalué à 2.

    Faut pas tout mélanger.
    C'est pas parce qu'il y a des bugs de sécurité découvert dans un programme qu'il n'est pas sure. Linux a déjà eu des tonnes de trou de sécurité et c'est un système très sure.

    Ce type de news est dans la ligne du FUD que fait MS :
    - Regardez y a plein de trou de sécurité sous GNU/Linux (CF les sites spécialisé) donc GNU/Linux n'est pas sure.
    • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

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

      Ce ne sont pas tant les trous de sécu qui sont gratuitement critiqués, mais plutôt le comportement de l'équipe face aux bugs : avec une telle importance, le moindre petit bug a des répercussions qui peuvent être désastreuses...
      • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

        Posté par  . Évalué à 0.

        > mais plutôt le comportement de l'équipe face aux bugs

        C'est pas évident de voir çà qu'en on ne lit que la news (je ne parle que de la news!).
      • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

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

        Non, c'est aussi le fait que Bind a déjà connu de nombreux bugs, car il mal codé, et surtout la sécurité n'a pas été prise en compte au moment de sa conception: par défaut il n'est ni chrooté, ni chowné (il tourne en root quoi) contrairement à d'autres serveurs DNS (comme djbdns).
        Donc il n'est pas exclu que Bind connaise d'autres failles de sécu.

        De plus c'est inquiétant qu'un serveur, qui plus est pour un service indispensable au fonctionnement du net, qui ait tout ces défauts soit en position de quasi-monopole.
        • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

          Posté par  . Évalué à 0.

          > surtout la sécurité n'a pas été prise en compte au moment de sa conception
          C'est normal a l'époque de sa création la sécurité n'était pas une obsession comme maintenant.

          > par défaut il n'est ni chrooté
          chrooté un programme c'est bien quand il a des trous de sécurité. Sinon çà ne présente aucun interêt. Apache n'est pas chrooté, proftpd n'est pas chrooté, ssh n'est pas chrooté, xinetd n'est pas chrooté (normal sinon çà marche pas) etc, etc...
          proftpd peut chrooter lors d'une connection. Mais la doc proftpd explique que ce n'est pas idéal pour la sécurité.

          > ni chowné (il tourne en root quoi)
          Comme les autres...
          extrait de man named :

          -u user
          setuid() to user after completing privileged operations, such as
          creating sockets that listen on privileged ports.

          Note: On Linux, named uses the kernel’s capability mechanism to
          drop all root privileges except the ability to bind() to a priv&#8208;
          ileged port and set process resource limits. Unfortunately,
          this means that the &#8208;u option only works when named is run on
          kernel 2.2.18 or later, or kernel 2.3.99&#8208;pre3 or later, since
          previous kernels did not allow privileges to be retained after
          setuid().

          > De plus c'est inquiétant qu'un serveur, qui plus est pour un service indispensable au fonctionnement du net, qui ait tout ces défauts soit en position de quasi-monopole.

          Faut arrêter tout ce FUD. Si bind était la merde que tu sous-entends il y a longtemps qu'il aurait été remplacé et jusqu'à maintenant il a très bien résisté à de très très nombreuse attaque.

          Mais si tu paniques toujours, tu peux installé un service DNS sur Windows.
          • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

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

            > par défaut il n'est ni chrooté
            chrooté un programme c'est bien quand il a des trous de sécurité. Sinon çà ne présente aucun interêt. Apache n'est pas chrooté, proftpd n'est pas chrooté, ssh n'est pas chrooté, xinetd n'est pas chrooté (normal sinon çà marche pas) etc, etc...
            proftpd peut chrooter lors d'une connection. Mais la doc proftpd explique que ce n'est pas idéal pour la sécurité.


            Moi je dis pareil, je peux faire de l'irc en root : mon client irc n'a aucune faille connue. Avec ce principe tu peux virer toutes les sécurités, vu que de toute facon les failles ne sont pas censer exister.
            Tu oublies tout de même le principe de faille potentielle. Il y a ou aura des failles, dont certaines seront connues. Le tout est que quand ca arrive ca soit le plus difficilement exploitable. Mettre des sécurités en plus pour limiter la casse ne peut pas faire de mal.
          • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

            Posté par  . Évalué à 2.

            > chrooté un programme c'est bien quand il a des trous de sécurité. Sinon çà ne présente aucun interêt.

            N'importe quoi !
            C'est idiot de se passer de chroot, car à moins d'un bug dans le noyeau c'est un des meilleurs moyen pour sécuriser un programme. Si les programmes n'avaient pas de bug, cela se saurait :-)

            > Apache n'est pas chrooté, ssh n'est pas chrooté,
            Faux !
            sshd utilse chroot : extrait du man
            /var/empty
            chroot(2) directory used by sshd during privilege separation in
            the pre-authentication phase.


            Apache et bind sont chrooté par défaut sous openbsd.
            • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

              Posté par  . Évalué à 1.

              Ce qui suit répond aussi à la question du « par défaut »

              Linux loge2 2.4.18-586tsc #1 Sun Apr 14 10:57:57 EST 2002 i586 unknown

              Most of the programs included with the Debian GNU/Linux system are
              freely redistributable; the exact distribution terms for each program
              are described in the individual files in /usr/share/doc/*/copyright

              Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
              permitted by applicable law.
              Last login: Mon Dec 2 21:23:29 2002 from dionysos
              root@loge2:~# ps euax
              USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
              root 1 0.0 1.4 1272 432 ? S 06:23 0:00 init TERM=linux
              root 2 0.0 0.0 0 0 ? SW 06:23 0:00 [keventd]
              root 3 0.0 0.0 0 0 ? SWN 06:23 0:00 [ksoftirqd_CPU0]
              root 4 0.0 0.0 0 0 ? SW 06:23 0:16 [kswapd]
              root 5 0.0 0.0 0 0 ? SW 06:23 0:00 [bdflush]
              root 6 0.0 0.0 0 0 ? SW 06:23 0:00 [kupdated]
              root 13 0.0 0.0 0 0 ? SW 06:24 0:11 [kjournald]
              root 97 0.0 0.0 0 0 ? SW 06:24 0:08 [kjournald]
              root 139 0.0 0.0 0 0 ? SW 06:24 0:00 [eth0]
              root 159 0.0 2.0 1472 616 ? S 06:24 0:00 /sbin/dhclient-2.
              daemon 167 0.0 1.2 1384 380 ? S 06:24 0:00 /sbin/portmap PWD
              root 226 0.0 1.8 1364 556 ? S 06:24 0:27 /sbin/syslogd PWD
              root 229 0.0 1.2 1900 388 ? S 06:24 0:02 /sbin/klogd PWD=/
              root 239 0.0 1.5 1444 488 ? S 06:24 0:00 /sbin/rpc.statd P
              root 243 0.0 2.0 1484 612 ? S 06:24 0:00 /usr/sbin/dhcpd-2
              daemon 256 0.0 1.6 1964 492 ? S 06:24 0:00 lpd Waiting
              root 270 0.1 0.0 0 0 ? SW 06:25 1:02 [nfsd]
              root 271 0.0 0.0 0 0 ? SW 06:25 0:00 [lockd]
              root 272 0.0 0.0 0 0 ? SW 06:25 0:00 [rpciod]
              root 273 0.1 0.0 0 0 ? SW 06:25 1:01 [nfsd]
              root 274 0.1 0.0 0 0 ? SW 06:25 1:00 [nfsd]
              root 275 0.1 0.0 0 0 ? SW 06:25 1:00 [nfsd]
              root 276 0.1 0.0 0 0 ? SW 06:25 1:01 [nfsd]
              root 277 0.1 0.0 0 0 ? SW 06:25 1:00 [nfsd]
              root 278 0.1 0.0 0 0 ? SW 06:25 0:59 [nfsd]
              root 279 0.1 0.0 0 0 ? SW 06:25 1:02 [nfsd]
              root 282 0.0 1.6 1512 496 ? S 06:25 0:00 /usr/sbin/rpc.mou
              root 288 0.0 2.4 2784 740 ? S 06:25 0:06 /usr/sbin/sshd PW
              root 297 0.0 1.7 2056 528 ? S 06:25 0:00 /usr/sbin/xinetd
              daemon 310 0.0 0.7 1384 232 ? S 06:25 0:00 /usr/sbin/atd PWD
              root 313 0.0 1.3 1652 404 ? S 06:25 0:00 /usr/sbin/cron PW
              root 373 0.0 2.0 71804 624 ? S 06:25 0:04 /usr/sbin/apache-
              root 382 0.0 0.9 1240 300 tty8 S 06:25 0:00 run --restart --r
              root 388 0.0 1.2 2020 372 tty8 S 06:25 0:00 less +F /var/log/
              root 391 0.0 0.9 1240 300 tty9 S 06:25 0:00 run --restart --r
              root 395 0.0 1.2 2944 372 tty9 S 06:25 0:01 less +F /var/log/
              root 396 0.0 1.2 1256 392 tty1 S 06:25 0:00 /sbin/getty 38400
              root 397 0.0 1.2 1256 392 tty2 S 06:25 0:00 /sbin/getty 38400
              root 398 0.0 1.2 1256 392 tty3 S 06:25 0:00 /sbin/getty 38400
              root 399 0.0 1.2 1256 392 tty4 S 06:25 0:00 /sbin/getty 38400
              root 400 0.0 1.2 1256 392 tty5 S 06:25 0:00 /sbin/getty 38400
              root 401 0.0 1.2 1256 392 tty6 S 06:25 0:00 /sbin/getty 38400
              www-data 544 0.0 0.8 2996 272 ? S 06:31 0:00 /usr/lib/apache-s
              www-data 550 0.0 9.6 72516 2948 ? S 06:31 0:18 /usr/sbin/apache-
              www-data 2174 0.0 9.9 72520 3032 ? S 06:37 0:11 /usr/sbin/apache-
              www-data 2175 0.0 10.1 72540 3100 ? S 06:37 0:11 /usr/sbin/apache-
              mail 4179 0.0 2.1 2804 664 ? S 16:26 0:00 /usr/bin/exim -bd
              root 5264 0.0 1.7 2584 532 ? S 19:53 0:00 SCREEN -l PWD=/ro
              root 5265 0.0 1.7 2704 536 pts/2 S 19:53 0:01 /bin/bash STY=526
              fetchma 5703 0.3 3.7 3348 1148 ? S 20:59 0:19 /usr/bin/fetchmai
              mail 6315 0.0 3.3 2832 1016 ? S 22:29 0:00 /usr/bin/exim -bd
              mail 6316 0.0 3.3 2832 1016 ? S 22:29 0:00 /usr/bin/exim -bd
              mail 6332 0.0 3.3 2832 1016 ? S 22:31 0:00 /usr/bin/exim -bd
              mail 6333 0.0 3.3 2832 1016 ? S 22:31 0:00 /usr/bin/exim -bd
              mail 6336 0.0 3.2 2828 1008 ? S 22:33 0:00 /usr/bin/exim -bd
              root 6337 1.7 5.0 5668 1548 ? S 22:33 0:00 /usr/sbin/sshd PW
              mail 6339 0.1 3.3 2832 1016 ? S 22:33 0:00 /usr/bin/exim -bd
              root 6340 10.8 5.0 2708 1556 pts/0 S 22:33 0:01 -bash USER=root L
              root 6356 0.0 4.6 3296 1424 pts/0 R 22:33 0:00 ps euax PWD=/root
            • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

              Posté par  . Évalué à 1.

              > sshd utilse chroot
              Il utilise chroot comme proftpd utilise chroot. Le serveur n'est pas toujours chrooté, il n'y a pas une arborescense spécifique pour lui (/lib/libc.so, /etc/passwd, etc...).

              Si tu as pleins de services chrootés il te faut plein de libc etc... pour chaque chroot. çà bouffe de la mémoire et pose des problèmes pour mettre à jour la librairie C et autre qui sont utilisés par les programmes chrootés (faut pas oublier de mettre à jour une librairie C etc...).

              Afin si (par exemple) apache est chrooté comment tu fais pour utiliser des scripts perl en cgi, etc... Tu fais une installe de perl dans le répertoire chroot d'Apache ? Comment tu fais pour utiliser la directive user_dir d'apache si apache est chrooté ? Tu copies /etc/passwd et consort dans le répertoire chrooté d'Apache ? Pour qu'Apache supporte user_dir il doit être root ou pouvoir utiliser un programme avec suid comme suexec. Imagine que ta partition racine soit /dev/hda1. S'il y a un trou de sécurté dans suexec et que tu l'exploites, tu peux faire un "mount /dev/hda1 /quelque_part" après avoir déposé un programme sur le serveur et tu perds tout l'intérêt de chroot. Si tes scrips cgi utilisent d'autres programmes il faut aussi les copier dans le répertoire chrooté etc, etc, etc... Et plein de problème pour maintenir ta bécane et donc des risques d'erreur humain (qui est certainement la première cause de perte de donnée, de temps etc...).

              bind chrooté : pourquoi pas. Mais Apache chrooté : bof. Si quelqu'un gagne les droits du compte named ou apache, çà va pas bien loin... A moins que ta bécane soit mal installée...

              openbsd avec leur obsession de la sécurité va finir par chrooté X ... Mieu encore a la création d'un compte, il font une installation complète d'openbsd dans /home/toto puis lorsque tu te loggue tu es chrooté dans /home/toto.

              Franchement cette paranoïa est ridicule. Les plus gros problèmes de sécurité c'est pas si tel ou tel programme utilise chroot. C'est la configuration des services (erreur humaine) et la non maintenance des bécanes (non application des correctifs).
              • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

                Posté par  . Évalué à 0.

                > Pour qu'Apache supporte user_dir il doit être root
                Je veux dire pour qu'Apache supporte user_dir avec des scripts cgi qui sont lancé avec le compte accédé. Cette fonctionnalité marche de paire avec suexec et suexec peut marché par virtual host.
                Exemple :
                http://qqpart/~toto/index.php(...)
                index.php est lancé en cgi avec les privilèges du compte toto.
                Ce qui est plus sure surtout si toto peut déposer des scripts php via ftp par exemple. Si le mot de passe du compte toto est connu par un cracker, les scripts déposés par le cracker seront limités aux possibilités du compte toto.
                • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

                  Posté par  . Évalué à 1.

                  Il me semble qu'Apache déconseille l'utilisation de suexec. Pour PHP il vaut mieux utiliser les protections fournies avec (safe_mode, open_basedir), ceci en conjonction avec une gestion "normale" des utilisateurs Unix.
                  • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

                    Posté par  . Évalué à 0.

                    > Il me semble qu'Apache déconseille l'utilisation de suexec.
                    QUOI !?!?

                    Extrait de la doc (http://httpd.apache.org/docs/suexec.html(...)) :
                    -------------------
                    Used properly, this feature can reduce considerably the security risks involved with allowing users to develop and run private CGI or SSI programs. However, if suEXEC is improperly configured, it can cause any number of problems and possibly create new holes in your computer's security. If you aren't familiar with managing setuid root programs and the security issues they present, we highly recommend that you not consider using suEXEC.
                    --------------------

                    En gros c'est du bon matos mais mal configuré çà peut être une merde.

                    > Pour PHP il vaut mieux utiliser les protections fournies avec (safe_mode, open_basedir)
                    Le problème est que ces protections son assez facilement contournables dans certain cas.

                    Exemple :
                    Je veux permettre à l'internaute d'uploader des .tgz et de les désarchiver.
                    Je met le fichier untargz.sh dans l'arborescence du site :

                    #!/bin/bash
                    cat $1 | gzip -d | tar xf -

                    puis je l'exécute avec php avec :

                    exec("scripts/untargz.sh /tmp/upload.tgz" , $output, $ret) ;

                    çà marche même avec safe_mode et open_basedir. C'est tant mieux vu l'énoncé du problème.

                    Maintenant j'autorise mon client a modifier les scripts php de son site (bref il devient le développeur du site). Le client, ou un cracker qui a eu connaissance du mot de passe du compte ftp qui permet de modifier le site, met dans le untargz.sh "rm -r -f /". çà marche toujours très bien.
                    Si j'utilise suexec les dégats seront limités au compte du site. Si je n'utilise pas suexec (donc j'ai le même compte pour tous les sites hébergés puisque qu'apache ne change pas de compte) ben je peux detruire tous les sites !

                    L'autre avantage d'utiliser suexec est la possibilité de mettre des quotas par site (chaque site ayant son compte Unix). Ainsi si un site peut-être modifié par un client via ftp, il ne peut pas saturer les disques (ce qui serait dramatique pour le bon fonctionnement du serveur).

                    Le seul problème de ce type de solution est que les fichiers servies par apache doivent être lisible par apache (lecture pour le compte apache). Donc les fichiers des sites web (qui ont chaqu'un un compte spécifique) doivent être en lecture pour tout le monde (ou au moins pour le groupe apache, mais dans ce cas, mes comptes font aussi parti du groupe apache). Donc dans mon cas d'utilisation de suexec il y a possibilité de lire tous les fichiers des autres sites (mais pas de les modifiers).
                    La bonne solution serait peut-être d'utiliser les ACL . Mais là j'y connais pas grand chose...
                    • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

                      Posté par  . Évalué à 1.

                      (...) Le client, ou un cracker qui a eu connaissance du mot de passe du compte ftp qui permet de modifier le site, met dans le untargz.sh "rm -r -f /". çà marche toujours très bien.

                      Heu, t'as mal foutu ton truc alors. Si tu veux fournir des scripts shell à tes clients, tu les mets dans un répertoire protégé où les clients n'ont pas le droit d'écriture (pas dans leur $HOME quoi !). D'autre part tu limites les possibilités d'exécution depuis PHP à ce répertoire protégé (directive safe_mode_exec_dir, un truc dans le genre). Comme ça une connerie d'un client ne peut pas compromettre ton système. Bien ça une connerie de ta part peut toujours le compromettre :)

                      Donc dans mon cas d'utilisation de suexec il y a possibilité de lire tous les fichiers des autres sites (mais pas de les modifiers).

                      Là aussi le safe_mode de PHP règle le problème : tu n'as le droit de lire que les fichiers ayant le même uid que le processus Apache.
                      • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

                        Posté par  . Évalué à 0.

                        > Heu, t'as mal foutu ton truc alors.

                        Je crois que tu n'as pas bien compris.

                        Ta méthode marche mais elle ne répond pas à tout le problème :
                        1 - c'est toi qui gère les scrips cgi du client.. Dans mon cas, je peux laisser le client faire ces scripts cgi (puisqu'il a son propre compte).
                        2 - tu ne peux pas appliquer les quotas dans ton cas (n'oublies que les uploads sont dans le compte apache dans ton cas). Ce point est très important si le client à un acces en écriture via ftp par exemple ou s'il peut modifier les scripts php ou s'il peut réaliser des uploads etc, etc, ...
                        3 - dans ton cas, tu ne peux pas raisonnablement autoriser des binaires fournis par le client.

                        De plus si j'utilise les acl (c'est un domaine que je dois creuser) je peux authoriser ssh et donc les crontabs, les mysql_dump, etc, etc... j'autorise ssh uniquement avec acl sinon il est vraiment trop simple pour le client de voir les fichiers des autres sites (même ceux qui sont protégés via http par un fichier .htaccess).
                        Sinon, si les acl ne repondent pas au problème, je peux faire une conf d'apache mini (et minucieusement audité) qui troune sous le compte root et mettre les fichiers des sites non lisible pour les autres.

                        Les systèmes de sécurité de php sont satisfesants dans beaucoup de cas. Néanmoins pour les exisgences de certains clients suexec peut être indispensable.

                        > pas dans leur $HOME quoi !
                        $HOME n'est pas forcément utilisé par suexec.
                        Exemple :
                        <VirtualHost>
                        ServerName www.toto.com
                        User toto
                        Group website
                        DocumentRoot /var/www/html/www.toto.com/site/
                        php_flag engine off
                        AddHandler php-script .php
                        Action php-script /cgi-bin-local/php
                        ScriptAlias /cgi-bin-local/php "/var/www/html/www.toto.com/cgi-bin-local/php"
                        [...]
                        </VirtualHost>
                        Le site www.toto.com tourne sous le compte toto (les cgi du moins, il faut donc désactiver mod_php pour ce site et utilisé php en cgi).
                        /var/www/html/www.toto.com/cgi-bin-local/php est tout con :
                        #!/bin/bash
                        exec php $*

                        L'intérêt de ce petit wrapper est que le fichier php.ini utilisé par php est /var/www/html/www.toto.com/cgi-bin-local/php.ini. Ce qui permet de configurer php en fonction du site (ou du répertoire, etc...). Le problème est que les directives php_* dans httpd.conf ne marche pas pour php en cgi.

                        Le $HOME de toto peut être /home/toto. çà n'a aucune importance.

                        Par contre $HOME est utilisé lors de l'utilisation de UserDir :
                        UserDir public_html

                        http://127.0.0.1/~toto/(...) => /home/toto/public_html/

                        Les scripts cgi tourne sous le compte toto (si suexec est installé).

                        Enfin, on peut ausi appliquer suexec par répertoire (ici http://hostname/www.toto.com/(...) ):
                        ProxyPass /www.toto.com/ http://www.toto.com.localhost/(...)
                        ProxyPassReverse /www.toto.com/ http://www.toto.com.localhost/(...)

                        L'ip de www.toto.com.localhost est 127.0.0.1.
                        Il reste à définir le virtual host www.toto.com.localhost (évidament non accessible de l'extérieur) comme fait au-dessus.

                        PS : Il existe d'autre solutions que suexec...
                        • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

                          Posté par  . Évalué à 1.

                          2 - tu ne peux pas appliquer les quotas dans ton cas (n'oublies que les uploads sont dans le compte apache dans ton cas).

                          Sur ce point précis, tu dois pouvoir appliquer les quotas de groupe et non d'utilisateur (si ça marche - jamais essayé), en assignant un groupe précis à chaque user, en mettant leur HOME sous user générique apache / groupe spécifique / mode g+s (quand je dis HOME, je parle du compte Web, pas spécifiquement de /home/user), en utilisant le safe_mode_gid de PHP, et en réglant leur umask à 002.
                          • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

                            Posté par  . Évalué à 0.

                            > tu dois pouvoir appliquer les quotas de groupe
                            Mouais. mais c'est un peu tordu. L'utilisateur devient le group et le group l'utilisateur.

                            > si ça marche - jamais essayé
                            les quota sur groupe marche.

                            > et en réglant leur umask à 002.
                            007 puisque les fichiers créés ont uid=apache.

                            > je parle du compte Web, pas spécifiquement de /home/user
                            Oublie le HOME. En général pour un site web j'ai :
                            - /home/www/toto : çà c'est pour le développeur (stockage de doc, etc...)
                            - /var/www/html/toto : çà c'est le site web. apache n'utilise jamais /home/www/toto (sauf avec user_dir).
                            - /var/www/data/toto : upload, statistiques, etc... Tout ce qui est dynamique. C'est ici que je pourrai faire le chmod g+s .

                            > Sur ce point précis

                            Malheureusement...
                            J'avais déjà étudié cette possibilité... et je l'utilise pour mysql. Elle est intéressante pour les sites où le client ne peut déposer de fichiers php (il n'est pas le développeur). Mais c'est cool pour les sites avec statistique et/ou upload.
              • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

                Posté par  . Évalué à 1.

                openbsd avec leur obsession de la sécurité va finir par chrooté X ...

                Bah il est deja sous privsep ce qui est loin de me mecontenter.

                Franchement cette paranoïa est ridicule. Les plus gros problèmes de sécurité c'est pas si tel ou tel programme utilise chroot. C'est la configuration des services (erreur humaine) et la non maintenance des bécanes (non application des correctifs).

                Ce que tu ne comprends pas c'est meme si le chroot n'empeche pas la faille , il a au moins le merite de limiter les degats d'ou son importance quand on parle d'un programme lance en root.
                • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

                  Posté par  . Évalué à 1.

                  > Ce que tu ne comprends pas c'est meme si le chroot n'empeche pas la faille ,
                  Je le sais. Mais il y a plein de truc à s'occuper avant d'en arrivé là...

                  > il a au moins le merite de limiter les degats
                  La meilleur façon de limité les degats est d'avoir un bon backup...
                  Les backup ont en parle jamais ici alors que c'est le truc le plus important !
        • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

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

          De plus c'est inquiétant qu'un serveur, qui plus est pour un service indispensable au fonctionnement du net, qui ait tout ces défauts soit en position de quasi-monopole.

          Le probleme est que bind est l'implémentation de référence.
          Le logiciel est fait par les gens qui font les RFC.
          Donc de facto, c'est celui dans lequel on trouvera le plus de failles.

          Quant au "programmé sans la sécurité comme objectif" j'aimerais bien qu'on m'explique un jour.
        • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

          Posté par  . Évalué à 2.

          Mais mais...
          IP aussi c'est mal conçu alors !
          Hé oui, à l''origine, Internet n'était pas conçu dans l'optique de la sécurité, mais du partage de la connaissance, purement et simplement...
          La bêtise humaine étant, ces idéalismes deviennent caduques.
          Maintenant, Bind9 est automatiquement chrooté chez Debian,
          si ce n'est pas le cas de ta distribution, tu sais ce qu'il te reste à faire.
          Ensuite, malgré toutes les qualités intrasèques de djbdns, il n'a jamais connu le même succés que Qmail... Pourquoi ? Parce qu'il n'est pas assez connu du décideur pressé ? Si on les écoutais, on aurait déjà des serveurs DNS sous win2k... La vraie raison est sans doute ailleurs...
          En outre, pour un service aussi important, il a plutôt bien tenu la charge des dernières DDoS... Est-ce que d'autres serveurs DNS en aurait été capable ?
          Personne ne le sait.
          Maintenant, plutôt que cracher sur Bind, XFree86 ou d'autres logiciels qui datent du début quand même et servent toujours aussi bien sans vraiment faillir,
          j'estime qu'il vaut mieux contribuer à des projets de ce genre plutôt que de vouloit briller tout seul dans son coin à la DJB (et encore, il fait du bon code, lui).
          Aprés, chacun est libre de faire ce qu'il veut.
          • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

            Posté par  . Évalué à 1.

            > Maintenant, plutôt que cracher sur Bind, XFree86 ou d'autres logiciels
            Faudrait déjà les remercier d'avoir développer en freesoftware de si bon programmes. Bind a rendu et rend toujours d'énormes services et ce de façon fiable et sous licence BSD-like.

            Merci Messieurs et Mesdame (s'il y en a) !
            • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

              Posté par  . Évalué à 1.

              Faudrait déjà les remercier d'avoir développer en freesoftware de si bon programmes.

              J'espere que c'est ironique ???
              Si cela ne l'est pas je te suggere d'aller voir le code pour te faire une idee reelle des "si bons programmes" ...
              • [^] # Re: Un nouveau serveur DNS libre : PowerDNS

                Posté par  . Évalué à 0.

                > J'espere que c'est ironique ???
                Non.

                > d'aller voir le code pour te faire une idee reelle des "si bons programmes" .

                Le programme bind est utilisé ? OUI ou NON
                OUI.
                Il marche bien ? OUI ou NON
                OUI
                Il donne satisfaction ? OUI ou NON
                OUI
                Il est free software ? OUI ou NON
                OUI

                C'est un bon programme.
                S'il est mal codé c'est une autre histoire. Je ne connais pas la qualité du code puisque que je ne l'ai pas regardé et je peux admettre qu'il est mal codé. Mais c'est un bon programme !
                Moi je vois qu'il y en a plein qui se la pête hackers avec "code crade", etc... sous-entendu qu'il peuvent faire mieux et que c'est une honte de faire du code comme çà.
                Vous me faites rire. Comment ce fait-il que toutes ces pointures n'ont pas fait un bon remplaçant à bind ? surtout que bind c'est "vieux".
                Que font ces pointures ?
                Elles utilisent Bind car çà les faient chier de coder un nouveau Bind.
                Chers pointures qui utilisés Bind, reconnaissez que c'est un bon programme. Sinon codé un remplaçant !
                Et meilleur puisque vous avez cette prétention.

                PS : Je ne dis pas çà à ceux qui ne critique QUE la qualité du code (si c'est vrai :-o )
  • # DLZ ou comment interfaçer Bind avec PostgreSQL, MySQL et d'autres...

    Posté par  . Évalué à 2.

    Je voulais ajouter un point.
    Actuellement, un hollandais dirige un groupe de travail pour écrire tout une API pour interfaçer Bind avec des SGBD comme PostgreSQL ou MySQL mais aussi iODBC plus tard voire même OpenLDAP.
    Donc, PowerDNS est loin d'avoir le monopole de ce genre d'interfaçage, sans compter que le projet DLZ est reconnu par l'ISC tout comme lbnamed est conseillé pour monter des serveurs DNS à répartition de charge.
    Encore une fois, tout le monde est libre de choisir les outils dont il a besoin mais j'estime pour ma part que Bind a déjà parcouru beaucoup de chemin et, plutôt que lui cracher dessus, il conviendrait peut-être de l'améliorer. Il me semble que l'essence même d'un logiciel Libre est d'offrir ce genre de possibilité à un utilisateur suffisament expérimenté pour le faire...

    Bind-DLZ: http://www.nlnet.nl/project/bind-dlz/(...)
    NB: pour l'instant, il n'y a que PostgreSQL et MySQL, mais le support de ce dernier devrait apporter moultes contributions et tests.
    (Et j'attends impatiemment le module LDAP)
  • # libDjbDns libre

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

    Tant qu'on y est (enfin, j'aurais du mettre ça dans la news) :
    la libdjbdns, qui fournit un équivalent à la libresolv (gethostbyname et ses amis, pour ceux qui connaissent), est passée dans le domaine public. DJB espère ainsi qu'elle sera plus largement adoptée qu'elle ne l'est maintenant.
    N'oublions pas non plus l'existence d'adns, qui fournit le même genre de services, quoi que de façon peut-être un peu plus complète, en GPL (et pas LGPL, hein) : http://www.chiark.greenend.org.uk/~ian/adns/(...)
  • # Bind source libre ou pas?

    Posté par  . Évalué à 0.

    Source isc.org :

    "The Internet Software Consortium (ISC) is a not-for-profit corporation dedicated to developing and maintaining production quality Open Source reference implementations of core Internet protocols. ISC efforts are supported primarily by the donations of generous sponsors."

    Les source bind founit par isc n'est pas libre?
    Les sources ne peuvent par etre modifier par la communotée?
    • [^] # Re: Bind source libre ou pas?

      Posté par  . Évalué à 0.

      > Les source bind founit par isc n'est pas libre?
      > Les sources ne peuvent par etre modifier par la communotée?

      Rien de tout çà. Les gens ont peur. C'est l'effet 21 avril.

Suivre le flux des commentaires

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