PfSense als DNS für ActiveDirectory?

tpf · Mar 15, 2015, 4:56 PM

Servus,
ich zentralisiere gerne, möchte den DNS fürs AD daher gerne auf die pfS verlagern. Nutzt hier einer problemlos einen DNS auf pfS für Windows-AD?

Grüße

JeGr · Mar 16, 2015, 3:12 PM

Ahoi,

naja ich weiß nicht wie/ob das sauber funktionieren wird, denn das Windows AD ist dann doch recht weit von "normalem" DNS entfernt, spätestens wenn die ersten "Schemaerweiterungen" wie von Exchange und Co da reinhageln. Insofern würde ich das eher kritisch mit "nö, geht nicht (ohne weiteres)" sehen, aber man mag mich da gern korrigieren, wenns um sowas geht lern' ich gerne dazu :)

Grüße

bitboy0 · Mar 16, 2015, 3:21 PM

DNS nur für die Namensauflösung von ausgehenden Anfragen, oder richtiger DNS für eine bei euch gehostete Domain?

Für den ersten Fall ist das recht einfach:

Die DNS für die externen Anfragen tragt man bei "System","General-Setup" ein.
Damit die Clients das AD erreichen können muss man die Domain des AD als "Domain-Override" im DNS-Forwarder eintragen und die IP des AD dort angeben.

Also "firma.local" auf "10.10.10.1" z.B. …
Dann gehen alle DNS-Anfragen über die pfSense in's WAN, außer es ist eine Anfrage auf "irgendwas.firma.local", die wird dann an das AD weitergeleitet und von dort beantwortet.

Einen richtigen DNS-Server (bind) habe ich nicht laufen, brauche ich aber auch hier nicht. Tiny-DNS habe ich mal versucht, aber der scheint auf 2.2 noch nicht zu laufen. Ein Dienst kann nicht gestartet werden den TinyDNS braucht.

gruß

JeGr · Mar 16, 2015, 3:30 PM

Damit die Clients das AD erreichen können muss man die Domain des AD als "Domain-Override" im DNS-Forwarder eintragen und die IP des AD dort angeben.

Dito übrigens auch für den DNS Resolver (sollte den jemand statt des Forwarders mit der 2.2 nutzen). Mit diesem sind auch etwas mehr Spielereien möglich (in Richtung DNSSEC, v6 etc.) Wer das aber nicht braucht, ist beim Forwarder durchaus richtig. Nebenbei: Man kann mit den Overrides selbst komplexere Konstrukte bauen wie bspw. domain.local an AD DNS, xy.domain.local mit echter IP bestücken damit Testserver extern bspw. erreichbar ist, subdomain.domain.local an anderen DNS deligieren und dyn.domain.local für lokale DDNS Auflösung von Clients nutzen, die nicht ins AD müssen (bspw. WLAN Gäste o.ä.).

Grüße

tpf · Mar 16, 2015, 8:16 PM

Servus,
ich meine schon die SRV-Records uuuund die A-Records des Windows-AD. In einem anderen DNS, mir fällt grad der Name partout nicht ein, kein Windows, kann ich die DCs einfach als schreibberechtigt für die Zone eintragen und die schreiben selbst ihre Records rein.

Ist echt genial, das hätte ich gerne auf pfS gehabt.

Grüße

viragomann · Mar 16, 2015, 8:49 PM

Hallo,

ich verstehe wieder mal nicht den Sinn der Aktion.

Warum installierst du nicht den DNS Dienst direkt auf dem Domain Controller? Damit funktioniert ja auch alles problemlos.
Oder hat Microsoft dies nun verpönt?

Für pfSense gibt es bestenfalls ein TinyDNS Package. Ich kenne zwar dessen Funktionsumfang nicht, aber der Name lässt auf einige Einschränkungen schließen.

Grüße

bitboy0 · Mar 17, 2015, 7:52 AM

Das AD auf die Sense spiegeln? Also vielleicht geht das, aber damit habe ich mich nicht beschäftigt. Da sehe ich für uns auch keine Vorteile.

TinyDNS hab ich auf der aktuellen 2.2 bisher nicht starten können. Ein Service kann nicht gestartet werden, den das Teil gerne hätte.
Da wir für die Web-Domains eh einen externen Server haben und der auch einen eigenen DNS hat, brauchen wir das in der Firma aber eh nicht.

Abgesehen davon ist es bei uns so: Der DNS/AD läuft auf dem Windows Server, die DNS-Anfragen für alles andere laufen nicht diesen Weg. Wir hatten schon den Fall, dass der Windows-Server ausgefallen ist. Dann konnte auch niemand mehr seine Mails per Webinterface checken weil der DNS grundsätzlich nur über den Server lief. Natürlich SOLLTE der Server nicht ausfallen… ist ja theoretisch alles redundant (Netzteile, LAN, Festplatten usw) aber es ist eben doch passiert.

Jetzt ist das besser, denn nur die Anfragen für das AD gehen auch direkt dahin, alles andere läuft direkt in's WAN.

JeGr · Mar 17, 2015, 8:37 AM

Da sehe ich für uns auch keine Vorteile.

Ich ebensowenig.

In einem anderen DNS, mir fällt grad der Name partout nicht ein, kein Windows, kann ich die DCs einfach als schreibberechtigt für die Zone eintragen und die schreiben selbst ihre Records rein.

Wenn der eigene DNS (sprich der DC) eh seine eigenen Einträge in das DNS einträgt, kann er doch gleich selbst DNS machen. Und da Windows AD inzwischen ziemliches Mischmasch aus wirklichen DNS Einträgen wie A, AAAA, SRV und PTRs sowie eigentlich LDAP Funktionalität ist, würde ich persönlich den Teufel tun und das woanders als in den Windows DNS reinzublasen. Die Chance, dass Windows da irgendwas nur halbgar anlegt und hinterher wieder Probleme auftreten wäre mir viel zu groß. :)

