DNS Resolver - Host Einträge greifen nicht
-
@the-other said in DNS Resolver - Host Einträge greifen nicht:
KEA ist noch nicht so ganz fertig
Das mag gut sein. Ich bin aber erst vor knapp zwei Monaten von einer anderen Firewall (IPFire) zu pfsense gewechselt und da ich dann sowieso alles von Hand neu aufsetzen musste habe ich gleich KEA genommen statt ISC DHCP-Server der nun mal eben Deprecated ist und daher so oder so bald ersetzt werden muss.
Das lag für mich näher, da ich sowieso bereits seit gut einem Jahr KEA in einer KVM (Debian) genutzt hatte, statt des in IPFire integrierten DHCP-Servers.
-
@the-other said in DNS Resolver - Host Einträge greifen nicht:
ISC DHCP
Hab auf ISC DHCP gewechselt und die DHCP Option gesetzt.
Das Klappt wunderbar mit den Unifi-Geräten, doch die Frage die noch immer offen ist,wie kann man Host (A) Einträge im DNS Resolver setzen, die dann auch von den Clients genutzt werden können ?
Hat jemand eine Idee ?
-
@KaschiFL said in DNS Resolver - Host Einträge greifen nicht:
wie kann man Host (A) Einträge im DNS Resolver setzen, die dann auch von den Clients genutzt werden können ?
Hat jemand eine Idee ?
Wäre nicht Firewall / Aliases / IP bzw. URLs eine mögliche Lösung?
Oder auch:
Services / DNS Resolver / General Settings - Host Overrides
-
@eagle61 Nope.
Wenn die Clients die pfSense als DNS-Server benutzen, dann geht das automatisch. Wenn sie was anderes nutzen, dann geht das gar nicht.
-
Mit Services / DNS Resolver / General Settings - Host Overrides
konnte ich z.B. erreichen, dass eine älter FritzBox im LAN der pfsense weiterhin als fritz.box erreichbar ist, um sie bei Bedarf mit Roger-Router zum Versenden von Faxen nutzen zu können
-
@eagle61 said in DNS Resolver - Host Einträge greifen nicht:
Mein Nope galt für vor dem Edit.
Du kannst auch einen Domain Override für fritz.box machen, dann können sämtliche fritz.box-Adressen aufgelöst werden, nicht nur die der Fritzbox selbst. -
Host Overrides scheint nur bei IPv4 möglich zu sein.
Die Firewall Aliases auch bei IPv6-Adressen an einem Anschluss mit täglich wechselnden IPv6-Präfix, indem man auf einen FQDN verweist. In einem Fall einen Server der eine Nextcloud beherrbergt (nextcloud.XXXXXX.XXXXXX.de) und selbst dafür sorgt dass seine IPv6-Adresse übergeordneten DNS-Servern bekannt ist.Daher nutze ich mal dies, mal das. Je nachdem was ich brauche.
-
@KaschiFL
Den Host Override hast du nun schon gesetzt?Dann noch in den DNS Resolver > General Settings im Feld "Custom options"
server: private-domain: "unifi"
eintragen. "server" ist der Konfig-Bereich. Solltest du die Zeile in den Custom Optrions bereits haben, nur die zweite Zeile darunter setzen.
-
Gesetzt habe ich alles:
Aber ein Ping auf unifi von einem Client aus ergibt , das der Name nicht aufgelöst werden kann.
Auf der pfsense funktioniert es:
-
Unter Host Overrides hast du aber keinen Hostname eingetragen, sondern einen Domainame (Parent domain of the host). Ein FQDN besteht aus Hostname.Domainame.
Du willst aber den Hostname anpingen. Der Domainame würde dann vom pfsense DNS-Resolver ergänzt.
-
Zudem: Warum antwortet bei Dir unter Timings - Name server Ein weiterer lokaler Nameserver (192.168.11.1))?
Bei mir kommt dann nach 127.0.0.1 gleich die Antworten der von mir unter System / General Setup und DNS Server Settings eingetragenen externen Namserver (bei mir die von digitale-gesellschaft.ch).
Welcher Nameserver verbirgt sich hinter 192.168.11.1? Bettreibst DU noch eine Lĺokalen übergeordneten Nameserver (z.B. weil die pfsense hinter einer FritzBox hängt)?
-
@KaschiFL
Nutzt der Client überhaupt die pfSense zur Namensauflösung?Kann er andere Namen auflösen?
Was genau liefert nslookup oder dig?
-
@eagle61
Ja, die pfsense hängt hinter der Fritzbox. -
@viragomann
Die Namensauflösung läuft über die netgate und eine Abfrage mit Angabe des Servers bringt das gleiche Ergebnis:
externe Domains werden aufgelöst:$ nslookup test.de 192.168.169.1
Server: 192.168.169.1
Address: 192.168.169.1#53Non-authoritative answer:
Name: test.de
Address: 128.65.209.28die lokal eigetragene nicht:
$ nslookup unifi 192.168.169.1
Server: 192.168.169.1
Address: 192.168.169.1#53** server can't find unifi: NXDOMAIN
-
@KaschiFL Also wenn ich den Thread durchrolle kann man es sich auch aktiv maximal schwer machen.
-
KEA ist nicht fertig und hat in deiner aktuell eingesetzten Version noch ALPHA Stadium. Da wechselt man nicht drauf nur "weils neuer ist". Das ist noch nichtmal in der 24.08 die angekündigt ist jetzt vollständig 100% kompatibel, wobei es dort dann wenigstens für die meisten wohl passen wird, gerade mit der neuen Integration ins DNS. Aber bisher: NEIN.
-
Den Unifi Namen kann man an Unifi Geräte am Besten per DHCP übergeben und macht das auch so. Mit ISC DHCP. Der nicht automagisch kaputt geht und an Altersschwäche stirbt, nur weil jetzt ein neuer KEA da ist ;)
-
DNS funktioniert nicht nur mit Namen. Kannst du vielleicht in deine /etc/hosts eintragen, aber einfach nur Hostnamen pushen ist quatsch und nicht DNS. DNS hat mindestens eine TLD (sowas wie .home.arpa, .de, .com, ...) oder Domain und den Hostnamen Part. Nur weil du den im Normalfall vielleicht nicht siehst und den Windows weg ignoriert und automatisch die Domain anhängt, die per DHCP gepusht wurde, heißt das nicht, dass man den ignorieren kann. Darum setzt man am Besten das Netz mit ner sauberen Domain auf. Egal was man macht, irgendeine minimum domain gibt es immer. Auch wenn du keine vergibst, hängt Windows dann sowas wie .workgroup oder .local intern automatisch an. Suffixliste und Co. definieren das.
-
wenn man via DHCP sauber eine DHCP Domain pusht (bspw. home.arpa) oder bei statischen IPs das den Geräten beibringt, ist das Unifi Ding noch weniger ein Problem, dann legt man dafür einfach einen unifi (hostname) home.arpa (domain) Eintrag im Override an und packt ggf. noch ein unifi.localdomain und unifi.workgroup dazu für den Fall der Fälle und hat bei den Geräten dann den Namen im Sack. Aber DHCP ist eh die bessere Option.
Für DHCP gibts auch diese lustige ältere Seite, die das Hex-Krams auswürfelt:
https://tcpip.wtf/en/unifi-l3-adoption-with-dhcp-option-43-on-pfsense-mikrotik-and-others.htm
Aber genau deshalb gibts mit nslookup und Co Probleme, denn nslookup oder dig oder host commands nutzen den normalen DNS Weg und der setzt eine Domain voraus. Da wird also im Normalfall der Domainsuffix vom DHCP automatisch angehängt und da wird er wohl aktuell bei dem Chaos nichts finden. Einfach unifi als Domain zu deklarieren ist nicht. Das wird als Hostname abgefragt, nicht als Domain, das würde auch gar keinen Sinn machen und Unifi in Enterprise netzen hochkant rauskegeln.
Ohne DHCP finden meine Kisten meinen unifi Eintrag ebenfalls ohne Probleme wenn sauber eine Default Domain ausgerollt wird (DHCP) und konfiguriert ist, dann ist auch die Abfrage der Kurzschreibweise "unifi" alleine kein Problem, da das dann automatisch auf den FQDN ergänzt wird.
Windows vergeigt es übrigens gern bei Kurznamen und zeigt die manchmal nicht an bzw. hängt sein Domain Suffix nicht an. Kurz DHCP refresht - geht wieder. Manuell das Suffix konfigurieren bringt es auch zum Fliegen, aber mitunter ignoriert es der Mumpitz einfach. Das ist dann der typische Fall im Support bei uns "nach dem Neustart gings wieder". Aber hey, Windows ignoriert ja auch NTP via DHCP, wundert also nicht, dass da nicht alles sauber läuft ;) Macht es nur dann hin und wieder schlecht fürs Debugging.
Cheers
-
-
Hier geht das, einfach die Domain als Suchdomäne an die Clients per DHCP ausrollen und schon lässt sich der statische DNS Eintrag immer sauber auflösen. Egal ob als FQDN oder Kurzname, was dann über die Suchdomäne zum FQDN vervollständig wird.
Daher auch bei der DNS Auflösung am Ende, wenn man FQDNs sucht immer einen . machen.
Die Option 43 ist echt simpel, in dem Link von Jens ist ja wirklich alles erklärt.
Dann noch im Controller den FQDN für den Controller hinterlegen und schon finden die immer wieder heim.