Pi-hole not caching when using dnscrypt-proxy

dnscrypt

#1

Expected Behaviour:

Pi-hole will forward the request to an upstream once and cache the response. Next time (within the TTL) pi-hole will answer the same request with the cached information.

Actual Behaviour:

All the sequential requests for the same name are forwarded to dnscrypt-proxy, noticed in the pi-hole log and by high response time in dig executed on client’s host (~20ms vs. 1-2ms).
Switching to Cloudflare resolver (w/o intermediary) or cloudflared as a proxy solves the problem.


Dig error using dnscrypt-proxy "Truncated, retrying in TCP mode"
#2

What is the time interval between subsequent requests for the same name?

When you dig the domain through dnscrypt-proxy, what is the returned TTL? And, if you do the same going to Cloudflare directly, do you get a different TTL?


#3

Requests were repeated almost immediately.
TTL values are different but not that small to miss the expiration:
$ dig bbc.com @1.1.1.1

; <<>> DiG 9.10.3-P4-Debian <<>> bbc.com @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11772
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;bbc.com. IN A

;; ANSWER SECTION:
bbc.com. 238 IN A 151.101.0.81
bbc.com. 238 IN A 151.101.64.81
bbc.com. 238 IN A 151.101.128.81
bbc.com. 238 IN A 151.101.192.81

;; Query time: 57 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri Oct 05 20:06:49
;; MSG SIZE rcvd: 100

$ dig bbc.com @127.0.0.1 -p 5353

; <<>> DiG 9.10.3-P4-Debian <<>> bbc.com @127.0.0.1 -p 5353
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30222
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;bbc.com. IN A

;; ANSWER SECTION:
bbc.com. 432 IN A 151.101.192.81
bbc.com. 432 IN A 151.101.0.81
bbc.com. 432 IN A 151.101.64.81
bbc.com. 432 IN A 151.101.128.81

;; Query time: 0 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Fri Oct 05 20:06:52
;; MSG SIZE rcvd: 100


#5

What confuses me is:

whereas, later, you wrote:

Does this mean that your dnscrypt-proxy answers within 0msec but your pihole-FTL still shows a notable delay? (see this question - for now - apart from the issue that the query is forwarded each time instead of being cached by pihole-FTL itself)


#6

Noticed that as well. I believe that was a result of caching in the dnscrypt-proxy itself, disabled it already.
Here is the recent result:

$ dig bbc.com @127.0.0.1 -p 5353

; <<>> DiG 9.10.3-P4-Debian <<>> bbc.com @127.0.0.1 -p 5353
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42094
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;bbc.com. IN A

;; ANSWER SECTION:
bbc.com. 295 IN A 151.101.128.81
bbc.com. 295 IN A 151.101.192.81
bbc.com. 295 IN A 151.101.0.81
bbc.com. 295 IN A 151.101.64.81

;; Query time: 248 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Sun Oct 07 23:18:37
;; MSG SIZE rcvd: 100

On sequential requests I see approx. 6-10 msec Query time.


#7

@AndrewZ could you also have a look here?

It’s still unclear what’s going on.


#8

@DL6ER thank you for referencing that, I see some progress there, so will follow.


#9

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.