Bonjour Xavier, bonjour tout le monde,
D'abord merci pour cette longue réponse et pour avoir pris le temps de
détailler à ce point.
En relisant ma question, je constate que j'aurais pu moi-même détailler
un peu plus le contexte :
- Je pense pouvoir dire que j'ai une maîtrise convenable des questions
relatives aux DNS, je vous aurais économisé du temps. Désolé.
- D'un point de vue perso, je gère déjà en auto-hébergement mon serveur
DNS, et utilise la technique de secours croisée avec un tiers, tel que
vous la décrivez.
- D'un point de vue professionnel, c'est bien dans le cadre d'un gros
LAN que se posait ma question, donc sans rapport avec internet, et le
vrai point qui me soucie est la haute disponibilité du SOA permettant
les mises à jour de zones. J'estime qu'en lecture seule, l'ensemble de
notre base de données DNS est robuste (et oui : Nagios veille aussi chez
nous ;) ). En revanche, nous ne disposons que d'un seul serveur
acceptant les updates, c'est le SOA, et les updates seront impossibles
durant le temps de réparation de sa panne potentielle.
Je suppose avoir compris que dans les grosses structures, un découpage
en sous-zones induit une multiplication des SOA par sous-zone, et
fragmente ainsi le risque.
Chez nous, la taille intermédiaire de notre SI induit que nous ne
disposons pas de sous-zones, donc nous n'avons qu'une seul SOA.
Ma question était donc : pour blinder le SOA, les méthodes standards du
DNS prévoient-elles une robustesse intrinsèque, avant de mettre en œuvre
mes propres mécanismes (heartbeat, virtual IP...) ?
--
Nicolas Ecarnot
PS : Je garde le texte ci-dessous, il est riche de conseils.
Le 12/12/2013 01:12, Xavier Belanger a écrit :
> Bonjour,
>
>> Pour faire suite aux questions relatives aux DNS, je me suis demandé
>> quelle était la meilleure façon d'assurer la haute disponibilité d'un SOA.
>> (...)
>
> Un enregistrement SOA (Start of Authority, ce qui défini une zone DNS)
> doit effectivement être disponible en permanence, sans quoi la zone
> disparaît d'Internet.
>
> La solution la plus simple et la plus éprouvée est d'avoir son serveur
> maître sur son réseau et au moins un (et même plus) esclave sur un autre
> réseau, disponible via une autre entité de routage (AS number - Autonomous
> System) de manière à ce que si le serveur maître ou le routeur assurant
> sa connection tombe, l'information est disponible par ailleurs.
>
> Example avec le domaine guilde.asso.fr :
>
> Quels sont les serveurs de noms de la zone ?
>
> xavier@mercury:~$ dig +short NS guilde.asso.fr
> ns5.axperia.net.
> ns0.axperia.net.
>
> Quelle est l'adresse IP du premier serveur ?
>
> xavier@mercury:~$ dig +short A ns5.axperia.net
> 213.218.137.115
>
> Quelle est l'adresse IP du second serveur ?
>
> xavier@mercury:~$ dig +short A ns0.axperia.net
> 217.117.157.190
>
> Rien qu'avec ça, on peut voir que les deux serveurs ne sont pas sur
> les mêmes réseaux, donc probablement connecté via des routeurs différents.
> Vérifions avec l'outil proposé par Team Cymru :
>
> [ http://www.team-cymru.org/Services/ip-to-asn.html#dns ]
>
> xavier@mercury:~$ dig +short 115.137.218.213.origin.asn.cymru.com TXT
> "8304 | 213.218.128.0/19 | FR | ripencc | 2004-02-03"
> xavier@mercury:~$ dig +short 190.157.117.217.origin.asn.cymru.com TXT
> "15830 | 217.117.144.0/20 | FR | ripencc | 2004-01-23"
>
> Oui, le premier serveur est connecté via le routeur avec l'AS 8304 et
> le second via le routeur ayant l'AS 15830.
>
> Pour véfier tout cela et bien plus, il existe différents outils en ligne :
>
> * DNSCheck [ http://dnscheck.iis.se/ ]
> * IntoDNS [ http://www.intodns.com/ ]
> * ZoneCheck [ http://www.zonecheck.fr/ ]
>
> La Guilde étant une organisation modeste, il n'y a probablement pas besoin
> de plus de serveurs DNS esclaves. Pour une organisation plus importante,
> il faudra songer à quelques serveurs de plus (le maximum est de sept selon
> les RFCs si ma mémoire est bonne).
>
> Attention ce n'est pas la solution ultime : si le serveur maître tombe
> la zone reste visible mais elle ne peut plus être mise à jour et finira
> par disparaître quand le TTL (Time To Live) expirera. Si l'administrateur
> DNS n'a pas réagit à temps, il y aura un gros problème (mais un bon
> administrateur surveille ses serveurs n'est-ce pas :-) ).
>
> Il existe par ailleurs un document de l'ANSSI préparé avec l'aide de
> l'AFNIC à propos de ce genre de chose :
>
> * Résilience de l'Internet 2012
>
> [ http://www.ssi.gouv.fr/fr/menu/actualites/l-observatoire-sur-la-resilience-de-l-internet-francais-publie-son-rapport-2012.html ]
>
> C'est un gros document, mais pas trop indigeste (et c'est composé en LaTeX).
>
> Cela répond d'ailleurs en partie comment "les très grosses boîtes" gèrent
> leur DNS : probablement aussi mal que les autres, avec peu de serveurs
> et peu de répartition (82% des serveurs sont sur la même AS en 2012...).
>
> Après la question est "comment faire héberger un serveur DNS ?". Il y a
> la méthode simple : louer un serveur correct chez un prestataire fiable
> et installer le nécessaire. La méthode un peu plus complexe est de trouver
> une organisation amie, lui demander d'héberger une zone esclave sur ses
> propres serveurs et de proposer la même chose en échange. C'est ce que font
> certaines universités françaises. Le tout est d'avoir une relation de
> confiance...
>
> S'il y a encore des questions sur DNS, allez-y, je suis chaud :-)
>
> A+
>
--
Nicolas Ecarnot
