DarkStat Not Resolving Internal (LAN) IP Adresses
-
I use Windows AD which handles DHCP and DNS, all servers and clients point to Windows servers for DNS and the Windows DNS servers have the pfSense IP as a forwarder. pfSense is configured with Google DNS servers only as I do not want to use my ISP DNS (and 127.0.0.1 is enabled also).
I added a Domain Override for my LAN domain (this is a lab) in Services\DNS Resolver\General Settings, and I can now resolve local queries using Diagnostics\DNS Lookup in pfSense, so pfSense now seems able to resolve LAN addresses (or is Domain Override not the best way?).
But the stats in DarkStat are still only showing IP addresses for the LAN side (even after restarting the service).
Is there any way I can show resolved address in the DarkStat hosts page?
-
So you setup up your reverse zones, ie PTR in your AD dns.
Do a PTR query to your AD for some IP - does that resolve? How did you setup your domain override?
If your using 192.168 rfc1918 it would be a domain override for like
168.192.in-addr.arpa
-
@johnpoz said in DarkStat Not Resolving Internal (LAN) IP Adresses:
So you setup up your reverse zones, ie PTR in your AD dns.No, I created my reverse lookup zone after originally setting up the domain and PTR records are created automatically when Windows clients register with the DNS server. I have not manually created a PTR record for the router.
@johnpoz said in DarkStat Not Resolving Internal (LAN) IP Adresses:
Do a PTR query to your AD for some IP - does that resolve?Any host I ping resolves correctly.
@johnpoz said in DarkStat Not Resolving Internal (LAN) IP Adresses:
How did you setup your domain override?Exactly as stated above, in the Domain Override section of the Services\DNS Resolver\General Settings i added the domain Home.local pointing at my primary DNS IP address
-
Post your domain override.. if your AD is resolving the PTR, and you setup the domain for the in-addr.arpa zone correctly then it would be resolving.
What kind of ACL do you have setup on unbound?
You do understand setting google dns in pfsense is pointless right? If you have it resolving, just point it loopback - itself and let it resolve. So it can use the domain override to lookup your PTRs
Quite possible pfsense is asking googledns for PTR which will not work ;) If you have it set to use google..
-
Sorry but you will need to talk down to me as I don't understand what you are talking about.
What does 'post my domain override' mean? Are you asking me to post a screenshot? Can you not understand from the text above the settings I have in Domain Override?
I have no issues resolving host in my LAN, this is purely the stats in DarkStat in pfSense NOT resolving hosts and only showing IP addresses, whereas for remote hosts/internet servers it resolves the addresses.
Please explain why setting Google DNS in pfSense is pointless
"If you have it resolving, just point it loopback - itself and let it resolve. So it can use the domain override to lookup your PTRs
Quite possible pfsense is asking googledns for PTR which will not work
If you have it set to use google…"I have no idea what any of this means.
-
Darkstats is trying to resolve the IP addresses into names for the machines on the LAN side, which is clearly not working.
DNS works in two directions; names to IPs, and IPs to names.
What Johnpoz is referring to is the IP to name resolution, also known as reverse DNS lookup, this use PTR type records.
On your AD server, you should have BOTH the forward domain and reverse domain, which will be in whatever subnet you have defined. Check under Reverse Lookup Zones in your AD server's DNS Manager. You should see something like 1.168.192.in-addr.arpa, if you are using 192.168.1.x addresses internally.
If the reverse zone doesn't already exist on your AD server, you need to create it, AND in pfSense you need to setup the override for this reverse domain too in the same way you set one up for your internal domain. -
@awebster said in DarkStat Not Resolving Internal (LAN) IP Adresses:
Darkstats is trying to resolve the IP addresses into names for the machines on the LAN side, which is clearly not working.
DNS works in two directions; names to IPs, and IPs to names.
What Johnpoz is referring to is the IP to name resolution, also known as reverse DNS lookup, this use PTR type records.
On your AD server, you should have BOTH the forward domain and reverse domain, which will be in whatever subnet you have defined. Check under Reverse Lookup Zones in your AD server's DNS Manager. You should see something like 1.168.192.in-addr.arpa, if you are using 192.168.1.x addresses internally.
If the reverse zone doesn't already exist on your AD server, you need to create it, AND in pfSense you need to setup the override for this reverse domain too in the same way you set one up for your internal domain.Thanks, that is really helpful clarification.
I already have the reverse lookup zones for the two subnets I use in my Windows DNS and I have a Domain Override in pfSense. I can ping/resolves hosts in my LAN, that is not an issue. pfSense cannot THAT is the issue.
-
@mikhailcompo said in DarkStat Not Resolving Internal (LAN) IP Adresses:
‘post my domain override’ mean?
I mean post a screenshot of it... How is that in any way ambiguous??
Yes I believe you think you did it correct, doesn't mean its actually correct. Have seen users putting overrides in the forwarder when they are using resolver and wondering why its not working, etc. Just because you think you did X doesn't mean its not Y. Which is why a picture is always worth 10k words. You also know the phrase pics or it didn't happen ;)
Pfsense out of the box is a RESOLVER!! Mean it walks down the roots to find the authoritative ns for whatever you looking for. If you tell pfsense itself that hey go ask google for something when it wants to know what the PTR of 192.168.9.100 is - google not going to have a clue and send back NXdomain.
If you want pfsense to resolve 100.1.168.193.in-addr.arpa then you need pfsense to only ask itself, ie the resolver on loopback, so it can use your domain override to go ask your AD server which you state you have the reverse setup on. But again still have not see this query actually respond..
Here is a simple PTR qrery... Lets see that against your AD dns for one of your IPs your wanting pfsense darkstat to resolve
example
C:>dig -x 192.168.9.10; <<>> DiG 9.11.3 <<>> -x 192.168.9.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62133
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;10.9.168.192.in-addr.arpa. IN PTR;; ANSWER SECTION:
10.9.168.192.in-addr.arpa. 1958 IN PTR nas.local.lan.;; Query time: 8 msec
;; SERVER: 192.168.3.10#53(192.168.3.10)
;; WHEN: Tue May 29 13:26:22 Central Daylight Time 2018
;; MSG SIZE rcvd: 81 -
@johnpoz said in DarkStat Not Resolving Internal (LAN) IP Adresses:
I mean post a screenshot of it... How is that in any way ambiguous??
Lets see that against your AD dns for one of your IPs your wanting pfsense darkstat to resolve
I've run this command in pfSense web UI:
dig -x 172.16.1.1
; <<>> DiG 9.11.2-P1 <<>> -x 172.16.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 38441
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;1.1.16.172.in-addr.arpa. IN PTR;; AUTHORITY SECTION:
16.172.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jun 02 18:28:44 BST 2018
;; MSG SIZE rcvd: 111 -
And that is NOT an in-addr.arp domain now is it!! So no that is not going to work..
Create your 168.192.in-addr.arpa domain override if your AD has its reverse zone setup and responds for whatever 192.168 network your using.
If your using 172.16.1 then create that
1.16.172.in-addr.arpa
