Re: Re: Choix d'architecture

Le 22 novembre 2010 17:29, Stephane Bortzmeyer <[email protected]> a écrit :
>> -4- Rediriger les requêtes d'un domaine vers un autre serveur ;
> J'avoue ne pas bien comprendre ce que vous demandez là, ni pourquoi
> c'est nécessaire. Un exemple concret aiderait peut-être ?
Notre réseau local est coupé d'internet et les utilisateurs passent
tous par un proxy pour aller sur internet (comme dans bcp
d'entreprises/écoles). C'est pourquoi les utilisateurs n'ont pas
besoin d’interroger les serveurs dns sauf pour les domaines locaux.
Jusque là, ça reste classique.

Cependant, une applications cliente a besoin de récupérer des
informations sur internet en utilisant le DNS.  (Exactement dans le
même style que "dig TXT XXX.wp.dg.cx"). Comme les serveurs dns n'ont
pas accès à internet, je dois forwarder ces requêtes vers un proxy dns
qui à accès au net.  Par mesure de sécurité, nous devons limiter le
forward uniquement à un domaine.


> Il est très dur de comprendre une description où il n'y a pas de noms,
> juste de vagues références (« l'autre serveur », « le premier
> serveur »).

Voici la situation actuelle qui fonctionne :
-NS1.domaine.com
--serveur primaire faisant autorité sur domaine.com, subY.domaine.com,
etc... et d'autres domaines (type master)
--zone racine
  .  IN    SOA   domain.com.  mail.domain.com (...)
  .               IN      NS      ns1.domain.com.
  .               IN      NS      ns2.domain.com.
 ns1.domain.com IN A a.b.c.d
 ns2.domain.com IN A e.f.g.h


-NS2.domaine.com
--serveur secondaire faisant autorité sur domaine.com et d'autres
domaines (type slave)
--zone racine
  .  IN    SOA   domain.com.  mail.domain.com (...)
  .               IN      NS      ns1.domain.com.
  .               IN      NS      ns2.domain.com.
 ns1.domain.com IN A a.b.c.d
 ns2.domain.com IN A e.f.g.h)

-NSX.sub.domaine.com  (avec X={0,*})
--serveur primaire/secondaire faisant autorité sur sousXX.domaine.com
et d'autres domaines (master/slave)
--Possède la zone "." de type hint qui contient :
  ns1.domaine.com.      3600000      A     a.b.c.d
  ns2.domaine.com.      3600000      A     e.f.g.h

Mon challenge : Les clients qui interrogent NS1, NS2, NSX doivent
pouvoir résoudre  les noms de *.service.com.

>> -vue 1 (catch les clients "normau")
>
> Les vues sont presque toujours une mauvaise idée. Elles compliquent
> sérieusement les choses (et votre configuration a déjà l'air très
> compliquée).
Depuis quand la réalité est simple ? ;-) Remanier de vieilles
architectures n'est pas si simple surtout quand le périmètre n'est pas
clairement défini... (d'où les X serveurs...)


>> DU coup, je ne sais pas trop comment faire pour arriver à mes fins.
>> Avez vous des idées ?
> Simplifier me parait déjà une bonne idée...
Qu'est ce que j'aimerai envisager cette possibilité ! Malheureusement,
ce n'est pas d'actualité..

Tom