Zwei Reverse-Zonen im gleichen Subnet möglich

[pangu]

Hallo,

bevor ich mich lange rumquäle würde ich von den DNS Profis hören, ob das generell möglich wäre oder nicht. Ihr kennt ja sicherlich das Problem, dass der BIND9 dynamische durch DDNS eingetragene Hosts querbet in die Zonendatei einträgt. Bei einer langen Liste sind dann die statisch eingetragenen Hosts und die dynamischen wild durcheinandergewürfelt. Daher trennen viele Admins diese Zonen, indem sie eine Zone für ihre statischen Hosts verwenden, und eine eigene für die DHCP-Clients als Beispiel.

Das habe ich auch gemacht. Wenn ich für meine statischen Clients das Subnet 192.168.0.0/24 verwende, und für alle DHCP-Clients das 192.168.1.0/24 dann habe ich eine schöne Trennung und in Summe 4 Zonenfiles (forward+reverse für das 192.168.0.0 Netz und eine forward und reverse für das 192.168.1.0 Netz). Aussen vor gelassen, dass natürlich zwischen den zwei Netzten geroutet werden muss, damit die auch problemlos miteinander funktionieren können.

Was aber wenn ich nur ein einzelnes Subnet hätte, sagen wir das 192.168.5.0/24 ? Ich möchte jetzt trotzdem allen DHCP-Clients in einer eigenen Zone haben. Soweit so gut, aber jetzt kommts:

kann ich auch die reverse Zone in diesem Beispiel trennen in zwei Zonen, obwohl ja irgendwie 5.168.192.in-addr.arpa verwendet werden müsste ?? Oder muss ich zwingend nur eine reverse Zone 5.168.192.in-addr.arpa in welcher dann sowohl die statischen als auch die dynamischen PTR records zu sehen sind?

[Natureshadow]

Hi,

der BIND verwaltet da eine Zone immer als Ganzes.

Wäre es eine Möglichkeit, ein größeres Netz zu nehmen?

-nik

[pangu]

es geht mir ums Prinzip, nicht wirklich um eine Lösung in der Praxis. Ich würd gerne wissen, ob das möglich wäre. Oder gibt's irgendwie nen speziellen Syntax mit diesem in-addr.arpa damit ich das trennen kann?

[Natureshadow]

Das Reverse DNS-Zeug stammt noch aus einer Zeit, in der man mit Netzwerkklassen arbeitete. Die kleinste Einheit für dich zum splitten ist also ein Oktett in der IP-Adresse.

Demnach:

Zonen trennen: unmöglich

Dateien trennen: Vielleicht, mit $INCLUDE, aber ich glaube, sobald BIND selber die Zone anfasst, schreibt es alles in eine Datei. Du könntest BIND abgewöhnen, die Zone auf der Festplatte anzufassen und ihn die DDNS-Records nur im RAM halten lassen.

[Cae]

Das Reverse DNS-Zeug stammt noch aus einer Zeit, in der man mit Netzwerkklassen arbeitete. Die kleinste Einheit für dich zum splitten ist also ein Oktett in der IP-Adresse.

Da bin ich mir nicht ganz sicher, ich meine, einmal ein in-addr.arpa in einer pseudo-CIDR-Schreibweise verwendet zu haben. Dummerweise finde ich die entsprechende Version der Konfiguration nicht, aus der Erinnerung:

Code: Alles auswählen

$ORIGIN 3/2.2.10.in-addr.arpa

Oder /25? Damit konnte man das 10.2.3.0/25-er Subnet mit PTR-Einträgen versorgen. Stellt sich die Frage, wie man das zweite Subnetz 10.2.3.128/25 ansprechen will…

Gruß Cae

[Natureshadow]

Häh?

Wie soll das denn gehen? Das widerspricht dem grundsätzlichen Aufbau von DNS so tiefgreifend . . .

Belege, bitte?

EDIT: Oh, aber hier ist was . . . http://serverfault.com/questions/22743/ ... cidr-world

[Cae]

Wie soll das denn gehen? Das widerspricht dem grundsätzlichen Aufbau von DNS so tiefgreifend . . .

Belege, bitte?

Genau diese Reaktion hab' ich erwartet. Wie ich schon oben schrieb, das sind Vermutungen im Nachhinein. Ich kann mich da durchaus irren, da ich jene Konfiguration eben nicht mehr finde.

