Support upstreams for subdomains of a domain only

[Magelo]

Hi,

In your documentation you refer to dnsmasq-like syntax :

"You can specify upstreams that will be used for specific domains using the dnsmasq-like syntax (see the documentation for the option --server here). This feature is intended for private nameservers which deal with intranet domains."

and this sentence in dsnmasq man page is interesting for me :

"For historical reasons, the pattern /.google.com/ is equivalent to /google.com/ if you wish to match any subdomain of google.com but NOT google.com itself, use /*.google.com/"

Could you make the necessary changes to support this? To be able to use internal DNS server for local private DNS, only for subdomains?

I want my domain.org to resolve to my external public ip, and only my services linked to a subdomain would use my internal DNS server.

So I could write something like this in Uptream DNS servers :

https://dns.quad9.net/dns-query
[/*.domain.org/]192.168.1.2

if 192.168.1.2 was the IP of my internal DNS server.

Thanks.

[ToqQrrl]

I agree with Magelo, as things are standing today, we need to do « non elegant » work arounds to bypass this inconvenience.

[ainar-g]

@Magelo, you can already do that with [/domain.org/]192.168.1.2. Does that not work for you? Also, if you're having issues with rDNS, have you checked the “Private reverse DNS servers” field?

EDIT: I misread the issue. Yeah, I can see the difference now.

[Magelo]

@ainar-g, sorry if I was not clear enough. You understand now my request?

I would prefer if AGH would mimic DNSMASQ :

assuming internal network is : 192.168.0.0/24
external IP is : 20.103.85.33 (borrowed the Microsoft.com IP for my example)
internal DNS for private network : 192.168.0.2

DNS upstream Servers set to :

1.1.1.1
[/domain.org/]192.168.0.2

would result in AGH to forward name resolution to internal DNS for *.domain.org, even domain.org

1.1.1.1
[/*.domain.org/]192.168.0.2

Only subdomains *.domain.org are forwarded to internal DNS, but domain.org is forwarded to 1.1.1.1 and would resolve to the external IP 20.103.85.33

The way DNSMASQ is doing it. In AHG documentation it's mentioned the syntax was taken from DNSMASQ, so I was hoping to be able to use this to the full extent DNSMASQ offers.

Thanks!

[ToqQrrl]

Basically, if AdguardHome follows the DNSMASQ documentation and supports the same syntax, this is how it would work:

Let’s suppose that domain.org if registered with an internet provider and that it resolves to 205.33.44.55 … a valid Internet address.

Let’s suppose that on his private network he has the following defined:

server1.domain.org resolves to 192.168.1.101
server2.domain.org resolves to 192.168.1.102
server3.domain.org resolved to 192.168.1.103

and …

Let’s say that domain.org normally resolves to is private address when accessed from his intranet … let’s say it’s his firewall … so … 192.168.1.1

If the AdguardHome upstream DNS is configured this way :

1.1.1.1
[/*.domain.org/]192.168.1.53

What he needs AdguardHome to do is the following …

AdguardHome needs to return :

server1.domain.org resolves to 192.168.1.101
server2.domain.org resolves to 192.168.1.102
server3.domain.org resolved to 192.168.1.103

and …

domain.org resolves to 205.33.44.55

And if the AdguardHome upstream DNS is configured this way :

1.1.1.1
[/domain.org/]192.168.1.53

AdguardHome needs to return :

server1.domain.org resolves to 192.168.1.101
server2.domain.org resolves to 192.168.1.102
server3.domain.org resolved to 192.168.1.103

and …

domain.org resolves to 192.168.1.1

essentially… the difference in the upstream DNS config would make the domain.org resolve differently

[ainar-g]

Yes, I do, thanks for the examples.

[Magelo]

Excelllent! Is it reasonable to expect an implementation eventually?

[ainar-g]

Yes, but unfortunately I cannot give any time frames regarding when.

[Magelo]

I can accept that... way better than a thumbs down or a big fat NO.

[ainar-g]

Related feature request: #3738.

[Mizzick]

@Magelo, @ToqQrrl please have a look, we have implemented the requested changes.
The new build v0.108.0-a.129+24d7dc8e has been just published to the edge channel.