About caching feature

[vp1981]

Hello.
I have a few questions about TTL cache feature.

1. If I set cache_min_ttl=600, does it mean that for any response with TTL less than 600 dnscrypt-proxy will set TTL=600?
2. If I set cache_max_ttl=3600, does it mean that for any response with TTL greater than 3600 dnscrypt-proxy will set TTL=3600?
3. If I have these settings in dnscrypt-proxy.toml and some host (dynDNS) has DNS record with TTL=60, does that mean that DNS response returned by dnscrypt-proxy (say, with dig or drill) will have TTL less than or equal to 600?

I tested a bit with some domain (aradzh.crabdance.com) that has TTL=60, but TTL returned by dnscrypt-proxy varies from 299 to 3599. Is this correct behavior?

Of course, I could be completely wrong and cache_min|max_ttl has nothing to do with DNS TTL at all.

[ghost]

1. Yes.
2. Yes.
3. Yes.

Note that it also subtracts the elapsed time. So if you look up the cached entry after 10s the TTL would be 10s less than it originally was.

[vp1981]

Hello livingentity.

Thank you, your answers support my thoughts about how this feature works.

Nevertheless, I think there is something fishy in logic: I would assume that TTL must be less than 600 and never greater but collected data show that TTL could be greater than cache_max_ttl so it is set to 3600. I suspect this is due to unsigned arithmetic (I didn't check but I looked briefly into the code): if a and b are both unsigned int32 and a < b then a-b overflows and gives number close to UINT32_MAX.

If you wonder I could post gathered data. I ran a script about a day but now I think I've chosen wrong repetition time: half an hour, it should be, e.g., 23 minutes.

[ghost]

Hello vp1981.

Yes, it would probably help to know how exactly you measure your results. Also, is there a chain of caches or only dnscrypt?

[vp1981]

Hello livingentity and all.

It took a time to collect data, but now I can share them to discuss what is going on.

it would probably help to know how exactly you measure your results

I just do a local DNS query using dig, here is the script: dns-ttl-ts.sh. The systemd runs the script by this timer and service.

is there a chain of caches or only dnscrypt?

Hmm, both yes and no (see the script). dig queries dnscryt-proxy directly. The dnscrypt-proxy is run by systemd, it listens on 5353 port, while dnsmasq listens on 53 port and queries dnscrypt-proxy in turn.

I gathered data on three hosts with the following settings in dnscrypt-proxy.toml

• with caching:

cache = true
cache_min_ttl = 300
cache_max_ttl = 3600

• without caching:

cache = false
cache_min_ttl = 300
cache_max_ttl = 3600

(yes, I changed only one line). The data are written into file with five columns, the TTL returned by dnscrypt-proxy is in fourth column. Data from host1, host2 and host3 with caching. And here data from host1, host2 and host3 without caching.

P.S. Maybe I have to improve my little script to write not only these data, but also cache settings from dnscrypt-proxy.toml.

[ghost]

Thanks vp1981.

Don't have the time for a proper analysis right now but a few things:

1. I believed you when you said aradzh.crabdance.com has TTL = 60 but when I resolve it it's TTL = 3600. That explains why your measured TTLs vary from 299 to 3599.
2. Yesterday when investigating your issue I found a bug in TTLs for cached responses and commited a fix. Also Frank introduced rounding for TTLs. So the next version of DNSCrypt should give correct and more accurate TTLs.
3. Your data without caching has a few glitches in it with huge TTLs. Will look into it when I find the time.

[vp1981]

Hello,

Don't have the time for a proper analysis right now

Not urgent, but annoying.

I believed you when you said aradzh.crabdance.com has TTL = 60 but when I resolve it it's TTL = 3600. That explains why your measured TTLs vary from 299 to 3599.

Ouch...

$ dig NS com

; <<>> DiG 9.16.21 <<>> NS com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4173
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;com.                           IN      NS

;; ANSWER SECTION:
com.                    86400   IN      NS      e.gtld-servers.net.
com.                    86400   IN      NS      l.gtld-servers.net.
com.                    86400   IN      NS      g.gtld-servers.net.
com.                    86400   IN      NS      m.gtld-servers.net.
com.                    86400   IN      NS      j.gtld-servers.net.
com.                    86400   IN      NS      a.gtld-servers.net.
com.                    86400   IN      NS      f.gtld-servers.net.
com.                    86400   IN      NS      b.gtld-servers.net.
com.                    86400   IN      NS      d.gtld-servers.net.
com.                    86400   IN      NS      c.gtld-servers.net.
com.                    86400   IN      NS      h.gtld-servers.net.
com.                    86400   IN      NS      i.gtld-servers.net.
com.                    86400   IN      NS      k.gtld-servers.net.

;; Query time: 131 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Sep 24 21:16:27 +08 2021
;; MSG SIZE  rcvd: 256

$ dig NS crabdance.com @d.gtld-servers.net.

; <<>> DiG 9.16.21 <<>> NS crabdance.com @d.gtld-servers.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28348
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;crabdance.com.                 IN      NS

;; AUTHORITY SECTION:
crabdance.com.          172800  IN      NS      ns1.afraid.org.
crabdance.com.          172800  IN      NS      ns2.afraid.org.
crabdance.com.          172800  IN      NS      ns3.afraid.org.
crabdance.com.          172800  IN      NS      ns4.afraid.org.

;; Query time: 133 msec
;; SERVER: 2001:500:856e::30#53(2001:500:856e::30)
;; WHEN: Fri Sep 24 21:16:52 +08 2021
;; MSG SIZE  rcvd: 124

$ dig aradzh.crabdance.com @ns1.afraid.org.

; <<>> DiG 9.16.21 <<>> aradzh.crabdance.com @ns1.afraid.org.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19388
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 31551627a01fc25401000000614dcfbd35b51c8956d6ace7 (good)
;; QUESTION SECTION:
;aradzh.crabdance.com.          IN      A

;; ANSWER SECTION:
aradzh.crabdance.com.   60      IN      A       176.48.14.244

;; Query time: 259 msec
;; SERVER: 2607:f0d0:1e04:74::3#53(2607:f0d0:1e04:74::3)
;; WHEN: Fri Sep 24 21:17:21 +08 2021
;; MSG SIZE  rcvd: 93

$ dig aradzh.crabdance.com @1.1.1.1

; <<>> DiG 9.16.21 <<>> aradzh.crabdance.com @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2127
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;aradzh.crabdance.com.          IN      A

;; ANSWER SECTION:
aradzh.crabdance.com.   60      IN      A       176.48.14.244

;; Query time: 208 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri Sep 24 21:17:37 +08 2021
;; MSG SIZE  rcvd: 65

$ dig aradzh.crabdance.com @8.8.8.8

; <<>> DiG 9.16.21 <<>> aradzh.crabdance.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61806
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;aradzh.crabdance.com.          IN      A

;; ANSWER SECTION:
aradzh.crabdance.com.   60      IN      A       176.48.14.244

;; Query time: 252 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Sep 24 21:17:55 +08 2021
;; MSG SIZE  rcvd: 65

$ dig aradzh.crabdance.com @9.9.9.9

; <<>> DiG 9.16.21 <<>> aradzh.crabdance.com @9.9.9.9
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8365
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;aradzh.crabdance.com.          IN      A

;; ANSWER SECTION:
aradzh.crabdance.com.   60      IN      A       176.48.14.244

;; Query time: 232 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Fri Sep 24 21:17:59 +08 2021
;; MSG SIZE  rcvd: 65

$ dig aradzh.crabdance.com @208.67.222.222

; <<>> DiG 9.16.21 <<>> aradzh.crabdance.com @208.67.222.222
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35275
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;aradzh.crabdance.com.          IN      A

;; ANSWER SECTION:
aradzh.crabdance.com.   60      IN      A       176.48.14.244

;; Query time: 839 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Fri Sep 24 21:18:58 +08 2021
;; MSG SIZE  rcvd: 65

$ dig aradzh.crabdance.com @76.76.19.19

; <<>> DiG 9.16.21 <<>> aradzh.crabdance.com @76.76.19.19
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14428
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ce354f1372f3092201000000614dd05a09f2d1a9e8de813f (good)
;; QUESTION SECTION:
;aradzh.crabdance.com.          IN      A

;; ANSWER SECTION:
aradzh.crabdance.com.   60      IN      A       176.48.14.244

;; Query time: 231 msec
;; SERVER: 76.76.19.19#53(76.76.19.19)
;; WHEN: Fri Sep 24 21:19:22 +08 2021
;; MSG SIZE  rcvd: 93

$ dig aradzh.crabdance.com @94.140.14.14

; <<>> DiG 9.16.21 <<>> aradzh.crabdance.com @94.140.14.14
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7389
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;aradzh.crabdance.com.          IN      A

;; ANSWER SECTION:
aradzh.crabdance.com.   60      IN      A       176.48.14.244

;; Query time: 221 msec
;; SERVER: 94.140.14.14#53(94.140.14.14)
;; WHEN: Fri Sep 24 21:20:27 +08 2021
;; MSG SIZE  rcvd: 65

I would like to know from where you get TTL=3600 from.

I'm still thinking that if dnscrypt-proxy has cache_min_ttl=300 and cache_max_ttl=3600 the variation from 299 to 3599 is due to these settings.

Your data without caching has a few glitches in it with huge TTLs

That mysterious to me too. I don't get how it is even possible. Why such bizarre numbers.

Yesterday when investigating your issue I found a bug in TTLs for cached responses and commited a fix. Also Frank introduced rounding for TTLs. So the next version of DNSCrypt should give correct and more accurate TTLs.

Would be like to test this, but then I have to build package myself (not a problem) with these patches (I don't really known which exactly, may be it is worth to build just git HEAD).

[ghost]

I would like to know from where you get TTL=3600 from.

From a regular, unencrypted resolver that seemingly applies its own TTL. Sorry for that, I didn't expect it to give wrong results.

I ran a script about a day but now I think I've chosen wrong repetition time: half an hour, it should be, e.g., 23 minutes.

Why are running your tests for such a long time, is this necessary to achieve your results? Also those strange repetition times, not 30m but 23m, 727s, why?

[vp1981]

Why are running your tests for such a long time, is this necessary to achieve your results?

Dunno. I'll try to write more versatile test suite to use different repetition time and add more information (about used dnscrypt-proxy "provider").

Also those strange repetition times, not 30m but 23m, 727s, why?

I tried to avoid possible "edge" cases. First I chose 23 minutes, but in seconds it is a multiple of 60 (remember, that domain in question has TTL=60). Then I tried 729 seconds (a prime number) but it is 600 + 120 + 9, too close to a round number (10). Same for 601 and 701, so I took 727 seconds. Why did I choose a prime number? I don't know, but I read in some (good?) book that whenever possible, try to use a prime number to avoid probable "edge" effects.

[vp1981]

Update.

Now I gathered information for dnscrypt-proxy version 2.1.1. The same three host, caching is enabled: host1, host2, host3, and without caching: host1, host2, host3.

There is one glitch, but still I don't understand, is it correct that dnscrypt-proxy returns TTL greater than 300?

[ghost]

is it correct that dnscrypt-proxy returns TTL greater than 300?

Probably best to verify first if it actually does that by either using it directly with its resolve option or with dnsmasq completely removed.
Just to rule out it's something in your setup.

[vp1981]

Hello,

directly with its resolve option

I don't get this. I'm using

$ dig -p 5353 aradzh.crabdance.com @::1

while dnscrypt-proxy listens on 5353 port, including ::1 address. Or do you mean there is another way to "resolve" using dnscrypt-proxy?

I deliberately run dnscrypt-proxy and dnsmasq on different ports, though on the same host (three actually), and my script queries them both to figure out how them work with TTL.

[jedisct1]

There is the dnscrypt-proxy -resolve example.com command.

[vp1981]

Hello jedistc1 (Frank)!

-resolve uses local resolver not dnscrypt-proxy as I see and doesn't return TTL. I have two other hosts which uses dnscrypt-proxy directly, I'll test dnscrypt-proxy on them and report back.

[vp1981]

Hello.

News on the issue.

This time I tested dnscrypt-proxy on four hosts (hA, hB, hC and hD) which run only it and not dnsmasq. The hA and hB use dnscrypt-proxy "directly" for resolving (it listens on port 53 and /etc/resolv.conf uses it), while hC and hD run dnscrypt-proxy on 5353 port (see this script).

As before, I tested with the cache on and off, and here the results:

• host hA, cache on and off;
• host hB, cache on and off;
• host hC, cache on and off;
• host hD, cache on and off;

Again, there are some "big" numbers, but they are within MIN MAX limits. Still, I think there is room for improvement.

Besides that on hosts hA and hB I also ran

$ dnscrypt-proxy -config /etc/dnscrypt-proxy/dnscrypt-proxy.toml -resolve aradzh.crabdance.com

and got following results:

• host hA:

Resolving [aradzh.crabdance.com] using 127.0.0.1 port 53

Resolver      : 94.242.59.35

Canonical name: aradzh.crabdance.com.

IPv4 addresses: 37.20.110.35
IPv6 addresses: -

Name servers  : no name servers found
DNSSEC signed : no
Mail servers  : no mail servers found

HTTPS alias   : -
HTTPS info    : -

Host info     : -
TXT records   : -

• host hB:

Resolving [aradzh.crabdance.com] using 127.0.0.1 port 53

Resolver      : 84.200.70.40

Canonical name: aradzh.crabdance.com.

IPv4 addresses: 37.20.110.35
IPv6 addresses: -

Name servers  : no name servers found
DNSSEC signed : no
Mail servers  : no mail servers found

HTTPS alias   : -
HTTPS info    : -

Host info     : -
TXT records   : -

No TTL, so no useful information for me, but I can see which resolver is used.

[ghost]

Thanks, that's much more useful.

With cache=false DNSCrypt doesn't apply it's own TTL but instead gives the original result from the resolver. So it seems some resolvers sometimes give wrong responses. It should be a coincidence that they max out at 3600 and not be related to DNSCrypt's cache_max_ttl.

If that's true it would also explain the results with cache=true.

I'll have a closer look this weekend.

[ghost]

I give up on this. I ran some longtime tests and the dnscrypt responses are always ok (well, some rare server timeouts but that seems unrelated). No clue what's going on here, sorry vp1981.

[vp1981]

Ok. I changed settings for cache, if there will be something new, I'll report.