Why is it so slow to give an answer from the dns resolver itself ?

[p_bear]

Hello,

I've set pfsense as the dns resolver, and configured it in forwarding mode.
When I do a dns lookup, I get such result:

So from my understanding, it gives the answers from the 2 dns servers that I've configured (System/General Setup). Then, in same time hopefully, pfsense enters the answer in his own cache. And only after that, it gives me the answer (the answer from 127.0.0.1).

Is it right ? Does it explain why it uses ~120msec more ?!

Thank you

[CiscoX]

@p_bear

I don't' have that problem here.

[johnpoz]

You got an answer back from 1.1.1.1 in 3ms? That seems pretty freaking low - are you in the DC where 1.1.1.1 has their services ;)

[CiscoX]

@johnpoz
Yeah, it's pretty loud in here
I do get 3-4ms most of the time, well that's what DNS Lookup says in my pfSense
Maybe i have some misconfiguration in my settings?

[johnpoz]

@ciscox haha.. I like the loud comment. Only someone that has actually been in a DC prob gets that joke ;)

I am not a forwarder sort of guy.. I will do my own resolving thank you very much..

But 3ms is pretty much lan speeds.. So unless something upstream of you caching and intercepting - must be freaking close to one of their pops..

I am not sure exactly the dns lookup gui php thing does it actual query.. I haven't bothered to look at the code.

I would think a better test might be to just query directly 127.0.0.1 from console or a client on your lan. And whatever your forwarding to directly and compare.

But yeah if you ask 127.0.0.1 for something.xyz.tld and it has to forward, its a given that its going to have to be n+x for that response time.. 145 does seem a bit slow.. If your getting a response in 27ms from 1.1.1.1.. But again not exactly sure how that gui look up thing is working.. Maybe it has to wait from time of both of them to response, and they were asked sequentially or something?? I setup forwarding and tested.. and I don't get such a long response from the local.

I would really do a specific query towards 127.0.0.1, and then directed queries towards who your forwarding too.. Once its cached locally doesn't really matter anyway.

Happy to try and duplicate whatever you might be seeing as a problem.. But like I said, I don't forward - you couldn't ever get me to forward my queries to somewhere else.. When I can resolve what I want directly..

[bingo600]

@johnpoz said in [Why is it so slow to give an answer from the dns resolver]

But like I said, I don't forward - you couldn't ever get me to forward my queries to somewhere else.. When I can resolve what I want directly..

I'm using forward to my own two local bind9 linux servers

It was (in my setup) the only thing that made sense...
I had a working isc-dhcpd "dhcp" setup (with. a working ddns system) , when
implementing pfSense.

And if wanted to resolve ddns , it was easy just to point pfSense at my local bind9's.

Now i can have ddns resolving , and still avoid setting the dreaded

Else i would totally agree with @johnpoz ...
Keep your DNS subsystem local , it's actually doing a nice job.
Except for the dreaded unbound DDNS restarts

/Bingo

[Bob.Dig]

I am seeing the same here, does look sub optimal.

Spoiler

@bingo600 Hiding that precious local IPs?

[bingo600]

@bob-dig
Yupp ... Better safe than .....

[Cool_Corona]

@bingo600 First search gives me long answer times, but subsequent tries to same domain gives me 1 ms since they are getting cached in the DNS resolver.

[bingo600]

@cool_corona
That would w 99% certainty be the same here.
Bind9 is caching the ansver.

And my guess is that the wife keeps google.com "cached"

I use DDGG , but SWMBO wants google.

What i meant w. the above was just , that it can be feasible to use forwarders.
If one has a reason for.

Ie. on the job where pfsense is the main resolver. I was asked (by CORP) to use (forward) to Cisco Umbrella DNS'es. As a security precaution.

/Bingo

[Cool_Corona]

@bingo600 said in Why is it so slow to give an answer from the dns resolver itself ?:

@cool_corona
That would w 99% certainty be the same here.
Bind9 is caching the ansver.

And my guess is that the wife keeps google.com "cached"