Ich habe das bislang immer ähnlich wie Bitboy0 gehandhabt. Die Clients bekommen als DNS ein oder zwei externe Hosts gepusht (ggf. die pfSense selbst und den Windows AD) und die lokale Domäne wird auf der pfSense eingetragen, damit Requests dazu immer beim DC landen. So hat man im Fall des Ausfalls des DCs nur mit der lokale Domain ein Problem, aber Internet an sich sollte noch laufen.

tpf · Mar 22, 2015, 1:24 PM

Ich habe seit Jahren den DNS für Windows-DCs in einen QIP ausgelagert und das funktioniert bestens. Der Vorteil liegt auf der Hand, ich muss nämlich einen DNS weniger pflegen. Die DCs schreiben einfach alles in den QIP-DNS rein und gut ist.

Das AD ist organisationsweit über den Haupt-DNS auflösbar.

Ich finds super praktisch.

Guest · Mar 29, 2015, 4:23 AM

Wenn die pfSense "verreckt" hat das gesamte LAN auch gleich nichts mehr zu lachen,
wenn aber die MS Server selbst den DNS Dienst erledigen ist wenigstens noch das LAN
funktionsfähig und es kann intern weiter gearbeitet werden. Es sein denn die pfSense
muss das Routing des LANs auch mit erledigen.

JeGr · Mar 30, 2015, 8:05 AM

Da hast du recht, Frank, allerdings: Wenn LAN->WAN dann so kritisch ist (mal von DNS abgesehen), dass bei Ausfall Internet alle die Panik bekommen ;) dann ist es eh sinnvoller, gleich nen pfSense CARP Cluster zu bauen :)
Ändert aber natürlich nichts an deiner Aussage, dass es durchaus Sinn macht / machen kann, den DNS auf dem AD Server zu belassen. Kann man mit dem DNS Forwarder/Resolver auf der pfSense aber bestens ergänzen und dort bspw. die lokale Domain auf den AD umleiten und den Rest dann via Cache und Forwarder raus ins Netz schicken/zwischenpuffern.

Grüße
Jens

Guest · Mar 30, 2015, 10:58 AM

dann ist es eh sinnvoller, gleich nen pfSense CARP Cluster zu bauen

Wenn man irgend wann active/active was realisieren kann, rückt das schon eher in
meinen Fokus, also arpbalance CARP & pfSync, ansonsten eher nicht.

JeGr · Mar 30, 2015, 11:49 AM

Das war auch eher auf das "wenn die pfSense ganz den Löffel abgibt" Satz ergänzt. Wenn die Außenanbindung/Internet wichtig genug ist, mach ich die HA, auch wenns active/passive ist. Das was ich mit pfSense spare reicht da mehr als genug um 2 kleine Kisten zu kaufen, anstatt 2x <grosses label="" einfügen="">:)</grosses>

Guest · Mar 30, 2015, 1:41 PM

@JeGr:

Das war auch eher auf das "wenn die pfSense ganz den Löffel abgibt" Satz ergänzt. Wenn die Außenanbindung/Internet wichtig genug ist, mach ich die HA, auch wenns active/passive ist. Das was ich mit pfSense spare reicht da mehr als genug um 2 kleine Kisten zu kaufen, anstatt 2x <grosses label="" einfügen="">:)</grosses>

Ich wusste gar nicht das OpenBSD jetzt schon zu den "Big 5" gehört.
Vielleicht wenn man auch Tilera Hardware setzt, aber fände ich auch nicht schlecht.

jahonix · Mar 30, 2015, 1:51 PM

@BlueKobold:

Ich wusste gar nicht das OpenBSD …

Korrigiere mal in: "Ich wusste gar nicht**, dass FreeBSD** …", solltest Du von pfSense sprechen.

Guest · Mar 30, 2015, 2:12 PM

@jahonix:

@BlueKobold:

Ich wusste gar nicht das OpenBSD …

Korrigiere mal in: "Ich wusste gar nicht**, dass FreeBSD** …", solltest Du von pfSense sprechen.

Nein ich sprach von OpenBSD in Bezug auf das Arpbalance Verbindung mit CARP.

JeGr · Mar 30, 2015, 2:55 PM

Und du redest die ganze Zeit an dem vorbei was ich schreibe ;)
Was ich sag(t)e ist, dass - sobald die Anbindung wichtig genug ist, dass sie nicht down sein soll, es den meisten Entscheidern völlig egal ist, ob das active/passive oder active/active ist, hauptsache es ist HA - hochverfügbar. Natürlich hängt da noch die Zuleitung dran, aber die ist nicht in der Hoheit des Admins/der Firma, da kann man also durchaus den ISP gängeln für. Aber wenn der Border Gateway absäuft steht der Admin/Netzwerker/whoever ziemlich dumm da.

Und wenn ich mir dann irgendeine HA Lösung von Cisco, Juniper oder wasauchimmer hole, nur weil die Entscheider da tolle Labels, große Marketingaktionen und dicke Eier sehen, lege ich mehr hin, als 2 potente Kisten (immer noch völlig egal ob eine passiv ist oder nicht) plus pfSense Support einzukaufen. So passiert mehrfach letztes Jahr bei unseren Kunden. Mehrere tausend Euro gespart, weil die entsprechende <label>Lösung teurer gewesen wäre und man gemerkt hat - hey das geht auch anders/besser.

Damit aber genug OT von mir, hier gehts trotzdem um DNS :)</label>