Adresse IP vers nom

Olivier Miakinen <om+news@miakinen.net> writes:

[diapublication, avec suivi vers fr.comp.reseaux.ip seul]

Bonjour,

Bonjour,

Pour remplacer un gethostbyaddr en C, je voudrais savoir si les deux
méthodes suivantes sont équivalentes, et sinon quelle diffà ©rence
il y a entre les deux :

1) faire un getaddrinfo suivi d'un getnameinfo du premier résultat ;

2) faire un getaddrinfo avec AI_CANONNAME et récupérer le ai_ca nonname.

Cordialement,

getnameinfo() permet (entre autres) de récupérer un enregistremen t PTR
relatif à une adresse. L'équivalent de gethostbyaddr(), en d'autr es
mots.

AI_CANONNAME permet d'avoir, en plus de l'adresse, le nom exact sous
lequel le résolveur a trouvé l'adresse, c'est à dire aprà ¨s éventuel
ajout d'un suffixe DNS et processing d'alias.

Je pense qu'on peut formuler ça de manière plus claire et plus pr écise,
mais ça s'illustre bien comme ça :

~$ # ajout d'un suffixe DNS
~$ ./gani www
getaddrinfo + AI_CANONNAME: www.wxcvbn.org
getnameinfo: coloc.wxcvbn.org
~$ # processing d'un alias (CNAME)
~$ ./gani www.kame.net
getaddrinfo + AI_CANONNAME: orange.kame.net
getnameinfo: orange.kame.net
~$

C'est traité dans la RFC 2553.

HTH
--
Jérémie Courrèges-Anglas
Empreinte GPG : 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494

jca+news@wxcvbn.morg (Jérémie Courrèges-Anglas) writes:

[...]

C'est traité dans la RFC 2553.

3493, plutôt.

De plus, on me dit dans l'oreillette que ce module[1] Perl vient avec
deux scripts, getaddrinfo et getnameinfo.

Bonne journée,
--
Jérémie Courrèges-Anglas
Empreinte GPG : 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494

Bonjour, et merci de ta réponse.

Le 24/01/2013 07:11, Jérémie Courrèges-Anglas a écrit :

getnameinfo() permet (entre autres) de récupérer un enregistrement PTR
relatif à une adresse. L'équivalent de gethostbyaddr(), en d'autres
mots.

Oui.

AI_CANONNAME permet d'avoir, en plus de l'adresse, le nom exact sous
lequel le résolveur a trouvé l'adresse, c'est à dire après éventuel
ajout d'un suffixe DNS et processing d'alias.

Je pense qu'on peut formuler ça de manière plus claire et plus précise,
mais ça s'illustre bien comme ça :

~$ # ajout d'un suffixe DNS
~$ ./gani www
getaddrinfo + AI_CANONNAME: www.wxcvbn.org
getnameinfo: coloc.wxcvbn.org
~$ # processing d'un alias (CNAME)
~$ ./gani www.kame.net
getaddrinfo + AI_CANONNAME: orange.kame.net
getnameinfo: orange.kame.net
~$

C'est là que je m'aperçois que j'avais oublié un détail important dans
ma question : je ne m'intéresse qu'au cas où la requête porte sur une
adresse IP (v4 ou v6) et pas sur un nom DNS. Est-ce que dans ce cas
le getnameinfo pourrait retourner un nom sans suffixe DNS, ou un alias,
au lieu de l'adresse canonique ?

C'est traité dans la RFC 2553 [remplacée par la RFC 3493]

J'avoue que je n'ai pas pensé à lire les RFC ; je me suis contenté
des pages man trouvées un peu partout, et de la page suivante :
<http://livre.g6.asso.fr/index.php/Programmation_d%27applications_bis>.

Merci pour le pointeur vers la RFC 3493, je vais regarder ça dès que
je serai arrivé au boulot.

Cordialement,
--
Olivier Miakinen

* jca+news@wxcvbn.morg (Jérémie Courrèges-Anglas) in fr.comp.reseaux.ip:

