KEA DHCP error - Error 9502: Bad DNS packet.

cjbujold

When doing a NSLookup on a client PC using pFSense as the DNS server, I keep getting the error:" Error 9502: Bad DNS packet". Using another DNS server (not PFsense) NsLookup from a client PC works perfectly. Using the PFsense diagnostic DNS lookup works perfectly. Tried over 10 different clients/servers with same failure results.

How can I fix this issue, since it is affecting my KEA DHCP clients. I have to point them to an external DNS for them to work.

Configuration:
Using PFsense 24.11 (the 25.3 stable version is still not available for update in my update option. - current beta version 25.07).
Unbound (DNS Resolver)
DHCP (KEA)

Gertjan

@cjbujold said in KEA DHCP error - Error 9502: Bad DNS packet.:

I keep getting the error:" Error 9502: Bad DNS packet"

What PC ? Windows ? Something else ?

Where / how did this error show up ?

What does (Windows) :

ipconfig /all

show you ?
Or the command equivalent of your PC.

cjbujold

All PC are running Windows 11 latest version with July updates
Servers are Windows server 2019 and 2025 with July updates
IPconfig /all using my PC running Windows 11 with July updates:
Using Windows NSLookup after clearing DNS cache and doing lookup on Google.com
using DNSDataview with primary DNS server set to 192.168.76.1(Pfsense)

6 Using DNSdata with primary DNS server set to ISP DNS server

DNS resolver is using standard out of the box setup. Also using PFBlockerNG which added in the custom field " server:include: /var/unbound/pfb_dnsbl.*conf "

Any help would be appreciated. Thanks

johnpoz

@cjbujold query refused points to the ACLs not being correct to allow queries.

Did you turn off automatic ACLs?

This would be under the unbound gui, advanced

If you turn that off - then you have to create your own ACLs

Other things I see wrong is all those other dns setup on your ethernet adapter.. Those outside NSers sure are not going to be able to resolve your local resources. If your going to point to more than 1 NS - the name servers you point to should resolve the same stuff. If they are filtering NSers then they should filter the same way. If NS A filtering is different than NS B - your going to run into issues because you never know which NS you might talk to.. So maybe something you want filtered is not, maybe something you want to resolve is filtered.. And none of those public are going to be able to resolve any local resources you want to resolve, etc.

You see when you do that lookup and it says unknown for server - that tells me your NS is borked - when nslookup tries to talk to a NS it would always do a PTR for the IP.. If the NS your talking to can not even resolve the PTR of its own IP address - there is something wrong with it..

$ nslookup
Default Server:  sg4860.home.arpa
Address:  192.168.9.253

192.168.9.253 is my pfsense IP, and that is where client points to for dns - see how it returns name of my pfsense.

cjbujold

Thank you that fixed my issue, much appreciated.

Gertjan

@cjbujold

Not related, but you have wired NIC and a wifi NIC, both using the same 192.168.76.0/24 network.
Wired 168.168.76.223 - gateway 192.168.76.1 (probably pfSense LAN)
Wireless : 192.168.76.50 - gateway 192.168.76.1 (probably pfSense LAN)
and both have a bunch of 'strange', non local DNSes.

Be ware that things can become confusing as a same device has more then one IP in the same network. I mean, its good for redundancy, true, but still ...

Normally the DNS server for that PC would / should be 192.168.76.1 also.
The ieda is that all your devices uses the same local 'pfSEnse' resolver - and if you have to use 47.55.55.55 etc as a DNS source, you could set the resolver to forward to that DNS (and the others).
Now, you local network DNS requests are getting cached locally so your entire network can benefit from this.

johnpoz

@Gertjan those 3 name server might be just his isp dns.. that first on is fibreop and the others are aliant - which are the same isp - with the fibre one being for their FTTH.

Yeah if you want to use those - you should have unbound forward to them - but I see little benefit to forwarding for dns, just let unbound resolve is better option imho.