Commande / scripts pour vérifier le time de search DNS inverse

Cela dépend en partie du résolveur de bout utilisé. Vous pouvez également rencontrer des problèmes avec IPv6, par exemple si des loggings IPv6 AAAA sont renvoyés mais qu'il n'y a pas de connectivité IPv6.

En supposant que le logiciel (erm, rsh ? Vraiment? Cette réponse n'est pas spécifique à rsh ) utilise le résolveur du système (comme ping ), et non sa propre implémentation (comme dig ou host ), vous pouvez utiliser getent pour voir ce qui pourrait être événement:

 $ time getent ahostsv4 www.google.com $ time getent ahostsv6 www.google.com 

Ce qui précède va effectuer une search avant et arrière (bien que vous ne puissiez pas forcer getent à searchr un PTR inversé ou d'autres types, cela ne concerne que les loggings A / AAAA).

Il y a quelques scripts pratiques dans cette réponse à https://serverfault.com/questions/7056/whats-the-reverse-dns-command-line-utility , ceux-ci vous permettent d'effectuer des searchs inversées (IPv4 uniquement) comme getent hosts , mais en perl pour que vous puissiez bricoler avec eux.

Les deux possibilités ci-dessus utilisent votre résolveur de système, y compris tous les swings et ronds-points impliqués dans nsswitch, ils doivent donc se comporter comme le font la plupart des applications.

N'oubliez pas de tester sur le client et le server, l'un ou l'autre ou les deux feront des searchs inversées.

Vous pouvez également vérifier vos résolveurs locaux un par un:

 $ while read opt p1 ; do [ "$opt" = "nameserver" ] && dig @$p1 www.google.com +short +identify; done < /etc/resolv.conf 

et pour vérifier DNS inverse:

 $ dig www.google.com +short | xargs -n1 -i dig -x {} PTR +short +identify 

Pour déboguer ceci, vous devrez vérifier:

• /etc/host.conf (diverses options, y compris la vérification par usurpation via DNS inverse)
• /etc/resolv.conf (vos résolveurs)
• /etc/nsswitch.conf (quelles bases de données vérifier, par exemple /etc/hosts , DNS, LDAP, etc.)
• la sortie de dnstrace et / ou dig +trace
• /etc/gai.conf , s'il est présent. Entre autres choses, cela peut contrôler si les loggings IPV6 AAAA sont sortingés avant A records.
• /etc/nscd.conf si /etc/nscd.conf est en cours d'utilisation

Si vous avez l'access root et le wirehark, vous pouvez regarder les requêtes DNS sur le fil:

 # tshark -w dns.cap "port 53" # tshark -V -ta -n -r dns.cap 

(L'option -V est trop verbeuse, mais les développeurs n'ont pas pensé à mettre des horodatages dans la sortie de dissection du protocole avec -O dns . Peut-être que cela est corrigé dans une version plus récente.)

Même si vous n'utilisez pas nscd ce moment, vous pouvez facilement voir ce qui se passe si vous le lancez interactivement avec l'option -dd ou -ddd . Notez que nscd ne met en cache que les loggings de l'hôte (A / AAAA), de sorte que les loggings PTR finiront par être mis en cache de manière négative avec une courte durée de vie (par défaut 20s).

Le résolveur de la glibc (et d'autres) supporte " options debug " dans /etc/resolv.conf ainsi que la variable d'environnement RES_OPTIONS qui peut être utilisée pour activer le debugging. Malheureusement, cette fonctionnalité utile exige que DEBUG soit activé lors de la construction de la glibc, il est donc peu probable que vous puissiez l'utiliser …

Pour le soulever, le meilleur candidat est ltrace , ce qui vous permet de tracer et d'horodater les appels de bibliothèque, tout comme la façon dont strace peut tracer les appels système, par exemple gethostbyname() ou gethostbyaddr() . L'inconvénient: avec les nombreuses couches d'indirection offertes par nsswitch , vous serez probablement perdu dans la production volumineuse. Une simple exécution sur telnet m'a donné plus de 3000 lignes de sortie, dans lesquelles sont enterrés deux appels à gethostbyname() .

 $ ltrace -ttT -e "getaddr*+gethost*+getname*" getent ahosts www.google.com 13:42:06.118718 getent->getaddrinfo("www.google.com", nil, { 0x2a, 0, 0, 0, 0, nil, nil, nil }, { 0x2a, 0x2, 0x3, 0, 16, { 2, 0, { 0x69187d4a } }, "www.google.com", { 0x2a, 0x2, 0x2, 0x11, 16, { 2, 0, { 0x93187d4a } }, nil, { 0x2a, 0x2, 0x3, 0, 16, { 2, 0, { 0x67187d4a } }, nil, { 0x2a, 0x2, 0x2, 0x11, 16, { 2, 0, { 0x68187d4a } }, nil, ... } } } }) = 0 <0.042561> 

Il est un peu plus difficile de comprendre ce qui se passe car il ne produit pas d'adresses IP lisibles par l'homme ( 0x69187d4a = 105,24,125,74 -> 74.125.24.105). C'est probablement la meilleure méthode pour traquer les problèmes locaux, car vous pouvez voir tous les appels via NSS.

J'ai utilisé ces modifications dans mon ~/.ltrace.conf pour ce qui précède, cela peut nécessiter un peu plus de piratage:

 typedef size_t = int; typedef sockaddr = struct(short, short, in_addr); typedef addrinfo = struct; typedef addrinfo = struct(hex(int), hex(int), hex(int), hex(int), size_t, sockaddr*, ssortingng, addrinfo *); int getaddrinfo(ssortingng, ssortingng, addrinfo *, +addrinfo**); int getnameinfo(sockaddr*, uint, +ssortingng, +uint, +ssortingng, +uint, uint); 

Si vous avez des doutes dans la réponse Lente dans la requête inverse, vous pouvez essayer l'une des methods ci-dessous pour rectifier la même chose:

1. Si possible, désactivez la search inversée dans votre application et voyez la différence

2. Vous pouvez utiliser le nscd (Name Service Cache Daemon) qui met également en cache le file PTR, mais il existe un problème de security:

   Le démon de cache de service de nom (nscd) a un comportement par défaut qui
   n'autorise pas les applications à valider les loggings DNS "PTR"
   Enregistrements "A".

   En particulier, nscd met en cache une requête pour un logging "PTR", et quand une requête arrive plus tard pour l'logging "A", nscd divulgue simplement le
   informations de l'logging "PTR" mis en cache, au lieu d'interroger le
   DNS faisant autorité pour l'logging "A".

Lien de reference