starred/AdGuardHome

Fork 0

mirror of https://github.com/AdguardTeam/AdGuardHome.git synced 2026-03-04 00:01:12 -05:00

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

New issue

Open

opened 2026-03-04 04:15:48 -05:00 by deekerman · 2 comments

deekerman commented

2026-03-04 04:15:48 -05:00

Owner

Originally created by @donald2612 on GitHub (Jun 28, 2022).

Originally assigned to: @ainar-g on GitHub.

I am running the latest version
I checked the documentation and found no answer
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

Originally created by @donald2612 on GitHub (Jun 28, 2022). Originally assigned to: @ainar-g on GitHub. - [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

deekerman added the

enhancement

external libs

labels

2026-03-04 04:15:48 -05:00

deekerman commented

2026-03-04 04:16:05 -05:00

Author

Owner

@ainar-g commented on GitHub (Sep 16, 2022):

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').

@ainar-g commented on GitHub (Sep 16, 2022): 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`][1] tool (`env RRTYPE=HTTPS dnslookup 'domain.example'`). [1]: https://github.com/ameshkov/dnslookup

deekerman commented

2026-03-04 04:16:05 -05:00

Author

Owner

@donald2612 commented on GitHub (Oct 17, 2022):

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 ;)

@donald2612 commented on GitHub (Oct 17, 2022): 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 ;)

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/AdGuardHome#3763

No description provided.

Rows
Columns