pfSense English Support > DHCP and DNS

DNS resolver & DHCP

(1/1)

mtk:
Hey,
My pfSense (2.4.2-RELEASE-p1) to use DNS Resolver in Forwarding Mode.
In the general settings I have Quad9's IPs:

* P: 9.9.9.9
* S: 149.112.112.112
The DHCP server is indeed setting the clients to use 192.168.1.1 (the pfSense IP) as the router, but every now and then (very often lately) the clients cannot resolve address for a few minutes, which really feels like lost of internet access.
Checking ping to any direct IP (i.e 8.8.8.8) does get a response during that "DNS resolution outage" time.

I can't find anything in the logs regarding this problem and pfSense itself seems to be able to route when I check in Diagnose -> Traceroute.

Any idea what could be the problem?

Thanks,
M.

jtodd:
Hi -
  Saw you seem to be having problems with Quad9 addresses - we're interested in seeing if it's a problem with us, with pfsense, or the network.  I happen to be involved in that project. Can you send us a few bits of debug data (support@quad9.net) done from the command line of your pfsense box:

dig @9.9.9.9  id.server txt ch +short

Also, when those issues are happening, see if you can get responses back from "ping" to 9.9.9.9.  If not, then what does "traceroute 9.9.9.9" show?

I'd be interested in seeing if you get different results from a host "inside" your NAT on those ping and traceroute tests as from directly from pfsense which I assume has a "real" external IP.

mtk:

--- Quote from: jtodd on February 10, 2018, 04:57:22 pm ---Hi -
  Saw you seem to be having problems with Quad9 addresses - we're interested in seeing if it's a problem with us, with pfsense, or the network.  I happen to be involved in that project. Can you send us a few bits of debug data (support@quad9.net) done from the command line of your pfsense box:

dig @9.9.9.9  id.server txt ch +short

--- End quote ---
Thanks for stepping in!

From inside the pfsense box, this would reply with: "res100.ams.rrdns.pch.net"
(btw, it's the same from a MacBook connected to the same network)


--- Quote from: jtodd on February 10, 2018, 04:57:22 pm ---Also, when those issues are happening, see if you can get responses back from "ping" to 9.9.9.9.  If not, then what does "traceroute 9.9.9.9" show?

I'd be interested in seeing if you get different results from a host "inside" your NAT on those ping and traceroute tests as from directly from pfsense which I assume has a "real" external IP.

--- End quote ---
The issue didn't happen (or at least I wan't able to "catch" it), but I did check a simple traceroute from the MacBook, the pfSense box and the modem itself, I got interesting results:

This is from inside the modem (provided by the local ISP):

--- Code: ---traceroute to 9.9.9.9, 30 hops max through WAN1 protocol ICMP
  1  85.144.96.1           10 ms
  2  10.10.10.105          10 ms
  3  80.249.208.250        10 ms
  4  9.9.9.9               10 ms
Trace complete.

--- End code ---

This is from both a MacBook connected to the same network:

--- Code: --- traceroute 9.9.9.9
traceroute to 9.9.9.9 (9.9.9.9), 64 hops max, 52 byte packets
 1  my.pfsense.box (192.168.1.1)  1.552 ms  0.952 ms  1.017 ms
 2  192.168.5.1 (192.168.5.1)  2.531 ms  1.203 ms  0.851 ms
 3  1-96-144-85.ftth.glasoperator.nl (85.144.96.1)  8.260 ms  6.270 ms  7.725 ms
 4  10.10.10.105 (10.10.10.105)  6.469 ms  7.018 ms  6.727 ms
 5  amsix.pch.net (80.249.208.250)  7.173 ms  7.313 ms  7.158 ms
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * *

--- End code ---

And this is from the pfSense box itself:

--- Code: ---/root: traceroute 9.9.9.9
traceroute to 9.9.9.9 (9.9.9.9), 64 hops max, 40 byte packets
 1  192.168.5.1 (192.168.5.1)  0.355 ms  0.211 ms  0.150 ms
 2  1-96-144-85.ftth.glasoperator.nl (85.144.96.1)  5.439 ms  5.280 ms  5.268 ms
 3  10.10.10.105 (10.10.10.105)  5.369 ms  5.457 ms  5.440 ms
 4  amsix.pch.net (80.249.208.250)  6.757 ms  6.978 ms  11.428 ms
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *

--- End code ---



Are there any issue in AMS I should know about?

jtodd:
Nothing is wrong with AMS servers in recent weeks that I can find... but let's add some debugging.

Your first test from the modem is using ICMP as the "traceroute" protocol, and the Macbook-based tests use standard (for traceroute) UDP packets to high-value ports, which receive an ICMP destination unreachable reply (which is the "right" way to do it.)  In any case, Im not sure that the traceroutes show enough detail for me to do a lot of debugging, but it is interesting that they don't get all the way to 9.9.9.9 with UDP, but I'm pretty sure that isn't related to any intermittent failures that you might be seeing (though it's still curious.)

What is the "outside" address of your pfSense box?  If you don't want to reveal that here, that's fine -just send mail to support@quad9.net and we can pick up the discussion there.

I know this isn't the answer you're looking for, but we haven't seen any complaints about AMS and it's one of our most-used POPs.  Now, that doesn't mean there is nothing wrong - it just might be that it's intermittent enough that nobody is noticing.  I'm really interested in any failures or significant delays that you're seeing, and if at that time there are any packets lost to 9.9.9.9 (maybe set up a slow steady ICMP echo that is always running in a window so you don't have to start it?) during the times that you see problems, and some of the domain names that you're looking up during the service interruption.

Also: unbound should "just work" with DNS-over-TLS that we operate on Quad9.  There's a few threads here on that (https://forum.pfsense.org/index.php?topic=138966.0 for starters) Perhaps don't try to mix this in just yet, but it might be interesting in the future for you to encrypt your outbound queries.

JT

Navigation

[0] Message Index

Go to full version