You forgot the CON on your last option that you will not be able to resolve anything local.

Your going to have to be specific on what your "secure your DNS queries" is in regard too…

Not all of us have our tinfoil hats on so tight that we are worried about our ISP sniffing our traffic to find our dns queries out.  Nor are we worried about the authoritative NS for a domain, or the roots knowing what IP we are asking for some FQDN from, etc.

So when you want to discuss "secure" your dns your going to need to spell it out so we know what your wanting to "secure" it from..

Out of the box pfsense resolves and uses dnssec.. This should be optimal configuration for typical use that the person has not cut off the blood flow to their brain with how tight their tin foil hat is ;)

Using something like opendns or quad9 have feature that resolving your own does not support and that is filtering out bad domains per some listing.  Now you could do this your self in unbound or with pfblocker and still resolve.  So vs handing over everything to some 3rd party company that says hey we have these lists of bad sites and wont resolve them for you.  You could do that yourself on pfsense and never send the query out in the first place.

If you do not want roots to know your looking for say www.domain.tld, you can turn on a setting to only send roots .tld and second level roots domain.tld and not send... But from my experience that are many domains that this is broken for.

You have 2 IP ranges shown 192.168.3 and 192.168.1 so your saying your using a 192.168.0/22 or larger network?  So it would include both of these networks..

And all the clients are using this same mask..

If you were using /16 lets say even - pfsense would have ZERO to do with traffic on this L2.. ZERO!!  Pfsense routes traffic at L3, it doesn't route L2 traffic.. So if your devices are in the same broadcast domain pfsense doesn't even touch this traffic.

@SammyWoo:

@JKnott:

It's obvious someone doesn't know what they're doing.

Nah, I wager is one of those just doing enough the get by. Contractor didn't want the hassle to run a new cable, so use old one with 1/2 pairs. this puppy is gonna come up again at upgrade time, hope the cable is outside of DMARC (ISP responsibility) 'cuz if it's inside, customer's expense to fix/upgrade.

The problem is these days Internet connections often exceed 100 Mb.  Mine now offers up to 1 Gb.  If the contractor takes pairs for phones, then that connection will never exceed 100 Mb, even though you may be paying for more.  It's just a bad idea.  Incidentally, other than for Gb, there is not a technical problem with having phone and Ethernet in the same cable.  The original spec for what became 10baseT (StarLAN) was designed to work over 3 pair CAT3 cable, with one pair used for the phone and 2 pairs for Ethernet.  However, these days it is considered bad practice.

I have also seen contractors do lousy work.  One for my sister's cable TV company stapled the black coax right down the middle of the living room wall!  On the other hand, when I had a cable modem installed, about 20 years ago, the first guy that showed up wanted to run the coax along the baseboards & around doors etc..  I refused.  They then sent 2 men, who took 3 hours to fish the cable from one end of my condo to the other.  I also had them pull in a couple of runs of CAT5, so I could have network connections at the other end of my unit.  They did a very nice, neat job!

33 DHCP? must be a maintenance nightmare.

"When I was resolving I felt I was seeing too much traffic to East Aisa"

And how exactly did you determine that?  Do you know the root servers are - which TLD are you talking about?

The roots are mostly all anycast anyway.  Unbound will determine which NS it should normally talk to via how fast it responds, etc.

This might help you understand how unbound picks the NS to talk to or which ones it will try first etc..
https://www.unbound.net/documentation/info_timeout.html

If you were seeing lots of traffic to places your not familiar with my guess would be you had something on your network requesting that… When you forward you have no clue to where that answer might be coming from.. Since your just asking X.. With unbound you will know all the authoritative ns for a specific domain, etc.

And yes if the domain is using dnssec, it would be validated - if fails then it wouldn't give those results to the client that asked for them.  All the roots are signed.

For whatever reason, after I set the IP for the LAN interface and rebooted the first time, the DHCP server still seemed to be looking at the old subnet.  However, when I looked at the logs, it seemed to be trying to use the correct subnet.

I rebooted the server a 2nd time and when it came back up, the DHCP server was
using the subnet which corresponded with the IP address of the interface.

I guess in answer to one of my original questions, it appears the subnet is automatically set based on the IP address which is assigned to the corresponding interface.

Does anyone know how to use above workaround for Loopia when I need to only update a specific Subdomain?

@Liath.WW:

I think I may have stumbled upon something in the ISP modem config that could be causing this, though the times are different than the pfSense 5 minute issues.
In the IP-passthrough page, there is a Passthrough DHCP Lease. Default value is 10 minutes.  I changed to 1 day, hopefully this is the root cause and will fix things.

FYI, the modem is this one:

Manufacturer ARRIS
Model Number BGW210-700

I have many of the problems discussed here on this thread and also an ARRIS modem on a poor signal quality cable ISP connection.
Maybe we can share remedies and results

Some of the steps to remedy the situation I have taken are extreme for the time being:

Removed as many FQDNs from my firewall rules aliases tables as possible and used specific IP #'s instead
Disabled CRON automatic updates in pfblockerng (with 2 TLD Blacklist entries)
Disabled Gateway Pinger
Disabled Gateway monitoring "Action"
Disabled default blocks on RFC 1918 on WAN - my ISP uses 192.168.0 to establish DHCP
Defined about 7 or 8 public resolvers, including the ISP assigned ones for Unbound to forward Queries to

I am not happy about having to do any of this but perhaps all I need to do is disable gateway monitoring action on WAN to prevent all the subsequent issues cause by unbound restarting

How did you get into the ARRIS to increase the length of DHCP leases ?
My solution was to spoof a fixed IP config in the WAN interface - which seems to work for a while but I have backed that out as a solution

Perhaps if we studied the WAN DHCP client Advanced options in pfSense there might be something there of value to us ? I don't know much about what is listed there as of now.

No problem, glad to heard it worked!

@giftedpenguin:

Currently, the only way they can connect is by using their IP address, but with DHCP that doesn't really work. Looking for a better solution than just using static IP's or IP reservations.

Devices that must be reached from LAN or outside should have a IP that "doesn't move".
When the DHCP pool is bigger as the number of LAN devices, then the IP that the DHCP server hands out will be pretty "static", but could move.
So - no need to use static information, but you'll be needing DHCP Static mappings.

Nice side effect : check the "DHCP Static mappings" check in the DNS Resolver, and then no need to use IP addressees anymore - use the device name.
When I VPN into my company network, I can access my company "Windows 2012 server" just fine (RDP) - never needed to use an IP.

Hi,

I got the same issue today. Did you solved it?

Regards,

Eric

I have come to know it. This post is very much for you.

Tengo una buena respuesta de este hilo.

hi IOAN,

Can I have a step by step process on how to bind NS. Please help.,

Thanks, Den

Go to command line to get more detailed answers.

Use nslookup & dig to find out where your DNS answers are coming from.

You don't say which interface looses dhcp service, or provide other relevant detail that would enable you problem to be solved, like how your vpn is configured address wise.

It could be that your tunnel network address range clashes with your local address range, and routing goes bad.

Can you test your config in a sandpit with a pair of VM pfsense in your virtual environment?

You could try https://github.com/CyberShadow/dhcptest, to see what is going on from client side.

A package capture on the affected interface could also be insightful.  Capture on pfSense then download to Wireshark for detailed inspection.