Wildcard DNS mit BIND

Ich versuche, BIND so einzurichten, dass es alle an ihn gerichteten Anforderungen auffängt und sie auf einen bestimmten Satz von NS-Servern und einen bestimmten A-Datensatz verweist.

Ich habe ungefähr 500 Domains und füge täglich 10-15 neue hinzu. Daher möchte ich nicht explizit für jede Domain eine Zone hinzufügen.

Mein aktuelles Setup ist: In meiner named.conf habe ich eine Ansicht (external) mit der folgenden Zone:

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

Dies entspricht allen Anforderungen.

ext.zone ist:

3600 US-Dollar
@ IN SOA. root.nsdomain.com. (
                              1; Seriell
                         3600; Aktualisierung
                          300; Wiederholen
                         3600; Verfallen
                         300); Negative Cache-TTL


        IN NS ns1.example.com
        IN NS ns2.example.com

ns1 IN A 192.0.2.4
ns2 IN A 192.0.2.5

*. IN A 192.0.2.6

Das Ziel ist also: Für alle NS-Anforderungen kehren Sie zurück ns1.example.comund ns2.example.com für alle A-Anforderungen, außer wenn es sich um ns1.example.comoder handelt ns2.example.com, kehren Sie zurück 192.0.2.6. Zur ns1.example.comRückkehr 192.0.2.4, zur ns2.example.comRückkehr 192.0.2.5.

Das funktioniert fast, das einzige Problem ist, dass ich beim Graben Folgendes bekomme:

dig @localhost somedomain.example

; > DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3> @localhost somedomain.example
; (1 Server gefunden)
;; globale Optionen: printcmd
;; Antwort bekommen:
;; Befehlscode: QUERY, Status: NOERROR, ID: 37733
;; Flags: qr aa rd; FRAGE: 1, ANTWORT: 1, BEHÖRDE: 2, ZUSÄTZLICH: 2

;; FRAGE ABSCHNITT:
; somedomain.example. IN EINEM

;; ANTWORT ABSCHNITT:
somedomain.example. 3600 IN A 192.0.2.6 // wie erwartet

;; BEHÖRDEN ABSCHNITT:
. 3600 IN NS ns1.example.com. // erwartet, ich weiß nicht ob das "." am anfang ist es allerdings schlecht.
. 3600 IN NS ns2.example.com. // siehe oben.

;; ZUSÄTZLICHER ABSCHNITT:
ns1.example.com. 3600 IN A 192.0.2.6 // nicht zu erwarten, sollte dies 192.0.2.4 sein
ns2.example.com. 3600 IN A 192.0.2.6 // nicht zu erwarten, sollte dies 192.0.2.5 sein

Wie behebe ich das? Mache ich etwas Schreckliches? Gibt es einen besseren Weg, dies zu tun?

Ihr Ursprung für die Zone richtet sich .nach Ihrer Konfiguration. Sie erstellen Datensätze für ns1.und ns2.anstelle von ns1.example.com.und ns2.example.com. Seit ns1.example.comund ns2.example.comsind nicht definiert. Sie werden durch den Platzhalter abgeglichen.

BEARBEITEN: Hier ist eine Bearbeitung Ihrer Konfiguration und Zone:

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

ext.zone:

$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

Alles in der Zone ist relativ zum Zonennamen in der benannten Konfiguration, sodass das Hinzufügen einer zweiten Zone nur auf dieselbe Datei verweist:

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

Basierend auf Ihrer Konfiguration ns1.example.comist 192.0.2.4und ns2.example.comist 192.0.2.5. Sie müssen die Namensauflösung des NS-Servers in der example.comZone konfigurieren , um die richtigen IP-Adressen zu erhalten.

Ich hoffe ich mache mich klar. Kommen Sie zu mir zurück, wenn Sie weitere Informationen benötigen.

Um einen Platzhalter für eine Subdomain festzulegen bind, sollten Sie das folgende Format verwenden:

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

Beispiel:

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

DNS-Platzhalter können Probleme verursachen!

Daher möchte ich nicht explizit für jede Domain eine Zone hinzufügen.

Es gibt viele Möglichkeiten - vom SHELL-Scripting bis zum SQL-basierten DNS-Server.

UPD. (2019-11) : Wie ich bereits vor 8 Jahren sagte , ist SHELL-Scripting ein guter Weg und wurde mit der vorgeschlagenen Lösung "Zoneneintrag hinzufügen" der akzeptierten Antwort bewiesen - eindeutig nicht basierend auf der Verwendung von Platzhaltern. ;-)

2019 ist es noch einfacher, Ressourcen zu finden, die die Nachteile von DNS-Platzhaltern erklären, und obwohl die meisten von ihnen "zu Beginn des Internets" geschrieben wurden, sind sie immer noch von Bedeutung. Zum Beispiel erwähnt RFC1912 einige Dinge, die mit der Verwendung von DNS-Platzhaltern zusammenhängen. Das Hauptproblem wird klar erklärt als "…

Platzhalter-MXs können schlecht sein, da sie einige Vorgänge zum Erfolg führen, wenn sie stattdessen fehlschlagen sollten . … "

Es gibt auch einige Beispiele aus dem wirklichen Leben, die etwas altmodisch sind.