Délégation de domaines avec bind

Support Debian
#1

Bonjour,

Voici mon fichier de zone pour le domaine almtesh.net :

$ORIGIN almtesh.net.
@ 3600 IN  SOA ns0.online.net. hostmaster.online.net. 20201111110640 10800 3600 604800 3600
@ 120 IN TXT "v=spf1 mx a:home.almtesh.net -all"
@ 120 IN AAAA 2001:bc8:3335::11
@ 120 IN A 51.159.34.87
@ 120 IN MX 10 mail.almtesh.net.
nut 120 IN AAAA 2001:bc8:6005:1c:208:a2ff:fe0c:686c
nut 120 IN A 51.159.34.87
home 120 IN AAAA 2a01:e0a:12c:3940::
home 120 IN A 82.65.155.50
home 120 IN NS nut.almtesh.net.
nut 120 IN NS nut.almtesh.net.

Je souhaite que nut.almtesh.net résolve les sous-domaines *.nut.almtesh.net et *.home.almtesh.net. Pour moi, les deux dernières lignes font l’affaire, mais, non seulement ça ne fonctionne pas, mais en plus, nut.almtesh.net ne se résout plus.
Ce que je trouve avec une recherche et les minces connaissances que j’ai sur le sujet me confortent dans l’idée que c’est la bonne façon de faire, du coup, je ne comprends pas.

#2

Ce que tu as fais, est légèrement différent : tu as délégué les domaines nut.almtesh.net et home.almtesh.net. D’autre part, déléguer un domaine à un NS qui a le même nom de domaine, je trouve ça un peu acrobatique. Quand le nom de domaine d’un NS appartient à la zone fille, la zone parente doit contenir les « glue records » A et AAAA de ce nom de domaine, mais je n’ai jamais vu le cas où le nom de la zone et le nom du NS étaient identiques. Par contre la zone parente ne devrait pas contenir d’enregistrements autres que NS pour des noms de domaines d’une zone déléguée en dehors des glue records A et AAAA de ces NS, or la tienne contient des A et AAAA pour home.

Tu as essayé dans un premier temps en déléguant seulement home.almtesh.net ?

Accessoirement, ta zone n’a pas été mise à jour sur les NS d’Online :

almtesh.net.		3600	IN	SOA	ns0.online.net. hostmaster.almtesh.net. 2020110531 10800 3600 604800 3600

et le serial dans ton message original me semble un peu long (> 32 bits).

Par ailleurs le DNS sur nut.almtesh.net répond en SERVFAIL :

; <<>> DiG 9.9.5-9+deb8u19-Debian <<>> home.almtesh.net @2001:bc8:6005:1c:208:a2ff:fe0c:686c
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54828
#3

Oui, peut-être, mais nut.almtesh.net est un serveur SSH, en plus d’être serveur DNS. Je souhaitais que le nom nut.almtesh.net ne soit pas seulement la racine de ce sous-domaine, mais également la machine qui sert les noms de ce domaines.
Pour moi, si on peut servir un sous-domaine avec une machine qui n’est pas de ce domaine ou avec une machine qui est de ce domaines à l’aide d’un glue, je ne vois pas pourquoi on ne pourrait pas le faire avec une machine qui a pour nom la racine du sous-domaine… enfin*

Le serveur qui sert la zone almtesh.net ne servira que la zone almtesh.net et délègue pour les sous-domaines.

Alors, je n’ai pas compris, pour moi, le nom home.almtesh.net est dans la zone almtesh.net, pas home.almtesh.net.

J’ai supprimé la délégation de nut.almtesh.net et je n’ai laissé que celle sur home.almtesh.net. Le nom nut.almtesh.net se résout de nouveau, mais pas le nom home.almtesh.net.

Aucune idée, je ne sais pas ce qu’est ce truc.

Tu lui a demandé quoi ?

#4

En effet tu n’as pas compris. Le nom d’une zone est dans la zone, pas dans la zone parente. Les seuls enregistrements contenant le nom de la zone qu’il peut y avoir dans la zone parente sont la délégation (NS) et les glue records (A et AAAA pour les NS).

