Devrions-nous héberger nos propres serveurs de noms ?

J'ai fait les deux. Il peut y avoir des avantages à héberger son propre site : vous apprenez certainement beaucoup sur le fonctionnement du DNS lorsque votre patron vous demande pourquoi cela prend autant de temps. De plus, vous avez un meilleur contrôle sur vos zones. Ce n'est pas toujours aussi puissant que cela devrait l'être, en grande partie à cause de la nature distribuée et hiérarchique du DNS, mais de temps en temps, c'est utile. C'est encore plus vrai si vous pouvez obtenir de votre fournisseur qu'il vous attribue le rôle de SOA pour le reverse DNS de votre bloc d'adresses IP, si vous en avez un.

Cependant, tous les commentaires ci-dessus sur la nécessité d'intégrer une grande résistance aux pannes sont tout à fait pertinents. Il est important de placer les serveurs dans différents centres de données situés dans différentes zones géographiques. Ayant géré la panne de courant massive dans le Nord-Est en 2003, nous avons tous appris que le fait d'avoir une boîte dans deux centres de données différents dans la même ville, ou même dans la même province ou le même état, n'est pas nécessairement une protection suffisante. L'exaltation qui vous envahit lorsque vous réalisez que vos batteries puis vos générateurs diesel vous ont sauvé la mise est rapidement remplacée par l'effroi causé par la prise de conscience que vous conduisez désormais sur votre pneu de secours.

Cependant, j'utilise toujours notre serveur DNS interne pour le réseau local. Cela peut s'avérer très pratique pour avoir un contrôle total sur le DNS que votre réseau utilise en interne - et si le courant est coupé dans votre bureau, votre serveur DNS interne, du fait qu'il se trouve dans le rack de serveurs, est probablement sur batterie ou sur batterie et diesel, alors que vos PC ne le seront pas - vos clients seront donc hors ligne bien avant le serveur.

Jetez un coup d'œil à Dyn.com Ils proposent toutes sortes de services liés au DNS, tels que l'hébergement DNS, le DNS dynamique, MailHop, etc, etc. Je les ai trouvés fiables et les utilise depuis probablement 5 ans.

Je lis toutes ces solutions avec un certain amusement parce que nous avons réussi à nous adapter accidentellement à toutes ces "exigences" en hébergeant notre DNS primaire sur une ligne DSL statique, et en demandant au bureau d'enregistrement (qui se trouvait sur un autre continent) de fournir un DNS secondaire sur une connexion beaucoup plus sérieuse et fiable. De cette façon, nous bénéficions de toute la flexibilité de l'utilisation de bind et de la définition de tous les enregistrements dans le tout en étant raisonnablement assurés que le secondaire sera mis à jour pour refléter ces changements et sera disponible dans le cas où une bouche d'égout prendrait feu, pour ne citer qu'un cas.

Cela remplit effectivement :
"Un minimum de deux serveurs DNS faisant autorité pour votre domaine ;"
"Les serveurs DNS doivent être connectés à des réseaux physiques et des alimentations électriques différents ;"
"Les serveurs DNS devraient être dans des zones géographiques différentes."

Ça dépend.

Je gère mes propres DNS pour mes différents emplois depuis la fin des années 80 (BSD 4.3c). Pour mon travail, j'ai toujours hébergé mon propre DNS, mais j'ai toujours eu plusieurs centres de données, ou j'ai pu échanger des DNS secondaires avec un partenaire. Par exemple, à mon dernier emploi, nous avons fait un DNS secondaire pour un autre .EDU (ils étaient dans le MN, nous sommes en CA), et ils ont fait la même chose pour nous. Diversité géographique et de réseau.

Ou, dans mon emploi actuel, nous avons nos propres centres de données sur les côtes est et ouest (États-Unis). L'hébergement de nos propres DNS nous permet de mettre en place tous les enregistrements DNS inhabituels dont nous pouvons avoir besoin (SVR, TXT, etc.) et qui ne sont pas pris en charge par certains services DNS graphiques. De plus, nous pouvons modifier les TTL quand nous le souhaitons ; nous disposons d'une flexibilité quasi-totale, au prix de le faire nous-mêmes.

Pour les affaires domestiques, j'ai fait les deux. Pour certains domaines où je fais des choses inhabituelles, ou qui nécessitent beaucoup de flexibilité, je continue à utiliser mes propres serveurs DNS maîtres "cachés" et à échanger des services DNS publics avec d'autres qui font de même. J'utilise RCS pour contrôler la version des fichiers de zone pour la gestion de la configuration, de sorte que je peux voir l'historique complet des changements de zone depuis le début des temps. Pour des choses simples comme un domaine avec un seul blog ou des serveurs web génériques (un enregistrement A ou un CNAME), il est simplement plus facile d'utiliser le service DNS d'un registrar de domaine lorsqu'il est disponible et de ne plus se soucier de la CM.

C'est un compromis. Le contrôle et la flexibilité ultimes se font au prix de la gestion de la diversité par vous-même, de l'exploitation de plusieurs serveurs, de la gestion des pannes matérielles et logicielles, etc. Si vous n'avez pas besoin de la flexibilité ou du contrôle total, n'importe lequel des fournisseurs de DNS de premier plan résoudra votre problème, probablement à un coût total inférieur.

Comme nous l'avons déjà mentionné dans ce fil de discussion, il existe plusieurs cas particuliers avec le DNS, la différence la plus significative étant entre les déploiements de serveurs de noms faisant autorité et de serveurs de noms en cache.

1. Si vous avez besoin d'un serveur DNS uniquement pour résoudre des ressources Internet, un résolveur DNS à encaissement gratuit est un choix judicieux. J'utilise personnellement PowerDNS recursor (pdns-recursor) sous Linux.

2. Pour la gestion de votre infrastructure externe, comme les sites web ou les MX, je n'utiliserais pas de NSes internes (si nous parlons de SOHO ici). Utilisez un bon service, fiable et à l'épreuve des balles, tel que DNSmadeasy . J'utilise leur forfait professionnel, et il est génial tout en étant très abordable.