Je rencontre le problème suivant en tentant une connexion ADSL chez
tiscali.be avec une slackware 10, rp-pppoe-3.5 et un modem ethernet
Alcatel Speedtouch.
Après avoir lancé le script adsl-start, je constate assez rapidement en
tapant un ifconfig que l'interface eth0 est activée et l'interface ppp0
créée. Une adresse IP m'est donc attribuée.
Il m'est cependant impossible de faire un ping vers quelque adresse que
ce soit, même vers une IP numérique (donc vraissembleblement pas un
problème de DNS)
Si je tape la commande route, elle reste en suspens sans rien afficher
tant que je n'ai pas fait un Ctrl-C (elle n'affiche même pas la ligne
relative au loopback qui s'affichait avant la tentative de connexion).
J'ai adapté le script adsl-start de manière à ce qu'il fonctionne en
mode debug et le fichier log contient ce qui suit :
using channel 7
Using interface ppp0
Connect: ppp0 <--> /dev/pts/0
rcvd [LCP ConfReq id=0x89 <mru 1492> <auth chap MD5> <magic 0x3681454d>]
sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x24a526c0>]
sent [LCP ConfAck id=0x89 <mru 1492> <auth chap MD5> <magic 0x3681454d>]
rcvd [LCP ConfAck id=0x1 <mru 1492> <magic 0x24a526c0>]
sent [LCP EchoReq id=0x0 magic=0x24a526c0]
rcvd [CHAP Challenge id=0x1 <4ae567a61b7325a86fa8fd056fc8e6c7>, name = "BAS-NAMUR"]
sent [CHAP Response id=0x1 <d6e169feb625b031d2e822a7d07560dd>, name = "xxxxxxxx@pro.tiscali.be"]
rcvd [LCP EchoRep id=0x0 magic=0x3681454d]
rcvd [CHAP Success id=0x1 "CHAP authentication success, unit 35804"]
CHAP authentication succeeded: CHAP authentication success, unit 35804
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>]
rcvd [IPCP ConfReq id=0x90 <addr 83.134.199.1>]
sent [IPCP ConfAck id=0x90 <addr 83.134.199.1>]
rcvd [IPCP ConfNak id=0x1 <addr 83.134.199.128>]
sent [IPCP ConfReq id=0x2 <addr 83.134.199.128>]
rcvd [IPCP ConfAck id=0x2 <addr 83.134.199.128>]
Cannot determine ethernet address for proxy ARP
local IP address 83.134.199.128
remote IP address 83.134.199.1
J'imagine que le problème est lié à la ligne relative au proxy ARP ; je
n'en connais pas la signification. Pourrait-on m'éclairer ?
Je précise que l'ensemble PC/carte réseau/câblage/modem a permis une
connexion auprès d'un autre fournisseur (pas de problème hardware donc)
et que la connexion chez tiscali s'effectue correctement sous ce même
compte au départ d'un PC windows avec modem USB.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal
Salut,
Il m'est cependant impossible de faire un ping vers quelque adresse que ce soit, même vers une IP numérique
Message d'erreur ? On peut toujours faire un ping. Qu'il soit refusé à la source ou n'ait pas de réponse est autre chose, le message d'erreur donne souvent des informations sur la cause du problème.
Si je tape la commande route, elle reste en suspens sans rien afficher tant que je n'ai pas fait un Ctrl-C
Je ne vois pas passer d'adresses de serveurs DNS. L'option "usepeerdns" est-elle présente dans le fichier d'options de pppd ? Que contient /etc/resolv.conf hors ligne et en ligne ?
Cannot determine ethernet address for proxy ARP
J'imagine que le problème est lié à la ligne relative au proxy ARP ; je n'en connais pas la signification. Pourrait-on m'éclairer ?
Non, rien à voir. Ce message est simplement lié à la présence non nécessaire de l'option "proxyarp" dans le fichier d'options de pppd. Elle sert à faire apparaître le "pair" PPP (la machine à l'autre bout de la liaison PPP, ici le routeur du FAI) comme appartenant au réseau local d'une interface ethernet de ta machine. Cela permet aux machines de ce réseau local de joindre le pair comme s'il était sur le réseau local, ta machine répondant aux requêtes ARP à sa place. Mais ça ne marche que si l'adresse IP du pair appartient à un sous-réseau local de l'hôte. Dans la configuration d'une connexion à un FAI, ce n'est jamais le cas. Par contre, c'est peut-être ce qui se passe côté FAI : cette option est plutôt utilisée par un "serveur" PPP pour associer un hôte distant à un réseau local.
Je précise que l'ensemble PC/carte réseau/câblage/modem a permis une connexion auprès d'un autre fournisseur (pas de problème hardware donc) et que la connexion chez tiscali s'effectue correctement sous ce même compte au départ d'un PC windows avec modem USB.
Vérifie les DNS, les politiques par défaut et règles de filtrage et de NAT iptables/ipchains.
Salut,
Il m'est cependant impossible de faire un ping vers quelque adresse que
ce soit, même vers une IP numérique
Message d'erreur ? On peut toujours faire un ping. Qu'il soit refusé à
la source ou n'ait pas de réponse est autre chose, le message d'erreur
donne souvent des informations sur la cause du problème.
Si je tape la commande route, elle reste en suspens sans rien afficher
tant que je n'ai pas fait un Ctrl-C
Je ne vois pas passer d'adresses de serveurs DNS. L'option "usepeerdns"
est-elle présente dans le fichier d'options de pppd ?
Que contient /etc/resolv.conf hors ligne et en ligne ?
Cannot determine ethernet address for proxy ARP
J'imagine que le problème est lié à la ligne relative au proxy ARP ; je
n'en connais pas la signification. Pourrait-on m'éclairer ?
Non, rien à voir. Ce message est simplement lié à la présence non
nécessaire de l'option "proxyarp" dans le fichier d'options de pppd.
Elle sert à faire apparaître le "pair" PPP (la machine à l'autre bout de
la liaison PPP, ici le routeur du FAI) comme appartenant au réseau local
d'une interface ethernet de ta machine. Cela permet aux machines de ce
réseau local de joindre le pair comme s'il était sur le réseau local, ta
machine répondant aux requêtes ARP à sa place. Mais ça ne marche que si
l'adresse IP du pair appartient à un sous-réseau local de l'hôte. Dans
la configuration d'une connexion à un FAI, ce n'est jamais le cas. Par
contre, c'est peut-être ce qui se passe côté FAI : cette option est
plutôt utilisée par un "serveur" PPP pour associer un hôte distant à un
réseau local.
Je précise que l'ensemble PC/carte réseau/câblage/modem a permis une
connexion auprès d'un autre fournisseur (pas de problème hardware donc)
et que la connexion chez tiscali s'effectue correctement sous ce même
compte au départ d'un PC windows avec modem USB.
Vérifie les DNS, les politiques par défaut et règles de filtrage et de
NAT iptables/ipchains.
Il m'est cependant impossible de faire un ping vers quelque adresse que ce soit, même vers une IP numérique
Message d'erreur ? On peut toujours faire un ping. Qu'il soit refusé à la source ou n'ait pas de réponse est autre chose, le message d'erreur donne souvent des informations sur la cause du problème.
Si je tape la commande route, elle reste en suspens sans rien afficher tant que je n'ai pas fait un Ctrl-C
Je ne vois pas passer d'adresses de serveurs DNS. L'option "usepeerdns" est-elle présente dans le fichier d'options de pppd ? Que contient /etc/resolv.conf hors ligne et en ligne ?
Cannot determine ethernet address for proxy ARP
J'imagine que le problème est lié à la ligne relative au proxy ARP ; je n'en connais pas la signification. Pourrait-on m'éclairer ?
Non, rien à voir. Ce message est simplement lié à la présence non nécessaire de l'option "proxyarp" dans le fichier d'options de pppd. Elle sert à faire apparaître le "pair" PPP (la machine à l'autre bout de la liaison PPP, ici le routeur du FAI) comme appartenant au réseau local d'une interface ethernet de ta machine. Cela permet aux machines de ce réseau local de joindre le pair comme s'il était sur le réseau local, ta machine répondant aux requêtes ARP à sa place. Mais ça ne marche que si l'adresse IP du pair appartient à un sous-réseau local de l'hôte. Dans la configuration d'une connexion à un FAI, ce n'est jamais le cas. Par contre, c'est peut-être ce qui se passe côté FAI : cette option est plutôt utilisée par un "serveur" PPP pour associer un hôte distant à un réseau local.
Je précise que l'ensemble PC/carte réseau/câblage/modem a permis une connexion auprès d'un autre fournisseur (pas de problème hardware donc) et que la connexion chez tiscali s'effectue correctement sous ce même compte au départ d'un PC windows avec modem USB.
Vérifie les DNS, les politiques par défaut et règles de filtrage et de NAT iptables/ipchains.
Dominique Blas
Gauthier wrote:
Bonjour à tous,
Je rencontre le problème suivant en tentant une connexion ADSL chez tiscali.be avec une slackware 10, rp-pppoe-3.5 et un modem ethernet Alcatel Speedtouch.
Après avoir lancé le script adsl-start, je constate assez rapidement en tapant un ifconfig que l'interface eth0 est activée et l'interface ppp0 créée. Une adresse IP m'est donc attribuée.
Il m'est cependant impossible de faire un ping vers quelque adresse que ce soit, même vers une IP numérique (donc vraissembleblement pas un problème de DNS) tapez ping 83.134.199.1
pour commencer et si ça répond traceroute -n 192.6.7.8
Si je tape la commande route, elle reste en suspens sans rien afficher tant que je n'ai pas fait un Ctrl-C (elle n'affiche même pas la ligne relative au loopback qui s'affichait avant la tentative de connexion). Visiblement un pb de DNS.
Tapez route -n afin déviter la résolution, on y verra déjà plus clair.
Et si la route par défaut n'est pas établie, établissez-la vous-même afin de contrôler que tout est ok et amendez votre script de connexion.
db
-- email : usenet blas net
Gauthier wrote:
Bonjour à tous,
Je rencontre le problème suivant en tentant une connexion ADSL chez
tiscali.be avec une slackware 10, rp-pppoe-3.5 et un modem ethernet
Alcatel Speedtouch.
Après avoir lancé le script adsl-start, je constate assez rapidement en
tapant un ifconfig que l'interface eth0 est activée et l'interface ppp0
créée. Une adresse IP m'est donc attribuée.
Il m'est cependant impossible de faire un ping vers quelque adresse que
ce soit, même vers une IP numérique (donc vraissembleblement pas un
problème de DNS)
tapez ping 83.134.199.1
pour commencer
et si ça répond
traceroute -n 192.6.7.8
Si je tape la commande route, elle reste en suspens sans rien afficher
tant que je n'ai pas fait un Ctrl-C (elle n'affiche même pas la ligne
relative au loopback qui s'affichait avant la tentative de connexion).
Visiblement un pb de DNS.
Tapez route -n afin déviter la résolution, on y verra déjà plus clair.
Et si la route par défaut n'est pas établie, établissez-la vous-même afin de
contrôler que tout est ok et amendez votre script de connexion.
Je rencontre le problème suivant en tentant une connexion ADSL chez tiscali.be avec une slackware 10, rp-pppoe-3.5 et un modem ethernet Alcatel Speedtouch.
Après avoir lancé le script adsl-start, je constate assez rapidement en tapant un ifconfig que l'interface eth0 est activée et l'interface ppp0 créée. Une adresse IP m'est donc attribuée.
Il m'est cependant impossible de faire un ping vers quelque adresse que ce soit, même vers une IP numérique (donc vraissembleblement pas un problème de DNS) tapez ping 83.134.199.1
pour commencer et si ça répond traceroute -n 192.6.7.8
Si je tape la commande route, elle reste en suspens sans rien afficher tant que je n'ai pas fait un Ctrl-C (elle n'affiche même pas la ligne relative au loopback qui s'affichait avant la tentative de connexion). Visiblement un pb de DNS.
Tapez route -n afin déviter la résolution, on y verra déjà plus clair.
Et si la route par défaut n'est pas établie, établissez-la vous-même afin de contrôler que tout est ok et amendez votre script de connexion.
db
-- email : usenet blas net
Gauthier
Le Mon, 27 Dec 2004 23:13:18 +0100, Dominique Blas a écrit:
Visiblement un pb de DNS. Tapez route -n afin déviter la résolution, on y verra déjà plus clair.
Et si la route par défaut n'est pas établie, établissez-la vous-même afin de contrôler que tout est ok et amendez votre script de connexion.
C'était bien un problème de DNS ; vérification faite auprès du FAI, les adresses DNS fournies par courrier à la souscription n'étaient plus valables... L'option -n de la commande route (merci !) m'avait permis de constater que le routage était établi correctement.
Cela dit, ce n'est pas mon abonnement personnel, cela se déroulait chez une tierce personne qui se connecte ordinairement sous windows XP ; puisque ces adresses DNS avaient été modifiées, je me demande comment ça pouvait ne pas poser problème sur ce système puisque rien n'avait été modifié depuis la configuration initiale. Y a t'il une explication à cela ?
-- ^^ Gauthier (_____/°°-ç | _`-" )/@mmm|| nn nn FOE-Belgium : http://www.amisdelaterre.be
Le Mon, 27 Dec 2004 23:13:18 +0100, Dominique Blas <nospam@spam.int> a écrit:
Visiblement un pb de DNS.
Tapez route -n afin déviter la résolution, on y verra déjà plus clair.
Et si la route par défaut n'est pas établie, établissez-la vous-même afin de
contrôler que tout est ok et amendez votre script de connexion.
C'était bien un problème de DNS ; vérification faite auprès du FAI, les
adresses DNS fournies par courrier à la souscription n'étaient plus
valables...
L'option -n de la commande route (merci !) m'avait permis de constater
que le routage était établi correctement.
Cela dit, ce n'est pas mon abonnement personnel, cela se déroulait chez
une tierce personne qui se connecte ordinairement sous windows XP ;
puisque ces adresses DNS avaient été modifiées, je me demande
comment ça pouvait ne pas poser problème sur ce système puisque
rien n'avait été modifié depuis la configuration initiale.
Y a t'il une explication à cela ?
--
^^ Gauthier
(_____/°°-ç
| _`-"
)/@mmm||
nn nn FOE-Belgium : http://www.amisdelaterre.be
Le Mon, 27 Dec 2004 23:13:18 +0100, Dominique Blas a écrit:
Visiblement un pb de DNS. Tapez route -n afin déviter la résolution, on y verra déjà plus clair.
Et si la route par défaut n'est pas établie, établissez-la vous-même afin de contrôler que tout est ok et amendez votre script de connexion.
C'était bien un problème de DNS ; vérification faite auprès du FAI, les adresses DNS fournies par courrier à la souscription n'étaient plus valables... L'option -n de la commande route (merci !) m'avait permis de constater que le routage était établi correctement.
Cela dit, ce n'est pas mon abonnement personnel, cela se déroulait chez une tierce personne qui se connecte ordinairement sous windows XP ; puisque ces adresses DNS avaient été modifiées, je me demande comment ça pouvait ne pas poser problème sur ce système puisque rien n'avait été modifié depuis la configuration initiale. Y a t'il une explication à cela ?
-- ^^ Gauthier (_____/°°-ç | _`-" )/@mmm|| nn nn FOE-Belgium : http://www.amisdelaterre.be
Pascal
C'était bien un problème de DNS ; vérification faite auprès du FAI, les adresses DNS fournies par courrier à la souscription n'étaient plus valables...
Cela dit, ce n'est pas mon abonnement personnel, cela se déroulait chez une tierce personne qui se connecte ordinairement sous windows XP ; puisque ces adresses DNS avaient été modifiées, je me demande comment ça pouvait ne pas poser problème sur ce système puisque rien n'avait été modifié depuis la configuration initiale. Y a t'il une explication à cela ?
Explication probable : par défaut les connexions PPP sous Windows sont configurées pour utiliser les adresses des serveurs DNS fournies par le pair. On peut faire la même chose avec l'option "usepeerdns" de pppd.
C'était bien un problème de DNS ; vérification faite auprès du FAI, les
adresses DNS fournies par courrier à la souscription n'étaient plus
valables...
Cela dit, ce n'est pas mon abonnement personnel, cela se déroulait chez
une tierce personne qui se connecte ordinairement sous windows XP ;
puisque ces adresses DNS avaient été modifiées, je me demande
comment ça pouvait ne pas poser problème sur ce système puisque
rien n'avait été modifié depuis la configuration initiale.
Y a t'il une explication à cela ?
Explication probable : par défaut les connexions PPP sous Windows sont
configurées pour utiliser les adresses des serveurs DNS fournies par le
pair. On peut faire la même chose avec l'option "usepeerdns" de pppd.
C'était bien un problème de DNS ; vérification faite auprès du FAI, les adresses DNS fournies par courrier à la souscription n'étaient plus valables...
Cela dit, ce n'est pas mon abonnement personnel, cela se déroulait chez une tierce personne qui se connecte ordinairement sous windows XP ; puisque ces adresses DNS avaient été modifiées, je me demande comment ça pouvait ne pas poser problème sur ce système puisque rien n'avait été modifié depuis la configuration initiale. Y a t'il une explication à cela ?
Explication probable : par défaut les connexions PPP sous Windows sont configurées pour utiliser les adresses des serveurs DNS fournies par le pair. On peut faire la même chose avec l'option "usepeerdns" de pppd.
Gauthier
Le Tue, 28 Dec 2004 23:49:39 +0100, a écrit:
Explication probable : par défaut les connexions PPP sous Windows sont configurées pour utiliser les adresses des serveurs DNS fournies par le pair. On peut faire la même chose avec l'option "usepeerdns" de pppd.
Intéressant. On peut se demander pourquoi les scripts de connexion sous Linux ne proposent pas ce choix par défaut, ça éviterait des soucis de mise à jour (en plus je ne sais pas si vous avez remarqué, mais il est devenu extrêmement rare qu'un FAI indique les adresses de ses serveurs DNS sur son site)
Encore merci, -- ^^ Gauthier (_____/°°-ç | _`-" )/@mmm|| nn nn FOE-Belgium : http://www.amisdelaterre.be
Le Tue, 28 Dec 2004 23:49:39 +0100, Pascal@plouf <pascal@plouf.invalid> a écrit:
Explication probable : par défaut les connexions PPP sous Windows sont
configurées pour utiliser les adresses des serveurs DNS fournies par le
pair. On peut faire la même chose avec l'option "usepeerdns" de pppd.
Intéressant. On peut se demander pourquoi les scripts de connexion sous
Linux ne proposent pas ce choix par défaut, ça éviterait des soucis de
mise à jour (en plus je ne sais pas si vous avez remarqué, mais il est
devenu extrêmement rare qu'un FAI indique les adresses de ses serveurs
DNS sur son site)
Encore merci,
--
^^ Gauthier
(_____/°°-ç
| _`-"
)/@mmm||
nn nn FOE-Belgium : http://www.amisdelaterre.be
Explication probable : par défaut les connexions PPP sous Windows sont configurées pour utiliser les adresses des serveurs DNS fournies par le pair. On peut faire la même chose avec l'option "usepeerdns" de pppd.
Intéressant. On peut se demander pourquoi les scripts de connexion sous Linux ne proposent pas ce choix par défaut, ça éviterait des soucis de mise à jour (en plus je ne sais pas si vous avez remarqué, mais il est devenu extrêmement rare qu'un FAI indique les adresses de ses serveurs DNS sur son site)
Encore merci, -- ^^ Gauthier (_____/°°-ç | _`-" )/@mmm|| nn nn FOE-Belgium : http://www.amisdelaterre.be
Dominique Blas
Gauthier wrote:
Le Tue, 28 Dec 2004 23:49:39 +0100, a écrit:
Explication probable : par défaut les connexions PPP sous Windows sont configurées pour utiliser les adresses des serveurs DNS fournies par le pair. On peut faire la même chose avec l'option "usepeerdns" de pppd.
Intéressant. On peut se demander pourquoi les scripts de connexion sous Linux ne proposent pas ce choix par défaut, ça éviterait des soucis de mise à jour (en plus je ne sais pas si vous avez remarqué, mais il est devenu extrêmement rare qu'un FAI indique les adresses de ses serveurs DNS sur son site) Forcément, ça se trouve en une simple commande.
Je parle des serveurs publics qui ne sont pas toujours (mais souvent tout de même pour des questions d'économie) les serveurs réservés aux clients.
db
Encore merci, R
-- email : usenet blas net
Gauthier wrote:
Le Tue, 28 Dec 2004 23:49:39 +0100, Pascal@plouf <pascal@plouf.invalid> a
écrit:
Explication probable : par défaut les connexions PPP sous Windows sont
configurées pour utiliser les adresses des serveurs DNS fournies par le
pair. On peut faire la même chose avec l'option "usepeerdns" de pppd.
Intéressant. On peut se demander pourquoi les scripts de connexion sous
Linux ne proposent pas ce choix par défaut, ça éviterait des soucis de
mise à jour (en plus je ne sais pas si vous avez remarqué, mais il est
devenu extrêmement rare qu'un FAI indique les adresses de ses serveurs
DNS sur son site)
Forcément, ça se trouve en une simple commande.
Je parle des serveurs publics
qui ne sont pas toujours (mais souvent tout de même pour des questions
d'économie) les serveurs réservés aux clients.
Explication probable : par défaut les connexions PPP sous Windows sont configurées pour utiliser les adresses des serveurs DNS fournies par le pair. On peut faire la même chose avec l'option "usepeerdns" de pppd.
Intéressant. On peut se demander pourquoi les scripts de connexion sous Linux ne proposent pas ce choix par défaut, ça éviterait des soucis de mise à jour (en plus je ne sais pas si vous avez remarqué, mais il est devenu extrêmement rare qu'un FAI indique les adresses de ses serveurs DNS sur son site) Forcément, ça se trouve en une simple commande.
Je parle des serveurs publics qui ne sont pas toujours (mais souvent tout de même pour des questions d'économie) les serveurs réservés aux clients.
db
Encore merci, R
-- email : usenet blas net
Pascal
(en plus je ne sais pas si vous avez remarqué, mais il est devenu extrêmement rare qu'un FAI indique les adresses de ses serveurs DNS sur son site)
Forcément, ça se trouve en une simple commande. Je parle des serveurs publics
Tu parles des DNS autoritaires pour les domaines gérés par le FAI ? A priori aucun rapport avec les DNS caches récursifs mis à la disposition des clients.
qui ne sont pas toujours (mais souvent tout de même pour des questions d'économie) les serveurs réservés aux clients.
Pas toujours en effet. Chez mon FAI, un seul des DNS joue les deux rôles, les autres sont uniquement caches ou autoritaires.
(en plus je ne sais pas si vous avez remarqué, mais il est
devenu extrêmement rare qu'un FAI indique les adresses de ses serveurs
DNS sur son site)
Forcément, ça se trouve en une simple commande.
Je parle des serveurs publics
Tu parles des DNS autoritaires pour les domaines gérés par le FAI ?
A priori aucun rapport avec les DNS caches récursifs mis à la
disposition des clients.
qui ne sont pas toujours (mais souvent tout de même pour des questions
d'économie) les serveurs réservés aux clients.
Pas toujours en effet. Chez mon FAI, un seul des DNS joue les deux
rôles, les autres sont uniquement caches ou autoritaires.
(en plus je ne sais pas si vous avez remarqué, mais il est devenu extrêmement rare qu'un FAI indique les adresses de ses serveurs DNS sur son site)
Forcément, ça se trouve en une simple commande. Je parle des serveurs publics
Tu parles des DNS autoritaires pour les domaines gérés par le FAI ? A priori aucun rapport avec les DNS caches récursifs mis à la disposition des clients.
qui ne sont pas toujours (mais souvent tout de même pour des questions d'économie) les serveurs réservés aux clients.
Pas toujours en effet. Chez mon FAI, un seul des DNS joue les deux rôles, les autres sont uniquement caches ou autoritaires.
Gauthier
Le Fri, 31 Dec 2004 13:17:43 +0100, a écrit:
(en plus je ne sais pas si vous avez remarqué, mais il est devenu extrêmement rare qu'un FAI indique les adresses de ses serveurs DNS sur son site)
Forcément, ça se trouve en une simple commande.
Ah bon, laquelle ?
Je parle des serveurs publics
Tu parles des DNS autoritaires pour les domaines gérés par le FAI ? A priori aucun rapport avec les DNS caches récursifs mis à la disposition des clients.
qui ne sont pas toujours (mais souvent tout de même pour des questions d'économie) les serveurs réservés aux clients.
Pas toujours en effet. Chez mon FAI, un seul des DNS joue les deux rôles, les autres sont uniquement caches ou autoritaires.
Un peu d'explication, s.v.p. ; qu'est qu'un serveur cache ou autoritaire ?
-- ^^ Gauthier (_____/°°-ç | _`-" )/@mmm|| nn nn FOE-Belgium : http://www.amisdelaterre.be
Le Fri, 31 Dec 2004 13:17:43 +0100, Pascal@plouf <pascal@plouf.invalid> a écrit:
(en plus je ne sais pas si vous avez remarqué, mais il est
devenu extrêmement rare qu'un FAI indique les adresses de ses serveurs
DNS sur son site)
Forcément, ça se trouve en une simple commande.
Ah bon, laquelle ?
Je parle des serveurs publics
Tu parles des DNS autoritaires pour les domaines gérés par le FAI ?
A priori aucun rapport avec les DNS caches récursifs mis à la
disposition des clients.
qui ne sont pas toujours (mais souvent tout de même pour des questions
d'économie) les serveurs réservés aux clients.
Pas toujours en effet. Chez mon FAI, un seul des DNS joue les deux
rôles, les autres sont uniquement caches ou autoritaires.
Un peu d'explication, s.v.p. ; qu'est qu'un serveur cache ou autoritaire ?
--
^^ Gauthier
(_____/°°-ç
| _`-"
)/@mmm||
nn nn FOE-Belgium : http://www.amisdelaterre.be
(en plus je ne sais pas si vous avez remarqué, mais il est devenu extrêmement rare qu'un FAI indique les adresses de ses serveurs DNS sur son site)
Forcément, ça se trouve en une simple commande.
Ah bon, laquelle ?
Je parle des serveurs publics
Tu parles des DNS autoritaires pour les domaines gérés par le FAI ? A priori aucun rapport avec les DNS caches récursifs mis à la disposition des clients.
qui ne sont pas toujours (mais souvent tout de même pour des questions d'économie) les serveurs réservés aux clients.
Pas toujours en effet. Chez mon FAI, un seul des DNS joue les deux rôles, les autres sont uniquement caches ou autoritaires.
Un peu d'explication, s.v.p. ; qu'est qu'un serveur cache ou autoritaire ?
-- ^^ Gauthier (_____/°°-ç | _`-" )/@mmm|| nn nn FOE-Belgium : http://www.amisdelaterre.be
Pascal
(en plus je ne sais pas si vous avez remarqué, mais il est devenu extrêmement rare qu'un FAI indique les adresses de ses serveurs DNS sur son site)
Forcément, ça se trouve en une simple commande.
Ah bon, laquelle ?
Sûrement quelque chose comme par exemple : $ host -t ns <domaine_du_fai>
nslookup -q=ns <domaine_du_fai>
Un peu d'explication, s.v.p. ; qu'est qu'un serveur cache ou autoritaire ?
