Problème bind9 délégation de zone

Support Debian
#1

Bonjour, voila j’ai un petit soucis avec ma délégation de zone, en effet j’ai 2 serveurs et un client Test. Tous les 3 sont des machines virtuelles sous Virtualbox. J’ai donc un serveur qui gère mon domaine principal et un second serveur qui lui gère une sous-zone.

Le problème c’est que comment expliqué, j’ai l’impression que le serveur qui gère le domaine principal ne délègue pas la zone géré par le serveur secondaire qui gère mon sous-domaine.

Si vous pourriez m’aider car la j’ai beau cherché et je ne trouve pas la solution sachant que dans les logs tout est indiqué comme correct et qu’après avoir “checké” tous les fichiers de zone ceux-ci sont aussi indiqués comme corrects.

Merci par avance pour votre aide

Fichier RR du serveur principal qui gère le domaine principal

[code]$TTL 3600
@ IN SOA serveurludovic.serveur-ludovic.no-ip.org. root.serveur-ludovic.no-ip.org. (
2010101601
36000
600
86400
600 )
@ IN NS serveurludovic.serveur-ludovic.no-ip.org.
testsszone IN NS serveur-3.testsszone.serveur-ludovic.no-ip.org.

serveur-3.testsszone IN A 192.168.1.15
serveurludovic IN A 192.168.1.101 [/code]

Fichier RR serveur secondaire qui gère le sous domaine

[code]$TTL 3600
@ IN SOA serveur-3.testsszone.serveur-ludovic.no-ip.org. root.testsszone.serveur-ludovic.no-ip.org. (
2010101601
36000
600
86400
600 )
@ IN NS serveur-3.testsszone.serveur-ludovic.no-ip.org.

serveur-3 IN A 192.168.1.15
client IN A 192.168.1.103 [/code]

#2

Première réaction : je n’ai strictement rien compris.
Et pourtant j’aime à penser que je connais quand même un peu DNS et BIND9…

PS : c’est trop dur de faire une copie des fichiers en mode texte plutôt qu’une capture d’écran graphique ?

EDIT : Deuxième réaction.

Les fichiers de zone ont l’air cohérents.

Questions :

  1. Qu’est-ce qu’un “client virtuel” ?
  2. Que signifie “mettre le client dans la zone principal” ?
  3. Que signifie “il répond bien aux requêtes” ? Un client qui répond à des requêtes ? Ce n’est pas plutôt le rôle d’un serveur de répondre à des requêtes ?
  4. Que signifie cette histoire de redirection et de resolv.conf ?
#3

Bonjour, j’ai réédité mon message pour plus de compréhension car j’avoue être débutant dans le sous-domaine et je me suis peut-être mal exprimé je m’en excuse.

En fait j’ai virtualisé comme expliqué toute mes machines sous debian 5.0 avec virtual box

Concernant le client si je le “déclare” dans la zone principal il répond à la commande nslookup et est donc bien présent dans le domaine principal
Maintenant si je le “déclare” dans la sous-zone il ne répond plus au nslookup et me retourne un NXDOMAIN

Concernant le resolv.conf du client je le définit comme suit :

domain testsszone.serveur-ludovic.no-ip.org search testsszone.serveur-ludovic.no-ip.org nameserver 192.168.1.101

Resolv.conf du serveur qui gère la sous zone

domain testsszone.serveur-ludovic.no-ip.org search testsszone.serveur-ludovic.no-ip.org nameserver 192.168.1.101

Resolv.conf du serveur principal

domain serveur-ludovic.no-ip.org search serveur-ludovic.no-ip.org nameserver 192.168.1.101

En espérant avoir été plus clair
Cordialement

#4

Non, ce n’est pas beaucoup plus clair.
Je reformule mes questions 2) 3) et 4).
2) Que signifie “déclarer le client dans la zone principale” (ou la sous-zone) ?
3) Que signifie “le client répond à la commande nslookup” ? Quelle commande exactement ? Un client envoie une requête avec nslookup, et c’est le serveur interrogé qui répond.
4) Qu’est-ce que c’est que cette histoire de redirection ?

Si le client interroge un serveur sur un nom de domaine appartenant à une zone pour laquelle il ne fait pas autorité, ce dernier doit avoir la récursion activée et savoir comment contacter le serveur faisant autorité. Est-ce bien le cas ? (autrement dit : que contient named.conf et ses éventuels fichiers inclus ?)

#5

1 ) dans le fichier RR du serveur primaire qui gère le domaine principal je l’intègre dans le domaine
2 ) nslookup "client"
3 ) le resolv.conf du serveur secondaire qui gère le sous-domaine est “dirigé” vers le serveur principal 192.168.1.101 ainsi que le client alors que le client se situe dans le sous-domaine, ainsi c’est le serveur principal qui redirige “la requête nslookup” vers le serveur secondaire qui gère le sous domaine dans le lequel le client est inclus.

Concernant ta question c’est exactement ça or le client n’arrive pas à contacter le serveur secondaire en passant par le serveur primaire.

named.conf.local serveur primaire

zone "serveur-ludovic.no-ip.org" { type master; file "/var/cache/bind/db.domaineludovic"; };

