Adguardhome: Device Identifier - DNS-over-TLS and DNS-over-HTTPS

[iganeshk]

Just migrated to Adguard-Home after hoping from nextdns and pihole. Everything seems to work out of the box, including DNS-over-TLS (standard installation).

While I was with nextdns, I found their device identifier to be a really nifty option where the device could be identified by identifier-subdomain.domain.com

DNS-over-TLS
Prepend the name of your choice to the provided domain (the name should only contain a-z, A-Z, 0-9 and -).
Example: for "John-Home-Router", you would use John-Home-Router-5ff9b1.dns.nextdns.io as your DNS-over-TLS endpoint.

Was wondering if something similar could be implemented within Encryption Settings with the following possibility:

• Ability to configure multiple sub-/domains with certificate and client name
  Example: Google-Pixel-subdomain.domain.com

This way, it would be easier to identify clients queries that were configured to use that particular domain in the DNS-o-TLS section.

[ameshkov]

Oh, interesting idea, I really like it!

We could use a different approach, though. We could extend "settings -> clients -> add client" dialog and allow settings this "subdomain" identifier there. This way you don't just identify the device, but you can also have different per-client settings.

[iganeshk]

That sounds cool! You could sign me up for beta testing if required 😄

[Jbbouille]

I would like to work on this feature, is it possible ?

[ameshkov]

@Jbbouille we're going to start working on it soon so I guess we may overlap here

[CalmLong]

建议在这个基础上可以增加对不同的域名(客户端)配置不同的拦截模式

[ameshkov]

@CalmLong

这有意义，谢谢。

我觉得如果 TLS 证书有一些”SAN“（subject alternative name），我们可能允许用几个域名。
但是我不想我们应该允许用一些证书，这是太复杂了。

[ameshkov]

Proposed implementation:

1. [ ] Allow wildcard certificates in the Encryption settings
2. [ ] Improve wording in the "Server name" field: https://uploads.adguard.com/up04_AdGuard_Home_3s1g4.png We should explain that if "Server name" is not set, we should accept TLS connections for any domain.
3. [ ] Allow setting custom strings as Client ID. These strings should be validated (i.e. needs they can be used as a domain name component): https://uploads.adguard.com/up04_AdGuard_Home_278y0.png
4. [ ] Once this identifier is configured, you can use a special domain name while configuring your client.
   Example:
   
   
   
   1. AdGuard Home domain name example.org.
   
   
   2. In AdGuard Home you add a client with identifier my-client.
   
   
   3. On the client device you can now configure:
      
      
      
      
      
      • DNS-over-TLS: tls://my-client.example.org
      
      
      
      • DNS-over-QUIC: quic://my-client.example.org
      
      
      
      • DNS-over-HTTPS: https://example.org/dns-query-my-client
      
      
      
   
   
5. [ ] Don't forget to add this description to the "Identifier" field in the UI.
6. [ ] If some client uses an address matching the above pattern, let's add it to "Clients (runtime)" automatically.
7. [ ] TODO: Query log and Dashboard UI for this new identifier

[Belphemur]

@ameshkov
I have a suggestion for the routes.

For the DNS-over-HTTPS currently NextDNS uses:
https://dns.nextdns.io/ACCOUNT_ID/DEVICE_ID

Maybe for AdGuardHome it could be
https://example.com/dns-query/DEVICE_ID/

This would make sense with the current routing of DoH.

[Macqael]

@ameshkov i think for DoT, DoQ instead of subdomain it's better to use like nextdns devide-id--domain.tld the "--" let us identify the client without having to create a wildcard certificate (not possible on some configuration with some domain provider) and/or can be messy to generate easily.

edit : in my case my dns server is on a dns subdomain with a certificate who cover only the dns, like that if my dns is hacked they can't use the certificate to redirect my other domain (it's my treat model).

[ameshkov]

@michaelb-ae -- is just a part of the domain name, it does not mean you don't need a wildcard certificate. Or you can use a certificate with multiple subaltnames which include your devide-id--domain.tld

[ainar-g]

@ameshkov, as I understand it, now we need to properly document it and close the issue?

[ameshkov]

@ainar-g well, it kinda is documented already: https://github.com/AdguardTeam/AdGuardHome/wiki/Clients

[ainar-g]

Ah, I see. Then the remaining bugs and improvements should probably become separate issues, like #2607.