OPNsense Forum
International Forums => German - Deutsch => Topic started by: wurmloch on May 12, 2021, 10:29:12 pm
-
Moin Ihr Wissenden,
liefert bei Euch auch ein "DNS Lookup" in der web Oberfläche kein Ergebnis zur Fragen nach Machinen im LAN, wohingegen ein nslookup in der Shell der FW oder auch in der Shell eines Clients im LAN ein korrektes Ergebnis liefern?
Hier sind die Screens als Beweis, mein LAN ist 192.168.20.0/22
DHCP Range ist 192.168.23.150 - 192.168.23.199, aber fast alle Geräte bekommen vom DCHP Service eine fest zugewiesene Adresse.
Ich nutze unbound, Haken sind gesetzt bei:
Register DHCP leases
Register DHCP static mappings
Enable Forwarding Mode
-
Nachtrag:
Nachdem ich den Kram seit gestern Abend nicht angefasst habe, lässt sich nun auf den Clients im LAN ein Maschinenname auch nicht mehr auflösen (das ging gestern noch):
„v1500“ sollte zu 192.168.23.64 aufgelöst werden, es wird aber nxdomain zurückgeliefert.
Woran scheitere ich, dass ich eine funktionierende Konfig. hinbekomme? Eine absolut saubere DNS-Konfiguration im Netz ist für mich die Grundlage, ohne die nichts wirklich verlässlich geht.
Ich würde mich über den einen oder anderen Tipp sehr freuen.
-
Könntest du etwas mehr Details über die Konfiguration posten? Was bekommen Clients als DNS? Wie ist die Firewall konfiguriert? Wie deren DNS Dienst und ggf Forwarder oder Resolver?
Cheers
-
Hallo "old" man,
die Konfig der OPNsense ist (noch) so ziemlich einfach gestrickt.
OPNsense ist GW und DNS (unbound) für dieses Netz
WAN IPv4 kommt per DHCP
LAN IPv4: 192.168.20.1/22 (habe bei Github #4984 gesehen, Zusammenhang?)
IPv6 ist ausgeschaltet.
Im DHCP Service des LAN habe ich nur eine kleine Range definiert, da alle bereits bekannten Geräte eine statische Lease bekommen. Die Lease time ist auf 86400 erhöht. Alles (GW,DNS) verweist auf die OPNsense LAN-IP.
Plugins:
os-wol (installed)
os-rfc2136 (installed)
os-dyndns (misconfigured) (Scheint "normal" zu sein, nutze ich nicht)
Der RFC2136 gibt meine Public IPv4 an meinen "dyn"-Service, was ich später mal für ein VPN nutzen möchte.
Die Domain in meinem Netz (und die aller Geräte FQDN) ist identisch mit diesem public namen, sagen wir, hier heißt die OPNsense "fw.kfm.example.com".
Daher weiß unbound, dass intern gefragt "fw.kfm.example.com" mit 192.168.20.1 zu beantworten ist: Host override Type A gesetzt.
Enable Forwarding Mode ist aktiviert, wie oben beschrieben, als öffentliche DNS habe ich eingetragen:
46.182.19.48, 80.241.218.68, 9.9.9.9
OPNsense 21.1.3_3-amd64
APU mit AMD GX-412TC SOC (4 cores) und 16GB SSD
Es könnte ein zeitlicher Zusammenhang (ein paar Tage) zwischen der "Erweiterung" meines Netzes von /24 auf /22 und den beschriebenen Effekten bestehen, aber so wirklich vorstellen kann ich mir das nicht. Das ist doch überhaupt nichts Ungewöhnliches, was ich da tue?!
Danke, dass Du Dir die Zeit genommen hast (und vielliecht nochmal nimmst) auf mein Posting zu schauen!
LG
-
Kommt bei den Clients eine Default Domain an?
Welche Art Hostnamen ist v1500? Ist das ein Client? Server? Versuchst du Clients mit Namen aufzurufen? Ich versuche noch rauszufinden, was du da mit dem DNS eigentlich abfragen möchtest. Zudem: Wenn du das Netz aufgeblasen hast auf /22 kann es sein, dass dein Unbound noch ACLs hat die auf /24 sind oder dass eben dein Client nicht im alten /24er Bereich ist und du die ACLs da anpassen musst?
Da bräuchte man ein wenig mehr Input beim DNS Resolver und dem Clientverhalten :)
-
Moin Jens,
natürlich, Du hast vollkommen recht (und meine Kristallkugel, die ich Dir evtl. hätte leihen können, ist immer noch zur Reparatur).
Zunächst gibt es ein Update:
Alle Clients im LAN lösen DNS via OPNsense nun korrekt auf! Das hat sich definitiv "von alleine" zum Positiven verändert. Ich habe in der Zwischenzeit nicht an meinem Problem gearbeitet, gestern einzig ein update von OPNsense 21.1.3_3-amd64 auf OPNsense 21.1.5-amd64 gemacht.
Die eigentliche Auffälligkeit, dass ich in der OPNsense GUI keine erfolgreichen DNS Abfragen hinbekomme, hat sich nicht verändert.
WAN / Internet
.
| Cable-Provider
|
.----'----.
| Modem | (CableModem)
'----.----'
|
WAN | Fixed public IPv4
|
.----------. Name: fw.kfm.example.com
| OPNsense | Services: dhcpd, unbound, ntp, wol, rfc2136
'----.-----'
|
|
LAN | 192.168.20.1/22
|
.------------.
| LAN-Switch |
'----.-------'
|
|
|
---------------- Clients
Alle Geräte sind Arbeitsplätze im LAN und alle sind auch DHCP-Clients und bekommen via MAC eine feste IPv4.
Screenshots zu der Auffälligkeit:
nslookup01.png: Die Anfrage nach "ap02" wird von 127.0.0.1 nicht beantwortet.
nslookup02.png: Die Anfrage nach "ap02.kfm.example.com" wird von meinem rfc2136-Server im Internet ("ns.example.com") empfangen, kann aber (logischerweise) nicht beantwortet werden, da dieser die Geräte in meinem LAN nicht kennt. Hier hätte ich erwartet, dass 127.0.0.1 vorher antwortet.
nslookup03.png und nslookup04.png: Sieh an, die "reverse" Anfragen werden von unbound beantwortet!
Einstellungen OPNsense Settings: General
Hostname fw
Domain kfm.example.com (verschleiert)
Time zone Europe/Berlin
Language English
Theme opnsense
Prefer IPv4 over IPv6 [ ] Prefer to use IPv4 even if IPv6 is available
DNS Servers 46.182.19.48 (no gateway)
80.241.218.68 (no gateway)
9.9.9.9 (no gateway)
DNS server options [ ] Allow DNS server list to be overridden by DHCP/PPP on WAN
[ ] Do not use the local DNS service as a nameserver for this system
Gateway switching [ ] Allow default gateway switching
Einstellungen DHCPD:
Subnet 192.168.20.0
Subnet mask 255.255.252.0
Available range 192.168.20.1 - 192.168.23.254
Range from 192.168.23.150 to 192.168.23.199
DNS servers <leer>
Domain name <leer>
Default lease time (seconds) 86400
Time format change [X] Change DHCP display lease time from UTC to local time.
DHCP Static Mappings for this interface:
xx:xx:xx:xx:xx:xx 192.168.20.241 ap02 (W-LAN Accesspoint (nicht router))
xx:xx:xx:xx:xx:xx 192.168.22.20 delldeb (Client mit debian)
xx:xx:xx:xx:xx:xx 192.168.22.50 FA-HB-KFM-W530 (Client mit Windows 10)
xx:xx:xx:xx:xx:xx 192.168.23.60 FA-HB-KFM-T430s (Client mit GhostBSD)
xx:xx:xx:xx:xx:xx 192.168.23.64 v1500 (Client mit FreeBSD 13.0)
Einstellungen unbound DNS:
Enable [X] Enable Unbound
Listen Port 53
Network Interfaces All
DNSSEC [X] Enable DNSSEC Support
DNS64 [ ] Enable DNS64 Support
DHCP Registration [X] Register DHCP leases
DHCP Domain Override <leer>
DHCP Static Mappings [X] Register DHCP static mappings
IPv6 Link-local [X] Register IPv6 link-local addresses
TXT Comment Support [ ] Create corresponding TXT records
DNS Query Forwarding [X] Enable Forwarding Mode
Local Zone Type transparent
Einstellungen unbound DNS: Overrides
Host | Domain | Type | Value | Description
fw | kfm.example.com | A | 192.168.20.1 | Firewall
pfs | kfm.example.com | A | Alias for fw.kfm.example.com | Alter Name historisch
-
Test auf der Konsole der OPNsense:
root@fw:~ # nslookup ap02
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: ap02.kfm.example.com
Address: 192.168.20.241
oder auch
root@fw:~ # host ap02
ap02.kfm.example.com has address 192.168.20.241
root@fw:~ # nslookup 192.168.20.241
241.20.168.192.in-addr.arpa name = ap02.kfm.example.com.
root@fw:~ # nslookup v1500
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: v1500.kfm.example.com
Address: 192.168.23.64
Hier noch ein paar Bestätigungen, dass DNS Anfragen von allen Clients zur OPNsense funtkionieren:
Test auf BSD-Notebook:
root@FA-HB-KFM-T430s /u/h/kfm# cat /etc/resolv.conf
# Generated by resolvconf
domain kfm.example.com
nameserver 192.168.20.1
root@FA-HB-KFM-T430s /u/h/kfm# host ap02
ap02.kfm.example.com has address 192.168.20.241
root@FA-HB-KFM-T430s /u/h/kfm# host 192.168.20.241
241.20.168.192.in-addr.arpa domain name pointer ap02.kfm.example.com
Test auf Windows 10 Notebook:
Windows-IP-Konfiguration
Hostname . . . . . . . . . . . . : FA-HB-KFM-W530
Primäres DNS-Suffix . . . . . . . :
Knotentyp . . . . . . . . . . . . : Hybrid
IP-Routing aktiviert . . . . . . : Nein
WINS-Proxy aktiviert . . . . . . : Nein
DNS-Suffixsuchliste . . . . . . . : kfm.example.com
Ethernet-Adapter Ethernet:
Verbindungsspezifisches DNS-Suffix: kfm.example.com
Beschreibung. . . . . . . . . . . : Intel(R) 82579LM Gigabit Network Connection
Physische Adresse . . . . . . . . : xx-xx-xx-xx-xx-xx
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::3414:b658:fb46:e7e1%6(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.22.50(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.252.0
Lease erhalten. . . . . . . . . . : Donnerstag, 20. Mai 2021 14:44:53
Lease läuft ab. . . . . . . . . . : Freitag, 21. Mai 2021 14:44:52
Standardgateway . . . . . . . . . : 192.168.20.1
DHCP-Server . . . . . . . . . . . : 192.168.20.1
DHCPv6-IAID . . . . . . . . . . . : 55897717
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-25-B1-D7-81-xx-xx-xx-xx-xx-xx
DNS-Server . . . . . . . . . . . : 192.168.20.1
NetBIOS über TCP/IP . . . . . . . : Aktiviert
KFM@FA-HB-KFM-W530 C:\Users\KFM
$ nslookup ap02
Server: fw.kfm.example.com
Address: 192.168.20.1
Name: ap02.kfm.example.com
Address: 192.168.20.241
KFM@FA-HB-KFM-W530 C:\Users\KFM
$ nslookup 192.168.20.241
Server: fw.kfm.example.com
Address: 192.168.20.1
Name: ap02.kfm.example.com
Address: 192.168.20.241
KFM@FA-HB-KFM-W530 C:\Users\KFM
$ nslookup v1500
Server: fw.kfm.example.com
Address: 192.168.20.1
Name: v1500.kfm.example.com
Address: 192.168.23.64
KFM@FA-HB-KFM-W530 C:\Users\KFM
$ nslookup 192.168.23.64
Server: fw.kfm.example.com
Address: 192.168.20.1
Name: v1500.kfm.example.com
Address: 192.168.23.64
-
Kurze Nachfrage: ap02 bspw. wird ja nicht aufgelöst laut deinen Shots. Aber wo hast du ap02 überhaupt eingetragen? Nur via DHCP Static Mapping? Ist in Unbound auch die Registrierung von static mappings an?
Zudem sehe ich oben, dass du beim DHCPD keine default domain angegeben hast. Dann kann er "ap02" auch schlecht auflösen, denn ohne default Domain weiß er nur "ap02" - aber nicht dass das bspw. ap02.example.com sein sollte. Du solltest ihm da schon auf dem entsprechenden Interface Bein auch die korrekte default Domain mitgeben, damit Unbound nicht nur den Namen, sondern die FQDN via static mapping reserviert.
Ansonsten kannst du es auch manuell testen indem du bspw. nen Host Override für ap02 anlegst und testest, ob dann unbound korrekt den Namen auflöst. Wenn er das tut, dann klemmts an der DHCP Static Reservation in Unbound bzw. dem Fehlen der korrekten Domain.
Cheers
-
Moin, danke für Deine Zeit!
Kurze Nachfrage: ap02 bspw. wird ja nicht aufgelöst laut deinen Shots. Aber wo hast du ap02 überhaupt eingetragen? Nur via DHCP Static Mapping?
Ja, genau. Alle Geräte bekommen ihre IP durch ein static mapping, auch ap02.
Hier ist ein Auszug aus den static mapping des DHCPD auf dem LAN interface:
xx:xx:xx:xx:xx:xx 192.168.20.241 ap02 (W-LAN Accesspoint (nicht router))
xx:xx:xx:xx:xx:xx 192.168.22.20 delldeb (Client mit debian)
xx:xx:xx:xx:xx:xx 192.168.22.50 FA-HB-KFM-W530 (Client mit Windows 10)
xx:xx:xx:xx:xx:xx 192.168.23.60 FA-HB-KFM-T430s (Client mit GhostBSD)
xx:xx:xx:xx:xx:xx 192.168.23.64 v1500 (Client mit FreeBSD 13.0)
Ist in Unbound auch die Registrierung von static mappings an?
Ja, ist in den Einstellungen von unbound angekreuzt.
Zudem sehe ich oben, dass du beim DHCPD keine default domain angegeben hast. Dann kann er "ap02" auch schlecht auflösen, denn ohne default Domain weiß er nur "ap02" - aber nicht dass das bspw. ap02.example.com sein sollte. Du solltest ihm da schon auf dem entsprechenden Interface Bein auch die korrekte default Domain mitgeben, damit Unbound nicht nur den Namen, sondern die FQDN via static mapping reserviert.
Ah, das wäre ein Erkenntnisgewinn. Alle Clients im LAN bekommen per DHCPD die (Such)domain der OPNsense (example.com) auch von der OPNsense mitgeteilt, obwohl das in den DHCPD Einstellungen nicht explizit angegeben ist. Das sieht man zB in dem automatisch erzeugten resolv.conf des BSD Clients. Ein "host ap02" wird dann zur Antwort:
root@FA-HB-KFM-T430s /u/h/kfm# host ap02
ap02.kfm.example.com has address 192.168.20.241
Meine Domain wir nur in den generellen Einstellungen gesetzt:
Einstellungen OPNsense Settings: General
Hostname fw
Domain kfm.example.com (verschleiert)
Aber die OPNsense selber beantwortet die Anfrage nach ap02 nicht, genauer gesagt, unbound arbeitet bei Anfragen in der GUI nicht auf 127.0.0.1 (localhost).
Wenn ich mich allerdings per SSH an der OPNsense anmelde und in der Shell die Anfrage ohne FQDN angebe, bekomme ich von der OPNsense ja eine korrekte Antwort. Hier "weiß" die OPNsense um die zu ergänzende domain:
root@fw:~ # host ap02
ap02.kfm.example.com has address 192.168.20.241
Ansonsten kannst du es auch manuell testen indem du bspw. nen Host Override für ap02 anlegst und testest, ob dann unbound korrekt den Namen auflöst. Wenn er das tut, dann klemmts an der DHCP Static Reservation in Unbound bzw. dem Fehlen der korrekten Domain.
Das teste ich sofort und berichte!
TNX again!
Uwe
-
Dass es lokal mit einem "host" funktioniert ist nicht so verwunderlich, da hier primär der interne Resolver befragt wird und der gern die Antwort liefert. Dass die Clients automatisch die Domain der Sense aus den general setup settings bekommen ist ggf. auch gewünscht, ich kann mir aber vorstellen, dass die DHCP Registrierung eben dann nicht automagisch annimmt, welche Domain er anhängen soll, wenn im DHCP keine angegeben ist. Daher würde ich zuerst mal diesen Punkt testen und beim DHCP die Default Domain mit angeben und pushen. Das sollte für die Clients keine Änderung geben, aber ggf. klappt dann schon die Auflösung der static mappings sauber.
-
Daher würde ich zuerst mal diesen Punkt testen und beim DHCP die Default Domain mit angeben und pushen. Das sollte für die Clients keine Änderung geben, aber ggf. klappt dann schon die Auflösung der static mappings sauber.
Also, der Test mit dem host override hat keine Verbesserung gebracht, siehe Bild. Jetzt trage ich meine Domain in die DHCPD Konfig explizit ein und werde wieder berichten.
Erstaunlich ist ja, dass 127.0.0.1 lange 33 msec gefragt wurde.
Danke!
-
Die GUI sagt bei den DHCPD Einstellungen:
Domain name
The default is to use the domain name of this system as the default domain name provided by DHCP. You may specify an alternate domain name here.Deshalb hatte ich dort nichts eingetragen.
So, meine Domain ist eingetragen und zur Sicherheit wurde der dhcpd neu gestartet. -> Keine Verbesserung
Nun zusätzlich auch hier
Domain search list
The DHCP server can optionally provide a domain search list. Use the semicolon character as separator.
Eingetragen und service neu gestartet. -> Wieder keine Veränderung. Ich bekomme in der GUI keine Antwort auf "ap02".
Da ist bei der Konfig irgendetwas im Argen und ich ärgere mich, dass ich keine Sicherung der Konfig vor der Änderung des LAN von /24 auf /22 gemacht hatte. Dann könnte ich ohne so viel Tippen und Klicken zurückgehen und zumindest diesem Verdacht nachgehen.
Jens, ich werde eine zweite Box aufsetzen und eine identische Konfig mit LAN /24 an den Start bringen. Dass muss ich dann außerhalb der (Homeoffice) Arbeitszeit machen, sonst springt mir hier jemand ins Gesicht ;)
Somit habe ich einen clean install, das ist, so glaube ich, zielführender. Oder was meinst Du?
Danke und LG, Uwe
-
ich werde eine zweite Box aufsetzen und eine identische Konfig mit LAN /24 an den Start bringen.
Das habe ich gemacht:
WAN: DHCP inkl. Übermittlung des öffentlichen DNS Servers
LAN: 192.168.200.1/24
Name der Firewall: opns2
Domain der Firewall: example.corp
DHCPD range auf LAN: 192.168.200.200-192.168.200.249
In unbound 2 Haken gesetzt:
DHCP Registration [X] Register DHCP leases
DHCP Static Mappings [X] Register DHCP static mappings
Notebook ins LAN gehängt und per DHCP Adresse und auch domain suffix empfangen: OK
nslookup auf dem Notebook:
KFM@FA-HB-KFM-W530 C:\Users\KFM
$ nslookup FA-HB-KFM-W530
Server: opns2.example.corp
Address: 192.168.200.1
Name: FA-HB-KFM-W530.example.corp
Address: 192.168.200.200OK
host auf der console der opns2:
root@opns2:~ # host FA-HB-KFM-W530
FA-HB-KFM-W530.example.corp has address 192.168.200.200OK
In der GUI (Diagnostics:DNS Lookup) bekomme ich auf die Frage nach "FA-HB-KFM-W530" weiterhin keine Antwort, aber die Frage nach "FA-HB-KFM-W530.example.corp" wird mit "192.168.200.200" korrekt beantwortet.
Lesson learned:
Die GUI (Diagnostics:DNS Lookup) kann Fragen nach dem Computernamen ohne domain schlicht nicht beantworten, wohingegen es auf der Console und bei den LAN-Clients funktioniert. Das hat auch nichts mit der Netzmaske zu tun.
Die GUI (Diagnostics:DNS Lookup) kann Fragen nach FQDN von Computern im LAN nur dann beantworten, wenn die domain keine Öffentliche ist, denn dann wird auf den entsprechenden öffentlichen DNS weitergeleitet (was ja auch korrekt ist!). In meinen obigen Versuchen bin ich ja mit einer öffentlichen domain meines dyn Dienstes am Start gewesen.
Hier kann zumindest die Frage nach "FA-HB-KFM-W530.example.corp" korrekt beantwortet werden. Ich konnte der OPNsense mit keinerlei dhcpd-Einstellungen beibiegen, in der GUI Anfragen ohne domain-Anteil aufzulösen (s.o.). Ist ja nicht schlimm, muss man also einfach nur wissen und akzeptieren.
Soweit zu unbound, jetzt versuche ich das alles mal mit bind ;D
-
> Die GUI (Diagnostics:DNS Lookup) kann Fragen nach FQDN von Computern im LAN nur dann beantworten, wenn die domain keine Öffentliche ist, denn dann wird auf den entsprechenden öffentlichen DNS weitergeleitet (was ja auch korrekt ist!). In meinen obigen Versuchen bin ich ja mit einer öffentlichen domain meines dyn Dienstes am Start gewesen.
DAS kann aber auch ganz natürlich damit zusammenhängen, wie dein DNS in General Setup konfiguriert ist. Wenn du den Resolver (Unbound) UND Forwarder im General Setup eingetragen hast, dann gibt es bei Abfrage an eine öffentliche Domain natürlich ein Problem: die offiziellen Nameserver im Netz sagen dann nämlich ggf. was anderes als dein lokaler Unbound der ja dann "mehr" weiß. Daher nimmt man gewöhnlich keine Domain, die 1:1 so im public Internet ebenfalls genutzt wird, sondern meist ne lokale Subdomain (lan/home/corp.example.com oder gleich RFC konform <name>.home.arpa). Da hat u.U. auch unbound dann einen DNS Poisoning Schutz drin, dass bei Antworten die zwischen lokale und public unterschiedlich sind, KEINE Antwort gegeben wird, weil man davon ausgeht, dass vllt. jemand den Cache vergiftet hat/vergiften will. Darum die Domains lokal/Internet nach Möglichkeit trennen.
Bind ist ja ein voller DNS Server und kein Resolver (nur ein Teil davon ist fürs Resolving zuständig), daher verhält sich Bind da nochmals anders. :)
> Hier kann zumindest die Frage nach "FA-HB-KFM-W530.example.corp" korrekt beantwortet werden. Ich konnte der OPNsense mit keinerlei dhcpd-Einstellungen beibiegen, in der GUI Anfragen ohne domain-Anteil aufzulösen (s.o.). Ist ja nicht schlimm, muss man also einfach nur wissen und akzeptieren.
Könnte höchstens sein - vielleicht kannst du nachschauen - dass in der lokalen Sense /etc/resolv.conf dann kein Search eingetragen ist? Eventuell würde es dann auch in der UI gehen, da muss ich aber gerade passen :)
Cheers :)
-
Könnte höchstens sein - vielleicht kannst du nachschauen - dass in der lokalen Sense /etc/resolv.conf dann kein Search eingetragen ist? Eventuell würde es dann auch in der UI gehen, da muss ich aber gerade passen :)
Au weia, da hätte ich doch als erstes schauen müssen!
So sah's aus:
root@fw:~ # cat /etc/resolv.conf
domain kfm.example.com
nameserver 127.0.0.1
nameserver 46.182.19.48
nameserver 80.241.218.68
nameserver 9.9.9.9
So sieht's jetzt aus:
root@fw:~ # cat /etc/resolv.conf
domain kfm.example.com
search kfm.example.com
nameserver 127.0.0.1
nameserver 46.182.19.48
nameserver 80.241.218.68
nameserver 9.9.9.9
Neustart des unbound Dienst -> Keine Veränderung.
Selbst das "host override"
"fw.kfm.example.com A 192.168.20.1"
wird für die GUI Abfrage immer noch nicht genutzt, am Client wird korrekt auf LAN IP aufgelöst.
Jens, so großen Dank für den Austausch mit Dir, I owe you a bottle of Jever.
Uwe
-
Kein Problem, mich wundert das genauso wie dich. In deinem neuen Beispiel mit dem Search kfm.example.com müsste die Kiste, wenn sie den local resolver nutzt, eigentlich sofort bei "nur Namen" den Search Path anhängen. Warum das die GUI nicht macht - seltsam.
Auf der Shell müsste ein "host fw" bspw. sofort in "fw.kfm.example.com" aufgelöst werden. Klar, das gibt dann ggf. Konflikte wie oben beschrieben wegen Abweichung public/private IP da auch Nameserver extern angegeben sind und nicht nur der Resolver aber trotzdem sollte es auflösen.
-
(...) da auch Nameserver extern angegeben sind und nicht nur der Resolver aber trotzdem sollte es auflösen
Nur um sicher zu sein. Wenn ich keine vorgelagerten DNS-Server angebe, also "nur" unbound als resolver einsetze, dann werden die root-server gefragt, falls unbound selber keine Antwort geben kann?
So hatte ich das verstanden und wollte meine Anfragen halt gerne auf meine Auswahl von Servern weitergeleitet wissen.
LG
-
Jein. Wenn du keine Forwarder angibst läuft alles über Unbound. Was er lokal oder aus Cache nicht bedienen kann wird dann via Resolver aufgelöst also: erst root Server fragen bzgl. tld, dann den NS der Domain fragen und von dem die Antwort bekommen. Wie ein klassischer DNS Server sein resolving auch macht. Vorteil: es gehen DNS calls dezentral raus und nicht alle Anfragen über den/die gleichen 2 Server die die Antworten kontrollieren :)