J'étais bien tranquille par ce dimanche maussade, dans ma salle, lorsque le
froid et l'humidité me gagnèrent. Alors, j'ai allumé la cheminée et, devant
un feu crépitant et joyeux, la chaleur m'envahissant, je me suis décidé à
poser ces quelques questions.
(1) Un client DNS peut-il avoir un cache ? Ou bien le cache est-il l'apanage
des serveurs DNS.
(2) Depuis chez moi, est-ce que je peux, par un procédé quelconque, obtenir
l'adresse de l'une des bases de donnée racine et aussi, celle d'un niveau
TLD, ".fr" par exemple.
(3) Un amateur comme moi m'a parlé de DNS sur TCP ! suis-je plus amateur que
lui ? J'ai l'impression que DNS ne s'appuye que sur du non-connecté.
Le problème est donc que les différentes adresses en question ne sont pas sur le même réseau. Et donc le contrôle du routage est pour le moins arbitraire, et va dépendre du point de départ, mais pas de façon optimale. L'approche de K est bien meilleure (même si elle est nettement plus limitée pour le moment).
Un scénario possible :
Mon opérateur Wanadoo utilise le backbone Opentransit qui doit bien desservir l'Asie, le serveur de racine f qui est déclaré dans ses tables de routage (par BGP) est celui de Hong Kong.
Ton opérateur utilise la fibre d'AboveNet qui passe de Londres à New York. De là, il est plus simple de rejoindre la Californie pour le serveur f de Palo Alto.
Bref ! ça nous éloigne un peu de Berduche-lès-Fossés.
Cordialement, Angelot
Bonsoir Jacques,
Le problème est donc que les différentes adresses en question ne sont pas
sur le même réseau. Et donc le contrôle du routage est pour le moins
arbitraire, et va dépendre du point de départ, mais pas de façon optimale.
L'approche de K est bien meilleure (même si elle est nettement plus
limitée pour le moment).
Un scénario possible :
Mon opérateur Wanadoo utilise le backbone Opentransit qui doit bien
desservir l'Asie, le serveur de racine f qui est déclaré dans ses tables de
routage (par BGP) est celui de Hong Kong.
Ton opérateur utilise la fibre d'AboveNet qui passe de Londres à New York.
De là, il est plus simple de rejoindre la Californie pour le serveur f de
Palo Alto.
Bref ! ça nous éloigne un peu de Berduche-lès-Fossés.
Le problème est donc que les différentes adresses en question ne sont pas sur le même réseau. Et donc le contrôle du routage est pour le moins arbitraire, et va dépendre du point de départ, mais pas de façon optimale. L'approche de K est bien meilleure (même si elle est nettement plus limitée pour le moment).
Un scénario possible :
Mon opérateur Wanadoo utilise le backbone Opentransit qui doit bien desservir l'Asie, le serveur de racine f qui est déclaré dans ses tables de routage (par BGP) est celui de Hong Kong.
Ton opérateur utilise la fibre d'AboveNet qui passe de Londres à New York. De là, il est plus simple de rejoindre la Californie pour le serveur f de Palo Alto.
Bref ! ça nous éloigne un peu de Berduche-lès-Fossés.
Cordialement, Angelot
Jaster
Disons qu'avant on devait se limiter a moins de 13 serveurs avec les anciens noms non harmonisés. Si on doit effectivement mettre le nom "complet" (FQDN), alors on pouvait
en mettre plus avant, ils avaient le plus souvent des noms beaucoup plus courts que les noms actuels.
Mais il me semble que dans la trame dns, il faut le fqdn complet du serveur, donc il faut imperativement le suffixe "root-servers.net".
[snip]
D'abord, les root-servers et les gtld-servers ne sont plus forcément les mêmes (alors qu'avant on utilisait la même série de NS pour ., .com, .net et .org, et probablement .edu et .gov aussi, je ne sais plus). D'ailleurs il me semble que les NS pour . sont toujours gérés à droite et à gauche par différentes entités, alors que les NS pour .com et .net sont gérés directement par Verisign. A vérifier. Ensuite, chaque NS (ou est-ce seulement les gtld-servers? sais plus) est en fait une paire de machines (on pourrait hâtivement qualifier ça de cluster).
Apres quelques recherches / vérifications :
Il n'y aura toujours que 13 serveurs racines dans le DNS (au sens adresse IP de service) cependant physiquement il n'y a pas que 13 machines !
- grace aux clusters effectivement (cela va de soi j'aurais tendance a dire) - grace a l'unicast (tiens oui j'ai aussi appris que cette bidouille qu'ils ont fait sur certains serveurs s'appelait comme ca). Toutes ces machines faisant partie d'un "groupe unicast" sont des clones qui repondent a la meme adresse IP selon l'endroit on l'on se trouve (a peu pres, lol :o) Cela contribue à limiter un eventuel DDoS devastateur. Le fameux serveur russe n'etait donc qu'une nouvelle instanciation d'un serveur existant et non pas un "nouveau serveur racine" (au sens service).
J'ai retrouvé la formule du japonais (et l'ajout des premiers record IPv6)
SZ(X, Y, Z) = 33 + 15X + 16Y + 28Z http://www.rssac.org/kato-v6-root.html (Effectivement on utilise un pointeur pour le nom, mais bon ca ne changait pas trop l'ordre de grandeur de ma formule vaseuse)
Un lien sympa qui liste les serveurs http://www.root-servers.org
Et 2/3 slides succints mais assez clairs. http://www.root-servers.org/presentations/rootops-gac-rio.pdf
Fabien
Disons qu'avant on devait se limiter a moins de 13 serveurs avec
les anciens noms non harmonisés.
Si on doit effectivement mettre le nom "complet" (FQDN), alors on pouvait
en mettre plus avant, ils avaient le plus souvent des noms beaucoup plus
courts que les noms actuels.
Mais il me semble que dans la trame dns, il faut le fqdn complet du
serveur, donc il faut imperativement le suffixe "root-servers.net".
[snip]
D'abord, les root-servers et les gtld-servers ne sont plus forcément les
mêmes (alors qu'avant on utilisait la même série de NS pour ., .com, .net
et .org, et probablement .edu et .gov aussi, je ne sais plus). D'ailleurs
il me semble que les NS pour . sont toujours gérés à droite et à gauche
par différentes entités, alors que les NS pour .com et .net sont gérés
directement par Verisign. A vérifier.
Ensuite, chaque NS (ou est-ce seulement les gtld-servers? sais plus) est
en fait une paire de machines (on pourrait hâtivement qualifier ça de
cluster).
Apres quelques recherches / vérifications :
Il n'y aura toujours que 13 serveurs racines dans le DNS (au sens adresse IP
de service)
cependant physiquement il n'y a pas que 13 machines !
- grace aux clusters effectivement (cela va de soi j'aurais tendance a dire)
- grace a l'unicast (tiens oui j'ai aussi appris que cette bidouille qu'ils
ont fait sur certains serveurs s'appelait
comme ca). Toutes ces machines faisant partie d'un "groupe unicast" sont des
clones qui repondent a la
meme adresse IP selon l'endroit on l'on se trouve (a peu pres, lol :o)
Cela contribue à limiter un eventuel DDoS devastateur.
Le fameux serveur russe n'etait donc qu'une nouvelle instanciation d'un
serveur existant
et non pas un "nouveau serveur racine" (au sens service).
J'ai retrouvé la formule du japonais (et l'ajout des premiers record IPv6)
SZ(X, Y, Z) = 33 + 15X + 16Y + 28Z
http://www.rssac.org/kato-v6-root.html
(Effectivement on utilise un pointeur pour le nom, mais bon ca ne changait
pas trop l'ordre de grandeur de
ma formule vaseuse)
Un lien sympa qui liste les serveurs
http://www.root-servers.org
Et 2/3 slides succints mais assez clairs.
http://www.root-servers.org/presentations/rootops-gac-rio.pdf
Disons qu'avant on devait se limiter a moins de 13 serveurs avec les anciens noms non harmonisés. Si on doit effectivement mettre le nom "complet" (FQDN), alors on pouvait
en mettre plus avant, ils avaient le plus souvent des noms beaucoup plus courts que les noms actuels.
Mais il me semble que dans la trame dns, il faut le fqdn complet du serveur, donc il faut imperativement le suffixe "root-servers.net".
[snip]
D'abord, les root-servers et les gtld-servers ne sont plus forcément les mêmes (alors qu'avant on utilisait la même série de NS pour ., .com, .net et .org, et probablement .edu et .gov aussi, je ne sais plus). D'ailleurs il me semble que les NS pour . sont toujours gérés à droite et à gauche par différentes entités, alors que les NS pour .com et .net sont gérés directement par Verisign. A vérifier. Ensuite, chaque NS (ou est-ce seulement les gtld-servers? sais plus) est en fait une paire de machines (on pourrait hâtivement qualifier ça de cluster).
Apres quelques recherches / vérifications :
Il n'y aura toujours que 13 serveurs racines dans le DNS (au sens adresse IP de service) cependant physiquement il n'y a pas que 13 machines !
- grace aux clusters effectivement (cela va de soi j'aurais tendance a dire) - grace a l'unicast (tiens oui j'ai aussi appris que cette bidouille qu'ils ont fait sur certains serveurs s'appelait comme ca). Toutes ces machines faisant partie d'un "groupe unicast" sont des clones qui repondent a la meme adresse IP selon l'endroit on l'on se trouve (a peu pres, lol :o) Cela contribue à limiter un eventuel DDoS devastateur. Le fameux serveur russe n'etait donc qu'une nouvelle instanciation d'un serveur existant et non pas un "nouveau serveur racine" (au sens service).
J'ai retrouvé la formule du japonais (et l'ajout des premiers record IPv6)
SZ(X, Y, Z) = 33 + 15X + 16Y + 28Z http://www.rssac.org/kato-v6-root.html (Effectivement on utilise un pointeur pour le nom, mais bon ca ne changait pas trop l'ordre de grandeur de ma formule vaseuse)
Un lien sympa qui liste les serveurs http://www.root-servers.org
Et 2/3 slides succints mais assez clairs. http://www.root-servers.org/presentations/rootops-gac-rio.pdf
Fabien
Angelot
Bonjour Fabien,
Merci pour votre intervention
cependant physiquement il n'y a pas que 13 machines !
Je ne peux que vous encourager à lire les liens que vous mentionnez. Il existe une bonne cinquantaine de serveurs physiques. Reprenez aussi le fil de la conversation avec Jacques et dites-nous par exemple vers quel serveur F vous aboutissez, à partir de quel opérateur.
Cordialement, Angelot
Bonjour Fabien,
Merci pour votre intervention
cependant physiquement il n'y a pas que 13 machines !
Je ne peux que vous encourager à lire les liens que vous mentionnez. Il
existe une bonne cinquantaine de serveurs physiques. Reprenez aussi le fil
de la conversation avec Jacques et dites-nous par exemple vers quel serveur
F vous aboutissez, à partir de quel opérateur.
cependant physiquement il n'y a pas que 13 machines !
Je ne peux que vous encourager à lire les liens que vous mentionnez. Il existe une bonne cinquantaine de serveurs physiques. Reprenez aussi le fil de la conversation avec Jacques et dites-nous par exemple vers quel serveur F vous aboutissez, à partir de quel opérateur.
Cordialement, Angelot
Jaster
Je ne peux que vous encourager à lire les liens que vous mentionnez. Il existe une bonne cinquantaine de serveurs physiques.
gni ? c'est pour ca que je dis ca, c'etait un résumé pour le thread :o)
Reprenez aussi le fil de la conversation avec Jacques et dites-nous par exemple vers quel serveur
F vous aboutissez, à partir de quel opérateur.
pour info, avec Free depuis Paris
2 40 ms 34 ms 35 ms p19-6k-1-a5.routers.proxad.net [213.228.5.254] 3 41 ms 35 ms 35 ms th1-6k-1-a6.routers.proxad.net [213.228.3.3] 4 41 ms 35 ms 35 ms above.FreeIX.net [213.228.3.234] 5 41 ms 35 ms 35 ms pos8-0.cr1.cdg2.fr.above.net [208.184.231.214] 6 41 ms 47 ms 47 ms so-5-1-0.cr1.lhr3.uk.above.net [64.125.31.129] 7 42 ms 47 ms 46 ms so-0-0-0.cr2.lhr3.uk.above.net [208.184.231.146] 8 149 ms 143 ms 143 ms so-7-0-0.cr2.lga1.us.above.net [64.125.31.182] 9 149 ms 155 ms 155 ms so-1-0-0.cr2.iad1.us.mfnx.net [208.184.233.65] 10 155 ms 155 ms 155 ms so-1-0-0.cr2.dca2.us.mfnx.net [208.184.233.129] 11 222 ms 227 ms 227 ms so-6-3-0.mpr4.sjc2.us.above.net [64.125.30.166] 12 233 ms 227 ms 227 ms pos-1-0.mpr2.pao1.us.above.net [209.249.0.125] 13 221 ms 227 ms 227 ms pos2-0.mpr1.pao1.us.mfnx.net [208.184.232.181] 14 207 ms 215 ms 214 ms isc-above-oc3.pao.isc.org [216.200.0.10] 15 207 ms 215 ms 215 ms f.root-servers.net [192.5.5.241]
Amicalement Fabien
Je ne peux que vous encourager à lire les liens que vous mentionnez. Il
existe une bonne cinquantaine de serveurs physiques.
gni ? c'est pour ca que je dis ca, c'etait un résumé pour le thread :o)
Reprenez aussi le fil
de la conversation avec Jacques et dites-nous par exemple vers quel
serveur
F vous aboutissez, à partir de quel opérateur.
pour info, avec Free depuis Paris
2 40 ms 34 ms 35 ms p19-6k-1-a5.routers.proxad.net
[213.228.5.254]
3 41 ms 35 ms 35 ms th1-6k-1-a6.routers.proxad.net [213.228.3.3]
4 41 ms 35 ms 35 ms above.FreeIX.net [213.228.3.234]
5 41 ms 35 ms 35 ms pos8-0.cr1.cdg2.fr.above.net
[208.184.231.214]
6 41 ms 47 ms 47 ms so-5-1-0.cr1.lhr3.uk.above.net
[64.125.31.129]
7 42 ms 47 ms 46 ms so-0-0-0.cr2.lhr3.uk.above.net
[208.184.231.146]
8 149 ms 143 ms 143 ms so-7-0-0.cr2.lga1.us.above.net
[64.125.31.182]
9 149 ms 155 ms 155 ms so-1-0-0.cr2.iad1.us.mfnx.net
[208.184.233.65]
10 155 ms 155 ms 155 ms so-1-0-0.cr2.dca2.us.mfnx.net
[208.184.233.129]
11 222 ms 227 ms 227 ms so-6-3-0.mpr4.sjc2.us.above.net
[64.125.30.166]
12 233 ms 227 ms 227 ms pos-1-0.mpr2.pao1.us.above.net
[209.249.0.125]
13 221 ms 227 ms 227 ms pos2-0.mpr1.pao1.us.mfnx.net
[208.184.232.181]
14 207 ms 215 ms 214 ms isc-above-oc3.pao.isc.org [216.200.0.10]
15 207 ms 215 ms 215 ms f.root-servers.net [192.5.5.241]
Je ne peux que vous encourager à lire les liens que vous mentionnez. Il existe une bonne cinquantaine de serveurs physiques.
gni ? c'est pour ca que je dis ca, c'etait un résumé pour le thread :o)
Reprenez aussi le fil de la conversation avec Jacques et dites-nous par exemple vers quel serveur
F vous aboutissez, à partir de quel opérateur.
pour info, avec Free depuis Paris
2 40 ms 34 ms 35 ms p19-6k-1-a5.routers.proxad.net [213.228.5.254] 3 41 ms 35 ms 35 ms th1-6k-1-a6.routers.proxad.net [213.228.3.3] 4 41 ms 35 ms 35 ms above.FreeIX.net [213.228.3.234] 5 41 ms 35 ms 35 ms pos8-0.cr1.cdg2.fr.above.net [208.184.231.214] 6 41 ms 47 ms 47 ms so-5-1-0.cr1.lhr3.uk.above.net [64.125.31.129] 7 42 ms 47 ms 46 ms so-0-0-0.cr2.lhr3.uk.above.net [208.184.231.146] 8 149 ms 143 ms 143 ms so-7-0-0.cr2.lga1.us.above.net [64.125.31.182] 9 149 ms 155 ms 155 ms so-1-0-0.cr2.iad1.us.mfnx.net [208.184.233.65] 10 155 ms 155 ms 155 ms so-1-0-0.cr2.dca2.us.mfnx.net [208.184.233.129] 11 222 ms 227 ms 227 ms so-6-3-0.mpr4.sjc2.us.above.net [64.125.30.166] 12 233 ms 227 ms 227 ms pos-1-0.mpr2.pao1.us.above.net [209.249.0.125] 13 221 ms 227 ms 227 ms pos2-0.mpr1.pao1.us.mfnx.net [208.184.232.181] 14 207 ms 215 ms 214 ms isc-above-oc3.pao.isc.org [216.200.0.10] 15 207 ms 215 ms 215 ms f.root-servers.net [192.5.5.241]
Amicalement Fabien
Stephane T.
Jaster wrote: ...
Pour moi, il ne peut pas y avoir plus de 13 serveurs racines dans l'etat actuel des choses a cause des 512 octets max du message udp (rfc 1035). la totalité des serveurs racines doivent tenir en une seule reponse (dans un NS record)
<<RFC 2671 - Extension Mechanisms for DNS (EDNS0)>> http://www.faqs.org/rfcs/rfc2671.html
, Stephane
Jaster wrote:
...
Pour moi, il ne peut pas y avoir plus de 13 serveurs racines dans l'etat
actuel des choses
a cause des 512 octets max du message udp (rfc 1035).
la totalité des serveurs racines doivent tenir en une seule reponse (dans un
NS record)
<<RFC 2671 - Extension Mechanisms for DNS (EDNS0)>>
http://www.faqs.org/rfcs/rfc2671.html
Pour moi, il ne peut pas y avoir plus de 13 serveurs racines dans l'etat actuel des choses a cause des 512 octets max du message udp (rfc 1035). la totalité des serveurs racines doivent tenir en une seule reponse (dans un NS record)
<<RFC 2671 - Extension Mechanisms for DNS (EDNS0)>> http://www.faqs.org/rfcs/rfc2671.html
, Stephane
Angelot
Bonsoir Jaster,
J'étais en train de faire une réponse le soir-même quand mon PC s'est bloqué (manque de mémoire).
gni ? c'est pour ca que je dis ca, c'etait un résumé pour le thread :o)
On finit par se prendre les pieds dans le fil !
12 233 ms 227 ms 227 ms pos-1-0.mpr2.pao1.us.above.net [209.249.0.125] 13 221 ms 227 ms 227 ms pos2-0.mpr1.pao1.us.mfnx.net [208.184.232.181] 14 207 ms 215 ms 214 ms isc-above-oc3.pao.isc.org [216.200.0.10] 15 207 ms 215 ms 215 ms f.root-servers.net [192.5.5.241]
Comme Jacques les accords de peering vous font passer par le backbone AboveNet MFN pour rejoindre en OC3 l'opérateur local de Californie, PAIX, qui dispose dans ses locaux du serveur racine F.
J'étais en train de faire une réponse le soir-même quand mon PC s'est bloqué
(manque de mémoire).
gni ? c'est pour ca que je dis ca, c'etait un résumé pour le thread :o)
On finit par se prendre les pieds dans le fil !
12 233 ms 227 ms 227 ms pos-1-0.mpr2.pao1.us.above.net
[209.249.0.125]
13 221 ms 227 ms 227 ms pos2-0.mpr1.pao1.us.mfnx.net
[208.184.232.181]
14 207 ms 215 ms 214 ms isc-above-oc3.pao.isc.org [216.200.0.10]
15 207 ms 215 ms 215 ms f.root-servers.net [192.5.5.241]
Comme Jacques les accords de peering vous font passer par le backbone
AboveNet MFN pour rejoindre en OC3 l'opérateur local de Californie, PAIX,
qui dispose dans ses locaux du serveur racine F.
J'étais en train de faire une réponse le soir-même quand mon PC s'est bloqué (manque de mémoire).
gni ? c'est pour ca que je dis ca, c'etait un résumé pour le thread :o)
On finit par se prendre les pieds dans le fil !
12 233 ms 227 ms 227 ms pos-1-0.mpr2.pao1.us.above.net [209.249.0.125] 13 221 ms 227 ms 227 ms pos2-0.mpr1.pao1.us.mfnx.net [208.184.232.181] 14 207 ms 215 ms 214 ms isc-above-oc3.pao.isc.org [216.200.0.10] 15 207 ms 215 ms 215 ms f.root-servers.net [192.5.5.241]
Comme Jacques les accords de peering vous font passer par le backbone AboveNet MFN pour rejoindre en OC3 l'opérateur local de Californie, PAIX, qui dispose dans ses locaux du serveur racine F.
a cause des 512 octets max du message udp (rfc 1035). la totalité des serveurs racines doivent tenir en une seule reponse (dans un
NS record)
<<RFC 2671 - Extension Mechanisms for DNS (EDNS0)>> http://www.faqs.org/rfcs/rfc2671.html
Intéressant, je lis cela :
"Note that a 512-octet UDP payload requires a 576-octet IP reassembly buffer. Choosing 1280 on an Ethernet connected requestor would be reasonable. The consequence of choosing too large a value may be an ICMP message from an intermediate gateway, or even a silent drop of the response message".
Je ne pige pas cette différence de 64 octets entre la charge utile UDP et le tampon IP. Un avis éclairé ?
Je pense que les 1280 octets Ethernet correspondent à la charge utile de la trame. Ce qui devrait faire une charge utile UDP de 1244 octets au lieu de 512 !
Cordialement, Angelot
Bonsoir Stéphane,
a cause des 512 octets max du message udp (rfc 1035).
la totalité des serveurs racines doivent tenir en une seule reponse
(dans un
NS record)
<<RFC 2671 - Extension Mechanisms for DNS (EDNS0)>>
http://www.faqs.org/rfcs/rfc2671.html
Intéressant, je lis cela :
"Note that a 512-octet UDP payload requires a 576-octet IP reassembly
buffer. Choosing 1280 on an Ethernet connected requestor would be
reasonable. The consequence of choosing too large a value may be an ICMP
message from an intermediate gateway, or even a silent drop of the response
message".
Je ne pige pas cette différence de 64 octets entre la charge utile UDP et le
tampon IP.
Un avis éclairé ?
Je pense que les 1280 octets Ethernet correspondent à la charge utile de la
trame. Ce qui devrait faire une charge utile UDP de 1244 octets au lieu de
512 !
a cause des 512 octets max du message udp (rfc 1035). la totalité des serveurs racines doivent tenir en une seule reponse (dans un
NS record)
<<RFC 2671 - Extension Mechanisms for DNS (EDNS0)>> http://www.faqs.org/rfcs/rfc2671.html
Intéressant, je lis cela :
"Note that a 512-octet UDP payload requires a 576-octet IP reassembly buffer. Choosing 1280 on an Ethernet connected requestor would be reasonable. The consequence of choosing too large a value may be an ICMP message from an intermediate gateway, or even a silent drop of the response message".
Je ne pige pas cette différence de 64 octets entre la charge utile UDP et le tampon IP. Un avis éclairé ?
Je pense que les 1280 octets Ethernet correspondent à la charge utile de la trame. Ce qui devrait faire une charge utile UDP de 1244 octets au lieu de 512 !
