J'ai quelques questions auxquelles je ne trouve pas de réponses claires.
Si je modifie les entrées DNS (je crée un CNAME, un A,...) de mon
serveur, comment indique-t-on à quels autres DNS sont transmis ces infos
en premier lieu (qui lui-même distribuera l'info) ?
Pourquoi me ferait-il confiance ?
Pourquoi faut-il toujours entrer au moins 2 NS ? Uniquement pour la
redondance ?
Donc dans mon cas, j'ai un seul serveur : est-ce que je peux mettre mon
IP en premier NS et un DNS de mon hébergeur en second ?
Merci.
PS : Nessus m'indique que "Remote DNS server is vulnerable to cache
snooping attacks". J'ai souvent obtenu des faux positifs dans la sécu
réseau avec cet outil, mais là, comme je ne comprends pas ce qu'il me
dit... est-ce grave et comment y remédier ?
Le Mon, 31 Mar 2008 16:23:29 +0200, Pascal Hambourg a écrit:
Ce n'est pas en général une configuration « grand public » et je doute qu'un prestataire « de base » fournisse cela.
Pourquoi ? Il suffirait que le prestataire permette l'utilisation de ses serveurs DNS en tant que secondaires et n'exige pas que le primaire spécifié figure dans les enregistrements NS de la zone, non ?
Je n'ai pas dit que c'était infaisable :-), j'ai juste dit que ce n'était pas standard/courant. Suffit de prendre les bureaux d'enregistrements qui font les services de DNS primaires et/ou secondaires, je n'en connais pas qui font du « hidden primary » (sans avoir cherché de manière exhaustive, donc les contradicteurs rectifieront :-)).
Ce n'est pas un service grand public c'est tout, puisque le grand public ne s'amuse pas à avoir son serveur DNS chez lui et le configurer à la main avec amour. Il préfère que son prestataire gère tout, et donc choisir préférentiellement le service de DNS primaire couplé à redirections email/web, et dans une moindre mesure le service de DNS secondaire.
Je ne connais pas de stats de ce genre public, mais si on regarde : http://web.archive.org/web/20041031231622/http://gandi.net/stats/serv_Redir.png http://web.archive.org/web/20041101001328/http://gandi.net/stats/serv_Sec.png http://web.archive.org/web/20041031225359/http://gandi.net/stats/serv_Custom.png
on a ~153 000 domaines utilisant le service de DNS primaire avec redirections ~30 000 domaines utilisant le service de DNS primaire personnalisé ~19 600 domaines utilisant le service de DNS secondaire
Donc c'est déjà un rapport 10 entre service primaire et secondaire, et je pense que ca serait encore un rapport 10 entre secondaire et primaire caché.
Mais c'est un service qui existe, oui forcément car cela répond à un besoin bien précis. De nombreuses racines ccTLD/gTLD fonctionnent ainsi.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/>
Le Mon, 31 Mar 2008 16:23:29 +0200, Pascal Hambourg a écrit:
Ce n'est pas en général une configuration « grand public » et je doute
qu'un prestataire « de base » fournisse cela.
Pourquoi ? Il suffirait que le prestataire permette l'utilisation de ses
serveurs DNS en tant que secondaires et n'exige pas que le primaire
spécifié figure dans les enregistrements NS de la zone, non ?
Je n'ai pas dit que c'était infaisable :-), j'ai juste dit que ce n'était
pas standard/courant. Suffit de prendre les bureaux d'enregistrements qui
font les services de DNS primaires et/ou secondaires, je n'en connais pas
qui font du « hidden primary » (sans avoir cherché de manière exhaustive,
donc les contradicteurs rectifieront :-)).
Ce n'est pas un service grand public c'est tout, puisque le grand public
ne s'amuse pas à avoir son serveur DNS chez lui et le configurer à la main
avec amour. Il préfère que son prestataire gère tout, et donc
choisir préférentiellement le service de DNS primaire couplé à redirections
email/web, et dans une moindre mesure le service de DNS secondaire.
Je ne connais pas de stats de ce genre public, mais si on regarde :
http://web.archive.org/web/20041031231622/http://gandi.net/stats/serv_Redir.png
http://web.archive.org/web/20041101001328/http://gandi.net/stats/serv_Sec.png
http://web.archive.org/web/20041031225359/http://gandi.net/stats/serv_Custom.png
on a
~153 000 domaines utilisant le service de DNS primaire avec redirections
~30 000 domaines utilisant le service de DNS primaire personnalisé
~19 600 domaines utilisant le service de DNS secondaire
Donc c'est déjà un rapport 10 entre service primaire et secondaire, et je
pense que ca serait encore un rapport 10 entre secondaire et primaire
caché.
Mais c'est un service qui existe, oui forcément car cela répond à un
besoin bien précis. De nombreuses racines ccTLD/gTLD fonctionnent ainsi.
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Le Mon, 31 Mar 2008 16:23:29 +0200, Pascal Hambourg a écrit:
Ce n'est pas en général une configuration « grand public » et je doute qu'un prestataire « de base » fournisse cela.
Pourquoi ? Il suffirait que le prestataire permette l'utilisation de ses serveurs DNS en tant que secondaires et n'exige pas que le primaire spécifié figure dans les enregistrements NS de la zone, non ?
Je n'ai pas dit que c'était infaisable :-), j'ai juste dit que ce n'était pas standard/courant. Suffit de prendre les bureaux d'enregistrements qui font les services de DNS primaires et/ou secondaires, je n'en connais pas qui font du « hidden primary » (sans avoir cherché de manière exhaustive, donc les contradicteurs rectifieront :-)).
Ce n'est pas un service grand public c'est tout, puisque le grand public ne s'amuse pas à avoir son serveur DNS chez lui et le configurer à la main avec amour. Il préfère que son prestataire gère tout, et donc choisir préférentiellement le service de DNS primaire couplé à redirections email/web, et dans une moindre mesure le service de DNS secondaire.
Je ne connais pas de stats de ce genre public, mais si on regarde : http://web.archive.org/web/20041031231622/http://gandi.net/stats/serv_Redir.png http://web.archive.org/web/20041101001328/http://gandi.net/stats/serv_Sec.png http://web.archive.org/web/20041031225359/http://gandi.net/stats/serv_Custom.png
on a ~153 000 domaines utilisant le service de DNS primaire avec redirections ~30 000 domaines utilisant le service de DNS primaire personnalisé ~19 600 domaines utilisant le service de DNS secondaire
Donc c'est déjà un rapport 10 entre service primaire et secondaire, et je pense que ca serait encore un rapport 10 entre secondaire et primaire caché.
Mais c'est un service qui existe, oui forcément car cela répond à un besoin bien précis. De nombreuses racines ccTLD/gTLD fonctionnent ainsi.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/>
Patrick Mevzek
Le Mon, 31 Mar 2008 16:23:29 +0200, Pascal Hambourg a écrit:
Et l'avantage, c'est bien sûr de pouvoir manipuler sa zone sans devoir passer par l'interface de gestion du prestataire.
Personnellement j'ai toujours pensé que, sans avoir besoin de hidden primary à gérer, les serveurs du prestataire pourraient être mis à jour à distance... tout simplement via le protocole DNS et son mécanisme de mise à jour (RFC2136) ! Cela permet un contrôle total à distance, c'est sécurisable (TSIG + ACL sur les IPs si nécessaire), évolué (gestion de pré-requis pour ne faire les modifications qu'à certaines conditions) et « standard », pas besoin de développer un client spécifique à une interface donnée, les sources de bind donnent l'exécutable nsupdate et cela suffit bien (et avec des bibliothèque comme Net::DNS::Update en Perl on peut aisément construire un client avec les fonctionnalités et les gimmicks de son choix).
Je ne connais pas de prestataires qui permettent cela (beaucoup permettent les modifications - pas forcément toutes - à distance, mais c'est en général à la DynDNS.com, via un appel HTTP), peut-être existent-ils. Mais c'est le même genre de service que le « primaire caché » donc pas grand public.
En tout cas je trouve cela intéressant à la fois en tant que consommateur et en tant que « producteur »... :-)
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/>
Le Mon, 31 Mar 2008 16:23:29 +0200, Pascal Hambourg a écrit:
Et l'avantage, c'est bien sûr de pouvoir manipuler sa zone sans devoir
passer par l'interface de gestion du prestataire.
Personnellement j'ai toujours pensé que, sans avoir besoin de hidden
primary à gérer, les serveurs du prestataire pourraient être mis à jour à
distance... tout simplement via le protocole DNS et son mécanisme de mise
à jour (RFC2136) ! Cela permet un contrôle total à distance, c'est
sécurisable (TSIG + ACL sur les IPs si nécessaire), évolué (gestion de
pré-requis pour ne faire les modifications qu'à certaines conditions) et «
standard », pas besoin de développer un client spécifique à une interface
donnée, les sources de bind donnent l'exécutable nsupdate et cela suffit
bien (et avec des bibliothèque comme Net::DNS::Update en Perl on peut
aisément construire un client avec les fonctionnalités et les gimmicks de
son choix).
Je ne connais pas de prestataires qui permettent cela (beaucoup permettent
les modifications - pas forcément toutes - à distance, mais c'est en
général à la DynDNS.com, via un appel HTTP), peut-être existent-ils. Mais
c'est le même genre de service que le « primaire caché » donc pas grand
public.
En tout cas je trouve cela intéressant à la fois en tant que consommateur
et en tant que « producteur »... :-)
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Le Mon, 31 Mar 2008 16:23:29 +0200, Pascal Hambourg a écrit:
Et l'avantage, c'est bien sûr de pouvoir manipuler sa zone sans devoir passer par l'interface de gestion du prestataire.
Personnellement j'ai toujours pensé que, sans avoir besoin de hidden primary à gérer, les serveurs du prestataire pourraient être mis à jour à distance... tout simplement via le protocole DNS et son mécanisme de mise à jour (RFC2136) ! Cela permet un contrôle total à distance, c'est sécurisable (TSIG + ACL sur les IPs si nécessaire), évolué (gestion de pré-requis pour ne faire les modifications qu'à certaines conditions) et « standard », pas besoin de développer un client spécifique à une interface donnée, les sources de bind donnent l'exécutable nsupdate et cela suffit bien (et avec des bibliothèque comme Net::DNS::Update en Perl on peut aisément construire un client avec les fonctionnalités et les gimmicks de son choix).
Je ne connais pas de prestataires qui permettent cela (beaucoup permettent les modifications - pas forcément toutes - à distance, mais c'est en général à la DynDNS.com, via un appel HTTP), peut-être existent-ils. Mais c'est le même genre de service que le « primaire caché » donc pas grand public.
En tout cas je trouve cela intéressant à la fois en tant que consommateur et en tant que « producteur »... :-)
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/>
