But I've determined it's definitely an issue with a particular Docker. For me, playing detective is the funnest part of the job.

If you run AD, then all clients should point to AD dns as their ONLY dns, and this should also be your dhcp server.. This is the designed and supported model from MS..  Pfsense dhcp and dns is meant for locations that do not have other systems in place to handle dhcp and dns. In a MS shop all members of AD should only point to your AD dns.  And having it provide your dhcp also makes it sure that even clients that can not register themselves in dns can be registered by the MS dhcp server. If your not running Active Directory and just using windows as workgroup and or standalone type servers then you could use anything else you want for dhcp and dns, for example pfsense.  But the pfsense dnsmasq service (forwarder) and the resolver (unbound) neither support client registration of their IPs and names in dns.  The only way for that to happen is if you create a host over ride or have the pfsense dhcp server put in those records for the leases or statics it has. If you want to do a full service of client registration in your dns running full service dns/dhcp - say for example from ICS bind and their dhcp server would be a better option. https://www.isc.org/downloads/

Thanks  :)

Great that you got your issue sorted, and lan having 2 gateways is PITA setup..  Someone didn't know what they were doing would be my guess. I bring up why something X is setup a specific way at work, and comes down to the guy before was an idiot ;)  So I use that same argument when setting something up at work or going over a design with colleagues – so when the next guy looks at this is he going to think you were an idiot?  Next guy not always aware of time constraints, budgets that lead to short cuts..  And none of which are really valid excuses for shit setup anyway ;) So when doing something I like to check my work by thinking hey is the guy after me that looks at this going to think I was a complete moron or what? ;)  Document, Document, Document - and if you do something that is odd ball document why..  So even when you come back to look at it a few months later you don't think to yourself WTF was I thinking ;)  Oh yeah this is why we had to do it that way when you look in the docs...

While I can see bogons from a routing point of view, your router shouldn't route to the internet anything in bogon..  But to me as a firewall blocking rule it seems kind of pointless in a setup where your blocking everything by default which is the pfsense default and most firewalls to be honest. So the only thing allowed is stuff I specifically allowed, I could care less if the IP that hits my block just to be dropped is valid or to route on the internet.. What does it matter I am going to drop it anyway. So it only comes into play when hitting one of my allowed rules, if my allow rule is locked down to source IP or block then again its pointless.  So it only comes into play when your source is ANY to a service you want the public net to talk too..  So its ok to allow all all the valid IPs in bot infections normally on actual valid IPs, script kiddies again normally valid IPs for the internet - your elite ninja hackers, yet again prob on a valid public IP, etc..  But stuff that prob not even going to route and just noise from your local IP.. Don't let it hit your service – seems like a lot of work keeping bogons clean and not having stuff you want to allow like rfc1918 for some really high level very tip top of the tree sort of fruit to pick.. Got to go get the ladder and safety rope, etc..  When its much easier to just pick the low lying fruit - or shit for that matter the fruit laying on the ground ;) Now I can see in a router that is doing advertisements or getting advertisements -- hey someone says route this, tell them to FO, etc..  But as a firewall rule not really sure I see the usefulness of bogons, especially since the listing has to be manipulated because it contains stuff that causes problems in many networks even though it shouldn't route on the public net.. Now if you have picked all the low laying fruit and even the shit high up in the tree and the only thing left is that apple at the very tip top that you need a crane to come in and get -- then ok ;)  This might be what your doing in a dod sort of firewall, but home/typical smb -- not so much.

As would mysite for the host and com for the domain, I believe.  Glad you got it working.

Those are the normal logs when dhcpd starts. Just showing what it's binding in the one particular line you pointed out. If it were receiving any DHCP requests that it couldn't service, it would log that and why.

my question is what is generating host only queries?

I hope Cisco does not mettle with it much as it's a great offering as it is.  I was even thinking of going enterprise for the office before I heard about this news. Cisco is known to muck things up so we'll see what happens next year.

