A propos de DNS

Jacques Caron

02/12/2003 à 13:01

Salut,

On Mon, 1 Dec 2003 23:32:29 +0100, Jaster <fabjunk.pipo at free.fr> wrote:

le champ ressource d'un message "DNS" tient sur 16 octets (16x13 = 208)
le champ record tient sur 23 octets actuellement (les serveurs
s'appellent
"x.root-servers.net") (23*13 = 299)

Si je ne m'abuse, le but de renommer tout les root servers dans le même
domaine était de pouvoir faire un peu de "compression" en utilisant une
base commune (root-servers.net), ce qui permet ensuite de limiter les noms
des NS à juste [a-m], non?

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

Jaster

02/12/2003 à 20:51

le champ ressource d'un message "DNS" tient sur 16 octets (16x13 = 208)
le champ record tient sur 23 octets actuellement (les serveurs
s'appellent
"x.root-servers.net") (23*13 = 299)

Si je ne m'abuse, le but de renommer tout les root servers dans le même
domaine était de pouvoir faire un peu de "compression" en utilisant une
base commune (root-servers.net), ce qui permet ensuite de limiter les noms
des NS à juste [a-m], non?

Disons qu'avant on devait se limiter a moins de 13 serveurs avec
les anciens noms non harmonisés.
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".
Sinon on pousse effectivement le nombre de racine a 16 ;
et je ne suis pas dans les petits papiers de l'icann mais depuis le temps
ils les auraient montés ces 3 serveurs de plus ... non ?

Fabien

Angelot

02/12/2003 à 22:48

Bonsoir Jaster et Jacques,

Disons qu'avant on devait se limiter a moins de 13 serveurs avec
les anciens noms non harmonisés.
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".
Sinon on pousse effectivement le nombre de racine a 16 ;
et je ne suis pas dans les petits papiers de l'icann mais depuis le temps
ils les auraient montés ces 3 serveurs de plus ... non ?

Permettez que je rajoute une observation sur le nombre de ces serveurs.

Le serveur de racine F par exemple est en fait instancié 15 fois dans le
monde (à Ottawa, Palo Alto, San Jose CA, New York, San Francisco, Madrid,
Hong Kong, Los Angeles, Rome, Auckland, Sao Paulo, Beijing, Seoul, Moscou,
Dubai)

Tous les 15 serveurs ont la même adresse 192.5.5.241 !

