AdGuardHome Few questions about AdGuard Home Install Script

[Tomo]

The cache you are talking about is the one that is activated during the installation phase by answering "Y" to the question ( Do you want to run AdGuardHome as a local caching DNS service which includes router traffic?) ?
Because i selected "N" and as i understand not using unbound for a simple configuration it is better to activate it.

 

[SomeWhereOverTheRainBow]

Once Unbound builds the cache AGH is fed with under 1ms responses. With or without middle cache the result is the same. Middle cache because the browsers keep DNS cache as well. If there is a difference - not easily user measurable.

I’ve run it in all configurations and the fastest all the time was Google upstream and AGH with its cache enabled. Nothing beats big public DNS servers cache. Google, OpenDNS and Cloudflare are the fastest in my area.

The noticeable difference comes from you not using the cache for a query that is typically issued a blocked response meaning AdGuardHome would have to work harder to block since it will not cache its own blocked responses. Unbound is not caching the blocked responses from Adguardhome. Therefore, Unbound cache is only benefiting the queries AdGuardHome does not block. No different from you querying goggles, cloudflair, or squad9. You would intentionally be causing AdGuardHome to perform poorly at what it is designed to do, all so it wont cache the unblocked answers from Unbound Cache. When you use goggles, cloudflair, or squad9, do you turn off AdGuardHomes Cache then so you could benefit from their upstream cache more?

 

[Tech9]

The noticeable difference

No noticeable difference observed.

When you use goggles, cloudflair, or squad9, do you turn off AdGuardHomes Cache then so you could benefit from their upstream cache more?

No, because it becomes my first local cache. Upstream server cache is 20ms, local is 1ms. When Unbound is used "upstream" cache for AGH is 1ms. With or without AGH cache enabled the response is still 1ms. Even if AGH cache is helping with something - the user can't measure under 1ms difference.

 

[SomeWhereOverTheRainBow]

No noticeable difference observed

Wait till it takes 20 ms to complete each block request.

 

[SomeWhereOverTheRainBow]

No, because it becomes my first local cache. Upstream server cache is 20ms, local is 1ms.

When Unbound is used "upstream" cache for AGH is 1ms.

If you could observe 20ms I'd be surprised (other than what tools like dig tell you).

 

[Tech9]

I can measure it at least. Under 1ms I can’t. If you run DNS speed test the DNS servers get tons of requests including the local one with its cache. With Unbound feeding AGH the result is all the same with or without AGH cache.

 

[SomeWhereOverTheRainBow]

The cache you are talking about is the one that is activated during the installation phase by answering "Y" to the question ( Do you want to run AdGuardHome as a local caching DNS service which includes router traffic?) ?
Because i selected "N" and as i understand not using unbound for a simple configuration it is better to activate it.

This is what I have my cache set to on AdGuardHome

 

[Tech9]

The cache you are talking about is the one that is activated during the installation phase by answering "Y" to the question ( Do you want to run AdGuardHome as a local caching DNS service which includes router traffic?) ?

This question is not about cache, but about DNS service. The answer is Yes.

This is what I have my cache set to on AdGuardHome

DNSSEC authentication fails with Optimistic caching enabled. At least on this test:

dnscheck.tools - check your dns resolvers

A tool to test for DNS leaks, DNSSEC validation, and more

dnscheck.tools

 

[SomeWhereOverTheRainBow]

This question is not about cache, but about DNS service. The answer is Yes.



DNSSEC authentication fails with Optimistic caching enabled. At least on this test:

dnscheck.tools - check your dns resolvers

A tool to test for DNS leaks, DNSSEC validation, and more

dnscheck.tools

looks like it is working for me

 

[SomeWhereOverTheRainBow]

This question is not about cache, but about DNS service. The answer is Yes.



DNSSEC authentication fails with Optimistic caching enabled. At least on this test:

dnscheck.tools - check your dns resolvers

A tool to test for DNS leaks, DNSSEC validation, and more

dnscheck.tools

Also looks like it is working where it counts....

 

[SomeWhereOverTheRainBow]

This question is not about cache, but about DNS service. The answer is Yes.



DNSSEC authentication fails with Optimistic caching enabled. At least on this test:

dnscheck.tools - check your dns resolvers

A tool to test for DNS leaks, DNSSEC validation, and more

dnscheck.tools

Dig test with AdGuardHome with DNSSEC and Opportunistic cache enabled.

Dig test with Google.

 

[SomeWhereOverTheRainBow]

This question is not about cache, but about DNS service. The answer is Yes.



DNSSEC authentication fails with Optimistic caching enabled. At least on this test:

dnscheck.tools - check your dns resolvers

A tool to test for DNS leaks, DNSSEC validation, and more

dnscheck.tools

It shows it has been Verified with DNSSEC in Query log.

It shows it is responding from cache with the RRSIG data intact.

Last, Your website works!

It sounds to me you are running into a problem where there is an issue between unbound+dnssec and adguardhome+dnssec. Unbound does a deep verification that sometimes does not behave when using dnssec on a pihole or an AdGuardHome. It is typically because Unbound strips away (or randomizes) too much information from the query response before it is sent to the client ( in your case, to adguardhome). Then AdGuardHome attempts to do the verification again, however there is too much info removed already. For example, in the pihole +unbound guide these are the only options adjusted for DNSSEC between unbound and pihole

    # Trust glue only if it is within the server's authority
    harden-glue: yes

    # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
    harden-dnssec-stripped: yes

    # Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
    # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
    use-caps-for-id: no

 