Tu manipules des zones et tu ne sais pas ce qu’est le serial (numéro de série) dans le SOA ?

C’est dans la première ligne de ce que j’ai cité (syntaxe de dig).

home.almtesh.net @2001:bc8:6005:1c:208:a2ff:fe0c:686c

#5

Donc, j’ai viré les enregistrement A et AAAA pour home.almtesh.net, je me suis assurée que le serveur nut.almtesh.net donne une valeur pour home.almtesh.net et j’ai mis nut.almtesh.net en cible NS pour le domaine home.almtesh.net, pour le moment, ça n’a pas l’air de fonctionner de là où je regarde. Et de chez toi ?

#6

Plusieurs anomalies du serveur DNS de nut.almtesh.net sur la zone home.almtesh.net :

  • il refuse les requêtes non récursives

  • le TTL des enregistrements A, AAAA, MX est 0

  • il renvoie SERVFAIL pour les enregistrements NS et SOA

C’est quoi, ce serveur ? On peut voir le fichier de zone ?

#7

Oh non, je crains le pire. Ça va faire mal.
oh-dear-we-are-in-trouble
Le serveur est dnsmasq. Bind est beaucoup trop compliqué pour moi

Ah bon ? C’est curieux, c’est son boulot de traiter des requêtes non récursives. Il ne sait même faire que ça, je dois utiliser un autre serveur pour les requêtes récursives.

C’est possible, ça pose problème ?

C’est parce qu’il n’a pas d’enregistrement de ce type, il faut qu’il en ait ?

#8

dnsmasq…ouch…
Bind est relativement simple en fait, en tout cas sur les fichiers de zones.
Normalement tu devrait avoir plutot quelque chose comme ça:

$TTL 3600
$ORIGIN almtesh.net
@      IN      SOA     ns0.online.net hostmaster.online.net. (
                        2020110407; serial
                        10800; refresh
                        3600;retry
                        604800; expire
                        3600 ) ; negative caching ttl
@       IN      NS       ip du serveur NS;
@       IN      NS       ipv6 du serveur DNS;
$TTL 120
@       IN      TXT     "v=spf1 mx a:home.almtesh.net -all"
@       IN AAAA 2001:bc8:3335::11
@       IN A 51.159.34.87
@       IN MX 10 mail.almtesh.net.

$ORIGIN nut.almtesh.net
$TTL 120
@       IN      NS      dns.nut.almtesh.net;
dns     IN      A       51.159.34.87
dns     IN      AAAA    2001:bc8:6005:1c:208:a2ff:fe0c:686c

$ORIGIN home.almtesh.net
$TTL 120
@       IN      NS      dns.nut.almtesh.net;
home    IN      A       82.65.155.50
home    IN      AAAA    2a01:e0a:12c:3940::

On évite de mettre un dns à la racine d’un domaine. un site web nut.almtesh.net c’est ok, mais un dns doit plutôt être dns.nut.altmesh.net.

#9

dnsmasq m’a sorti d’énormément de galères de réseau et il fonctionne très bien. Il est très efficace et gère beaucoup de choses maintenant.

Je n’ai rien compris. Est-ce utile d’avoir un enregistrement SOA sur un serveur unique, non redondé et avec des enregistrements dynamiques ?

#10

Alors pourquoi avoir mentionné bind dans le titre ?
Je ne connais pas beaucoup dnsmasq, ne l’ayant jamais utilisé, mais je doute que dnsmasq soit suffisant comme DNS faisant autorité pour servir une zone.

Euh, que je sache dnsmasq est avant tout un cache récursif. Il peut servir des noms définis localement (ex: ceux définis dans le fichiers hosts), mais ça n’en fait pas un serveur autoritaire complet.

Je le crains, car si ces enregistrements transitent par un serveur cache récursif avec un TTL de 0, ils vont être immédiatement supprimés. Si c’est après avoir répondu, ça ira quand même. Si c’est avant…