Toutes ces choses-là m'émerveillent. J'arrête de dire que les adresses IP
sont uniques (je l'avais déjà un peu fait...).

Cordialement,
Angelot

Jacques Caron

03/12/2003 à 01:13

Salut,

On Tue, 2 Dec 2003 20:51:30 +0100, Jaster <fabjunk.pipo at free.fr> wrote:

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".

Je ne crois pas justement. Il me semble qu'il y a un méchanisme équivalent
à $ORIGIN, ce qui est bienvenu, vu que la probabiilité qu'il y ait
*beaucoup* de noms avec une base commune étant très forte dans n'importe
quelle requête DNS.

[... oqp lire RFC1035 ... ce qu'il y a comme trucs obsolètes là-dedans
dites donc ... ]

Ach voui. Bon, ça marche pas du tout comme je croyais, ce n'est pas du
tout $ORIGIN-like, c'est juste une forme de compression:

-- begin quote --

4.1.4. Message compression

In order to reduce the size of messages, the domain system utilizes a
compression scheme which eliminates the repetition of domain names in a
message. In this scheme, an entire domain name or a list of labels at
the end of a domain name is replaced with a pointer to a prior occurance
of the same name.

The pointer takes the form of a two octet sequence:

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 1 1| OFFSET |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The first two bits are ones. This allows a pointer to be distinguished
from a label, since the label must begin with two zero bits because
labels are restricted to 63 octets or less. (The 10 and 01 combinations
are reserved for future use.) The OFFSET field specifies an offset from
the start of the message (i.e., the first octet of the ID field in the
domain header). A zero offset specifies the first byte of the ID field,
etc.

The compression scheme allows a domain name in a message to be
represented as either:

- a sequence of labels ending in a zero octet
- a pointer
- a sequence of labels ending with a pointer

Pointers can only be used for occurances of a domain name where the
format is not class specific. If this were not the case, a name server
or resolver would be required to know the format of all RRs it handled.
As yet, there are no such cases, but they may occur in future RDATA
formats.

If a domain name is contained in a part of the message subject to a
length field (such as the RDATA section of an RR), and compression is
used, the length of the compressed name is used in the length
calculation, rather than the length of the expanded name.

Programs are free to avoid using pointers in messages they generate,
although this will reduce datagram capacity, and may cause truncation.
However all programs are required to understand arriving messages that
contain pointers.

For example, a datagram might need to use the domain names F.ISI.ARPA,
FOO.F.ISI.ARPA, ARPA, and the root. Ignoring the other fields of the
message, these domain names might be represented as:

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
20 | 1 | F |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
22 | 3 | I |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
24 | S | I |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
26 | 4 | A |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
28 | R | P |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
30 | A | 0 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
40 | 3 | F |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
42 | O | O |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
44 | 1 1| 20 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
64 | 1 1| 26 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
92 | 0 | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The domain name for F.ISI.ARPA is shown at offset 20. The domain name
FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to
concatenate a label for FOO to the previously defined F.ISI.ARPA. The
domain name ARPA is defined at offset 64 using a pointer to the ARPA
component of the name F.ISI.ARPA at 20; note that this pointer relies on
ARPA being the last label in the string at 20. The root domain name is
defined by a single octet of zeros at 92; the root domain name has no
labels.

-- end quote --

et je ne suis pas dans les petits papiers de l'icann mais depuis le temps
ils les auraient montés ces 3 serveurs de plus ... non ?

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).

Pour finir, il me semble qu'il y a quelques problèmes politiques justement
entre ICANN et... à peu près tout le monde sauf Verisign et
Neu-ce-que-tu-veux. Déjà qu'ils sont brouillés avec les autorités
nationales (qui gèrent chacun des ccTLD), ça m'étonnerait pas qu'ils soit
vaguement brouillés avec les opérateurs de NS aussi. Mais il me semble
qu'il y a eu des changements récemment pour passer certains NS en anycast
(en IPv6), donc il y a du boulot. J'avoue que je ne suis pas tout ça de
très près, mais un tour sur le serveur de l'ICANN et quelques
mailing-lists devrait nous dire la vérité.

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

Salut,

On Tue, 2 Dec 2003 20:51:30 +0100, Jaster <fabjunk.pipo at free.fr> wrote:

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".

Je ne crois pas justement. Il me semble qu'il y a un méchanisme équivalent
à $ORIGIN, ce qui est bienvenu, vu que la probabiilité qu'il y ait
*beaucoup* de noms avec une base commune étant très forte dans n'importe
quelle requête DNS.

[... oqp lire RFC1035 ... ce qu'il y a comme trucs obsolètes là-dedans
dites donc ... ]

Ach voui. Bon, ça marche pas du tout comme je croyais, ce n'est pas du
tout $ORIGIN-like, c'est juste une forme de compression:

-- begin quote --

4.1.4. Message compression

In order to reduce the size of messages, the domain system utilizes a
compression scheme which eliminates the repetition of domain names in a
message. In this scheme, an entire domain name or a list of labels at
the end of a domain name is replaced with a pointer to a prior occurance
of the same name.

The pointer takes the form of a two octet sequence:

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 1 1| OFFSET |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The first two bits are ones. This allows a pointer to be distinguished
from a label, since the label must begin with two zero bits because
labels are restricted to 63 octets or less. (The 10 and 01 combinations
are reserved for future use.) The OFFSET field specifies an offset from
the start of the message (i.e., the first octet of the ID field in the
domain header). A zero offset specifies the first byte of the ID field,
etc.

The compression scheme allows a domain name in a message to be
represented as either:

