Re: Fonctionnement d'un DNS. Et pourquoi 2 NS ?

Le Thu, 27 Mar 2008 14:50:24 +0100, Olivier Masson a écrit:
>>>> Après bien sûr comme dit précédemment il y a des pistes pour sécuriser
>>>> l'ensemble.
>>> J'ai vu que j'avais dnssec-keygen et -seczone, mais j'attendrai déjà
>>> d'avoir bien configuré le reste...
>> 
>> Vous pouvez effectivement utiliser dnssec-keygen pour créer une clef à
>> utiliser par le mécanisme TSIG qui, en résumé, « sécurise » le transfert
>> de zone (entre primaire et secondaires) en authentifiant fortement
>> l'émetteur (le primaire). Cela remplace ou s'adjoint aux ACLs sur les
>> adresses IP.
> 
> Mais il faut contrôler le secondaire pour pouvoir faire cela, sinon 
> comment signifier au secondaire qu'on utilise ce mécanisme, etc. ?

Pas forcément le contrôler, mais il doit être configuré en rapport, oui.
Certaines sociétés proposent cela, par exemple DNSPark (j'en suis juste un
client satisfait) qui propose des serveurs secondaires (qu'ils gèrent)
configurés pour des transferts avec TSIG : ils donnent la clef à utiliser
(à mettre dans la configuration du primaire)
 
>>> Pour limiter les risques, est-il possible d'envoyer toutes les mises à
>>> jour aux DNS Gandi, sans pouvoir être interrogé par qui que ce soit
>>> d'autre (que les DNS Gandi) ?
>> 
>> Je ne suis pas sûr de comprendre la question, mais si vous voulez que
>> votre serveur DNS ne soit pas « public » c'est à dire ne réponde
>> quasimment à personne, sauf à votre prestataire, en phase de tests, il
>> suffit de placer une directive du type : allow-query { dns_gandi; };
>> dans votre fichier.
>>  
>>  
> Je pense que la structure que je souhaite n'existe pas : informer les
> DNS de mon registrar des modifications grâce à mon serveur DNS, sans que
> ce dernier ne soit public (pour limiter les risques et décharger le
> serveur).

Ca ressemble un peu à une configuration du type « hidden primary » : un
serveur DNS fait office de primaire, c'est là que les modifications (de
configuration, de zone) ont lieu, mais ce serveur n'est pas accessible
publiquement.
Les serveurs accessibles publiquement sont en fait tous des serveurs
secondaires liés au primaire « caché ».

Ce n'est pas en général une configuration « grand public » et je doute
qu'un prestataire « de base » fournisse cela.
Ce que vous cherchez n'est pas vraiment un service de DNS secondaire :
c'est plutôt un service de DNS « complet » où votre prestataire gère tous
les serveurs DNS de votre domaine, mais ces derniers récupèrent
l'information chez vous d'une façon ou d'une autre (cela pourrait aussi
être via l'interface web ou une interface RPC quelconque que vous utilisez
pour alimenter le contenu de votre zone stockée chez votre prestataire).

> Si j'utilise allow-query { dns_registrar } et que je me mets en DNS
> primaire, les requêtes publiques seront donc toujours traitées par les
> secondaires ce qui, je pense, n'est pas du tout "réglementaire" ?

Ce n'est pas une bonne idée effectivement. Si vous avez un tel
allow-query, il ne faut pas mettre le serveur en question dans les NS.

A noter, par rapport à que je disais avant, que le « vrai » primaire est
dans le SOA normalement, et que donc un prestataire de DNS secondaire peut
très bien aussi se baser sur ca. Encore une fois il faut voir les détails
des offres disponibles sur le marché (comme dit précédemment, récupération
des NS de la zone, ou spécification explicite de l'IP/du nom du primaire,
ou donc aussi recherche dans le SOA)

>> Dès que je mets les services en-ligne, y aura un bouton « Order », ce
>> qui devrait faire l'affaire :-)
>> 
> Quel type de service en ligne ?

Autour des noms de domaine, si si :-)
Désolé je suis antibuzz, donc la politique c'est zéro communication
publique ou privée sur le sujet.
Mais merci pour l'intérêt porté.

-- 
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>