So ganz abwegig erscheint mir die weitere Unterteilung in CIDR-notierte Netze allerdings nicht, schließlich ist der einzige technische Unterschied zwischen beispielsweise Klasse A und einem /27-er Netz die Subnetzmaske. Das DNS hat im Laufe der Zeit Erweiterungen bekommen, gut möglich, dass diese Funktion nicht von Anfang an dabei gewesen ist.

Gruß Cae

--Edit: Nach einem Austausch mit Natureshadow im Chat steht wohl fest, dass ich einen üblen Workarround nach RFC 2317 [1] gemeint habe. Also ist das keine spezielle Notation im DNS, sondern ein willkürlich gewählter Name. Das Prinzip wird auch im oben genannten serverfault-Eintrag verwendet.

[1] http://tools.ietf.org/rfc/rfc2317.txt

[pangu]

Da stell ich mir nun die Frage, wie ich eigentlich verschiedene Subnets behandelt soll. Wenn ich andere IP-Bereiche besitze, z.B. meine DMZ, oder evtl. ein weiteres Subnet (WLAN)... Ist es sinnvoll fuer jedes einzelne Subnet eine eigene Zone in der named.conf.local des BIND zu definieren und auch ein eigenes forward- und reverse file anzulegen?

Oder koennte ich solche Eintraege da es nicht allzuviele sind, einfach in meine bestehende Zonen aufnehmen? würde das funktionieren oder ist das nicht empfehlenswert? dass ich das dann nicht ALLE/VERSCHIEDENE IP-Bereiche in der selben reverse Zonendatei unterbringen kann, ist natuerlich bloed.

EDIT: Es funktioniert tadellos, habs grad probiert. selbst die reverseone könnte ich als ClassB anlegen und in einer einzigen Datei verwalten, als Beispiel:
/etc/bind/named.conf.local:

Code: Alles auswählen

zone "meine-firma.de" {
        type master;
        file "/var/cache/bind/forwardzone.meine-firma.de";
};

zone "168.192.in-addr.arpa" {
        type master;
        notify no;
        file "/var/cache/bind/reversezone.192.168";
};

Reverse-Zonenname="168.192.in-addr.arpa", Zonendateiname="/var/cache/bind/reversezone.192.168":

Code: Alles auswählen

$TTL 1W
@       IN      SOA     serverhostname.meine-firma.de. admin.meine-firma.de. (
                        2012052201
                        8H
                        2H
                        1W
                        11H )
                                        NS      ns1.meine-firma.de.
                                        NS      ns2.meine-firma.de.

; das soll von mir aus eine VPN-Leitung nach Hamburg sein
$ORIGIN 1.168.192.in-addr.arpa.
1                               IN      PTR     guguck1.hamburg.meine-firma.de.
5                               IN      PTR     cisco2.hamburg.meine-firma.de.
9                               IN      PTR     irgendwas.hamburg.meine-firma.de.

; und das eine andere VPN-Anbindung nach Bonn
$ORIGIN 2.168.192.in-addr.arpa.
1                               IN      PTR     rp1.bonn.meine-firma.de.
2                               IN      PTR     server5.bonn.meine-firma.de.

; das ganze WLAN-Netz
$ORIGIN 3.168.192.in-addr.arpa.
38                             IN      PTR     ap38.wlan.meine-firma.de.

Das funktioniert soweit. Lediglich für meine DMZ müsste ich eine extra Forwardzone und ReverseZone (also auch zwei neue Zonendateien anlegen). Ich kann nämlich nicht einfach

Code: Alles auswählen

[...]
$ORIGIN 0.0.10.in-addr.arpa
[...]

in die vorhandene 168.192.in-addr.arpa Zone reinnehmen, weil es sonst nicht funktioniert, da andere IP-Bereiche und somit das in-addr.arpa nicht greifen kann.

[Natureshadow]

Code: Alles auswählen

$ORIGIN 0.0.10.in-addr.arpa
1 IN PTR bla.example.com.

wird zu

1.0.0.10.in-addr.arpa.168.192.in-addr.arpa.

in deiner Config oben.

FQDNs haben am Ende einen Punkt!

[pangu]