- a sequence of labels ending in a zero octet
- a pointer
- a sequence of labels ending with a pointer

Pointers can only be used for occurances of a domain name where the
format is not class specific. If this were not the case, a name server
or resolver would be required to know the format of all RRs it handled.
As yet, there are no such cases, but they may occur in future RDATA
formats.

If a domain name is contained in a part of the message subject to a
length field (such as the RDATA section of an RR), and compression is
used, the length of the compressed name is used in the length
calculation, rather than the length of the expanded name.

Programs are free to avoid using pointers in messages they generate,
although this will reduce datagram capacity, and may cause truncation.
However all programs are required to understand arriving messages that
contain pointers.

For example, a datagram might need to use the domain names F.ISI.ARPA,
FOO.F.ISI.ARPA, ARPA, and the root. Ignoring the other fields of the
message, these domain names might be represented as:

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
20 | 1 | F |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
22 | 3 | I |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
24 | S | I |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
26 | 4 | A |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
28 | R | P |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
30 | A | 0 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
40 | 3 | F |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
42 | O | O |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
44 | 1 1| 20 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
64 | 1 1| 26 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
92 | 0 | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The domain name for F.ISI.ARPA is shown at offset 20. The domain name
FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to
concatenate a label for FOO to the previously defined F.ISI.ARPA. The
domain name ARPA is defined at offset 64 using a pointer to the ARPA
component of the name F.ISI.ARPA at 20; note that this pointer relies on
ARPA being the last label in the string at 20. The root domain name is
defined by a single octet of zeros at 92; the root domain name has no
labels.

-- end quote --

et je ne suis pas dans les petits papiers de l'icann mais depuis le temps
ils les auraient montés ces 3 serveurs de plus ... non ?

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).

Pour finir, il me semble qu'il y a quelques problèmes politiques justement
entre ICANN et... à peu près tout le monde sauf Verisign et
Neu-ce-que-tu-veux. Déjà qu'ils sont brouillés avec les autorités
nationales (qui gèrent chacun des ccTLD), ça m'étonnerait pas qu'ils soit
vaguement brouillés avec les opérateurs de NS aussi. Mais il me semble
qu'il y a eu des changements récemment pour passer certains NS en anycast
(en IPv6), donc il y a du boulot. J'avoue que je ne suis pas tout ça de
très près, mais un tour sur le serveur de l'ICANN et quelques
mailing-lists devrait nous dire la vérité.

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

Vous avez filtré cet utilisateur ! Consultez son message

Salut,

On Tue, 2 Dec 2003 20:51:30 +0100, Jaster <fabjunk.pipo at free.fr> wrote:

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".

Je ne crois pas justement. Il me semble qu'il y a un méchanisme équivalent
à $ORIGIN, ce qui est bienvenu, vu que la probabiilité qu'il y ait
*beaucoup* de noms avec une base commune étant très forte dans n'importe
quelle requête DNS.

[... oqp lire RFC1035 ... ce qu'il y a comme trucs obsolètes là-dedans
dites donc ... ]

Ach voui. Bon, ça marche pas du tout comme je croyais, ce n'est pas du
tout $ORIGIN-like, c'est juste une forme de compression:

-- begin quote --

4.1.4. Message compression

In order to reduce the size of messages, the domain system utilizes a
compression scheme which eliminates the repetition of domain names in a
message. In this scheme, an entire domain name or a list of labels at
the end of a domain name is replaced with a pointer to a prior occurance
of the same name.

The pointer takes the form of a two octet sequence:

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 1 1| OFFSET |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The first two bits are ones. This allows a pointer to be distinguished
from a label, since the label must begin with two zero bits because
labels are restricted to 63 octets or less. (The 10 and 01 combinations
are reserved for future use.) The OFFSET field specifies an offset from
the start of the message (i.e., the first octet of the ID field in the
domain header). A zero offset specifies the first byte of the ID field,
etc.

The compression scheme allows a domain name in a message to be
represented as either:

- a sequence of labels ending in a zero octet
- a pointer
- a sequence of labels ending with a pointer