[SomeWhereOverTheRainBow]

This question is not about cache, but about DNS service. The answer is Yes.

Actually, the user was getting the two intertwined, thus he did not understand any of it.

For adguardhome, You can modify the cache value here:

the default value is "4194304bytes" or "4mb" I chose "524288bytes" which is approximately 1/8th the default size. I noticed alot less strain on my RAM at this size (it is still using alot of ram, but the demand dropped). A good amount of cache typically ranges in sizes from 524288 to 2097152 bytes. The fact that AdGuardHome uses 4194304bytes is a bit overkill incomparison the the amount memory it already demands.

 

[Gary_Dexter]

No noticeable difference observed.



No, because it becomes my first local cache. Upstream server cache is 20ms, local is 1ms. When Unbound is used "upstream" cache for AGH is 1ms. With or without AGH cache enabled the response is still 1ms. Even if AGH cache is helping with something - the user can't measure under 1ms difference.

Surely using AGH cache alongside Unbound cache would be quicker and reduce the number of hops required over time?

E.g a request that isn’t cached in AGH or Unbound would go:

Client>AGH>Check Blocklist>Check Cache>Unbound>Check Cache>Root Servers>Unbound>AGH>Device

A cached request in Unbound would go:

Client>AGH>Check Blocklist>Check Cache>Unbound>Check Cache>AGH>Device

Whereas a cached request in AGH would go:

Client>AGH>Check Blocklist>Check Cache>Device

Does that look right?

 

[Gary_Dexter]

View attachment 49479
It shows it has been Verified with DNSSEC in Query log.

View attachment 49478
It shows it is responding from cache with the RRSIG data intact.

Last, Your website works!

View attachment 49477

It sounds to me you are running into a problem where there is an issue between unbound+dnssec and adguardhome+dnssec. Unbound does a deep verification that sometimes does not behave when using dnssec on a pihole or an AdGuardHome. It is typically because Unbound strips away (or randomizes) too much information from the query response before it is sent to the client ( in your case, to adguardhome). Then AdGuardHome attempts to do the verification again, however there is too much info removed already. For example, in the pihole +unbound guide these are the only options adjusted for DNSSEC between unbound and pihole

    # Trust glue only if it is within the server's authority
    harden-glue: yes

    # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
    harden-dnssec-stripped: yes

    # Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
    # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
    use-caps-for-id: no

I use AGH and Unbound on a RPi and I don’t seem to pass all the DNSSEC requests, only the one:

 

[SomeWhereOverTheRainBow]

I use AGH and Unbound on a RPi and I don’t seem to pass all the DNSSEC requests, only the one:

View attachment 49485

Yep this is an specifically and Unbound and AdBlocker issue. I use Unbound along side Pihole, and my results are identical to this.

So there is no Official "issue" with adguardhomes optimistic caching, this is strictly related to the interaction between forwarding request from between an adblocker resolver (e.g. pihole and adguardhome) and unbound. (maybe even a specific behavior exclusive to unbound)

I am beginning to think this specifically relates to how unbound is compiled:

 

[SomeWhereOverTheRainBow]

Surely using AGH cache alongside Unbound cache would be quicker and reduce the number of hops required over time?

E.g a request that isn’t cached in AGH or Unbound would go:

Client>AGH>Check Blocklist>Check Cache>Unbound>Check Cache>Root Servers>Unbound>AGH>Device

A cached request in Unbound would go:

Client>AGH>Check Blocklist>Check Cache>Unbound>Check Cache>AGH>Device

Whereas a cached request in AGH would go:

Client>AGH>Check Blocklist>Check Cache>Device

Does that look right?

yes bingo. So this issue is not exclusive to AdGuardHome, or Pihole. Just to unbound when used in conjunction with the two. To be honest, I dont consider it to be a game breaking issue. After-all it is only one test.

 

[Gary_Dexter]

Yep this is an specifically and Unbound and AdBlocker issue. I use Unbound along side Pihole, and my results are identical to this.
View attachment 49486

So there is no Official "issue" with adguardhomes optimistic caching, this is strictly related to the interaction between forwarding request from between an adblocker resolver (e.g. pihole and adguardhome) and unbound. (maybe even a specific behavior exclusive to unbound)

I am beginning to think this specifically relates to how unbound is compiled:

View attachment 49487

OK - good to know it's not just me and something with my setup then!

 

[Gary_Dexter]

yes bingo. So this issue is not exclusive to AdGuardHome, or Pihole. Just to unbound when used in conjunction with the two. To be honest, I dont consider it to be a game breaking issue. After-all it is only one test.

View attachment 49488

I'd rather have stuff cached in AGH in the first instance, although once it's cached in Unbound I suppose there's a couple less hops for it to do going out to the Root DNS servers and back again.. so no real biggie I guess?

 

[SomeWhereOverTheRainBow]

I'd rather have stuff cached in AGH in the first instance, although once it's cached in Unbound I suppose there's a couple less hops for it to do going out to the Root DNS servers and back again.. so no real biggie I guess?

correct.