@bmeeks said in Need help understanding DNS Leak:

Yes, a DNS Leak Test is only valid when you use a VPN. Go to the web site you linked and then read the topic "What is a DNS Leak Test?". There is a link near the top of that page.

What you are seeing otherwise is simply the public IP block "owner" of the IP address your provider is giving you for your WAN IP.

A "DNS Leak" means that when using a VPN, your DNS traffic does NOT go through the VPN and instead goes out in the clear to another server. Hence the term "leak". With a VPN configuration, the preferred path is for ALL traffic to go through the VPN tunnel.

Thanks for clarifying. That helps a lot.

i know this is old but when i did a google search i found this so i thought i would comment here. So i too replaced my Verizon FiOS router with a pfsense firewall/router. and sure enough every 24 hours i received the send error 65 message and everything would hang until i rebooted the pfsense. I started playing around with the DHCP settings on the WAN interface. When i set them to "freeBSD default" the problem went away. so the defaults listed in my protocol timing section are timeout=60 retry=3-- select timeout=0 reboot=10 backoff cutoff=120 and initial interval=10

so i am day 3 with no problems. i have asked the quality assurance team (my 14 year old daughter who is home 24/7 now because covid-19, with iPhone and iPad) to let me know of any problems. so far she and not generate any bug reports :)

Hi @johnpoz
thanks for your help, I appreciate it!

I did some further investigating. I compared the packet capture from one of the (semi-)failed lookups to a working one. It seems it tries to get the root servers (f.root-servers.net. and so forth) first. In the working case, it gets them immediately, and in the failed case, it attempts a few times, times out and continues on to get the A and AAAA records (which succeeds.)

On the console, I did a dig NS . and sure enough, it times out if using the PPP interface. Tried the same on a client connected through the provider router: works. So I guess the issue may come from something the provider box does when passing through PPPoE, or some obscure (or maybe only obscure to me...) DNS config. To prove this, I used another computer, established a PPPoE connection using its client (in this case MacOS's PPP client) -> same issue, cannot dig the root servers. Hmph.

Next thing to try is actually not using PPPoE pass-through, but using a modem in bridge mode. Unfortunately, that neutered provider supplied box cannot (easily) be convinced to work in bridge mode (and my AllNet modem has not yet arrived.) I do have a Lancom 1790VA router around, which can be put into bridge mode easily, I can't do this during the day, because I need the internet connection for my office VPN connection.

For those few of you still reading. Any ideas about the root cause (no pun intended :P)? Or a means of preventing unbound or dnsmasq from trying to get the root NSes?

No, that is not possible to accomplish in any supported manner.

@Bob-Dig Thanks for the input! Ended up being because 1.1.1.3 doesn't support DoT yet.

Then create a new vlan, and put devices that you want to do whatever xyz on that vlan, and devices you want to do abc on a different vlan that you setup that way and with rules you want, etc.

Yes it is definitely only IPv6 which does not work and as I reported if I tell it to monitor the LAN address it reports the internal IPv6 address correctly, so there is some definite issue in pfSense when somehow dealing with a IPv6 WAN address at least in my scenario. As I also said the problem occurs with other providers also.

@johnpoz said in DNS Resolver - getting IPv6 results when there is no IPv6?:

@mmiller7 said in DNS Resolver - getting IPv6 results when there is no IPv6?:

Previously it's been quite solid for a couple years.
Really you been running dot for 2 years? Just you jumped on it like day one? As to why it could of recently happened - I don't know the whole planet in their houses doing internet could have something to do with it ;) heheh

Actually yeah...started playing TLS back when it required manually adding entries to the config file because it wasn't a checkbox, and at that time also had to go thru figuring out which other web DNS hosts supported it. There weren't many! Once I fixed it so I only had DNS servers that properly supported DNSSEC and TLS as the only ones for pfSense to look at, things went very smooth from there on with no noticeable change in performance. Obviously if you put in a server that doesn't support the security features it breaks badly. Once I got it, I didn't touch it not wanting to break it more.

I think it was around the same time I discovered my ISP (Cox back where I lived at the time) was injecting code into HTTP pages, altering the pages in-flight to provide in-browser updates about their email services which was REALLY not cool. That's when I became more paranoid about my ISP tampering with my data.

Not so much I'm worried about ISP spying...but I do want some assurance the bits I get are the bits that were sent to me, unaltered by anyone inbetween. Which I don't think is an unreasonable expectation, and DNSSEC+TLS seemed a reasonable step to take given what I observed with plan HTTP traffic being modified at one point. I used to think it was stupid, until I had that experience. Now I (as much headache as it adds) agree it's worthwhile to add encryption to stuff in-flight.

That's my take on it anyway. I wish it wasn't necessary.

How is it "just a forwarder" if it's also providing DNS for my LAN hosts to find each other?

You mean like every single caching NS since the beginning of DNS has done?

Here is the thing - if you have problems with a client connecting to something - just check the dns with a simple cmd.. It takes like .3 seconds to do.. You don't have to sniff.. To see what dns is responding to you with.. Be it the record in X amount time, from cache or had to forward or resolve, or servfail, or NX, etc. etc.

I do, but this intermittent nature seems hard to figure out. If the application fails and I run the dig command it all looks good, now what? Run it again the app works. Later repeat. Drives me nuts.

I also am not fond of the ISP's DNS servers that redirect unknown lookups to random sketchy search sites

Nobody does - doesn't mean you have to forward to somewhere, resolve fixes that nonsense - and you get the info direct from the horses mouth...

I am under the impression "Query Name Minimization" helps with that? I would rather go to the most direct source possible when I can.

BTW if you don't want your local NS (unbound) to return IPv6, you can do that with simple
private-address: ::/0

In your unbound custom option box.. But that wouldn't of solved your issue, still wouldn't of work with you not being able to resolve the A record for the fqdn you were trying to get to.

I'll give that a shot. If I can at least make it so it fails completely vs getting an address that it thinks is good but can't possibly work, that would be an improvement (in my eyes).

@dotdash said in Changing LAN IP:

The 10.x range gives you the most chance of not encountering a conflicting subnet.

I find the 172.16.0.0 /12 range to be very rarely used. That's why I picked it for my network. I've only once seen it used elsewhere.

@jimp I'll investigate first, thanks again for your answers.

Ah - ok that explains it ;)

When you put in a domain as example.. its best to be sure its obvious that its a example domain.. if your thinking in German could see how that comes out, but to us that only understand the one langue and sometimes that is even a stretch.. It just looked like some valid domain name ;)

Glad you got it sorted.. left of period is always host or domain.. if only single domain to the right then its host.

host.domain (tld)

host.domain.tld

host.subdomain.domain.tld

etc..

Request that this thread be closed and deleted.

For some reason the examples I found online shows that domain overrides were needed for this and after more searching and testing, I now understand that Host Overrides are needed.

Additional question though, if I am tried to redirect ftp.us.debian.org do I put ftp in the host or ftp.us in the host?

Are you running it on a 8088 ?