Pointers can only be used for occurances of a domain name where the
format is not class specific. If this were not the case, a name server
or resolver would be required to know the format of all RRs it handled.
As yet, there are no such cases, but they may occur in future RDATA
formats.

If a domain name is contained in a part of the message subject to a
length field (such as the RDATA section of an RR), and compression is
used, the length of the compressed name is used in the length
calculation, rather than the length of the expanded name.

Programs are free to avoid using pointers in messages they generate,
although this will reduce datagram capacity, and may cause truncation.
However all programs are required to understand arriving messages that
contain pointers.

For example, a datagram might need to use the domain names F.ISI.ARPA,
FOO.F.ISI.ARPA, ARPA, and the root. Ignoring the other fields of the
message, these domain names might be represented as:

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
20 | 1 | F |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
22 | 3 | I |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
24 | S | I |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
26 | 4 | A |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
28 | R | P |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
30 | A | 0 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
40 | 3 | F |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
42 | O | O |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
44 | 1 1| 20 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
64 | 1 1| 26 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
92 | 0 | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The domain name for F.ISI.ARPA is shown at offset 20. The domain name
FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to
concatenate a label for FOO to the previously defined F.ISI.ARPA. The
domain name ARPA is defined at offset 64 using a pointer to the ARPA
component of the name F.ISI.ARPA at 20; note that this pointer relies on
ARPA being the last label in the string at 20. The root domain name is
defined by a single octet of zeros at 92; the root domain name has no
labels.

-- end quote --

et je ne suis pas dans les petits papiers de l'icann mais depuis le temps
ils les auraient montés ces 3 serveurs de plus ... non ?

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).

Pour finir, il me semble qu'il y a quelques problèmes politiques justement
entre ICANN et... à peu près tout le monde sauf Verisign et
Neu-ce-que-tu-veux. Déjà qu'ils sont brouillés avec les autorités
nationales (qui gèrent chacun des ccTLD), ça m'étonnerait pas qu'ils soit
vaguement brouillés avec les opérateurs de NS aussi. Mais il me semble
qu'il y a eu des changements récemment pour passer certains NS en anycast
(en IPv6), donc il y a du boulot. J'avoue que je ne suis pas tout ça de
très près, mais un tour sur le serveur de l'ICANN et quelques
mailing-lists devrait nous dire la vérité.

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

Jacques Caron

03/12/2003 à 01:16

On Tue, 2 Dec 2003 22:48:26 +0100, Angelot
wrote:

Bonsoir Jaster et Jacques,
Permettez que je rajoute une observation sur le nombre de ces serveurs.

Le serveur de racine F par exemple est en fait instancié 15 fois dans le
monde (à Ottawa, Palo Alto, San Jose CA, New York, San Francisco, Madrid,
Hong Kong, Los Angeles, Rome, Auckland, Sao Paulo, Beijing, Seoul,
Moscou, Dubai)

Euh, j'y crois pas trop. Ou alors en IPv6 seulement, peut-être. Où
est-ce-que tu as vu ça? Et tu parles bien de f.root-servers.net, ou de
f.gtld-servers.net?

Tous les 15 serveurs ont la même adresse 192.5.5.241 !

Même si c'est théoriquement possible (si toutes les instances sont sur le
même réseau, c'est super facile de faire des routes dynamiques à partage
de charge, sélection du serveur le plus proche et failover automatique,
même pour un /32...), je ne pense pas que ce soit le cas ici.

Toutes ces choses-là m'émerveillent. J'arrête de dire que les adresses IP
sont uniques (je l'avais déjà un peu fait...).

Si si, elles le sont :-) Il s'agirait dans ce cas d'une IP virtuelle, qui
est bien unique. Même si elle aboutit sur plusieurs machines ;->>>

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

Angelot

03/12/2003 à 13:18

Bonjour Jacques,

Euh, j'y crois pas trop. Ou alors en IPv6 seulement, peut-être. Où
est-ce-que tu as vu ça? Et tu parles bien de f.root-servers.net, ou de
f.gtld-servers.net?

