Mon réseau personnel est en 192.168.0.0/24 avec pour nom "homelan.net".
J'ai configuré sur la même machine dnscache et tinydns.
dnscache :
- écoute les requêtes sur 192.168.0.4,
- forward les requêtes si nécessaire aux serveurs DNS de mon provider
Noos (212.198.0.91 & 212.198.2.51),
- transfère les requêtes concernant le domaine "homelan.net" à tinydns.
tinydns:
- écoute les requêtes sur 127.0.0.1 (en provenance de dnscache),
- répond uniquement aux requêtes concernant le domaine "homelan.net".
Suite à un premier poste dans fr.comp.os.linux.configuration j'ai
cherché des exemples de configuration de tinydns mais je dois avouer que
je galère avec le contenu du fichier de zones de tinydns.
Avec cette configuration et à partir de mon poste sous WinXP, les noms
sont bien résolus et je peux pinger ns.homelan.net et
machine4.homelan.net (ainsi que les autres machines du réseau) mais
quand je fais nslookup, j'obtiens :
C:\>nslookup ns.homelan.net
*** Impossible de trouver le nom de serveur pour l'adresse 192.168.0.4 :
Non-existent domain
Serveur : dns1.noos.fr
Address: 212.198.0.91
*** dns1.noos.fr ne parvient pas à trouver ns.homelan.net : Non-existent
domain
C:\>nslookup 192.168.0.4
*** Impossible de trouver le nom de serveur pour l'adresse 192.168.0.4 :
Non-existent domain
Serveur : dns1.noos.fr
Address: 212.198.0.91
*** dns1.noos.fr ne parvient pas à trouver 192.168.0.4 : Non-existent domain
Que faut-il donc que je mette dans ce fichier pour que je puisse enfin
nslookuper en rond ?
Mauvaise pioche. Homelan.net existe et n'est pas à vous :
A l'époque où j'ai configuré mon réseau "homelan.net" je n'avais pas fait attention si le domaine était enregistré. Cela n'a d'importance que théoriquement car les probabilités pour que j'aille visiter le vrai domaine sont infinitésimales.
Êtes-vous certain qu'il y a un DNS qui tourne ?
Oui. Un 'netstat -anp' sur ns.homelan.net montre bien dnscache à l'écoute sur 192.168.0.4:53 (tcp/udp) et tinydns sur 127.0.0.1:53 (udp).
Pourquoi votre machine XP est-elle configurée avec un DNS local et un DNS externe ?
Pour que je puisse continuer à surfer si jamais je fais une mauvaise configuration du serveur DNS ou si ce dernier est éteint.
Par ailleurs, pourquoi ne pas utiliser un Bind sous Windows, qui marche très bien, lui ?
Pour ce que j'en ai lu sur le Web, bind est complexe, insecure, consommateur de ressource ; parce je préfère avoir mon DNS sous Linux ; parce j'aime bien faire différement de tout le monde :-)
Mauvaise pioche. Homelan.net existe et n'est pas à vous :
A l'époque où j'ai configuré mon réseau "homelan.net" je n'avais pas
fait attention si le domaine était enregistré.
Cela n'a d'importance que théoriquement car les probabilités pour que
j'aille visiter le vrai domaine sont infinitésimales.
Êtes-vous
certain qu'il y a un DNS qui tourne ?
Oui.
Un 'netstat -anp' sur ns.homelan.net montre bien dnscache à l'écoute sur
192.168.0.4:53 (tcp/udp) et tinydns sur 127.0.0.1:53 (udp).
Pourquoi votre machine XP est-elle
configurée avec un DNS local et un DNS externe ?
Pour que je puisse continuer à surfer si jamais je fais une mauvaise
configuration du serveur DNS ou si ce dernier est éteint.
Par ailleurs, pourquoi ne pas utiliser un Bind sous Windows, qui marche très
bien, lui ?
Pour ce que j'en ai lu sur le Web, bind est complexe, insecure,
consommateur de ressource ; parce je préfère avoir mon DNS sous Linux ;
parce j'aime bien faire différement de tout le monde :-)
Mauvaise pioche. Homelan.net existe et n'est pas à vous :
A l'époque où j'ai configuré mon réseau "homelan.net" je n'avais pas fait attention si le domaine était enregistré. Cela n'a d'importance que théoriquement car les probabilités pour que j'aille visiter le vrai domaine sont infinitésimales.
Êtes-vous certain qu'il y a un DNS qui tourne ?
Oui. Un 'netstat -anp' sur ns.homelan.net montre bien dnscache à l'écoute sur 192.168.0.4:53 (tcp/udp) et tinydns sur 127.0.0.1:53 (udp).
Pourquoi votre machine XP est-elle configurée avec un DNS local et un DNS externe ?
Pour que je puisse continuer à surfer si jamais je fais une mauvaise configuration du serveur DNS ou si ce dernier est éteint.
Par ailleurs, pourquoi ne pas utiliser un Bind sous Windows, qui marche très bien, lui ?
Pour ce que j'en ai lu sur le Web, bind est complexe, insecure, consommateur de ressource ; parce je préfère avoir mon DNS sous Linux ; parce j'aime bien faire différement de tout le monde :-)
TiChou
Dans le message <news:, *Michel Guillou* tapota sur f.c.r.ip :
Par ailleurs, pourquoi ne pas utiliser un Bind sous Windows, qui marche très bien, lui ?
Pour ce que j'en ai lu sur le Web, bind est complexe, insecure, consommateur de ressource
Non, c'est faux, pour l'essentiel.
Non, c'est vrai pour l'essentiel, surtout si on le compare avec la suite djbdns, celle qu'utilise ici François RONVAUX.
-- TiChou
Dans le message <news:41cfea74.891238953@news.neottia.net>,
*Michel Guillou* tapota sur f.c.r.ip :
Par ailleurs, pourquoi ne pas utiliser un Bind sous Windows, qui marche
très bien, lui ?
Pour ce que j'en ai lu sur le Web, bind est complexe, insecure,
consommateur de ressource
Non, c'est faux, pour l'essentiel.
Non, c'est vrai pour l'essentiel, surtout si on le compare avec la suite
djbdns, celle qu'utilise ici François RONVAUX.
Dans le message <news:, *Michel Guillou* tapota sur f.c.r.ip :
Par ailleurs, pourquoi ne pas utiliser un Bind sous Windows, qui marche très bien, lui ?
Pour ce que j'en ai lu sur le Web, bind est complexe, insecure, consommateur de ressource
Non, c'est faux, pour l'essentiel.
Non, c'est vrai pour l'essentiel, surtout si on le compare avec la suite djbdns, celle qu'utilise ici François RONVAUX.
-- TiChou
François RONVAUX
Impossible de déboguer, alors.
En ne laissant pour mon WinXP que 192.168.0.4 comme serveur DNS, j'obtiens ceci :
C:>nslookup ns.homelan.net *** Impossible de trouver le nom de serveur pour l'adresse 192.168.0.4 : Non-existent domain *** Les serveurs par défaut ne sont pas disponibles Serveur : UnKnown Address: 192.168.0.4
Réponse ne faisant pas autorité : Nom : ns.homelan.net Address: 192.168.0.4
C:>nslookup 192.168.0.4 *** Impossible de trouver le nom de serveur pour l'adresse 192.168.0.4 : Non-existent domain *** Les serveurs par défaut ne sont pas disponibles Serveur : UnKnown Address: 192.168.0.4
*** UnKnown ne parvient pas à trouver 192.168.0.4 : Non-existent domain
Deux choses : - j'ai toujours droit au "Non-existent domain" alors qu'il est renseigné dans le fichier de zones (si mes maigres compétences ne me trompent pas), - du nouveau, ns.homelan.net étant désormais indiqué comme répondant mais ne faisant pas autorité !?
La mise en place d'un serveur DNS est une chose plutôt curieuse :-)
Impossible de déboguer, alors.
En ne laissant pour mon WinXP que 192.168.0.4 comme serveur DNS,
j'obtiens ceci :
C:>nslookup ns.homelan.net
*** Impossible de trouver le nom de serveur pour l'adresse 192.168.0.4 :
Non-existent domain
*** Les serveurs par défaut ne sont pas disponibles
Serveur : UnKnown
Address: 192.168.0.4
Réponse ne faisant pas autorité :
Nom : ns.homelan.net
Address: 192.168.0.4
C:>nslookup 192.168.0.4
*** Impossible de trouver le nom de serveur pour l'adresse 192.168.0.4 :
Non-existent domain
*** Les serveurs par défaut ne sont pas disponibles
Serveur : UnKnown
Address: 192.168.0.4
*** UnKnown ne parvient pas à trouver 192.168.0.4 : Non-existent domain
Deux choses :
- j'ai toujours droit au "Non-existent domain" alors qu'il est renseigné
dans le fichier de zones (si mes maigres compétences ne me trompent pas),
- du nouveau, ns.homelan.net étant désormais indiqué comme répondant
mais ne faisant pas autorité !?
La mise en place d'un serveur DNS est une chose plutôt curieuse :-)
En ne laissant pour mon WinXP que 192.168.0.4 comme serveur DNS, j'obtiens ceci :
C:>nslookup ns.homelan.net *** Impossible de trouver le nom de serveur pour l'adresse 192.168.0.4 : Non-existent domain *** Les serveurs par défaut ne sont pas disponibles Serveur : UnKnown Address: 192.168.0.4
Réponse ne faisant pas autorité : Nom : ns.homelan.net Address: 192.168.0.4
C:>nslookup 192.168.0.4 *** Impossible de trouver le nom de serveur pour l'adresse 192.168.0.4 : Non-existent domain *** Les serveurs par défaut ne sont pas disponibles Serveur : UnKnown Address: 192.168.0.4
*** UnKnown ne parvient pas à trouver 192.168.0.4 : Non-existent domain
Deux choses : - j'ai toujours droit au "Non-existent domain" alors qu'il est renseigné dans le fichier de zones (si mes maigres compétences ne me trompent pas), - du nouveau, ns.homelan.net étant désormais indiqué comme répondant mais ne faisant pas autorité !?
La mise en place d'un serveur DNS est une chose plutôt curieuse :-)
Pascal
Salut,
François RONVAUX wrote:
En ne laissant pour mon WinXP que 192.168.0.4 comme serveur DNS, j'obtiens ceci :
Astuce : on peut forcer l'utilisation d'un serveur DNS donné en mettant son nom ou son adresse comme deuxième argument de nslookup.
C:>nslookup ns.homelan.net *** Impossible de trouver le nom de serveur pour l'adresse 192.168.0.4 : Non-existent domain *** Les serveurs par défaut ne sont pas disponibles Serveur : UnKnown Address: 192.168.0.4
Réponse ne faisant pas autorité : Nom : ns.homelan.net Address: 192.168.0.4
C:>nslookup 192.168.0.4 *** Impossible de trouver le nom de serveur pour l'adresse 192.168.0.4 : Non-existent domain *** Les serveurs par défaut ne sont pas disponibles Serveur : UnKnown Address: 192.168.0.4
*** UnKnown ne parvient pas à trouver 192.168.0.4 : Non-existent domain
Deux choses : - j'ai toujours droit au "Non-existent domain" alors qu'il est renseigné dans le fichier de zones (si mes maigres compétences ne me trompent pas),
Je vois que tu as créé la zone inverse 0.168.192.in-addr.arpa sur tinydns, mais as-tu bien configuré dnscache pour qu'il transfère aussi les requêtes sur cette zone vers tinydns ?
- du nouveau, ns.homelan.net étant désormais indiqué comme répondant mais ne faisant pas autorité !?
Si c'est dnscache qui répond, c'est peut-être normal. Le serveur autoritaire, c'est tinydns. Qu'est-ce que ça donne si tu lances nslookup (ou host) sur la machine qui fait serveur avec comme adresse de serveur 192.168.0.0 puis 127.0.0.1 pour court-circuiter dnscache ?
La mise en place d'un serveur DNS est une chose plutôt curieuse :-)
Avec BIND, une fois les notions de base du DNS assimilées, ce fut plus facile que j'aurais cru. Et c'est un débutant total qui te le dit.
Salut,
François RONVAUX wrote:
En ne laissant pour mon WinXP que 192.168.0.4 comme serveur DNS,
j'obtiens ceci :
Astuce : on peut forcer l'utilisation d'un serveur DNS donné en mettant
son nom ou son adresse comme deuxième argument de nslookup.
C:>nslookup ns.homelan.net
*** Impossible de trouver le nom de serveur pour l'adresse 192.168.0.4 :
Non-existent domain
*** Les serveurs par défaut ne sont pas disponibles
Serveur : UnKnown
Address: 192.168.0.4
Réponse ne faisant pas autorité :
Nom : ns.homelan.net
Address: 192.168.0.4
C:>nslookup 192.168.0.4
*** Impossible de trouver le nom de serveur pour l'adresse 192.168.0.4 :
Non-existent domain
*** Les serveurs par défaut ne sont pas disponibles
Serveur : UnKnown
Address: 192.168.0.4
*** UnKnown ne parvient pas à trouver 192.168.0.4 : Non-existent domain
Deux choses :
- j'ai toujours droit au "Non-existent domain" alors qu'il est renseigné
dans le fichier de zones (si mes maigres compétences ne me trompent pas),
Je vois que tu as créé la zone inverse 0.168.192.in-addr.arpa sur
tinydns, mais as-tu bien configuré dnscache pour qu'il transfère aussi
les requêtes sur cette zone vers tinydns ?
- du nouveau, ns.homelan.net étant désormais indiqué comme répondant
mais ne faisant pas autorité !?
Si c'est dnscache qui répond, c'est peut-être normal. Le serveur
autoritaire, c'est tinydns.
Qu'est-ce que ça donne si tu lances nslookup (ou host) sur la machine
qui fait serveur avec comme adresse de serveur 192.168.0.0 puis
127.0.0.1 pour court-circuiter dnscache ?
La mise en place d'un serveur DNS est une chose plutôt curieuse :-)
Avec BIND, une fois les notions de base du DNS assimilées, ce fut plus
facile que j'aurais cru. Et c'est un débutant total qui te le dit.
En ne laissant pour mon WinXP que 192.168.0.4 comme serveur DNS, j'obtiens ceci :
Astuce : on peut forcer l'utilisation d'un serveur DNS donné en mettant son nom ou son adresse comme deuxième argument de nslookup.
C:>nslookup ns.homelan.net *** Impossible de trouver le nom de serveur pour l'adresse 192.168.0.4 : Non-existent domain *** Les serveurs par défaut ne sont pas disponibles Serveur : UnKnown Address: 192.168.0.4
Réponse ne faisant pas autorité : Nom : ns.homelan.net Address: 192.168.0.4
C:>nslookup 192.168.0.4 *** Impossible de trouver le nom de serveur pour l'adresse 192.168.0.4 : Non-existent domain *** Les serveurs par défaut ne sont pas disponibles Serveur : UnKnown Address: 192.168.0.4
*** UnKnown ne parvient pas à trouver 192.168.0.4 : Non-existent domain
Deux choses : - j'ai toujours droit au "Non-existent domain" alors qu'il est renseigné dans le fichier de zones (si mes maigres compétences ne me trompent pas),
Je vois que tu as créé la zone inverse 0.168.192.in-addr.arpa sur tinydns, mais as-tu bien configuré dnscache pour qu'il transfère aussi les requêtes sur cette zone vers tinydns ?
- du nouveau, ns.homelan.net étant désormais indiqué comme répondant mais ne faisant pas autorité !?
Si c'est dnscache qui répond, c'est peut-être normal. Le serveur autoritaire, c'est tinydns. Qu'est-ce que ça donne si tu lances nslookup (ou host) sur la machine qui fait serveur avec comme adresse de serveur 192.168.0.0 puis 127.0.0.1 pour court-circuiter dnscache ?
La mise en place d'un serveur DNS est une chose plutôt curieuse :-)
Avec BIND, une fois les notions de base du DNS assimilées, ce fut plus facile que j'aurais cru. Et c'est un débutant total qui te le dit.
François RONVAUX
Je vois que tu as créé la zone inverse 0.168.192.in-addr.arpa sur tinydns, mais as-tu bien configuré dnscache pour qu'il transfère aussi les requêtes sur cette zone vers tinydns ?
Effectivement c'est mieux avec :
Sous Linux : #echo 127.0.0.1 > /var/djbdns/dnscachex/root/servers/0.168.192.in-addr.arpa #svc -t /service/dnscachex/
Sous WinXP : C:>nslookup 192.168.0.4 Serveur : ns.homelan.net Address: 192.168.0.4
Réponse ne faisant pas autorité : Nom : www.yahoo.akadns.net Addresses: 216.109.118.66, 216.109.118.67, 216.109.118.69, 216.109.118.72, 216.109.118.75, 216.109.118.78, 216.109.117.106, 216.109.117.206 Aliases: www.yahoo.com
Ca marche enfin :-)
Si c'est dnscache qui répond, c'est peut-être normal. Le serveur autoritaire, c'est tinydns. Qu'est-ce que ça donne si tu lances nslookup (ou host) sur la machine qui fait serveur avec comme adresse de serveur 192.168.0.0 puis 127.0.0.1 pour court-circuiter dnscache ?
Ca marche aussi :-)
Dernière question : Dans mon fichier de zone, machine4.homelan.net est un alias pour ns.homelan.net. Comment se fait-il que nslookup ne l'indique pas alors que pour le domaine yahoo.com c'est affiché ?
Je vois que tu as créé la zone inverse 0.168.192.in-addr.arpa sur
tinydns, mais as-tu bien configuré dnscache pour qu'il transfère aussi
les requêtes sur cette zone vers tinydns ?
Effectivement c'est mieux avec :
Sous Linux :
#echo 127.0.0.1 > /var/djbdns/dnscachex/root/servers/0.168.192.in-addr.arpa
#svc -t /service/dnscachex/
Sous WinXP :
C:>nslookup 192.168.0.4
Serveur : ns.homelan.net
Address: 192.168.0.4
Réponse ne faisant pas autorité :
Nom : www.yahoo.akadns.net
Addresses: 216.109.118.66, 216.109.118.67, 216.109.118.69,
216.109.118.72, 216.109.118.75, 216.109.118.78, 216.109.117.106,
216.109.117.206
Aliases: www.yahoo.com
Ca marche enfin :-)
Si c'est dnscache qui répond, c'est peut-être normal. Le serveur
autoritaire, c'est tinydns.
Qu'est-ce que ça donne si tu lances nslookup (ou host) sur la machine
qui fait serveur avec comme adresse de serveur 192.168.0.0 puis
127.0.0.1 pour court-circuiter dnscache ?
Ca marche aussi :-)
Dernière question :
Dans mon fichier de zone, machine4.homelan.net est un alias pour
ns.homelan.net.
Comment se fait-il que nslookup ne l'indique pas alors que pour le
domaine yahoo.com c'est affiché ?
Je vois que tu as créé la zone inverse 0.168.192.in-addr.arpa sur tinydns, mais as-tu bien configuré dnscache pour qu'il transfère aussi les requêtes sur cette zone vers tinydns ?
Effectivement c'est mieux avec :
Sous Linux : #echo 127.0.0.1 > /var/djbdns/dnscachex/root/servers/0.168.192.in-addr.arpa #svc -t /service/dnscachex/
Sous WinXP : C:>nslookup 192.168.0.4 Serveur : ns.homelan.net Address: 192.168.0.4
Réponse ne faisant pas autorité : Nom : www.yahoo.akadns.net Addresses: 216.109.118.66, 216.109.118.67, 216.109.118.69, 216.109.118.72, 216.109.118.75, 216.109.118.78, 216.109.117.106, 216.109.117.206 Aliases: www.yahoo.com
Ca marche enfin :-)
Si c'est dnscache qui répond, c'est peut-être normal. Le serveur autoritaire, c'est tinydns. Qu'est-ce que ça donne si tu lances nslookup (ou host) sur la machine qui fait serveur avec comme adresse de serveur 192.168.0.0 puis 127.0.0.1 pour court-circuiter dnscache ?
Ca marche aussi :-)
Dernière question : Dans mon fichier de zone, machine4.homelan.net est un alias pour ns.homelan.net. Comment se fait-il que nslookup ne l'indique pas alors que pour le domaine yahoo.com c'est affiché ?
Pascal
François RONVAUX wrote:
Qu'est-ce que ça donne si tu lances nslookup (ou host) sur la machine qui fait serveur avec comme adresse de serveur 192.168.0.0 puis 127.0.0.1 pour court-circuiter dnscache ?
Ca marche aussi :-)
Je n'en doutais pas :) Mais la question implicite était : dans ces deux cas la réponse obtenue est-elle autoritaire ou non ?
Dernière question : Dans mon fichier de zone, machine4.homelan.net est un alias pour ns.homelan.net. Comment se fait-il que nslookup ne l'indique pas alors que pour le domaine yahoo.com c'est affiché ?
Dans le fichier de zone, le nom mchine4.homelan.net est-il défini dans un enregistrement de type 'CNAME' pointant vers ns.homelan.net ou de type 'A' pointant vers 192.168.0.4 ? Ce n'est qu'avec un CNAME que le lookup indique que le nom est un alias.
François RONVAUX wrote:
Qu'est-ce que ça donne si tu lances nslookup (ou host) sur la machine
qui fait serveur avec comme adresse de serveur 192.168.0.0 puis
127.0.0.1 pour court-circuiter dnscache ?
Ca marche aussi :-)
Je n'en doutais pas :) Mais la question implicite était : dans ces deux
cas la réponse obtenue est-elle autoritaire ou non ?
Dernière question :
Dans mon fichier de zone, machine4.homelan.net est un alias pour
ns.homelan.net.
Comment se fait-il que nslookup ne l'indique pas alors que pour le
domaine yahoo.com c'est affiché ?
Dans le fichier de zone, le nom mchine4.homelan.net est-il défini dans
un enregistrement de type 'CNAME' pointant vers ns.homelan.net ou de
type 'A' pointant vers 192.168.0.4 ? Ce n'est qu'avec un CNAME que le
lookup indique que le nom est un alias.
Qu'est-ce que ça donne si tu lances nslookup (ou host) sur la machine qui fait serveur avec comme adresse de serveur 192.168.0.0 puis 127.0.0.1 pour court-circuiter dnscache ?
Ca marche aussi :-)
Je n'en doutais pas :) Mais la question implicite était : dans ces deux cas la réponse obtenue est-elle autoritaire ou non ?
Dernière question : Dans mon fichier de zone, machine4.homelan.net est un alias pour ns.homelan.net. Comment se fait-il que nslookup ne l'indique pas alors que pour le domaine yahoo.com c'est affiché ?
Dans le fichier de zone, le nom mchine4.homelan.net est-il défini dans un enregistrement de type 'CNAME' pointant vers ns.homelan.net ou de type 'A' pointant vers 192.168.0.4 ? Ce n'est qu'avec un CNAME que le lookup indique que le nom est un alias.
François RONVAUX
Dans le fichier de zone, le nom mchine4.homelan.net est-il défini dans un enregistrement de type 'CNAME' pointant vers ns.homelan.net ou de type 'A' pointant vers 192.168.0.4 ? Ce n'est qu'avec un CNAME que le lookup indique que le nom est un alias.
Je viens de regarder dans le man. L'auteur déconseille l'usage du CNAME et préconise plutôt l'utilisation de l'alias.
Dans le fichier de zone, le nom mchine4.homelan.net est-il défini dans
un enregistrement de type 'CNAME' pointant vers ns.homelan.net ou de
type 'A' pointant vers 192.168.0.4 ? Ce n'est qu'avec un CNAME que le
lookup indique que le nom est un alias.
Je viens de regarder dans le man.
L'auteur déconseille l'usage du CNAME et préconise plutôt l'utilisation
de l'alias.
Dans le fichier de zone, le nom mchine4.homelan.net est-il défini dans un enregistrement de type 'CNAME' pointant vers ns.homelan.net ou de type 'A' pointant vers 192.168.0.4 ? Ce n'est qu'avec un CNAME que le lookup indique que le nom est un alias.
Je viens de regarder dans le man. L'auteur déconseille l'usage du CNAME et préconise plutôt l'utilisation de l'alias.
Pascal
François RONVAUX wrote:
Dans le fichier de zone, le nom mchine4.homelan.net est-il défini dans un enregistrement de type 'CNAME' pointant vers ns.homelan.net ou de type 'A' pointant vers 192.168.0.4 ? Ce n'est qu'avec un CNAME que le lookup indique que le nom est un alias.
Je viens de regarder dans le man. L'auteur déconseille l'usage du CNAME et préconise plutôt l'utilisation de l'alias.
Certes l'emploi du CNAME est soumis à des restrictions. Mais ça ne répond pas directement à ma question. Je suppose indirectement que tu n'as pas utilisé un CNAME. Par contre je ne vois pas ce que l'auteur entend par "alias" en terme de type d'enregistrement DNS. J'avais dans l'idée que c'était un synonyme de CNAME.
François RONVAUX wrote:
Dans le fichier de zone, le nom mchine4.homelan.net est-il défini dans
un enregistrement de type 'CNAME' pointant vers ns.homelan.net ou de
type 'A' pointant vers 192.168.0.4 ? Ce n'est qu'avec un CNAME que le
lookup indique que le nom est un alias.
Je viens de regarder dans le man.
L'auteur déconseille l'usage du CNAME et préconise plutôt l'utilisation
de l'alias.
Certes l'emploi du CNAME est soumis à des restrictions. Mais ça ne
répond pas directement à ma question. Je suppose indirectement que tu
n'as pas utilisé un CNAME. Par contre je ne vois pas ce que l'auteur
entend par "alias" en terme de type d'enregistrement DNS. J'avais dans
l'idée que c'était un synonyme de CNAME.
Dans le fichier de zone, le nom mchine4.homelan.net est-il défini dans un enregistrement de type 'CNAME' pointant vers ns.homelan.net ou de type 'A' pointant vers 192.168.0.4 ? Ce n'est qu'avec un CNAME que le lookup indique que le nom est un alias.
Je viens de regarder dans le man. L'auteur déconseille l'usage du CNAME et préconise plutôt l'utilisation de l'alias.
Certes l'emploi du CNAME est soumis à des restrictions. Mais ça ne répond pas directement à ma question. Je suppose indirectement que tu n'as pas utilisé un CNAME. Par contre je ne vois pas ce que l'auteur entend par "alias" en terme de type d'enregistrement DNS. J'avais dans l'idée que c'était un synonyme de CNAME.
François RONVAUX
Mais ça ne répond pas directement à ma question.
Oups pardon :-)
Je suppose indirectement que tu n'as pas utilisé un CNAME.
Effectivement, comme j'utilise les scripts ad-hoc pour ajouter les membres du réseau, il n'y a comme choix possible que host, alias, ns, childns et mx. Pas de script pour CNAME, bien qu'il soit possible d'éditer manuellement le fichier de zone pour ajouter la ligne adéquate.
Mais ça ne
répond pas directement à ma question.
Oups pardon :-)
Je suppose indirectement que tu
n'as pas utilisé un CNAME.
Effectivement, comme j'utilise les scripts ad-hoc pour ajouter les
membres du réseau, il n'y a comme choix possible que host, alias, ns,
childns et mx.
Pas de script pour CNAME, bien qu'il soit possible d'éditer manuellement
le fichier de zone pour ajouter la ligne adéquate.
Je suppose indirectement que tu n'as pas utilisé un CNAME.
Effectivement, comme j'utilise les scripts ad-hoc pour ajouter les membres du réseau, il n'y a comme choix possible que host, alias, ns, childns et mx. Pas de script pour CNAME, bien qu'il soit possible d'éditer manuellement le fichier de zone pour ajouter la ligne adéquate.
Pascal
François RONVAUX wrote:
Je suppose indirectement que tu n'as pas utilisé un CNAME.
Effectivement, comme j'utilise les scripts ad-hoc pour ajouter les membres du réseau, il n'y a comme choix possible que host, alias, ns, childns et mx. Pas de script pour CNAME, bien qu'il soit possible d'éditer manuellement le fichier de zone pour ajouter la ligne adéquate.
Piqué par la curiosité, j'ai trouvé cette discussion en anglais dans l'archive de comp.protocols.dns.bind (lien long): http://groups.google.fr/groups?hl=fr&lr=&threadmÃ4tnr%2414d5%241%40sf1.isc.org&rnum=1&prev=/groups%3Fhl%3Dfr%26lr%3D%26selm%3Dc34tnr%252414d5%25241%2540sf1.isc.org
-- Extrait <c34tnr$14d5$ --
d> I do not think there is any distinction between "A" d> and "CNAME" records. [note de moi : dans tinydns]
Nonetheless, there actually is.
d> The "add-alias" script only accepts an IP address for the target!
Correct, and nothing to in fact be surprised at. "add-alias" is (one of quite a few means) for creating _server-side_ aliases. "CNAME" resource records are _client-side_ aliases.
Understanding that there are _two different kinds_ of aliases is an important step in the understanding of DNS service.
-- Fin extrait <c34tnr$14d5$ --
Il est dit en gros que : 1) Le script de création d'alias de tinydns prend une adresse IP comme argument, donc cela ne peut créer un enregistrement CNAME. 2) Il y aurait dans DNS deux types d'alias, "côté client" et "côté serveur". Le CNAME serait l'alias "côté client". Par contre je ne vois pas du tout à quoi correspond l'alias "côté serveur".
François RONVAUX wrote:
Je suppose indirectement que tu n'as pas utilisé un CNAME.
Effectivement, comme j'utilise les scripts ad-hoc pour ajouter les
membres du réseau, il n'y a comme choix possible que host, alias, ns,
childns et mx.
Pas de script pour CNAME, bien qu'il soit possible d'éditer manuellement
le fichier de zone pour ajouter la ligne adéquate.
Piqué par la curiosité, j'ai trouvé cette discussion en anglais dans
l'archive de comp.protocols.dns.bind (lien long):
http://groups.google.fr/groups?hl=fr&lr=&threadmÃ4tnr%2414d5%241%40sf1.isc.org&rnum=1&prev=/groups%3Fhl%3Dfr%26lr%3D%26selm%3Dc34tnr%252414d5%25241%2540sf1.isc.org
-- Extrait <c34tnr$14d5$1@sf1.isc.org> --
d> I do not think there is any distinction between "A"
d> and "CNAME" records.
[note de moi : dans tinydns]
Nonetheless, there actually is.
d> The "add-alias" script only accepts an IP address for the target!
Correct, and nothing to in fact be surprised at. "add-alias" is (one of
quite a few means) for creating _server-side_ aliases. "CNAME" resource
records are _client-side_ aliases.
Understanding that there are _two different kinds_ of aliases is an
important step in the understanding of DNS service.
-- Fin extrait <c34tnr$14d5$1@sf1.isc.org> --
Il est dit en gros que :
1) Le script de création d'alias de tinydns prend une adresse IP comme
argument, donc cela ne peut créer un enregistrement CNAME.
2) Il y aurait dans DNS deux types d'alias, "côté client" et "côté
serveur". Le CNAME serait l'alias "côté client". Par contre je ne vois
pas du tout à quoi correspond l'alias "côté serveur".
Je suppose indirectement que tu n'as pas utilisé un CNAME.
Effectivement, comme j'utilise les scripts ad-hoc pour ajouter les membres du réseau, il n'y a comme choix possible que host, alias, ns, childns et mx. Pas de script pour CNAME, bien qu'il soit possible d'éditer manuellement le fichier de zone pour ajouter la ligne adéquate.
Piqué par la curiosité, j'ai trouvé cette discussion en anglais dans l'archive de comp.protocols.dns.bind (lien long): http://groups.google.fr/groups?hl=fr&lr=&threadmÃ4tnr%2414d5%241%40sf1.isc.org&rnum=1&prev=/groups%3Fhl%3Dfr%26lr%3D%26selm%3Dc34tnr%252414d5%25241%2540sf1.isc.org
-- Extrait <c34tnr$14d5$ --
d> I do not think there is any distinction between "A" d> and "CNAME" records. [note de moi : dans tinydns]
Nonetheless, there actually is.
d> The "add-alias" script only accepts an IP address for the target!
Correct, and nothing to in fact be surprised at. "add-alias" is (one of quite a few means) for creating _server-side_ aliases. "CNAME" resource records are _client-side_ aliases.
Understanding that there are _two different kinds_ of aliases is an important step in the understanding of DNS service.
-- Fin extrait <c34tnr$14d5$ --
Il est dit en gros que : 1) Le script de création d'alias de tinydns prend une adresse IP comme argument, donc cela ne peut créer un enregistrement CNAME. 2) Il y aurait dans DNS deux types d'alias, "côté client" et "côté serveur". Le CNAME serait l'alias "côté client". Par contre je ne vois pas du tout à quoi correspond l'alias "côté serveur".
