Then you're putting the wrong IP address in the DNS entry. Use the inside address of the host. The "Real" IP address.

@raj_amid: sorry only dhcp range is from cisco switch dns from AD all meembers pointing to AD dns. I'm not sure what you mean exactly, but your DNS setup should probably look something like this: Your Squid (running on PFS?), your PFS and your clients should all have your Windows DNS server (domain controller) set as the main DNS server. Your Windows DNS server should have your external (public) DNS servers set as it's forwarders. That way, your Windows clients can resolve all your internal and external hosts as well as function within the AD envirnoment correctly, and your proxy/firewall will also resolve all internal and external hosts.

Safari == New IE!?

https://doc.pfsense.org/index.php/Why_can%27t_I_query_SNMP,_use_syslog,_NTP,_or_other_services_initiated_by_the_firewall_itself_over_IPsec_VPN%3F

yeah if your saying you adjusted the range, there is prob an OLD lease the client is asking for…  You need to delete that lease off pfsense, since the client is prob asking for it.. You can sniff the dhcp packets and look for the discover.. Make sure you look in all the pfsense leases and delete the OLD one..

Why I want to run BIND on WAN. Because if someone doesn't do it, then no one will be able to visit my domains. Why I want to do my own hosting. For exactly the same reason I want to own my own transportation rather than always take the bus or call a cab. In other news: IT WORKS! Thought I'd grab BIND's config files and see what's really happening. All those Google results talk about config files, not pfSense graphical interface. So did a bit of Googling to see where the files might be hiding. Found a 10-page thread on this forum from 2013. Pretty darn helpful. Never having used BIND before I wasn't sure what to expect–MS's DNS does a bit more hand holding and checks everything as you type it in. Plus MS's DNS server isn't as versatile, so the interface is simpler. Didn't know ACLs or Views (I did look at them), so I did Settings then jumped to Zones. In Zones the View selector was empty, so it must not be important, right? Down at the bottom the text box labeled "Resulting Zone Config File" was always empty. But wasn't that a place where BIND wizards typed their magical incantations into? The interface is full of those so I thought this was just one more. When I tried to look up BIND in your wiki there was nothing. While poking around a few days ago I set up what I thought might be a useful View for a WAN, but nothing happened. Then today, because of the mention in that old forum thread about selecting a View in a Zone, I tried it and magic happened. That text box filled itself in. Then I discovered no more refused connections. After several hours of experimentation I got all my zones working (18). And was finally able to switch my other DNS server (Win 2008 Server) to secondary, and sync everything up. I even double checked to see that only my secondary could pull a zone from BIND. HUZZAH! DNSSEC is next. I have Lucas' little book. Think I might read it. Dude, thanks a million for your help.

Thanks, Static route did the trick. Forgot about that. My thinking was that I if I could connect with IP address' that DNS should also work without static routes. After reading that article it all makes sense now. Thank you so much :) I shouldve known as I had static route on my old m0n0wall ::) BTW. Migrating from m0n0wall and really appreciate all the work that has been done. I've tried all the other embedded firewalls and nothing is as stable and familiar as pfSense. I think pfSense is going to put a hurting on soekris also.

your right pfsense runs isc dhcpd not dnsmasq dhcp server my bad, but its the same problem - your problem is still that your dhcpinfrom is getting your configured default setting vs what you setup via a static, this is by dhcp design it seems not a pfsense issue. Here this is your exact problem..  When windows clients send out the dhcpinform they get the standard dns vs what was setup in reservation. https://readme.phys.ethz.ch/windows/what_to_do_if_windows_vista_gets_the_wrong_dns_servers_via_dhcpinform_answers/ According to the most current DHCP standard, DHCP servers are not allowed to look up any lease data about the requesting MAC address if they answer to a DHCPINFORM packet. In ISC's interpretation of this rule this even includes group membership which belongs to the configured static (and not dynamic) lease data. Setting to non authoritative it now just doesn't answer dhcpinform requests I would take it, so no you don't get any dhcpinform info for anything..  Problem is most related to windows asking for wpad.. This sends out a dhcp inform..

in a normal setup with pfsense resolve of hostnames should be pretty much automatic.. your machine lets call it hosta gets dhcp IP from pfsense dhcp server, it also hands it a domain you setup like mydomain.tld…  Now when your box queries for hosta it really should be doing a query for hosta.mydomain.tld and even if it didn't pfsense will register hosta all by itself and if you ask for just hosta. you should get an answer.. now if your pointing your clients directly to some outside dns like google or your isp..  Then no they would not have any clue to your local hosts. Point to pfsense as  your dns and you should be fine in resolving host names.  Pfsense will either look up www.google.com for you from the roots or you can set it to forward to your isp or any other outside dns. Also windows still broadcasts for names anyway.. So as long as machines are on same network segment/vlan/broadcast domain and they are limited in answering then sure a broadcast would work as well.  But dns is the preferred way to resolve hosts, and you should really get out of the bad habit of just using hostname and use a fqdn hostname.domain.tld

You'll have to write your own code if you want to do this. /usr/local/www/diag_backup.php will probably be a great help. To be honest, if you want to do anything 'clever' that requires functionality beyond that provided in pfSense, you are probably better off implementing that feature entirely separate of pfSense. For example, I require my RADIUS server to do things that are not supported in the pfSense FreeRADIUS package, so the most straightforward way ahead is to run FreeRADIUS on another FreeBSD box. You clearly have other devices available to you, as you want to synchronise the data to them. Depending on your application, it might help if your switches have DHCP Relay functionality.

what screenshot???  Don't see any screenshots… Or links to images, nothing..

There we go, something learnt every day and all that :) Cheers.