AD joined computers should NOT ever point to pfSense for DNS or DHCP. Period.

"Why??  Thought you said you were using the resolver..  What is the point of putting in forwarders if your going to resolve?" - good point. my initial thought was that having a backup destination is good (just like having more than one ntp server).  I take it that if the resolver cannot reach root hints doing this will not make the resolver go elsewhere? "Who exactly would be talking to your resolver if your going to tell dhcp clients to use outside dns??" - internal clients.  For example, PC1, PC2, Switch1, PRN1, etc. etc.  I would like to be able to resolve PC1 from PC2 or vice-versa.  The bigger thing is being able to have my syslog VM resolve all the internal IPs to names during log post processing. "Are you saying you just want your guests to be able to use google and opendns?  While your other networks use pfsense resolver?" - no. I just want to be able to resolve internal hostnames. So if I was on PC1 and needed to poll or connect to say PRN1 i could just use the FQHN or if the syslog data has IP addressing i could do a reverse lookup on the ip and get the hostname.  If PC1 or the syslog box were looking up something on the internet then the end result we be they go to OpenDNS or Google DNS. thanks!

Solved, but I don't like the solution.  Interfaces -> WAN -> "DHCP6 Client Configuration" -> "Use IPv4 connectivity as parent interface" = enabled IPv4 shouldn't be required to bootstrap the IPv6 connection and my IPv6 connection worked without enabling this.  However, turning this on probably brings up the connection fast enough that it is ready when Unbound starts so it doesn't fail to bind.

;D ;D ;D ;D ;D ;D ;D ;D ;D ;D That worked!! Thank you!! I'll remember that for any of the services if/when I run into a similar issue - before posting for help.

Not exactly sure how had your pfsense setup? but yeah internet - modem - router/wifirouter - pfsense - wired clients not the optimal setup. Normally you would want internet - modem - pfsense - switch/AP/etc.. So that all your devices are on networks behind pfsense be wired or wireless this way you don't double nat and you don't have issues with stuff on wifi or connected to your router in front of pfsense having to go through a port forward, etc. etc. Glad you got it sorted.. Don't really owe me anything ;)  Just pay it forward if you can by helping someone on the board that you know the answer to their question.

It was never my intention to get this deep into why I was getting a request from a strange dhcp server.  It's been interesting tho and I have learned a few things. Regarding my ISP provided cable modem and other customers on the same subnet, my ISP upgraded my modem about a month ago, it has more channels.  I have 8 bonded downstream channels and 4 upstream, 3 of which are bonded.  I have no access to the other features in the modem except to see the status page. In the past, I did see other customers, I cannot see them now.  One item shown on status page which may explain this is "DOCSIS Privacy = Enabled".  I have not attempted to find out what that means but assume it explains why I don't see others on the subnet.  I do not recall if the privacy option was on my prior modem or not. Since obtaining the MAC of the stray dhcp server, I can add this to the discussion. The stray MAC is:  00:01:5c:66:c0:04 The MAC of my upstream gateway is:  00:01:5c:66:c0:46 Since the equipment of the upstream gateway is only 66d difference in MAC address I assume that the device that is giving me the stray dhcp offer belongs to my ISP.

What client you use to query shouldn't really matter..  So where do you doing query for any or something vs A.. This stuff is really pretty basic troubleshooting.  But we need something to go off of.. like the output of your query, your exact query.  Your exact setup.  Log of bind when you did the query, etc.

you're welcome, however with those rules you can prevent the effects of changing the DNS directly on the user's devices ;)

I found what was wrong. A PfBlockerNG config entry was in the unbound advanced config box that was from a old dnsbl setting. I had PfBlockerNG turned off for some time. maybe location of config files changed in PfBlockerNG. I removed the setting and disabled and re-enabled dnsbl in PfBlockerNG and now everything works well!

Yay, DHCP relay fixed in Fri Nov 18 20:40:07 CST 2016 snapshots and later.

you can just delete the whole file if you want.  Or delete the leases from the gui..

Nope.  That computer used to run openSUSE 13.1 for my firewall, prior to pfSense, so no cables were moved.  I realize it won't make any difference.  Just curious.

Thank you, John! So, yes, this will break anybody trying to upgrade VMware VCSA if pfSense/unbound is their DNS server. Hacking dns_utils.py on the 6.5 VM and removing that addition of 'ANY' to the dig arguments allowed me to complete the upgrade. That's really pretty bad coding - they don't want or need 'ANY' (imagine if there were MX records!), they only want 'A' or 'AAAA', so I'll look log a bug with VMware.

ok thanks - sorry - will repost it  - feel free to delete etc..

Thank you! I somehow missed it.

@jimp: If you want to restrict by MAC per interface, use the MAC allow or deny boxes and not "deny unknown clients". That doesn't scale very well, but it will give you more fine-grained control over who can pull from where. Thanks, I never thought of that one!!

Why is what, why is it default or why is a resolver better than a forwarder? As to why its default, ask the developers.  But a resolver with dnssec enabled is better from a security point of view because as long as the domain your asking for a record from is using dnssec you are assured that the answer you get back is legit and what the authoritative server wants to hand out.  Not some record in a cache, its quite possible the stuff in a cache has been poisoned, etc. Or maybe your cache entry ttl has not expired, or maybe the ones running the cache don't adhere to the authoritative servers ttls settings?  To reduce their traffic? If your asking the authoritative server you getting the answer right from the horses mouth, not some cache.  To me this would always be the preferred method.  Be it they sign it with dnssec or not.  But in a perfect world all dns would be using dnssec.. Look at it like this, if the developers of pfsense thought it was better or a preferred setup to use unbound in forwarder mode - why and the F is out of the box in resolver mode ;)  That would make zero sense.  So its logical that pfsense using unbound in resolver mode is the preferred method.. You could debate that since some users have problem with resolver mode because they on some bad isp that blocks dns to anything other then their servers, or they intercept dns traffic and do something odd with it.  Or maybe the user is just on a bad connection where talking to the authoritative servers for a domain on the other side of the planet takes too long.  So in that case the forwarder to the users local isp dns would answer queries better.  That really should be one offs to typical connection, and those users should make the decision to either bring up the issue to their isp, or get a better connection or use the forwarder. I think its better to deal with the few users that have issues, and put most of the users than don't really know any better on a better security footing then leaving the default at forward mode and hoping the users read and figure out on their own that resolver is better and more secure.