@rcoleman-netgate
yaya ^^ that thing.

Yes, there are VLANs at play here.

The device is on wifi, though it hasn't moved and a new identical device newly installed right next to it is not exhibiting this issue. The logs from my wireless infrastructure don't suggest any major connection blips either.

I also don't believe the device rebooted, though that is possible.

I ended up, rather than setting up a static IP on the lease (that particular vlan is for IoT stuff and has no extra room on its subnet that isn't allocated to the DHCP pool), just setting a static lease that overrides the DHCP lease time to one day. And now I see daily DHCP renewals with no problems.

Odd though that this worked fine with hourly lease renewals for a couple of years before this problem arose.

@johnpoz said in Unable to illegal DNS record from pfsense (DNS-resolver corruption):

@asadz said in Unable to illegal DNS record from pfsense (DNS-resolver corruption):

with backhole address.

of 100.1.2.4 ? that is a HORRIBLE blackhole choice that is for sure..

A simple wireshark would of seen right away that answer was coming from a different mac address, etc.

Again if the DC was putting traffic on the wire, would of seen that and know from upstream something was returning the 100.x address.

Glad you found it.. but using a valid public IP, ie 100.1.2.4 is horrible horrible choice of blackhole address.. Maybe it was a typo and was suppose to be 10.1.2.4?

Yes I share your concerns, this IP made it first appearance in var/log of pfsense of 14th same day we enabled new snort rules
The DNS reply logs

Dec 14 14:31:08,reply,A,A,Unk,sb.scorecardresearch.com,192.168.3.6,100.2.3.4,USDNS-reply,Dec 14 14:31:08,reply,A,A,Unk,sb.scorecardresearch.com,192.168.4.9,100.2.3.4,USDNS-reply

Suggest sunnyvalley providing black hole response. I still think black hole address should be private to be safe and esp should not resolve or routable to www.

Also the MAC address lookup shows 0050560B0310 -> 00005E000101
One is register with VMware other is IANA. Most probably sunnyvalley cloud app is running over VMware.

I guess, those are normal and unbound is the source?

Although I haven't noticed blocking has had any unwanted effect to anything, at least info TLD would probably be better to be allowed?

It turns out that I had a brain fart and misconfigured DHCP guarding in the UniFi OS Console for my access points. Rather than using the gateway address of the WiFi network’s subnet as the DHCP server address, I used the address of the Netgate box. With that fixed, everything works.

Thanks for all who made suggestions! I am learning from each of your contributions.

@rchiocchio Keep that NAT disabled, you don't need that.

You are allowing only TCP traffic, DNS most of the times uses UDP, try to change that rule from the IPsec tab to TCP/UDP and test again.

@gertjan hello there

Yeah, I'm puzzled too. I just can't prove if its from our huawei core switch or from pfsense itself.
But I don't see any documentation regarding huawei having that domain.. I already escalate it to huawei TAC and they just said this "if 172.1.83.10 is the address of HW switch, switch just replay a icmp packet, will not take these information (lightspeed.moblal.sbcglobal.net), and it is the behavior of PC."

and base from this forum, I think no-one yet encountered this ghost domain with their pfsense, so I think its not really the pfsense causing

@juergenbrandstaetter said in How to configure Dynamic DNS with unsupported DNS provider:

In my case I my providers router works in bridge mode, and my WAN interface is configured as DHCP -> so I guess it should recognize, if the IP changes

Not recognize 😊
If you use a DHCP client on your WAN interface, this client will initiate a DHCP lease request as soon as the WAN interface comes 'UP'.
The ISP, with it's DHCP server, will give the client an IP (your WAN IP), a gateway, maybe a DNS or two.
A DHCP lease has always a duration, like 24 hours. So, half way that duration, the DHCP client will wake up, and request for an DHCP lease 'extension'. It will of course suggest that it likes to keep the actual (WAN) IP.
The ISP DHCP server can grant that lease extension, or so, "NO, now you get a new IP (WAN)".

The WAN IP changes (or not) a "interface event" is fired, and this will affect all processes that are "bound to" these interfaces, so that these process can be made aware that an IP on some interface changed (or not).
On of these process is : the DynDNS. It has stored the (now past) WAN IP in a file, it will compare it with the actual WAN IP, and fire up a dyndns update if the tow are different. And it will update the file with the current WAN IP for future events.

@viragomann Yes, the same chip celeron N3060.
By default pfsense listen in all interfaces under DNS Resolver.
Them I'm not alone.
My felling is that is related to N3060 electronics.
Them have discover something else about this issue?

@viper_rus Close thread, problem solved

@mctechsolutions
pfSense on its own can only redirect IPs and ports. It cannot read a host header in a HTTP request if that's what you're purpose.

If you want to redirect traffic on host name basis you need to install and configure the HAproxy package.

@adamitj
DoT requests which are redirected to another server won't work anyway, because the SSL verification will fail.

Therefore I simply block all DoT and DoH in my network. Hence the clients have to do unencrypted DNS requests, which I can redirect as needed.

@bingo600 The issue was your first quote...
I feel dumb right now, I'm highly appreciated for your help.