Ce serait bien de l'IPV4 anycast et non de l'IPV6.

Je parlais bien de f.root-servers.

Voici le cas du k.root-servers instancié à Londres et à Amsterdam sous la
même adresse 193.0.14.129.

cf. http://k.root-servers.org

"RIPE NCC operates k.root-servers.net, one of the 13 Internet root name
servers. The k.root service is provided by a set of distributed server
instances using IPv4 Anycast. Each server instance announces the
193.0.14.0/24 network in AS25152. A k.root server instance consists of a
cluster of server machines running the NSD name server software".

Tes commentaires ?
Cordialement,
Angelot

Angelot

03/12/2003 à 13:56

Bonjour Michel, Jaster et Jacques,

ah ? je suis curieux de savoir d'ou ca sort

Michel Guillou a-t-il plus d'éléments ? Est-ce consistant comme info, en
IPV4, ou simplement entendue.

Non. j'ai lu ça quelque part mais ne sais plus où. Il faut faire comme si
je

n'avais rien dit.

Surtout pas Michel ! ton information n'est pas dénué de sens.

En furetant sur le site de RIPE j'ai transmis cette nuit un mail à une
adresse proposée pour les commentaires techniques, voici la réponse obtenue
tout à l'heure :

"note that f-root installed in moscow a few weeks ago".