Gut aufgepasst, war ein Tippfehler von mir im Eifer des Gefechts Trotzdem danke.

==> Ich hab die Lösung für eine einzige Reversezone gefunden.

Ich habs jetzt ausgiebig getestet, funktioniert in beide Richtungen für alle verschiedenen Bereiche. Vielleicht bin ich jetzt nur etwas euphorisch, weil es momentan so funktioniert, abe --> hab ich 'nen Denkfehler, oder überseh ich etwas? Könnte ich dadurch Probleme kriegen?

Die Lösung ist ganz einfach, indem ich eine komplette Reverse-Zone errichte namens in-addr.arpa. Daraufhin kann ich in meinem reverse zonefile beliebig viele IP-Subnets definieren, und so auch übersichtlich strukturieren.

/etc/bind/named.conf.local

Code: Alles auswählen

zone "meine-firma.de" {
        type master;
        file "/var/cache/bind/forwardzone.meine-firma.de";
};

zone "in-addr.arpa" {
        type master;
        notify no;
        file "/var/cache/bind/reversezone.meine-firma.de";
};

/var/cache/bind/reversezone.meine-firma.de

Code: Alles auswählen

$TTL 1W
@       IN      SOA     serverhostname.meine-firma.de. admin.meine-firma.de. (
                        2012052201
                        8H
                        2H
                        1W
                        11H )
                                        NS      ns1.meine-firma.de.
                                        NS      ns2.meine-firma.de.

; das soll von mir aus eine VPN-Leitung nach Hamburg sein
$ORIGIN 1.168.192.in-addr.arpa.
1                               IN      PTR     guguck1.hamburg.meine-firma.de.
5                               IN      PTR     cisco2.hamburg.meine-firma.de.
9                               IN      PTR     irgendwas.hamburg.meine-firma.de.

; und das eine andere VPN-Anbindung nach Bonn
$ORIGIN 2.168.192.in-addr.arpa.
1                               IN      PTR     rp1.bonn.meine-firma.de.
2                               IN      PTR     server5.bonn.meine-firma.de.

; das ganze WLAN-Netz
$ORIGIN 3.168.192.in-addr.arpa.
38                             IN      PTR     ap38.wlan.meine-firma.de.
usw...

; und ich kann jetzt sogar ein ganz andres Netz angeben
$ORIGIN 0.0.10.in-addr.arpa.
69                             IN      PTR     lust.dmz.meine-firma.de.
70                             IN      PTR     laune.dmz.meine-firma.de.
usw...

; und von mir aus auch ein 16er Netz
$ORIGIN 21.172.in-addr.arpa.
1.0                            IN      PTR     gateway1.meine-firma.de.
55.88                        IN       PTR     wasanderes.meine-firma.de.
usw...

Jetzt hab ich endlich ein festes statisches File für meine forward- und reversezone und kann manuell per Hand meine Einträge schön sortiert eintragen. Für meine DHCP-Clients hab ich 'n extra Zonenfile angelegt, da ja DDNS wild herumträgt und seine TXT-records schreibt. Wenn nix von den Profis hier einzuwenden ist, bleib ich bei dieser config. Ich würde mich auf euer Feedback freuen.

Danke und Gruß,
Pangu.

[Natureshadow]

Das ist schon dreist, sich einfach als Verwalter für das gesamte IPv4-Internet darzustellen, nur um einen ekligen Workaround zu haben . . .

Und das bricht für dich DNS für alle Subzonen, die du nicht verwaltest, weil dein BIND sich jetzt autoritativ für alle Subnetze fühlt.

Du kannst darüber nun nie wieder externe Reverse-Lookups machen, wie sie z.B. für einen ordentlichen MTA-Betrieb notwendig wären.

Korrekt:

Code: Alles auswählen

nik@keks ~ % host 8.8.8.8
8.8.8.8.in-addr.arpa domain name pointer google-public-dns-a.google.com.

Über deinen BIND:

Code: Alles auswählen

nik@keks ~ % host 8.8.8.8
8.8.8.8.in-addr.arpa. not found: 3(NXDOMAIN)

Was soll das Gewurste?

[pangu]

Na deswegen fragte ich ja siehst du, das hatte ich gar nicht mitberücksichtig *lol*

Danke dir.