De plus, on me dit dans l'oreillette que ce module[1] Perl vient avec
deux scripts, getaddrinfo et getnameinfo.

http://search.cpan.org/~pevans/Socket-GetAddrInfo-0.22/lib/Socket/GetAddrInfo.pm

:)

--
DW

Le 24/01/2013 09:12, je répondais à Jérémie :

Merci pour le pointeur vers la RFC 3493, je vais regarder ça dès que
je serai arrivé au boulot.

Je l'ai lue.

Non seulement je n'y ai pas trouvé la réponse à ma question, mais
cela m'a fait me poser deux autres questions. Bon, il y en a une
pour laquelle je pense avoir trouvé la réponse.

====================================================================== 1)

<http://tools.ietf.org/html/rfc3493#page-25>
The ai_flags field to which hints parameter points shall be set to
zero or be the bitwise-inclusive OR of one or more of the values
AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV,
AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG.
</>

Je viens de regarder les fichiers netdb.h de plusieurs Linux et
plusieurs SunOS (je n'arrive pas à me connecter sur les AIX en ce
moment), et tous ont AI_NUMERICHOST mais pas AI_NUMERICSERV.

Je ne comprenais pas pourquoi jusqu'à ce que je voie que ce n'était
pas prévu dans la RFC 2553, et que les OS des machines en question
sont assez vieux.
====================================================================== 2)

<http://tools.ietf.org/html/rfc3493#page-24>
If hints is a null pointer, the behavior
shall be as if it referred to a structure containing the value zero
for the ai_flags, ai_socktype and ai_protocol fields, and AF_UNSPEC
for the ai_family field.
</>

<http://tools.ietf.org/html/rfc2553#page-28>
If the third argument to
getaddrinfo() is a NULL pointer, this is the same as if the caller
had filled in an addrinfo structure initialized to zero with
ai_family set to PF_UNSPEC.
</>

Ceci est en contradiction avec la page de man suivante :

<http://manpagesfr.free.fr/man/man3/getaddrinfo.3.html>
Spécifier hints à NULL est équivalent à définir ai_socktype et
ai_protocol à 0, ai_family à AF_UNSPEC et ai_flags à (AI_V4MAPPED |
AI_ADDRCONFIG).
</>

C'est aussi un problème de version ?
======================================================================
Cordialement,
--
Olivier Miakinen

Olivier Miakinen <om+news@miakinen.net> writes:

[...]

AI_CANONNAME permet d'avoir, en plus de l'adresse, le nom exact sous
lequel le résolveur a trouvé l'adresse, c'est à dire apr ès éventuel
ajout d'un suffixe DNS et processing d'alias.

Je pense qu'on peut formuler ça de manière plus claire et plus précise,
mais ça s'illustre bien comme ça :

~$ # ajout d'un suffixe DNS
~$ ./gani www
getaddrinfo + AI_CANONNAME: www.wxcvbn.org
getnameinfo: coloc.wxcvbn.org
~$ # processing d'un alias (CNAME)
~$ ./gani www.kame.net
getaddrinfo + AI_CANONNAME: orange.kame.net
getnameinfo: orange.kame.net
~$

C'est là que je m'aperçois que j'avais oublié un déta il important dans
ma question : je ne m'intéresse qu'au cas où la requête po rte sur une
adresse IP (v4 ou v6) et pas sur un nom DNS. Est-ce que dans ce cas
le getnameinfo pourrait retourner un nom sans suffixe DNS, ou un alias,
au lieu de l'adresse canonique ?

[...]

Il peut retourner à peu près tout ce qui est une valeur acceptabl e pour
un enregistrement PTR, une entrée de table hosts, etc. Exemple (g4 est
une machine sur mon lan).

~$ # avant modifs
~$ ./gani g4
getaddrinfo + AI_CANONNAME: g4.wxcvbn.org
getnameinfo: g4.wxcvbn.org
~$ # bidouillage du /etc/hosts
~$ ./gani g4
getaddrinfo + AI_CANONNAME: foo
getnameinfo: foo
~$ # bidouillage du PTR
~$ ./gani g4
getaddrinfo + AI_CANONNAME: g4.wxcvbn.org
getnameinfo: bar
~$

