Pfsense 2.3.4 / unbound / Domain-Overide (Windows AD)
-
Hi,
i'm quite stumped with unbound and it's domain override in a conjunction with Windows AD / DNS.
I was using aliases on hostnames with local domain for quite some time which "suddenly" failed - pretty sure it was with update on (2.3.4-RELEASE-p1).My internal dns-server is a Windows AD named tuempel with IP 192.168.2.223 and resolves for "test.local". Everything else is forwarded to pfsense with unbound/pfblockerng. Internal resolution is working for external sites and all "host" / "host.test.local" requests.
As said i was using aliases for firewall-purposes like "host1.test.local" and "host2.test.local" may access an external services (basically grouping).
Unfortunatly that fails now.Domain-Override and Hostoverride are both set with not much else configured. (dns3.jpg)
Both are picked up in
# cat /var/unbound/domainoverrides.conf forward-zone: name: "gastzugang.test.local" forward-addr: 192.168.2.223 forward-zone: name: "test.local" forward-addr: 192.168.2.223
Under DNS Lookup it returns for a host Host "orca.test.local" could not be resolved. (also tested with just "orca")
Watching a packet capture there is no outgoing dns-packet on LAN (192.168.2.x) interface.I testet with DNS-Forwarder and also domain override which works flawlessly.
I already searched the forum and google just finding a lot of other people with problems - mostly using domain overrides without a dns-server. But regarding this i found nothing.
I greatly appreciated any help.
Thanks
-
It is a very bad idea to use anything.local for a DNS domain. I know that Microsoft used to recommend it but if you look at their website you will find that .local has quietly vanished (around 10 years ago) I know this because I have had this discussion with many who know better than me but are unable to read documentation 8)
The primary reason for not using .local is it will break Apple Bonjour style browsing - Avahi etc. which uses that domain.
Anyway you have one so you need to work out exactly where the fault is. nslookup on Windows is a fair diagnostic tool but does not compare to "dig". Go here: https://www.isc.org/downloads/ click on the blue download button next to the "stable" branch. Select the Windows link. Extract the .zip file somewhere. That is the full DNS server plus tools but it it is pretty small and you may want to run BIND on Windows anyway 8) Run up a cmd prompt and cd to the directory with the dig program in it. I am assuming you use Windows on your PC. If not then install the bind-tools package or whatever gives you "dig".
What do these return (where $|C:> means either a unix or a Windows command prompt):
$|C:> dig @your_dc_ip host1.test.local A
$|C:> dig @your_pfsense_ip host1.test.local A
Obviously, you put the IP address of each system after the @. This is the same as typing "server w.x.y.z" into nslookup to change the destination of lookups. eg "dig @192.168.2.223 host1.test.local. A"
Post back with any oddities.
-
Many thanks for your reply.
The .local problem is unfortunately not solvable - the AD-Server is a SBS 2011 with attached Exchange 2010 which does not support a Domain rename. It has to be made completely from scratch.
The dig does not show any oddities - every dns-server available (two pfsense in CARP/unbound, one pfsense testbed/dnsmasq) reply with correct
;; ANSWER SECTION: orca.mb-mw.local. 819 IN A 192.168.2.225
The testbed can resolve internally, the two main-pfsense still fail.
-
You can work around .local with SBS with a bit of work - you can treat everything as "external". Hopefully when the system is eventually pensioned off, you will take the opportunity to fix the choice of domain name!
I'm still having trouble working out what you exact problem really is. I suggested two tests in my first post but you have only given the answer from one test.
Am I correct in assuming that the Windows DNS on your SBS server is using unbound as its forwarder and that is where the problem is?
Test 1: dig on PC @SBS_DNS_server
Test2: dig on PC @pfsense_unbound
Test3: nslookup on SBSFor all three tests do the same lookup. Are they all consistent?
Cheers
Jon -
Yes, unbound is the Forwarder for the SBS/AD-Domain. And no, the problem is pfsense itself - it can't resolve domain names of the AD-domain internally. As said - it works with dnsmasq but not with unbound and technically the same settings.
The digs
AD-Domain
dig @192.168.2.223 orca.mb-mw.local A ; <<>> DiG 9.10.6 <<>> @192.168.2.223 orca.mb-mw.local A ; (1 server found) ;; global options: +cmd ;; Got answer: ;; WARNING: .local is reserved for Multicast DNS ;; You are currently testing what happens when an mDNS query is leaked to DNS ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1761 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;orca.mb-mw.local. IN A ;; ANSWER SECTION: orca.mb-mw.local. 1200 IN A 192.168.2.225 ;; Query time: 0 msec ;; SERVER: 192.168.2.223#53(192.168.2.223) ;; WHEN: Fri Sep 01 08:53:09 Mitteleuropõische Sommerzeit 2017 ;; MSG SIZE rcvd: 61
pfsense CARP
dig @192.168.2.202 orca.mb-mw.local A ; <<>> DiG 9.10.6 <<>> @192.168.2.202 orca.mb-mw.local A ; (1 server found) ;; global options: +cmd ;; Got answer: ;; WARNING: .local is reserved for Multicast DNS ;; You are currently testing what happens when an mDNS query is leaked to DNS ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55831 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;orca.mb-mw.local. IN A ;; ANSWER SECTION: orca.mb-mw.local. 819 IN A 192.168.2.225 ;; Query time: 0 msec ;; SERVER: 192.168.2.202#53(192.168.2.202) ;; WHEN: Fri Sep 01 08:53:01 Mitteleuropõische Sommerzeit 2017 ;; MSG SIZE rcvd: 61
nslookup
nslookup orca.mb-mw.local Server: 192.168.2.223 Address: 192.168.2.223#53 Name: orca.mb-mw.local Address: 192.168.2.225