@gertjan said in DNS reslution error just on pfsense box: ort the config back in, and one reboot later you're back at square 1. I reinstalled pfsense, left everything as default. It still couldn't resolve DNS. Ended up upgrading installation boot usb from 2.5 to 2.6, re-installed pfsense once again with all default settings, changed the NIC and it resolved the issue. I am still unsure what caused the issue though. Thanks for all your input Gertjan :)

@fsc830 said in DHCP not working as expected!?: was focused at the pfSense. What is more likely - you have a rouge dhcp, or pfsense handing out info you didn't set it - and not logging that it handed anything out ;)

@johnpoz You are right, this android device joined the IOT SSID. On pfsense I have majority of IOT devices static DHCP binding with DNS assigned. But for dynamic DHCP pool I did not specify DNS server. So it was using .30.1 (pfsense gateway) as DNS and I have DNS redirect configured for external DNS servers not pfsense itself. This is resolved. Thank you very much for pointing out the issue.

Got it! I had to add "LAN" to the list of authorized outbound network interfaces for unbound. Without that, it wasn't able to send traffic from an IPv6-enabled interface (since my WAN interface has no IPv6 address).

A HUGE thank you for taking the time to point out the relevant parts in the documentation and explain them. Bart

@mathomas3 Timings Name server Query time 127.0.0.1 No response 192.168.1.1 No response That sure doesn't look normal..

@randombits I have not looked into what Pis do - and would guess depends on what OS your actually running on them. But its possible it could/should also send out a gratuitous arp. This is basically the device just telling the network on its own, hey if your looking for IP address x.x.x.x - that is me, here is my mac. This should update any cache.. But sure arp cache should be something you should be aware of when you swap in the other device, that if you have any issues talking to it - make sure to check the cache on the device trying to talk to it, that its cache is not pointing the first devices mac.

@techvic said in DynDNS not updating IP by itself but only with "force update": but in that scenario the DynDNS is not updated even though I have the entry in the log that claims it updates the DynDNS. That's why I was asking for what was shown after the line : [image: 1669275658351-909cc90f-25d8-48ca-b1a4-941036a87525-image.png] When using verbose mode (you are) : [image: 1669275693829-cb28d7c4-e023-4b19-b8c6-ed60f681d584-image.png] the answer coming from the dyndns service of that https request will get shown. That answer also proofs that the dyndns servcie was contacted. These are a bunch of "Response Header:" and "Response Data:" lines.

In general that's not a known issue. Pretty much everyone here at Netgate runs with a private domain entry for our company domain and things hum along as usual. unbound can get cranky sometimes if it is trying to reach a specific upstream server and it doesn't respond. Keep an eye on Status > DNS Resolver entries when it works vs when it doesn't work. You can get the same output from the shell with: : unbound-control -c /var/unbound/unbound.conf dump_infra Odds are when it stops responding there is an entry in there for a server that has also stopped responding. Restarting unbound clears all that knowledge and forces it to try again. You could also try manually flushing things for that domain (or all domains) to see if that's sufficient to make it try again: : unbound-control -c /var/unbound/unbound.conf flush_zone foo.com There are some other similar commands to try listed in the docs: https://docs.netgate.com/pfsense/en/latest/services/dns/resolver-cli.html

figured it out, there was an old dhcp reservation on one of the carp routers that were not synchrnoised.

@qbhatti said in Pihole as secondary dns: blocks some google ads so it means I cant click on shopping items or sponsored items when searching. Seems like a problem of the ad blocking list your are using in Pihole. You could try a safe one like OISD Basic that has no false positives.

@johnpoz I am hallucinating indeed I see that I can use other dns that are not those of my provider. I don't know if it's their mistake or they have changed their policy and now they allow us to use others. If so, this has solved my problem. Ufff! Thank you very much for your help.

@johnpoz I just verified. In the Network preference of the mac, under "DNS", I had specified a bunch of IP addresses of entities other than my own ISP (like 1.1.1.1 or 9.9.9.9 ...), owned by Google, Clouflare and possibly others. I erased all entries in this field yesterday and just checked now : it contains one entry it added itself, which is 198.168.xxx.1 : the LAN address of my SG-1000 pfSense firewall-router, in the private vlAN of which this mac is client.

@bob-dig Yes, what you say is true. Luckily my prefix(es) are not dynamic and I'd need to do quite a few changes to flip to what you suggest. I'll probably think about that as a longer-term project but for now this solution works for my specific use case.

@chris1284 when I get a chance I will try and duplicate this.

@br116 said in IP Addresses not showing up: Is there a reason for this? You're probably missing important info. If you set up a device with static IP settings, like : a screen shot of one of my APs : [image: 1668604662375-92141b30-4402-496b-a5c3-369802092bc6-image.png] then the DHCP client process on that device, my AP, and your device, isn't used. So, my AP will never emit a DHCP request, and the pfSense DHCP server will never receive a request for a lease from this device. Because : DHCP isn't used by this device. So : no lease. Because you chose not to use DHCP for your device.

@derelict this has come up multiple times ;) Here is an old thread where went into much detail about when the dns server your redirecting on on a different vlan, etc. or when its on the same network and you get back the unexpected IP, etc.. https://forum.netgate.com/topic/139457/transparently-intercept-and-redirect-dns-traffic-to-an-internal-dns Personally not a fan of redirection either, either use the dns I handed you - or not getting dns ;) But I have done on one of my vlans just to shut up some iot shit that insists on trying to talk to 8.8.8.8, so just redirect it to my pihole - there you go buddy googledns answered you ;) If you would just use the freaking dns I handed you with dhcp you dumb crappy pos we wouldn't have to do such nonsense.