Have customDNS mapping with foo.bar and conditional mapping with custom resolver for clients.foo.bar

[sn0opy]

Finding a proper title for this was kinda challenging so I'm going to explain it by examples.

customDNS:
  mapping:
    foo.bar: 192.168.0.7
    jupiter.foo.bar: 192.168.0.8

I use this customDNS configuration with two hosts that have each a traefik running on them. Thanks to the way blocky works, container1.foo.bar, container2.foo.bar etc. will all resolve to 192.168.0.7 and traefik will pick it up and serve the matching container's page. jupiter.foo.bar and all its sub-sub domains like containerA.jupiter.foob.bar, containerB.jupiter.foo.bar etc. will all resolve to 192.168.0.8.

Now I am also running a dhcp server and a custom dns resolver for local clients on 192.168.0.8 (could be any other host) and I wanted to put all clients under the clients.foo.bar domain. So I went with this configuration

conditional:
  mapping:
    clients.foo.bar: tcp+udp:192.168.0.8:5353

Something like appletv.clients.foo.bar, notebook.clients.foo.bar should each be resolved by 192.168.0.8:5353.

Instead, blocky keeps resolving clients.foo.bar, appletv.clients.foo.bar and all sub-sub domains to 192.168.0.7. I know that the conditional mapping works, if I use a different domain instead. Only the customDNS mapping seems to break it.

Is this intended? Without looking into the code, is there any possibility to change this behaviour without refactoring everything?

Thanks in advance

[sn0opy]

Had a quick look into the code and if I understand it correctly, there's a chain resolver that goes through all the types of resolvers and keeps on going if it wasn't able to resolve the request. I assume my problem lies in the order of resolvers. The conditional resolver comes after the customDNS resolver probably causing the problem.

I assume that simply changing the order of resolvers may lead to other issues?

[ThinkChaos]

Yeah the issue here is you're wanting something that's incompatible with the resolver order, and that order is not configurable.
The issues you'd run into would mostly be use case dependent as you're changing the resolver priorities.

I haven't tested this, but I think you can use a rewrite as a workaround:

customDNS:
  rewrite:
    clients.foo.bar: skip-custom
  mapping:
    foo.bar: 192.168.0.7
    jupiter.foo.bar: 192.168.0.8

skip-custom doesn't have any special meaning, it's just not present in the mapping. So IIRC the customDNS resolver will just ignore requests for clients.foo.bar.