DNS générique avec BIND

J'essaie de configurer BIND afin qu'il intercepte toutes les demandes qui lui sont adressées et les pointe vers un ensemble spécifique de serveurs NS et un enregistrement A spécifique.

J'ai environ 500 domaines et j'en ajoute de nouveaux à raison de 10 à 15 par jour, donc je ne veux pas ajouter explicitement une zone pour chaque domaine.

Ma configuration actuelle est la suivante: dans mon named.conf, j'ai une vue (nommée external) avec la zone suivante:

zone "." {
        type master;
        file "ext.zone";
};

Cela correspond à toutes les demandes.

ext.zone est:

TTL 3600 $
@ SOA. root.nsdomain.com. (
                              1 ; En série
                         3600; Rafraîchir
                          300; Retenter
                         3600; Expirer
                         300); Cache TTL négatif


        EN NS ns1.example.com
        EN NS ns2.example.com

ns1 IN A 192.0.2.4
ns2 IN A 192.0.2.5

*. DANS UN 192.0.2.6

ainsi, l'objectif est: pour toutes les demandes NS, retourner ns1.example.comet ns2.example.com pour toutes les demandes A, sauf là où c'est ns1.example.comou ns2.example.com, retourner 192.0.2.6. Pour le ns1.example.comretour 192.0.2.4, pour le ns2.example.comretour 192.0.2.5.

Cela fonctionne presque, le seul problème est que lorsque je fais une fouille, j'obtiens:

creuser @localhost somedomain.example

; > DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3> @localhost somedomain.example
; (1 serveur trouvé)
;; options globales: printcmd
;; J'ai une réponse:
;; opcode: QUERY, statut: NOERROR, id: 37733
;; drapeaux: qr aa rd; DEMANDE: 1, RÉPONSE: 1, AUTORITÉ: 2, SUPPLÉMENTAIRE: 2

;; SECTION QUESTION:
; undomaine.exemple. DANS UN

;; SECTION RÉPONSE:
undomaine.exemple. 3600 DANS UN 192.0.2.6 // comme prévu

;; SECTION DE L'AUTORITÉ:
. 3600 IN NS ns1.example.com. // attendu, je ne sais pas si le "." au début, c'est mauvais.
. 3600 IN NS ns2.example.com. // voir au dessus.

;; SECTION SUPPLÉMENTAIRE:
ns1.example.com. 3600 IN A 192.0.2.6 // non attendu, cela devrait être 192.0.2.4
ns2.example.com. 3600 IN A 192.0.2.6 // non attendu, cela devrait être 192.0.2.5

Comment puis-je réparer ça? Suis-je en train de faire quelque chose d'horrible? Y a-t-il une meilleure manière de faire cela?

Votre origine pour la zone est .selon votre configuration. Vous créez des enregistrements pour ns1.et ns2.au lieu de ns1.example.com.et ns2.example.com. puisque ns1.example.comet ns2.example.comne sont pas définis, ils sont mis en correspondance par le caractère générique.

EDIT: voici un edit de votre config et de votre zone:

zone "example.com." {
        type master;
        file "ext.zone";
};

zone ext .:

$TTL    3600
@       IN      SOA     ns1 root (
                              1         ; Serial
                         3600         ; Refresh
                          300         ; Retry
                         3600         ; Expire
                         300 )        ; Negative Cache TTL


        IN      NS      ns1
        IN      NS      ns2
        IN      A       192.0.2.6


ns1     IN      A       192.0.2.4
ns2     IN      A       192.0.2.5

*      IN      A       192.0.2.6

Tout dans la zone est relatif au nom de la zone dans la configuration nommée, donc l'ajout d'une deuxième zone pointe simplement vers le même fichier:

zone "example.net." {
    type master;
    file "ext.zone";
};

Pour définir un caractère générique de sous-domaine, bindvous devez utiliser le format suivant:

name.tld.   IN  A   IP    # main domain ip
*.name.tld. IN  A   IP    # wildcard subdomains ip

Exemple:

mydomain.com.   IN  A   1.1.1.1
*.mydomain.com. IN  A   1.1.1.1 

Basé sur votre configuration ns1.example.comest 192.0.2.4et ns2.example.comest 192.0.2.5. Vous devez configurer la résolution de nom de serveur NS dans la example.comzone pour obtenir les bonnes adresses IP.

J'espère que je me fais comprendre. Revenez à moi si vous avez besoin de plus d'informations.

Les caractères génériques DNS peuvent causer des problèmes!

donc je ne veux pas ajouter explicitement une zone pour chaque domaine.

Il existe de nombreuses façons de procéder - des scripts SHELL aux serveurs DNS basés sur SQL.

UPD. (2019-11) : Donc, comme je l'ai dit il y a 8 ans , le script SHELL est un chemin à parcourir et cela a été prouvé avec la solution proposée par la réponse acceptée "ajouter une entrée de zone" - clairement non basée sur l'utilisation de caractères génériques. ;-)

En 2019, il est encore plus facile de trouver des ressources expliquant les inconvénients des caractères génériques DNS et bien que la plupart d'entre eux aient été écrits "à l'aube d'Internet", ils ont encore une certaine valeur. Par exemple, RFC1912 mentionne quelques éléments liés à l'utilisation des caractères génériques DNS. Le problème principal est clairement expliqué comme «…

Les MX génériques peuvent être mauvais, car ils font que certaines opérations réussissent alors qu'elles devraient échouer à la place . … "

Il contient également des exemples concrets un peu démodés.