La plupart du temps, quand une application vérifie le nom d'un client,
elle récupère le reverse avec getnameinfo() puis fait une requà ªte sur ce
reverse avec getaddrinfo(), et regarde si l'adresse obtenue est la mêm e.

C'est simplifié, car un système peut avoir plusieurs adresses et une
adresse peut avoir plusieurs enregistrements PTR.

--
Jérémie Courrèges-Anglas
Empreinte GPG : 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494

Olivier Miakinen <om+news@miakinen.net> writes:

Le 24/01/2013 09:12, je répondais à Jérémie :

Merci pour le pointeur vers la RFC 3493, je vais regarder ça dà ¨s que
je serai arrivé au boulot.

Je l'ai lue.

Non seulement je n'y ai pas trouvé la réponse à ma questio n, mais
cela m'a fait me poser deux autres questions. Bon, il y en a une
pour laquelle je pense avoir trouvé la réponse.

Effectivement, AI_CANONNAME est expliqué de manière assez brà ¨ve.

======================== ========================= ======================
1)

<http://tools.ietf.org/html/rfc3493#page-25>
The ai_flags field to which hints parameter points shall be set to
zero or be the bitwise-inclusive OR of one or more of the values
AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV,
AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG.
</>

Je viens de regarder les fichiers netdb.h de plusieurs Linux et
plusieurs SunOS (je n'arrive pas à me connecter sur les AIX en ce
moment), et tous ont AI_NUMERICHOST mais pas AI_NUMERICSERV.

Je ne comprenais pas pourquoi jusqu'à ce que je voie que ce n'é tait
pas prévu dans la RFC 2553, et que les OS des machines en question
sont assez vieux.

Intéressant.

======================== ========================= ======================
2)

<http://tools.ietf.org/html/rfc3493#page-24>
If hints is a null pointer, the behavior
shall be as if it referred to a structure containing the value zero
for the ai_flags, ai_socktype and ai_protocol fields, and AF_UNSPEC
for the ai_family field.
</>

<http://tools.ietf.org/html/rfc2553#page-28>
If the third argument to
getaddrinfo() is a NULL pointer, this is the same as if the caller
had filled in an addrinfo structure initialized to zero with
ai_family set to PF_UNSPEC.
</>

Ceci est en contradiction avec la page de man suivante :

<http://manpagesfr.free.fr/man/man3/getaddrinfo.3.html>
Spécifier hints à NULL est équivalent à définir ai_socktype et
ai_protocol à 0, ai_family à AF_UNSPEC et ai_flags à (AI_V 4MAPPED |
AI_ADDRCONFIG).
</>

C'est aussi un problème de version ?
======================== ========================= ======================

Cordialement,

Je dirais plutôt un choix d'implémentation de la part des dé veloppeurs
de la glibc. AI_ADDRCONFIG (par défaut) a sans doute du sens, par cont re
les adresses v6 mappées font un peu moins consensus[1] et cette valeur
par défaut (AI_V4MAPPED) n'a pas de sens[2].