C’est obligatoire pour servir une zone. En fait ce sont les deux seuls types d’enregistrements obligatoires.

#11

Désolé le temps de répondre proprement :slight_smile:
vois mon message complet cette fois (car une erreur de clavier l’avait interrompuu :slight_smile: )un peu plus haut.

en passant je ne crois pas que tu puisse faire un DNS Authoritative avec dnsmaq. je suis d’accord avec pascal. Perso j’utilise Bind. Il permet en prime de faire du DNSSEC.

En passant,

2a01:e0a:12c:3940:: ne serait elle pas une adresse de routeur anycast?

#12

Cool, je pourrais avoir une fonctionnalité que je comprends pas avec une fonctionnalité que je maîtrise à peine.

Oui, c’est l’adresse externe de Lookout, mon routeur. Si tu veux lui passer le bonjour, il répond aux pings. Mais cette adresse n’assure pas de routage, c’est juste une adresse d’identité. Je ne sais pas si c’est censé fonctionner comme ça, mais je pense que fe80::dea6:32ff:fe52:32d7 n’aurait pas pu fonctionner pour accéder à l’Internet.

#13

:rofl: uniquement au premier routeur suivant :wink:
mais sinon il y a l’adresse étendue de celle ci avec l’adresse mac. celle qui est delivrée par defaut par une box.

#14

Pas vraiment, non. Ce fichier de zone contient plusieurs erreurs manifestes. Je te laisse corriger.

#15

d’où le quelque chose comme ca.
j’ai corrigé le « ; » derriere hostmaster qui etait une faute de frappe.
le reste attendra la fin du diner

#16

Je parlais des grosses erreurs de conception, pas des petites fautes de frappe.

#17

Personnellement, je ne comprend pas, je te laisse trouver.

#18

personnellement je n’utilise pas dnsmasq :slight_smile:
Après coté conception, comme je ne sais pas exactement la réalité des adresses IP, le reste je ne suis pas d’accord. A moins d’explication, je ne suis pas un joueur de devinettes.
sans compter que j’ai du simplement subodorer l’architecture faute d’information.
C’est pour ca que je disais, ressembler, et non doit etre.

#19

Sinon, est-ce que je peux dire à bind d’être autoritaire sur une zone DNS, mais qu’il n’a pas la zone dans sa configuration, mais qu’il doit la chercher dans un serveur DNS amont ? Personnellement, je ne vois pas l’intérêt d’une telle configuration, mais bon, je n’en suis plus là.
Sinon, pour le fichier de zone, l’erreur, ce n’est pas que le nom dns.nut.almtesh.net doit se trouver dans la partie almtesh.net et non dans la partie nut.almtesh.net ?

#20

Non un serveur n’est autoritaire que sur une zone qu’il delivre lui meme. Mais il n’est pas obligé d’etre maitre, il peut etre serveur esclave et recuperer la zone par transfert.
S’il doit la chercher dans un serveur amont, c’est du forward et leur serveur amont signalera son autorité.
Le parametre de recursivité joue dans ce cas là.

dns.nut.almtesh.net fait obligatoirement partie de la zone nut;almesh.net, masi la gestion de la zone peut etre attribué au serveur almtesh.net.
Il faut diff"rencier les zones proprement diotes des serveurs eux meme.

C’est comme ca que tu peux avoir une zone almtesh.net servir par un serveur dns.online.net.
j’ai fait quelques a priori sur l’exemple que j’ai donné faute de savoir ton architecture.

dans un DNs tu as un SOA qui definie une zone
auquel est associé un NS qui definie le serveur
Auquel un A ou AAAA est associé pour l’adresse ip(v6), car ne l’oublions pas, le but c’est d’avoir une adresse IP au bout.
Ensuite dans ta zone tu peux definir une sous zone, mais qui va rester definie par le SOA de sa zone maitre.

personnellement j’evite ce genre de truc.
je definie toujours un enregistrement de zone meme si je gere la zone maitre de la sous zone. c’est plus pratique pour s’y retrouver.