On a donc 15 instanciations multiples de f-root, pour l'adresse unique
192.5.5.241, par accès IPV4 anycast. La dernière en date serait donc celle
de Moscou. Un rapide tracert me montre que, depuis Berduche-lès-Fossés où je
suis (un petit hameau de quelques fermes d'un nom approchant) je devrais
être attaché à celui de Hong Kong, ce qui est, on le conçoit bien, beaucoup
plus court que de joindre celui de Madrid.

Vos remarques ?
Cordialement,
Angelot

Jacques Caron

03/12/2003 à 17:29

On Wed, 3 Dec 2003 13:18:47 +0100, Angelot
wrote:

"RIPE NCC operates k.root-servers.net, one of the 13 Internet root name
servers. The k.root service is provided by a set of distributed server
instances using IPv4 Anycast. Each server instance announces the
193.0.14.0/24 network in AS25152. A k.root server instance consists of a
cluster of server machines running the NSD name server software".

Tes commentaires ?

Que je ne savais pas qu'on avait rebaptisé le concept d'IP virtuelle en
"anycast" :-) Mais sinon, oui, comme je le disais, c'est tout à fait
possible (je faisais déjà ça pour certains de mes serveurs il y a 5 ou 6
ans de ça, même si ce n'était pas à la même échelle), c'est juste une
question de routage, et il faut nécessairement que toutes les instances
soient sur le même réseau (AS25152 ici), ce qui n'est pas forcément
difficile à grands coups de VPN.

Par contre j'ai un gros doute pour f.root-servers.net, moi je tombe sur
Palo Alto, alors s'il y en a d'autres instances en Europe le routage est
plutôt mal fait...

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

Angelot

03/12/2003 à 17:41

Bonsoir Jacques,

Par contre j'ai un gros doute pour f.root-servers.net, moi je tombe sur
Palo Alto, alors s'il y en a d'autres instances en Europe le routage est
plutôt mal fait...

Sacrebleu ! es-tu sûr ? j'aboutis sur Hong Kong

C:WINDOWS>tracert 192.5.5.241

Détermination de l'itinéraire vers f.root-servers.net [192.5.5.241]
avec un maximum de 30 sauts :

6 319 ms 246 ms 59 ms P1-0.PASCR1.Pastourelle.opentransit.net
[193.251
.243.30]
7 250 ms 248 ms 233 ms P0-0.SINBB1.Singapore.opentransit.net
[193.251.2
42.30]
8 299 ms 299 ms 299 ms P2-0.HKGBB1.Hong-kong.opentransit.net
[193.251.2
42.193]
9 286 ms 294 ms 274 ms isc2-FE.hkix.net [202.40.161.200]
10 299 ms 299 ms 289 ms f.root-servers.net [192.5.5.241]

Cordialement,
Angelot

Jacques Caron

03/12/2003 à 18:56

On Wed, 3 Dec 2003 17:41:51 +0100, Angelot
wrote:

Sacrebleu ! es-tu sûr ? j'aboutis sur Hong Kong

C:WINDOWS>tracert 192.5.5.241

Détermination de l'itinéraire vers f.root-servers.net [192.5.5.241]
avec un maximum de 30 sauts :

6 319 ms 246 ms 59 ms P1-0.PASCR1.Pastourelle.opentransit.net
[193.251
.243.30]
7 250 ms 248 ms 233 ms P0-0.SINBB1.Singapore.opentransit.net
[193.251.2
42.30]
8 299 ms 299 ms 299 ms P2-0.HKGBB1.Hong-kong.opentransit.net
[193.251.2
42.193]
9 286 ms 294 ms 274 ms isc2-FE.hkix.net [202.40.161.200]
10 299 ms 299 ms 289 ms f.root-servers.net [192.5.5.241]

traceroute to f.root-servers.net (192.5.5.241), 64 hops max, 44 byte
packets
1 194.150.57.1 (194.150.57.1) 0.692 ms 0.771 ms 0.825 ms
2 ci1.paris-hc.fr.psi.net (154.14.186.1) 2.599 ms 0.952 ms 1.061 ms
3 154.14.65.13 (154.14.65.13) 2.355 ms 1.258 ms 1.236 ms
4 t1-1.LDN2.psie.net (154.14.65.2) 13.449 ms 13.241 ms 14.651 ms
5 ge3-0.pr1.lhr1.uk.above.net (195.66.224.76) 13.512 ms 13.614 ms
14.650 ms
6 pos9-0.mpr1.lhr1.uk.above.net (208.184.231.69) 13.528 ms 13.486 ms
13.665 ms
7 so-4-1-0.cr1.lhr3.uk.above.net (208.184.231.174) 13.786 ms 13.773
ms 13.784 ms
8 so-7-0-0.cr1.dca2.us.above.net (64.125.31.186) 85.492 ms 85.543 ms
85.475 ms
9 so-3-0-0.mpr3.sjc2.us.mfnx.net (208.184.233.133) 151.874 ms 156.150
ms 151.729 ms
10 pos1-0.mpr1.pao1.us.above.net (209.249.0.121) 152.015 ms 153.072 ms
152.252 ms
11 isc-above-oc3.pao.isc.org (216.200.0.10) 155.974 ms 155.476 ms
155.029 ms
12 f.root-servers.net (192.5.5.241) 155.342 ms 155.068 ms 155.550 ms

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).

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

On Wed, 3 Dec 2003 17:41:51 +0100, Angelot <OnSePame@KestceKonSePame.fr>
wrote:

Sacrebleu ! es-tu sûr ? j'aboutis sur Hong Kong

C:WINDOWS>tracert 192.5.5.241

Détermination de l'itinéraire vers f.root-servers.net [192.5.5.241]
avec un maximum de 30 sauts :

6 319 ms 246 ms 59 ms P1-0.PASCR1.Pastourelle.opentransit.net
[193.251
.243.30]
7 250 ms 248 ms 233 ms P0-0.SINBB1.Singapore.opentransit.net
[193.251.2
42.30]
8 299 ms 299 ms 299 ms P2-0.HKGBB1.Hong-kong.opentransit.net
[193.251.2
42.193]
9 286 ms 294 ms 274 ms isc2-FE.hkix.net [202.40.161.200]
10 299 ms 299 ms 289 ms f.root-servers.net [192.5.5.241]