Perso j'aime utiliser mes propres hints même pour des petites applis,
entre autres pour supporter des options telles que -4 ou -6 (choix de la
famille d'adresse).

[1] http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful
[2] http://sourceware.org/bugzilla/show_bug.cgi?id=14415
--
Jérémie Courrèges-Anglas
Empreinte GPG : 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494

Le 27/01/2013 03:04, Jérémie Courrèges-Anglas m'a répondu :

C'est là que je m'aperçois que j'avais oublié un détail important dans
ma question : je ne m'intéresse qu'au cas où la requête porte sur une
adresse IP (v4 ou v6) et pas sur un nom DNS. Est-ce que dans ce cas
le getnameinfo pourrait retourner un nom sans suffixe DNS, ou un alias,
au lieu de l'adresse canonique ?

Bon, ma question n'a plus lieu d'être puisque, au moins sur Linux,
je constate que getaddrinfo(adresse IP, AI_CANONNAME) me retourne
l'adresse IP et pas un nom canonique. Je n'ai donc pas le choix,
je fais un getaddrinfo suivi de getnameinfo. Et tant que j'y suis
j'ai rajouté un AI_NUMERICHOST au getaddrinfo puisque l'adresse
est numérique, ça ne mange pas de pain.

[...]

Il peut retourner à peu près tout ce qui est une valeur acceptable pour
un enregistrement PTR, une entrée de table hosts, etc. Exemple (g4 est
une machine sur mon lan).

~$ # avant modifs
~$ ./gani g4
getaddrinfo + AI_CANONNAME: g4.wxcvbn.org
getnameinfo: g4.wxcvbn.org
~$ # bidouillage du /etc/hosts
~$ ./gani g4
getaddrinfo + AI_CANONNAME: foo
getnameinfo: foo

En l'occurrence, ces deux tests retournaient la même valeur.

~$ # bidouillage du PTR
~$ ./gani g4
getaddrinfo + AI_CANONNAME: g4.wxcvbn.org
getnameinfo: bar

Mais là, effectivement, c'est différent.

La plupart du temps, quand une application vérifie le nom d'un client,
elle récupère le reverse avec getnameinfo() puis fait une requête sur ce
reverse avec getaddrinfo(), et regarde si l'adresse obtenue est la même.

Oui, ok. Je ne suis pas sûr d'avoir ce besoin, mais cela pourrait
arriver (j'ai un certain nombre de programmes à migrer ou faire
migrer vers la nouvelle interface).

C'est simplifié, car un système peut avoir plusieurs adresses et une
adresse peut avoir plusieurs enregistrements PTR.

À ce propos, existe-t-il avec la nouvelle interface un moyen de
récupérer la liste de tous les alias, comme avec le h_aliases
de l'ancienne structure hostent ? Il me semble que c'est devenu
impossible, n'est-ce pas ?

Cordialement,
--
Olivier Miakinen

Le 27/01/2013 04:24, Jérémie Courrèges-Anglas m'a répondu :

[ai_flags par défaut vaut 0 selon les RFC, mais
(AI_V4MAPPED | AI_ADDRCONFIG) selon un man(3)]

C'est aussi un problème de version ?

Je dirais plutôt un choix d'implémentation de la part des développeurs
de la glibc. AI_ADDRCONFIG (par défaut) a sans doute du sens, par contre
les adresses v6 mappées font un peu moins consensus[1] et cette valeur
par défaut (AI_V4MAPPED) n'a pas de sens[2].

Perso j'aime utiliser mes propres hints même pour des petites applis,
entre autres pour supporter des options telles que -4 ou -6 (choix de la
famille d'adresse).

Pour le moment j'ai défini mes propres hints dans tout ce que j'ai
fait, et je vais le recommander aux autres aussi.

[1] http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful
[2] http://sourceware.org/bugzilla/show_bug.cgi?id415

Deux liens très intéressants, un grand merci pour cela.

Cordialement,
--
Olivier Miakinen

Le 28/01/2013 17:07, je répondais à Jérémie Courrèges-Anglas :

[...] par contre
les adresses v6 mappées font un peu moins consensus[1] et cette valeur
par défaut (AI_V4MAPPED) n'a pas de sens[2].

[1] http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful
[2] http://sourceware.org/bugzilla/show_bug.cgi?id415

Deux liens très intéressants, un grand merci pour cela.

Je n'avais fait que survoler le premier lien avant de répondre.
Je viens maintenant de le lire plus attentivement, et en réalité
le plus grand problème serait qu'une adresse IPv4-Mapped transite
telle quelle sur le réseau. Certes, ce draft explique que si on
éradique complètement ces adresses, y compris dans l'API de base,
cela diminue le risque qu'elles se baladent sur le réseau. Mais
si on peut les interdire sur le réseau, cela suffit.

Cordialement,
--
Olivier Miakinen