Some IPv6-DNS/HTTPS-type lookups are not being altered by "Override minimum TTL"

donald2612 commented 2 years ago

[x] I am running the latest version
[x] I checked the documentation and found no answer
[x] I checked to make sure that this issue has not already been filed

Issue Details

AdGuard Home Version: v0.107.7 Channel: release Go version: go1.17.9 Commit time: 2022-06-06 17:10:40 +0200 CEST GOOS: linux GOARCH: amd64 Race: false

Version of AdGuard Home server: *0v.107.7
How did you install AdGuard Home:
- Github release
How did you setup DNS configuration:
- Upstream TLS lookups
If it's a router or IoT, please write device model: *AMD64 or Raspberry 3
CPU architecture: *AMD64, ARMv71
Operating system and version: *Ubuntu 22.04 LTS / Raspberry Bullseye

Expected Behavior

I would like to maximize the cache-usage of AdGuard and minimize upstream lookups through tweaking "Override minimum TTL". Using Ipv4/Ipv6-dualstack lookups are done with a override value of "7200", leading to the result, that one domain should be only found once in the upstream logs every 2 hours (7200), reducing upstream usage to a minimum.

Actual Behavior

First behaviour

I can observe several AAAA-lookups not being altered by AdGuards mincache when 'digging' them (while their A-lookups do):

GoogleDNS returns:

; <<>> DiG 9.16.1-Ubuntu <<>> pop3.web.de AAAA @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59129 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;pop3.web.de. IN AAAA

;; AUTHORITY SECTION: web.de. 600 IN SOA ns-webde.ui-dns.de. dnsadmin.1und1.de. 2005099693 28800 7200 604800 600

;; Query time: 23 msec ;; SERVER: 8.8.8.8#53(8.8.8.8)

AdGuard returns:

; <<>> DiG 9.16.1-Ubuntu <<>> pop3.web.de AAAA ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18891 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;pop3.web.de. IN AAAA

;; AUTHORITY SECTION: web.de. 533 IN SOA ns-webde.ui-dns.de. dnsadmin.1und1.de. 2005099693 28800 7200 604800 600

;; Query time: 51 msec

The difference in A-lookups with this domain seems to be, that its TTL is following the "authority section" TTL, which is always 600. This doesn't get altered by AdGuard.

Second example

Google returns

; <<>> DiG 9.16.1-Ubuntu <<>> teams.events.data.microsoft.com AAAA @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3616 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;teams.events.data.microsoft.com. IN AAAA

;; ANSWER SECTION: teams.events.data.microsoft.com. 24 IN CNAME teams-events-data.trafficmanager.net. teams-events-data.trafficmanager.net. 35 IN CNAME onedscolprdwus09.westus.cloudapp.azure.com.

;; AUTHORITY SECTION: westus.cloudapp.azure.com. 35 IN SOA ns1-02.azure-dns.com. msnhst.microsoft.com. 10001 900 300 604800 60

AdGuard returns

; <<>> DiG 9.16.1-Ubuntu <<>> teams.events.data.microsoft.com AAAA ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1870 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;teams.events.data.microsoft.com. IN AAAA

;; AUTHORITY SECTION: eastus.cloudapp.azure.com. 39 IN SOA ns1-201.azure-dns.com. msnhst.microsoft.com. 10001 900 300 604800 60

This is the same behaviour with a 60 second TTL not getting altered.

Second behaviour

I can observe many lookups of HTTPS-type originating from Apple-devices to "gateway.icloud.com" I haven't found out yet how to 'dig' those type of records, but TTL seems also to be roughly 60 seconds, which obviously don't get cached either for longer.

If this type of record cannot be cached, could there be a way to block this type of record??

Thanks for your good work on the product!!

See you, Don

ainar-g commented 2 years ago

Sincere apologies for the very belated response.

The TTL override feature the way it is implemented today overrides only the TTLs of the RRs in the Answer section, not touching the Authority section. @ameshkov, I think, this should be changed in the dnsproxy module, what do you think? After all, the Authority section is taken into account when a NODATA response is cached.

Re. the HTTPS type, if your version of dig is recent enough, you can simply do dig IN HTTPS 'domain.example'. If it isn't, you can either use the TYPE65 alias (dig IN TYPE65 'domain.example') or use our dnslookup tool (env RRTYPE=HTTPS dnslookup 'domain.example').

donald2612 commented 2 years ago

Most welcome and thank you for your response - currently I block those emerging-domains per dnstype rule, if a change a in dnsproxy could manage that, I'd be very happy ;)

AdguardTeam / AdGuardHome