Domain Overrides not working
-
I have a 3x site OpenVPN and almost everying works correctly.
DOMAIN OVERRIDES however, is not.
Site 1 Server
Netgate 8200 v24.03
LAN IP: 192.168.90.1/24
VPN Tunnel Net: 10.99.90.0/24
(This should not be important yet, we will be moving a server here soon)Site 2
Netgate 2100 v24.03
VPN CSO: Provide a default domain name to clients = YES (mcm.local)
VPN CSO: Provide a DNS server list to clients = YES (10.90.1.3)
LAN IP: 10.90.1.1/24
Domain DNS server temporarily resides here: 10.90.1.3Site 3
Netgate 2100 v24.03
VPN CSO: Provide a default domain name to clients = YES (mcm.local)
VPN CSO: Provide a DNS server list to clients = YES (10.90.1.3)
LAN IP: 10.90.2.1/24All clients on all LANs can ping each other, they can all connect to DNS server on pfsense at all 3 sites as well as directly to 10.90.1.3 (DC DNS) over the VPN.
When I create a DOMAIN OVERRIDE in DNS RESOLVER as:
Domain: mcm.local
Lookup Server IP Addr: 10.90.1.3However, this fails from site 2 & site 3 (tested from netgate shell to eliminate external factors from equation)
*** DIRECT TO SITE 2 ***
nslookup - 10.90.1.1 Default Server: pfSense.mcm.arpa Address: 10.90.1.1 > mcm-dc.mcm.local Server: pfSense.mcm.arpa Address: 10.90.1.1 *** pfSense.mcm.arpa can't find mcm-dc.mcm.local: Server failed*** FAILED - Normal recursive DNS lookups work OK ***
*** DIRECT TO SITE 3 ***
nslookup - 10.90.2.1 > mcm-rds.mcm.local Server: 10.90.2.1 Address: 10.90.2.1#53 ** server can't find mcm-rds.mcm.local: SERVFAIL*** FAILED - Normal recursive DNS lookups work OK ***
*** DIRECT TO DC DNS ***
C:\>nslookup - 10.90.1.3 Default Server: UnKnown Address: 10.90.1.3 > mcm-dc.mcm.local Server: UnKnown Address: 10.90.1.3 Name: mcm-dc.mcm.local Address: 10.90.1.3*** SUCCESS ***
When I added a DOMAIN OVERRIDE on the Site 1 netgate 8200 exactly the same:
Domain: mcm.local
Lookup Server IP Addr: 10.90.1.3(It worksed ONCE when querying the Site 1 - but is now not working again!?!?!)
nslookup - 192.168.90.1 > mcm.local Server: 192.168.90.1 Address: 192.168.90.1#53 ** server can't find mcm.local: NXDOMAIN > mcm-rds.mcm.local Server: 192.168.90.1 Address: 192.168.90.1#53 ** server can't find mcm-rds.mcm.local: NXDOMAIN > mcm-dc.mcm.local Server: 192.168.90.1 Address: 192.168.90.1#53 ** server can't find mcm-dc.mcm.local: NXDOMAIN > cisco.com Server: 192.168.90.1 Address: 192.168.90.1#53** Normal DNS queries resolve OK **
Non-authoritative answer: Name: cisco.com Address: 72.163.4.185 Name: cisco.com Address: 2001:420:1101:1::185Debug Logs from Site 3 Unbound - hopefully includes a service restart and multiple mcm.local queries:
please let me know if you would like more logs and from whereJul 1 16:16:01 unbound 60237 [60237:0] debug: close of port 6017 Jul 1 16:16:01 unbound 60237 [60237:0] debug: comm_point_close of 18: event_del Jul 1 16:16:01 unbound 60237 [60237:0] debug: close fd 18 Jul 1 16:16:01 unbound 60237 [60237:0] info: receive_udp on interface: 10.90.2.1 Jul 1 16:16:01 unbound 60237 [60237:0] debug: udp request from ip4 10.90.2.1 port 31488 (len 16) Jul 1 16:16:01 unbound 60237 [60237:0] debug: mesh_run: start Jul 1 16:16:01 unbound 60237 [60237:0] debug: validator[module 0] operate: extstate:module_state_initial event:module_event_new Jul 1 16:16:01 unbound 60237 [60237:0] info: validator operate: query mcm.local. A IN Jul 1 16:16:01 unbound 60237 [60237:0] debug: validator: pass to next module Jul 1 16:16:01 unbound 60237 [60237:0] debug: mesh_run: validator module exit state is module_wait_module Jul 1 16:16:01 unbound 60237 [60237:0] debug: iterator[module 1] operate: extstate:module_state_initial event:module_event_pass Jul 1 16:16:01 unbound 60237 [60237:0] debug: process_request: new external request event Jul 1 16:16:01 unbound 60237 [60237:0] debug: iter_handle processing q with state INIT REQUEST STATE Jul 1 16:16:01 unbound 60237 [60237:0] info: resolving mcm.local. A IN Jul 1 16:16:01 unbound 60237 [60237:0] debug: request has dependency depth of 0 Jul 1 16:16:01 unbound 60237 [60237:0] debug: forwarding request Jul 1 16:16:01 unbound 60237 [60237:0] debug: iter_handle processing q with state QUERY TARGETS STATE Jul 1 16:16:01 unbound 60237 [60237:0] info: processQueryTargets: mcm.local. A IN Jul 1 16:16:01 unbound 60237 [60237:0] debug: processQueryTargets: targetqueries 0, currentqueries 0 sentcount 0 Jul 1 16:16:01 unbound 60237 [60237:0] info: DelegationPoint<MCM.local.>: 0 names (0 missing), 1 addrs (0 result, 1 avail) parentNS Jul 1 16:16:01 unbound 60237 [60237:0] debug: ip4 10.90.1.3 port 53 (len 16) Jul 1 16:16:01 unbound 60237 [60237:0] debug: attempt to get extra 3 targets Jul 1 16:16:01 unbound 60237 [60237:0] debug: rpz: iterator module callback: have_rpz=0 Jul 1 16:16:01 unbound 60237 [60237:0] debug: servselect ip4 10.90.1.3 port 53 (len 16) Jul 1 16:16:01 unbound 60237 [60237:0] debug: rtt=339 Jul 1 16:16:01 unbound 60237 [60237:0] debug: selrtt 339 Jul 1 16:16:01 unbound 60237 [60237:0] info: sending query: mcm.local. A IN Jul 1 16:16:01 unbound 60237 [60237:0] debug: sending to target: <MCM.local.> 10.90.1.3#53 Jul 1 16:16:01 unbound 60237 [60237:0] debug: dnssec status: not expected Jul 1 16:16:01 unbound 60237 [60237:0] debug: mesh_run: iterator module exit state is module_wait_reply Jul 1 16:16:01 unbound 60237 [60237:0] info: mesh_run: end 1 recursion states (1 with reply, 0 detached), 1 waiting replies, 5 recursion replies sent, 0 replies dropped, 0 states jostled out Jul 1 16:16:01 unbound 60237 [60237:0] info: average recursion processing time 0.639163 sec Jul 1 16:16:01 unbound 60237 [60237:0] info: histogram of recursion processing times Jul 1 16:16:01 unbound 60237 [60237:0] info: [25%]=0.55402 median[50%]=0.70268 [75%]=0.85134 Jul 1 16:16:01 unbound 60237 [60237:0] info: lower(secs) upper(secs) recursions Jul 1 16:16:01 unbound 60237 [60237:0] info: 0.065536 0.131072 1 Jul 1 16:16:01 unbound 60237 [60237:0] info: 0.524288 1.000000 4 Jul 1 16:16:01 unbound 60237 [60237:0] info: 0RDd mod1 rep mcm.local. A IN Jul 1 16:16:01 unbound 60237 [60237:0] debug: cache memory msg=54785 rrset=140227 infra=66438 val=45438 Jul 1 16:16:01 unbound 60237 [60237:0] debug: serviced send timer Jul 1 16:16:01 unbound 60237 [60237:0] debug: EDNS lookup known=1 vs=0 Jul 1 16:16:01 unbound 60237 [60237:0] debug: serviced query UDP timeout=339 msec Jul 1 16:16:01 unbound 60237 [60237:0] debug: inserted new pending reply id=aa87 Jul 1 16:16:01 unbound 60237 [60237:0] debug: opened UDP if=0 port=52520 Jul 1 16:16:01 unbound 60237 [60237:0] debug: comm point start listening 15 (-1 msec) Jul 1 16:16:01 unbound 60237 [60237:0] debug: answer cb Jul 1 16:16:01 unbound 60237 [60237:0] debug: Incoming reply id = aa87 Jul 1 16:16:01 unbound 60237 [60237:0] debug: Incoming reply addr = ip4 10.90.1.3 port 53 (len 16) Jul 1 16:16:01 unbound 60237 [60237:0] debug: lookup size is 1 entries Jul 1 16:16:01 unbound 60237 [60237:0] debug: received udp reply. Jul 1 16:16:01 unbound 60237 [60237:0] debug: udp message[54:0] AA8785800001000100000001036D636D056C6F63616C0000010001C00C000100010000025800040A5A01030000290FA0000080000000 Jul 1 16:16:01 unbound 60237 [60237:0] debug: outnet handle udp reply Jul 1 16:16:01 unbound 60237 [60237:0] debug: measured roundtrip at 78 msec Jul 1 16:16:01 unbound 60237 [60237:0] debug: svcd callbacks start Jul 1 16:16:01 unbound 60237 [60237:0] debug: worker svcd callback for qstate 0x6e68c1f3df90 Jul 1 16:16:01 unbound 60237 [60237:0] debug: mesh_run: start Jul 1 16:16:01 unbound 60237 [60237:0] debug: iterator[module 1] operate: extstate:module_wait_reply event:module_event_reply Jul 1 16:16:01 unbound 60237 [60237:0] info: iterator operate: query mcm.local. A IN Jul 1 16:16:01 unbound 60237 [60237:0] debug: process_response: new external response event Jul 1 16:16:01 unbound 60237 [60237:0] info: scrub for MCM.local. NS IN Jul 1 16:16:01 unbound 60237 [60237:0] info: response for mcm.local. A IN Jul 1 16:16:01 unbound 60237 [60237:0] info: reply from <MCM.local.> 10.90.1.3#53 Jul 1 16:16:01 unbound 60237 [60237:0] info: incoming scrubbed packet: ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0 ;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: mcm.local. IN A ;; ANSWER SECTION: mcm.local. 600 IN A 10.90.1.3 ;; AUTHORITY SECTION: ;; ADDITIONAL SECTION: ;; MSG SIZE rcvd: 43 Jul 1 16:16:01 unbound 60237 [60237:0] debug: iter_handle processing q with state QUERY RESPONSE STATE Jul 1 16:16:01 unbound 60237 [60237:0] info: query response was ANSWER Jul 1 16:16:01 unbound 60237 [60237:0] debug: iter_handle processing q with state FINISHED RESPONSE STATE Jul 1 16:16:01 unbound 60237 [60237:0] info: finishing processing for mcm.local. A IN Jul 1 16:16:01 unbound 60237 [60237:0] debug: mesh_run: iterator module exit state is module_finished Jul 1 16:16:01 unbound 60237 [60237:0] debug: validator[module 0] operate: extstate:module_wait_module event:module_event_moddone Jul 1 16:16:01 unbound 60237 [60237:0] info: validator operate: query mcm.local. A IN Jul 1 16:16:01 unbound 60237 [60237:0] debug: validator: nextmodule returned Jul 1 16:16:01 unbound 60237 [60237:0] debug: val handle processing q with state VAL_INIT_STATE Jul 1 16:16:01 unbound 60237 [60237:0] debug: validator classification positive Jul 1 16:16:01 unbound 60237 [60237:0] info: no signer, using mcm.local. TYPE0 CLASS0 Jul 1 16:16:01 unbound 60237 [60237:0] debug: val handle processing q with state VAL_FINISHED_STATE Jul 1 16:16:01 unbound 60237 [60237:0] debug: mesh_run: validator module exit state is module_finished Jul 1 16:16:01 unbound 60237 [60237:0] info: send_udp over interface: 10.90.2.1 Jul 1 16:16:01 unbound 60237 [60237:0] debug: query took 0.079968 sec Jul 1 16:16:01 unbound 60237 [60237:0] info: mesh_run: end 0 recursion states (0 with reply, 0 detached), 0 waiting replies, 6 recursion replies sent, 0 replies dropped, 0 states jostled out Jul 1 16:16:01 unbound 60237 [60237:0] info: average recursion processing time 0.545964 sec Jul 1 16:16:01 unbound 60237 [60237:0] info: histogram of recursion processing times Jul 1 16:16:01 unbound 60237 [60237:0] info: [25%]=0.114688 median[50%]=0.643216 [75%]=0.821608 Jul 1 16:16:01 unbound 60237 [60237:0] info: lower(secs) upper(secs) recursions Jul 1 16:16:01 unbound 60237 [60237:0] info: 0.065536 0.131072 2 Jul 1 16:16:01 unbound 60237 [60237:0] info: 0.524288 1.000000 4 Jul 1 16:16:01 unbound 60237 [60237:0] debug: cache memory msg=54996 rrset=140420 infra=66438 val=45438 Jul 1 16:16:01 unbound 60237 [60237:0] debug: svcd callbacks end Jul 1 16:16:01 unbound 60237 [60237:0] debug: serviced_delete Jul 1 16:16:01 unbound 60237 [60237:0] debug: close of port 52520 Jul 1 16:16:01 unbound 60237 [60237:0] debug: comm_point_close of 15: event_del Jul 1 16:16:01 unbound 60237 [60237:0] debug: close fd 15Thanks in advance.
-
@danielatblueskyit said in Domain Overrides not working:
pfSense.mcm.arpa
mcm-dc.mcm.localThese are both just horrible choices..
mcm.home.arpa would be fine. Since home.arpa is special use domain for local domains.
.local is meant for mdns, horrible choice for local tld. Use the upcoming .internal as the tld if you want to use mcm
I really would change those..
Few things to keep in mind if your going to forward, ie a domain override - if the answer is rfc1918 that would be a rebind. So you would need to set the domain as private so unbound would allow for rfc1918 answer
https://docs.netgate.com/pfsense/en/latest/services/dns/rebinding.html
Second would be ACLs - if your forwarding to unbound on a different pfsense, you would have to make sure the ACL allows for queries from networks that are not its own interfaces networks. Same would go for any other NS you might query, like your DC in AD.
C:>nslookup - 10.90.1.3
That would be a PTR query - did you forward the in-addr.arpa range 1.90.10.in-addr.arpa. If the answer would come from some other NS?
-
Hi and thanks for the reply.
pfsense.mcm.arpa - this is the standard naming convention we use across about dozen different client sites with no issue.
mcm-dc.mcm.local - I don't have a say in this one, .local is still widely used on Windows Domain networks.
(I didn't know about the .internal one though, good to know.)These may not be ideal, however, they should work, and again, we have many cases of this exact naming convention working well, including with Domain Overrides.
And yes, I have cross-referenced all the settings in working sites and can find no differences between this setup and other sites.Additionally, I had already disabled DNS Rebind Protection on all Pfsenses.
nslookup - 10.90.3.1will not do a PTR lookup, the - denotes connect nslookup to this DNS server.
Regardless, there are reverse lookup zones for 10.90.1.0 & 10.90.2.0 on the Windows DC.One other thing I forgot to mention, since this isn't working, I've added temporary allow any proto from any to any on all LAN and OpenVPN interfaces until DNS override is functioning correctly and then can be locked back down again.
I will investigate the ACL situation though.
Thanks again for the assist.
-
@danielatblueskyit said in Domain Overrides not working:
this is the standard naming convention we use across about dozen different client sites with no issue
And no offense its horrible.. .arpa is not a tld that should be used..
I could use mcm.google.com as well and could make it work.. Doesn't mean it would be a good choice.
-
@johnpoz said in Domain Overrides not working:
@danielatblueskyit said in Domain Overrides not working:
this is the standard naming convention we use across about dozen different client sites with no issue
And no offense its horrible.. .arpa is not a tld that should be used..
I could use mcm.google.com as well and could make it work.. Doesn't mean it would be a good choice.
No offense taken, I had never used .arpa until pfsense started a) settings as default
home.arpaand recommending it whilst advising against .local.
What TLD do you recommend to use for this?
In relation to this issue though, do you think mcm.arpa is having a detremental effect on domain override?
Oh, it is probably helpful to point out that Site 3
pfSense.cakora.arpaso at least the mcm isn't conflicting with anything, yet override still not working. -
@danielatblueskyit said in Domain Overrides not working:
mcm.arpa is having a detremental effect on domain override?
No not really - but its just a bad choice.. home.arpa is specific for this sort of use.. so use say mcm.home.arpa would be fine.
sitex.home.arpa, sitey.home.arpa sitez.home.arpa would be fine to use..
.internal is supposed to be new tld for local user so mcm.internal, cakora.internal would be good choices, etc..
Do you have dnssec enabled? .arpa believe dnssec enabled - this could cause some issues. .local could be problematic with how the client might handle it, etc.
I would prob set private and non secure settings for the domains your using that you set domain override for.
If your using it as default domain in pfsense, prob wouldn't have the zone type set to transparent either.
if you have site A with a domain overide to B.. If your going to have rfc1918 as an answer, you need to setup private in site A.
To validate your domain override is working. Validate you can actually query it directly from pfsense A, to IP address B. This would also validate that ACLs at site B allow for pfsense A ip address to query it.
Set it as private and nonsecure if your using tld that is dnssec
Also are you using pfblocker on any of these sites - those tlds could be problematic with it.