I use DDGG , but SWMBO wants google.

What i meant w. the above was just , that it can be feasible to use forwarders.
If one has a reason for.

Ie. on the job where pfsense is the main resolver. I was asked (by CORP) to use (forward) to Cisco Umbrella DNS'es. As a security precaution.

/Bingo

HAHAHAHAHAHAH thats kind a funny....

[p_bear]

@bingo600

From the pfsense itself:

set domain=aliexpress.com
dig @9.9.9.9 $domain | grep time
;; Query time: 357 msec
dig @1.1.1.1 $domain | grep time
;; Query time: 50 msec
dig @127.0.0.1 $domain | grep time
;; Query time: 657 msec

set domain=twitter.com
dig @9.9.9.9 $domain | grep time
;; Query time: 47 msec
dig @1.1.1.1 $domain | grep time
;; Query time: 34 msec
dig @127.0.0.1 $domain | grep time
;; Query time: 244 msec

If I disable forwarding mode:

set domain=twitter.com
dig @9.9.9.9 $domain | grep time
;; Query time: 41 msec
dig @1.1.1.1 $domain | grep time
;; Query time: 43 msec
dig @127.0.0.1 $domain | grep time
;; Query time: 302 msec

set domain=aliexpress.com
dig @9.9.9.9 $domain | grep time
;; Query time: 52 msec
dig @1.1.1.1 $domain | grep time
;; Query time: 34 msec
dig @127.0.0.1 $domain | grep time
;; Query time: 112 msec

Btw I was using forwarding mode to avoid my ISP from spying me at dns level (with DOT).

[johnpoz]

@p_bear said in Why is it so slow to give an answer from the dns resolver itself ?:

Btw I was using forwarding mode to avoid my ISP from spying me at dns level (with DOT).

You understand with using dot.. The only query from what you gave that would be using DOT would be when you query 127.0.0.1

Directed queries or queries showing 1.1.1.1 via the dns gui looking wouldn't be using DOT.. So yeah a DOT query and response is going to be much slower than not using DOT quite often. No matter how much the DOT providers want you to think otherwise ;)

You could validate that yourself with simple sniff on wan when you do the queries.. But sure queries via that gui showing some other NS, isn't using DOT.. Let me setup the forwarding again and test that to be sure... But I doubt what the gui shows is via a DOT query when it shows anything other than localhost..

I will have to spend a few minutes setting up DOT.. but can tell you for sure pfsense itself does not use dot when talking to nameservers listed in general.. The only way to use dot is via unbound doing the query.. So those queries shown in the gui I find highly highly unlikely that anything other than to localhost could of been done via dot..

[p_bear]

@johnpoz said in Why is it so slow to give an answer from the dns resolver itself ?:

You understand with using dot.. The only query from what you gave that would be using DOT would be when you query 127.0.0.1

The dns query tool in the Diagnostic menu of course it does not use DOT. It's same when I manually use dig.
I'm using DOT for the pfsense DNS resolver.

[johnpoz]

Again - that would explain the difference in the query.

I ask 1.1.1.1 without dot, its going to be faster than if I ask via dot.. Which is what would be happening via your 127.0.0.1 query

Plus you prob have dnssec still selected don't you? Which is pointless if forwarding.. And just going to cause extra traffic. Which will slow down responses

[p_bear]

@johnpoz

I've unchecked Use SSL/TLS for outgoing DNS Queries to Forwarding Servers.
I still get a difference. :(

[johnpoz]

Well I can not duplicate that.. So I again turned on just normal forwarding, no dot. No dnssec

You can see when I first query there is response time, then if query again response is zero -- because its cached.

Asking unbound shouldn't have any signification additional latency.. Sure there could be few ms, and there is going to be deviation for any specific 1 off query, etc. But maybe when unbound asked whoever there was a delay in that response.

I suggest you sniff, and up your logging level.. And do more than just query of 1 fqdn.. Your going to have to do more testing to show that unbound is adding latency to that extent.. I think your seeing outlayers, or do not have a full picture of what is happening during the query.