named.conf.local serveur secondaire

zone "testsszone.serveur-ludovic.no-ip.org { type master; file "/var/cache/bind/db.souszone"; };

Cela a-t-il pu vous éclaircir ?
Cordialement

#6

“client” est un nom de domaine non qualifié, et les tests de DNS doivent se faire exclusivement avec des noms de domaines pleinement qualifiés (FQDN). Sinon on ne teste pas seulement les serveurs DNS mais aussi la façon dont le resolveur local traite les noms de domaine non qualifiés, en fonction des options “search” et “domain” du resolv.conf local… bref c’est risque de bazar. Refais tes requêtes nslookup (perso je préfère dig ou host mais bon) avec le nom complet et indique le résultat.

Quand je demandais la configuration de bind9, c’est plutôt la partie options qui m’intéressait.

#7

D’accord merci pour les précisions c’est toujours bon à prendre.
J’ai donc refait un test en saisissant le domaine totalement qualifié et le résultat est toujours le même NXDOMAIN
En ayant test un dig comme vous me l’avez suggéré cela donne

[code];<< >> DIG 9.6-ESV-R1 <<>> client.testsszone.serveur-ludovic.no-ip.org
;; global options : +cmd
;; Got answer;
;; ->>HEADER<<- opcode : query, status: NXDOMAIN, id: 9330
;; flags: qr rd ra; query: 1, ANSWER: 0, AUTHORITY: 1; ADDITIONAL:0

;;QUESTION SECTION:
;client.testsszone.serveur-ludovic.no-ip.org. IN A

;; server: 192.168.1.101#53[/code]

De ce que j’ai compris le client émet bien une demande mais le serveur n’arrive pas à lui répondre après pour le reste je ne suis pas assez bon pour l’interpréter.

Dans mon named.conf.options j’ai juste rajouter les fowarders qui correspondent aux DNS de mon F.A.I si j’ai bien compris le tutoriel.
Pour avoir fait le test en cours on avait pas eu besoin de plus le modifier. Peut-être que dans une configuration domestique je dois modifier d’autres choses ?

#8

Quelle est l’adresse du serveur interrogé par dig ? Est-ce bien 192.168.1.101 ? dig l’affiche dans ce que tu as coupé de sa réponse.
D’après cette réponse, il ne connaît aucune de tes deux zones.

#9

Oups oui pardon j’avais coupé la fin, donc oui il interroge bien le 192.168.1.101, mais le serveur ne retourne pas de réponse

#10

Le serveur répond. Mais il répond qu’il ne connaît pas ce nom de domaine (NXDOMAIN). Ce n’est pas vraiment une erreur comme le serait un SERVFAIL, juste une réponse négative.

Je soupçonne que ce sont les forwarders qui perturbent la résolution. BIND les interroge en premier (par défaut si l’option “forward first;” est présente) ou seulement (si l’option “forward only” est présente). Ces serveurs répondent qu’ils ne connaisent pas le nom de domaine - et pour cause, tu n’as pas de délégation depuis no-ip.org) - et ton serveur s’en contente. Il ne fait pas la récursion lui-même et n’interroge pas l’autre serveur.

Pour le forcer à faire la récursion, une solution serait de lui définir la zone fille de type “forward” mais sans forwarders, ou alors avec comme forwarder l’adresse de l’autre serveur.

[code]zone “testsszone.serveur-ludovic.no-ip.org”
{
type forward;

forwarders { 192.168.1.15; }; // decommenter si necessaire

};[/code]

PS : il manque un guillemet " dans la définition de la zone sur le serveur secondaire, c’est une erreur de copier/coller ?

#11

Super tout fonctionne et en plus vous m’avez expliqué pourquoi, du coup je comprend un peu mieux le fonctionnement et le principe du DNS.
J’aurais une dernière question concernant le resolv.conf qui a tendance à se réinitialiser à chaque redémarrage de la machine et je ne comprend pas trop pourquoi

domaine home search home nameserver 192.168.1.1 ( adresse IP Lan )

Merci beaucoup pour votre patience et votre aide.

#12

Dsl de ré-ouvrir ce sujet que je pensais résolu mais qui ne l’est pas vraiment en fait.
J’explique à nouveau, j’ai rajouté le type forwarder comme vous me l’aviez demandé, le soucis c’est que now le serveur répond aux clients de façon positive même si le serveur qui gère le sous-domaine est éteint, j’imagine que ce n’est pas normal non ?

#13

Cela peut être dû au cache du serveur qui conserve les réponses des requêtes récursives déjà reçues et qu’il a fait suivre à d’autres serveurs et lui permettant de répondre immédiatement en cas de nouvelle requête pour un enregistrement en cache. Le TTL (durée de vie) des enregistrements en cache est affiché par dig et diminue au cours du temps à partir du TTL initial (1h par défaut d’après tes fichiers de zones). Lorsqu’il expire et atteint 0, l’enregistrement est effacé du cache, et c’est seulement à ce moment là qu’il fera suivre une requête ultérieure à d’autres serveurs.

#14

ça parait tellement logique et même pas je m’en suis rendu compte …
Encore merci pour votre aide et désolé pour les questions un peu bête sur la fin.