DNS Resolver Timeouts
-
You got it.
I have to get back to you after Christmas for that benchmark test (which I'm familiar with as I used it before). I'm physically at site A right now and while troubleshooting another issue with IPsec, I accidentally lost access to site B's pfsense and no one is physically there to undo what I did.
As for the settings, they are exactly the same with the unbound settings I have site A and here they are:
I don't have a DNS server in the DNS settings under General because I don't need one. I'm using unbound as a "resolver" so it queries the root hints directly. In the settings that you've shown, it looks like you're using unbound as a forwarder too, why?
-
How is this not the same exact problem you had before.. If you have a shit isp, then you have a shit isp..
Your previous thread showed loss on your isp.. If either of these sites its on that isp, or whatever isp they have is loosing packets.. Then yes you can have issue, be it dns or anything else.
Doesn't matter if you forward or tunnel or whatever.. If your isp sucks it sucks.. Nothing pfsense can do about that.
Previous you had sniffs showing traffic leaving your wan, with no answer.. There is nothing pfsense can do to fix that..
-
@kevindd992002 said in DNS Resolver Timeouts:
it looks like you're using unbound as a forwarder too, why?
Forwarding Mode to 1.1.1.1 = general tab
as I try to achieve more privacy and greater security
CloudFlare / 853 DoT
-
@daddygo said in DNS Resolver Timeouts:
as I try to achieve more privacy and greater security
Well that sure isn't doing anything about that..
-
@johnpoz said in DNS Resolver Timeouts:
Well that sure isn't doing anything about that..
I say I'm trying
at least I don't interrogate root servers through my own ISP, hihihihi
-
@johnpoz said in DNS Resolver Timeouts:
How is this not the same exact problem you had before.. If you have a shit isp, then you have a shit isp..
Your previous thread showed loss on your isp.. If either of these sites its on that isp, or whatever isp they have is loosing packets.. Then yes you can have issue, be it dns or anything else.
Doesn't matter if you forward or tunnel or whatever.. If your isp sucks it sucks.. Nothing pfsense can do about that.
Previous you had sniffs showing traffic leaving your wan, with no answer.. There is nothing pfsense can do to fix that..
Right, I just actually continued that old thread to this thread to make it "cleaner". The only new information I have now is that I tried with dnsmasq and it seems to have no timeouts. As to why, I don't know. But I was still having problems with unbound set as forwarder.
If you see my packet captures in the OP of this thread, it still does show traffic leaving the WAN and not getting any replies back. You're still right, I'm still pushing hard for my ISP to fix this shit, but what I don't understand is why dnsmasq seems to be working just fine?
-
@kevindd992002 said in DNS Resolver Timeouts:
I'm still pushing hard for my ISP to fix this shit
Indeed, if you have a shitty ISP, there’s nothing you can do, but my tests suggested above they are caught quickly
-
@daddygo said in DNS Resolver Timeouts:
I say I'm trying
But all you have accomplished is handing your info off to someone else on silver platter. With explicit trust of what they hand you back.. Your sure not hiding anything from your ISP that.. Since they still know every IP you go to, and simple if they wanted to to just sniff your sni for any https traffic to know what specific domain your going to.. Just like they could with your dns.
So what your trying to hide from the root servers?
Oh - the other thing you did accomplish is slowing down dns.. Guess you got that going for you ;)
-
@johnpoz said in DNS Resolver Timeouts:
@daddygo said in DNS Resolver Timeouts:
I say I'm trying
But all you have accomplished is handing your info off to someone else on silver platter. With explicit trust of what they hand you back.. Your sure not hiding anything from your ISP that.. Since they still know every IP you go to, and simple if they wanted to to just sniff your sni for any https traffic to know what specific domain your going to.. Just like they could with your dns.
So what your trying to hide from the root servers?
Oh - the other thing you did accomplish is slowing down dns.. Guess you got that going for you ;)
@DaddyGo sorry but I'm on @johnpoz on this one. He is completely right. If you're using unbound, then its primary purpose should be a "resolver" like what I've been telling you with my earlier posts. I guess you misunderstood again.
-
@johnpoz said in DNS Resolver Timeouts:
Oh - the other thing you did accomplish is slowing down dns.. Guess you got that going for you ;)
I'm not that simple.....
look at the following...it's not that bad (3 ms)
which I did not show...... where is the ISP here.....
+++edit:
our ISP can't even set foot on us, only the VPN IP can see and it's done -
Handing info over to company B, because you don't trust company A - while company A still has all this info (if they want it). When you don't even know if company A is doing anything with that info in the first place in no way shape or form increasing privacy or security. If anything it lowers both of those..
I could see doing dot if for example you knew that company A was intercepting your dns and messing with it..
But unless company A is doing that, forwarding all your dns to company B does not provide anything of value..
edit:
Your doing a query through a vpn, to cloudflare over dot in 3 ms.. Sorry but BS!!edit: So you have hidden your traffic from your ISP with your vpn.. .You have hidden your IP from the bad old root servers. But now you have handed over all your dns to xyz dns provider.. So how does that again do anything for privacy or security... You have just handed over all your info on a silver platter is all..
You have just traded where you going via IP and sni from your isp to your vpn provider.. How does that improve anything? Again unless you know your isp is messing with this traffic or filtering it, etc.
-
@johnpoz said in DNS Resolver Timeouts:
Your doing a query through a vpn, to cloudflare over dot in 3 ms.. Sorry but BS!!
I know your opinion on this theme (DNS) John, so I do not argue...
indeed, you are half right, but he / she who does nothing will stick his / her head in the sand...or rather I quote
:
As Edward Snowden says:
“Arguing that you don’t care about the right to privacy because you have nothing to hide is no different than saying you don’t care about free speech because you have nothing to say.”
+++edit:
otherwise pls. name a secure third party DNS provider, 1.1.1.1 is only because we have a lot of services running on them, otherwise we use ExpVPN DNS servers / VPN servers
They run in RAM and restart every 24 hoursgood old root servers:
-
@kevindd992002 said in DNS Resolver Timeouts:
I guess you misunderstood again.
for sure, that's right
-
@daddygo So to try and resolve this problem for Site B, I want to use unbound on Site B and forward all requests to the unbound in Site A (which acts as a real unbound, not forwarding, DNS server). The problem is when I do this, I still get DNS query timeouts even though the unbound server in Site A is perfectly working. This is randomly happening and is evident when shows me entries with a "retried" status:
When I do a DNS bench test, I get 100% results but then again this test is only ran for a very few seconds and does not catch when the drops are happening:
I also get a fairly stable IPsec tunnel between the two sites:
So I'm not sure why there are DNS drops here. How can I troubleshoot further?
-
-
You have a binding issue there.. you have something using the same port already trying to run bind with control 953? Something else.
If you can not bind then no you can not sent to..
What else do you have running that could be trying to use 53 or 953? Do you have bind installed?
Or you trying to bind to an address that is not there, like a vpn interface - use localhost as your outbound interface.
-
@johnpoz said in DNS Resolver Timeouts:
You have a binding issue there.. you have something using the same port already trying to run bind with control 953? Something else.
If you can not bind then no you can not sent to..
What else do you have running that could be trying to use 53 or 953? Do you have bind installed?
Or you trying to bind to an address that is not there, like a vpn interface - use localhost as your outbound interface.
Well, I mean I have dnsmasq disabled, of course. I don't have BIND installed. These are all my packages:
These are my outbound interfaces:
So yes, I'm binding to a VPN interface. I was using only localhost before (because that was your suggestion when we were talking another issue) but that was when I was using OpenVPN where outbound NAT through the OpenVPN interface is actually working. Outbound NAT is needed so that the return traffic for DNS requests from one site to another comes back properly to the source device. Now that I'm using an IPsec tunnel, outbound NAT does not work and is a known issue so I didn't have much choice but to use those individual interfaces as outbound interfaces in unbound. Does it matter though?
-
Well my take is that you having issues with ipsec interface then.. If the connection is updown or having issue then sure unbound could have issues sending on that interface.
Not sure how you think sending dns over a vpn is going to fix a connectivity problem.. If you have connectivity issues over this connection, then your going to have problems..
Putting the traffic inside a tunnel is just going to make it harder to troubleshoot that..
-
@johnpoz said in DNS Resolver Timeouts:
Well my take is that you having issues with ipsec interface then.. If the connection is updown or having issue then sure unbound could have issues sending on that interface.
Not sure how you think sending dns over a vpn is going to fix a connectivity problem.. If you have connectivity issues over this connection, then your going to have problems..
Putting the traffic inside a tunnel is just going to make it harder to troubleshoot that..
That's the thing, the IPsec interface is very stable (as you can see in the graph ping monitor). I'm also using it for a couple of site-to-site traffic traversal and I don't have any issues with it.
Well, since the IPsec tunnel is stable, forwarding DNS requests to the DNS server on the other side "can" server as a workaround. I'm just testing it because sending over DNS requests from a branch site to a main site in an enterprise environment is kinda common so why not try it in my home setup.
-
Well your remote site clearly doesn't think something is stable or is having issues if your getting errors like you posted..
You have something wrong that is clear - what that something is, is the tricky part.. If your vpn is stable - why not move the dns function off the pfsense box and just route the traffic through pfsense.