DNS pb zone inverse-Pb

Support Debian
#1

Bonjour,
Débutant pour l’installation d’un DNS, je l’ai configuré sur un serveur hébergé sous Lenny avec deux clients sur OS Ubuntu. Aucun souci pour la zone directe qui fonctionne comme je le souhaite.

Problème lorsque que je tape nslookup ou dig 210.200.30.161 pour obtenir la résolution inverse: named-checkconf qui vérifie mon fichier named.conf et named.conf.local et named-checkzone qui vérifie la syntaxe de mon fichier de zone (résolution inverse)m’indiquent que tout est parfait.

En revanche, le message d’erreur, après nslookup ou dig 210.200.30.161, qui est

;; connection timed out; no servers could be reached

me surprend. Je crois comprendre, dans le message d’erreur, qu’il ne localise pas le serveur dont l’adresse est indiquée, pour moi, dans /etc/resolv.conf. Mon fichier reproduit sur les 3 machines est

search table6.salle14.univ.fr
nameserver 210.200.30.161

Je rappelle qu’en recherche directe, cela fonctionne parfaitement.

J’ai peut-être fait une erreur dans mes fichiers (j’y regarde), mais c’est le message qui m’interpelle!

Merci d’avance pour vos idées

#2

si ce sont des serveurs hébergés il est possible que la résolution inverse se fasse plutôt chez l’hébergeur non ?

#3

Merci de votre réponse.

Non, au stade où je suis, j’ai simplement 3 machines en réseau local sans raccordement à l’internet.

#4

ben annonce tes fichiers de conf named.

#5

Mais ça pose un pbm:

[quote]~$ host 210.200.30.161
Name: TC210-200-30-161.static.apol.com.tw
Address: 210.200.30.161
[/quote]et c’est une adresse taiwanaise. Tu ne peux pas prendre une IP comme ça, en tout cas il est heureux qu’il y est un souci dans la résolution DNS inverse. Il faut prendre une IP locale genre 192.168.?.? non routée.

#6

Je comprends qu’il faut rester avec des adresses privées dans le cas général (connexion à l’internet), mais je reste (et je resterais) en local. Tu me suggères qu’il y aurait <<une sécurité>> qui bloquerait des adresses publiques? cela me parait étrange. Je vais essayer…Lundi.

Merci encore

#7

Il y a deux choses

  1. la requête par la machine qui indique peu de choses (host 210.200.30.161)

  2. L’utilisation de dig

Ce serait ici

dig -t ptr 161.30.200.210.in-addr.arpa @ton_serveurDNS

On obtient ici

[quote];; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5127
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;; QUESTION SECTION:
;161.30.200.210.in-addr.arpa. IN PTR

;; ANSWER SECTION:
161.30.200.210.in-addr.arpa. 86400 IN PTR TC210-200-30-161.static.apol.com.tw.

;; AUTHORITY SECTION:
30.200.210.in-addr.arpa. 86400 IN NS dns2.ht.net.tw.
30.200.210.in-addr.arpa. 86400 IN NS dns.ht.net.tw.

;; ADDITIONAL SECTION:
dns.ht.net.tw. 86398 IN A 203.79.224.30

;; Query time: 4025 msec
;; SERVER: 192.168.1.1#53(panda)
;; WHEN: Sat Nov 14 18:46:17 2009
;; MSG SIZE rcvd: 154
[/quote]Le serveur DNS du domaine univ.fr est celui d’ovh qui n’indique rien sur cette adresse (ce qui est heureux):

[quote]$ dig -t ptr 161.30.200.210.in-addr.arpa @ns.ovh.net

; <<>> DiG 9.2.4 <<>> -t ptr 161.30.200.210.in-addr.arpa @ns.ovh.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 14923
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;161.30.200.210.in-addr.arpa. IN PTR

;; Query time: 32 msec
;; SERVER: 213.251.128.136#53(ns.ovh.net)
;; WHEN: Sat Nov 14 18:48:21 2009
;; MSG SIZE rcvd: 45
[/quote]
En local, tu peux interroger ton serveur en spécifiant son IP collée à l’«@»

#8

[quote=“Cchaigne”];; connection timed out; no servers could be reached

me surprend. Je crois comprendre, dans le message d’erreur, qu’il ne localise pas le serveur dont l’adresse est indiquée, pour moi, dans /etc/resolv.conf.[/quote]
A mon avis, l’explication est autre.
Le client a parfaitement “trouvé” ton serveur DNS et lui a envoyé la requête ; c’est juste le serveur qui n’a pas répondu dans les temps. Imaginons que tu n’ais pas configuré correctement la zone inverse correspondant à la requête, dans ce cas BIND ne se considère pas comme faisant autorité pour cette zone et, si la récursion est autorisée (c’est le cas par défaut), va chercher la réponse en interrogeant d’autres serveurs DNS, en commençant par un serveur racine. Mais si le réseau est isolé, alors il n’aura jamais de réponse, et le temps qu’il s’en rende compte (s’il essaye les 13 serveurs racines, ça prend du temps) le client aura peut-être abandonné avec le message ci-dessus. Les requêtes DNS normales utilisent le protocole UDP qui n’est pas connecté, on ne sait donc pas si le serveur interrogé a reçu ou non une requête.

Donc : vérifie que la zone inverse est correctement définie, et pas seulement syntaxiquement correcte.

Je trouve que tu te compliques bien la vie pour faire une requête DNS inverse.

PS : Je soutiens complètement fran.b quant à l’utilisation d’adresses privées plutôt que l’utilisation sauvage d’adresses publiques officiellement attribués à quelqu’un d’autre même dans le cadre d’un réseau local isolé.

#9

Je ne me souvenais plus de cette syntaxe, et je viens de m’apercevoir que dans le «dig -h», ces abrutis ont mis le «-x» en premier alors que d’habitude c’est par ordre alphabétique. Et surtout je pensais que «dig -t ptr 210.200.30.161» aurait marché, donc après j’ai mis l’extension exacte et ça a fonctionné mais ça me paraissait effectivement assez peu convivial.

Mon idée était qu’il interroge directement le serveur pour voir si c’est le paramétrage du client qui coince ou le serveur qui ne répond pas.

#10

C’est vrai que dig, contrairement à host ou nslookup, a besoin qu’on lui spécifie avec -x qu’il faut traiter l’opérande comme une adresse et faire une résolution inverse. “dig -t ptr” avec l’adresse IP directement ça ne va pas le faire car il ne convertit pas l’adresse en sa représentation DNS en .arpa.

Je ne pense pas que le client soit mal configuré si la résolution directe fonctionne.