traceroute to f.root-servers.net (192.5.5.241), 64 hops max, 44 byte
packets
1 194.150.57.1 (194.150.57.1) 0.692 ms 0.771 ms 0.825 ms
2 ci1.paris-hc.fr.psi.net (154.14.186.1) 2.599 ms 0.952 ms 1.061 ms
3 154.14.65.13 (154.14.65.13) 2.355 ms 1.258 ms 1.236 ms
4 t1-1.LDN2.psie.net (154.14.65.2) 13.449 ms 13.241 ms 14.651 ms
5 ge3-0.pr1.lhr1.uk.above.net (195.66.224.76) 13.512 ms 13.614 ms
14.650 ms
6 pos9-0.mpr1.lhr1.uk.above.net (208.184.231.69) 13.528 ms 13.486 ms
13.665 ms
7 so-4-1-0.cr1.lhr3.uk.above.net (208.184.231.174) 13.786 ms 13.773
ms 13.784 ms
8 so-7-0-0.cr1.dca2.us.above.net (64.125.31.186) 85.492 ms 85.543 ms
85.475 ms
9 so-3-0-0.mpr3.sjc2.us.mfnx.net (208.184.233.133) 151.874 ms 156.150
ms 151.729 ms
10 pos1-0.mpr1.pao1.us.above.net (209.249.0.121) 152.015 ms 153.072 ms
152.252 ms
11 isc-above-oc3.pao.isc.org (216.200.0.10) 155.974 ms 155.476 ms
155.029 ms
12 f.root-servers.net (192.5.5.241) 155.342 ms 155.068 ms 155.550 ms

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).

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

Vous avez filtré cet utilisateur ! Consultez son message

On Wed, 3 Dec 2003 17:41:51 +0100, Angelot
wrote:

Sacrebleu ! es-tu sûr ? j'aboutis sur Hong Kong

C:WINDOWS>tracert 192.5.5.241

Détermination de l'itinéraire vers f.root-servers.net [192.5.5.241]
avec un maximum de 30 sauts :

6 319 ms 246 ms 59 ms P1-0.PASCR1.Pastourelle.opentransit.net
[193.251
.243.30]
7 250 ms 248 ms 233 ms P0-0.SINBB1.Singapore.opentransit.net
[193.251.2
42.30]
8 299 ms 299 ms 299 ms P2-0.HKGBB1.Hong-kong.opentransit.net
[193.251.2
42.193]
9 286 ms 294 ms 274 ms isc2-FE.hkix.net [202.40.161.200]
10 299 ms 299 ms 289 ms f.root-servers.net [192.5.5.241]

traceroute to f.root-servers.net (192.5.5.241), 64 hops max, 44 byte
packets
1 194.150.57.1 (194.150.57.1) 0.692 ms 0.771 ms 0.825 ms
2 ci1.paris-hc.fr.psi.net (154.14.186.1) 2.599 ms 0.952 ms 1.061 ms
3 154.14.65.13 (154.14.65.13) 2.355 ms 1.258 ms 1.236 ms
4 t1-1.LDN2.psie.net (154.14.65.2) 13.449 ms 13.241 ms 14.651 ms
5 ge3-0.pr1.lhr1.uk.above.net (195.66.224.76) 13.512 ms 13.614 ms
14.650 ms
6 pos9-0.mpr1.lhr1.uk.above.net (208.184.231.69) 13.528 ms 13.486 ms
13.665 ms
7 so-4-1-0.cr1.lhr3.uk.above.net (208.184.231.174) 13.786 ms 13.773
ms 13.784 ms
8 so-7-0-0.cr1.dca2.us.above.net (64.125.31.186) 85.492 ms 85.543 ms
85.475 ms
9 so-3-0-0.mpr3.sjc2.us.mfnx.net (208.184.233.133) 151.874 ms 156.150
ms 151.729 ms
10 pos1-0.mpr1.pao1.us.above.net (209.249.0.121) 152.015 ms 153.072 ms
152.252 ms
11 isc-above-oc3.pao.isc.org (216.200.0.10) 155.974 ms 155.476 ms
155.029 ms
12 f.root-servers.net (192.5.5.241) 155.342 ms 155.068 ms 155.550 ms

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).

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

A propos de DNS

10 réponses

Veuillez sélectionner un problème