5
DNS PTR Zones - bei Subnetzen
Hallo zusammen,
ich stehe bzgl. DNS PTR Zones gerade etwas auf dem Schlauch.
Wir nutzen z.B. folgende IP Netze:
172.18.0.0 255.255.255.0
172.18.9.0 255.255.255.0
172.18.26.0 255.255.255.0
Benötige ich hier jetzt im DNS Server für jedes einzelne Netz auch eine eigene PTR Zone oder kann ich die Netze im reverse DNS auch zu 18.172.in-addr.arpa zusammen fassen?
Oder ginge theoretisch sogar nur 172.in-addr.arpa ?
ich stehe bzgl. DNS PTR Zones gerade etwas auf dem Schlauch.
Wir nutzen z.B. folgende IP Netze:
172.18.0.0 255.255.255.0
172.18.9.0 255.255.255.0
172.18.26.0 255.255.255.0
Benötige ich hier jetzt im DNS Server für jedes einzelne Netz auch eine eigene PTR Zone oder kann ich die Netze im reverse DNS auch zu 18.172.in-addr.arpa zusammen fassen?
Oder ginge theoretisch sogar nur 172.in-addr.arpa ?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-Key: 1458379727
Url: https://administrator.de/contentid/1458379727
Ausgedruckt am: 25.04.2024 um 06:04 Uhr
5 Kommentare
Neuester Kommentar
Moin,
Gruß,
Dani
Benötige ich hier jetzt im DNS Server für jedes einzelne Netz auch eine eigene PTR Zone oder kann ich die Netze im reverse DNS auch zu 18.172.in-addr.arpa zusammen fassen?
meines Wissens nach geht beides. Schlussendlich ist es eine Frage der Übersichtlichkeit und bei einer großen Anzahl von Zonen auch im Last. Wobei ich in deinem Fall wohl eher über Ersteres Gedanken machen würde. Oder ginge theoretisch sogar nur 172.in-addr.arpa ?
Müsste auch gehen. Wobei du damit Probleme bekommen wirst, wenn eine Internetseite eine öffentliche IP-Adresse (z.B. 172.2.2.2) hat. Dann wird der Zugriff aus dem Netzwerk nicht mehr funktionieren, da der DNS-Server dies nicht mehr auflösen kann. Daher am Besten mti 172.16.x.x arbeiten.Gruß,
Dani
Müsste auch gehen. Wobei du damit Probleme bekommen wirst, wenn eine Internetseite eine öffentliche IP-Adresse (z.B. 172.2.2.2) hat. Dann wird der Zugriff aus dem Netzwerk nicht mehr funktionieren, da der DNS-Server dies nicht mehr auflösen kann. Daher am Besten mti 172.16.x.x arbeiten.
ja klar, 172.in-addr.arpa war natürlich Quatsch, Denkfehler meinerseits!
und bei einer großen Anzahl von Zonen auch im Last.
was meinst du damit genau?
Fall 1:
eine Zone 18.172.in-addr.arpa
Fall 2:
jeweils eine Zone von 0.18.172.in-addr.arpa bis 254.18.172.in-addr.arpa
macht es "performance technisch" einen Unterschied welchen Fall man im DNS anlegt?
eine Zone 18.172.in-addr.arpa
Fall 2:
jeweils eine Zone von 0.18.172.in-addr.arpa bis 254.18.172.in-addr.arpa
macht es "performance technisch" einen Unterschied welchen Fall man im DNS anlegt?
Hi,
Man kann dann sicherlich keine öffentlichen Adressen aus diesem Bereich in Namen auflösen. Aber man kann weiterhin Namen (A-Records) auflösen, welche auf Adressen aus diesem Bereich verweisen, und dann natürlich auch auf Dienste (z.B. Web-Seiten) zugreifen, welche an diesen Adressen angeboten werden. Das hängt davon ab, wie und womit man da zugreift, und ob da als Sicherheitsabfrage eine PTR-Auflösung erfolgt. z.B. bei SMTP sollte das ja so sein.
E.
Zitat von @Dani:
Nein, sorry, das stimmt so nicht ganz. Oder ginge theoretisch sogar nur 172.in-addr.arpa ?
Müsste auch gehen. Wobei du damit Probleme bekommen wirst, wenn eine Internetseite eine öffentliche IP-Adresse (z.B. 172.2.2.2) hat. Dann wird der Zugriff aus dem Netzwerk nicht mehr funktionieren, da der DNS-Server dies nicht mehr auflösen kann.Man kann dann sicherlich keine öffentlichen Adressen aus diesem Bereich in Namen auflösen. Aber man kann weiterhin Namen (A-Records) auflösen, welche auf Adressen aus diesem Bereich verweisen, und dann natürlich auch auf Dienste (z.B. Web-Seiten) zugreifen, welche an diesen Adressen angeboten werden. Das hängt davon ab, wie und womit man da zugreift, und ob da als Sicherheitsabfrage eine PTR-Auflösung erfolgt. z.B. bei SMTP sollte das ja so sein.
E.
@emeriks: Pfusch bleibt es trotzdem 
@menace: Performance-Unterschiede wirst du wohl nicht sehen. Das RIPE delegiert die PTR-Zonen für öffentliche IPs auch als /24-Zonen. Wenn es also eine effizientere Methode brauchen würde, wäre die erfunden
Du solltest die Zonen lieber so anlegen, wie sie logisch auch existieren. Wenn du dann mal bei einzelnen Zonen automatische Eintragungen willst (vom DHCP-Server) ist es einfacher, diese einzelnen Zonen dann dafür zu konfigurieren, als es mit Teilbereichen einer großen Zone möglich wäre.
@menace: Performance-Unterschiede wirst du wohl nicht sehen. Das RIPE delegiert die PTR-Zonen für öffentliche IPs auch als /24-Zonen. Wenn es also eine effizientere Methode brauchen würde, wäre die erfunden
Du solltest die Zonen lieber so anlegen, wie sie logisch auch existieren. Wenn du dann mal bei einzelnen Zonen automatische Eintragungen willst (vom DHCP-Server) ist es einfacher, diese einzelnen Zonen dann dafür zu konfigurieren, als es mit Teilbereichen einer großen Zone möglich wäre.
