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

- [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