Add Full DNS Management, Query Logs, and Blocklist Support to the AdGuard DNS App

[mzaa01]

Issue Details

Currently, the AdGuard DNS app only functions as a connection client, allowing users to configure DNS connection settings.
However, it lacks essential DNS management features that are already available in the web interface.

At the moment, users cannot:

View DNS query logs

Block or unblock domains directly from the app

Manage blocklists or whitelists

Access dashboard and server settings without opening a web browser

This limitation makes mobile usage inconvenient, especially for users who manage DNS rules frequently.

Proposed solution

Enhance the AdGuard DNS app to support full DNS management features, including:

1. Query Log Access

View allowed, blocked, and resolved DNS queries directly in the app

Enable quick actions (block / allow) from log entries

2. Domain Management

Block or unblock domains directly from:

Query logs

A dedicated domain management section

Sync changes automatically with the user’s AdGuard DNS profile

3. Blocklist and Whitelist Support

Add support for importing blocklists and whitelists via:

.txt files

Remote URLs containing domain lists

Allow automatic list updates on a schedule

Similar to list management in Pi-hole

4. Web Dashboard Features in the App

Provide in-app access (native UI or embedded web views) for:

Dashboard

Servers

Server settings

General settings

Alternative solution

If implementing full native UI support is not feasible in the short term, consider:

Embedding the existing web dashboard inside the app using a secure WebView

Providing read-only access to query logs as a first step

Gradually enabling write actions (block / allow domains, list management) in later updates

This phased approach would still significantly improve usability while reducing development complexity.

[Lwb828]

Your thoughts remind me of the DNS protection feature in the Adguard app. In fact, the Adguard app can fully function as a DNS server. In its advanced settings, there is a "DNS request timeout" option. I think this feature could be optimized and upgraded to a "valid response record timeout." This would allow recording valid DNS responses. If a DNS request is not blocked by the rules, its response could be automatically updated after a certain period. This would not only reduce DNS queries but also speed up DNS filtering, because the query logic would be: valid DNS response → DNS blocklist → sending DNS query. It could even be further optimized to: DNS response (both valid responses and blocked requests) → blocklist → sending DNS query. After rules are updated, Adguard could automatically check if there are new DNS requests in the response list that need to be blocked or allowed. If so, it could modify the response method for those to be newly blocked, or delete and re-enter them. For requests in the list that need to be newly allowed, it could send the DNS query after the network returns to normal, then record the response, or delete it and wait for the next trigger. Furthermore, a "DNS request non-trigger time" could be set. If a specific DNS request is not triggered within a certain period, it would be automatically deleted. This would streamline the DNS records, as some requests (e.g., from rarely visited websites) would be removed, while frequently used ones would remain, creating a good cycle. Also, sometimes network issues cause DNS responses like SERVFAIL, which is an invalid response. There are other invalid response codes as well. Therefore, an "invalid response timeout" should be set to promptly update DNS records. Additionally, if Adguard is designed this way, it would need a network connectivity check. If the network is unstable and receives responses like SERVFAIL, it should notify the user. The connectivity check could allow users to specify a DNS server address to test, or default to checking the currently used DNS server address.:But I don't know if this is a good setting.

[ESurina]

Thank you for your suggestion! We will consider it and may add this functionality.