Given what you are doing, yes it is normal. The reason it has two ARP table entries is because the permanent (static) one is there all the time regardless of the actual device status.  That's the intention of the static ARP table entry.  Then if the device is configured with some other IP address a "normal" ARP table entry gets created for that IP address too.  Thus you have two ARP table entries for the same MAC.

@johnpoz: What extra hardware?  The L3 switch I am quite sure can hand out some dhcp addresses ;) As to why this is not a current feature of pfsense I would guess its not a really needed feature by the majority of the user base..  Normally you would have pfsense do your intervlan routing - this also added feature of full firewall features that many L3 switches would lack. Would it be nice feature - sure it would come in handy for this sort of scenario. If your so large that that your wanting to handle intervlan at a L3 switch, then your prob so large that your already running a dhcp server be it AD or not, etc.  Which again reduces the actual need of pfsense being able to handle this specific sort of scenario. Kind of a special case if you ask me, large enough network that you need multiple vlans but no firewall between them and so much traffic between them that your pfsense box does not handle it well, etc.  So you want to do it at L3 switch - but you still want to run dhcp on your edge router/firewall? I would think the best solution for this OP is just use 1 segment so just doing L2 and pfsense can be his dhcp server, etc.  But he has not given details to why he need 2 segments or even if doing any ACLs at the switch between them, etc.  Would really need a lot of devices to have vlans to shrink your broadcast domains, etc.d I don't think the devs or even the users expect pfsense to be all things for all scenarios.. In a scenario where your running down stream L3 switches and pfsense is your edge I don't really think pfsense being your dhcp server is a huge userbase.. I was looking for hte same working with some l3 switches. it will be an option at pfsense at some point. =)

What does pinging have to do with resolving? When you ping your fqdn, do you get back an IP? example - this resolved.. but did not ping C:>ping pi.local.lan Pinging pi.local.lan [192.168.9.31] with 32 bytes of data: Reply from 192.168.9.100: Destination host unreachable. See it resolved the address of pi.local.lan This is not resolving C:>ping something.local.lan Ping request could not find host something.local.lan. Please check the name and try again. There is HUGE freaking difference!!! As to what you read about downloading??  No freaking clue - whatever it was you didn't understand it, or it was complete and utter FUD!!  There is no need to check anything in dns every hour, or download anything every so often, etc..  All dns is related to your ttl, this is how long a record is cached after it was looked up from the authoritative name server..  I would really suggest you read a bit about how dns actually works.  Are you thinking of a zone transfer?  There would really be no reason to do this at some period, other servers would be notified on change be the soa ns, etc.  neither unbound or dnsmasq in pfsense support being authoritative for a zone and do zone transfers, etc.  If your thinking of updating of the root hints? So where did pfsenseSRV1.miami.domainX resolve from?  Did you put in a host over ride in newyork pfsense, or did you put in a domain over ride?  When you say there is a firewall rule?  Where is this rule, what interface?  How are these 2 connected?  What is the source interface used for the query?  Are you using the forwarder or the resolver, where did you setup the over ride? is domainx really a private non used public tld, or is it something like .net or .com ?

Please disregard…such a rookie mistake: New IP = 97.85.112.76 The IP in the firewall was 97.85.112.6 This should work now once DNS is propagated. Still odd that I was able to pull by IP...but I must have had the script which I run to report to outside server IP to my clipboard.  :-X I wrote a script to write to http://unix.eng.ua.edu/~noland/izzIP.html so that I can be notified without using the new paid DynDNS. :)

yeah I didn't have to reboot mine.. But clearly it was in the config - so if still handing out the old stuff then it didn't read the config for some reason. Could of always killed the process, and then started it back up..  So curious now what is your response time from discover to offer..

Alex, if I understand your original request correctly, you can address this by configuring resolver (unbound) to use the LAN interface as the only outbound interface. You shouldn't need the fake gateway and static routes. Note that this will mean all your other DNS packets (to root servers etc.) will be processed via NAT.

No, nothing else going on (as seen from the logs) at the same time. Just the segfault in the system log.

No, beyond "run your own dynamic DNS server". (Not really sure what you are doing with your dynamic PPP interface that does not have internet access.)