[Feature Request] Allow custom ports in UPSTREAM_DNS

[astrolox]

Didn't realize till now, but the port number doesn't work, not sure if I should open another issue about this, but from what I can tell the lancache-dns docker doesn't allow custom ports on the Upstream DNS servers.

Originally posted by @Deanosim in #84 (comment)

[VibroAxe]

I've had a look at this but it appears that there are some limitations that whilst bind supports nonstandard ports for upstream resolv.conf does not allow a port directive at which point the git pulls would fail even if we found a way to strip the non compliant port :(

@Deanosim Can you provide some context why you were trying to use a nonstandard port?

[astrolox]

I believe the intent was to allow the use of a special proxy server (such as one that does encryption).

[Deanosim]

I actually can't remember why I was trying to do that, I know I no longer use the lancache-dns container and have just added the cache-domains into pi-hole because I was already using that on my network and it was easier to just insert the rules into the existing pi-hole containers.
I probably ran into the same problems trying to get nonstandard ports to work and just went another route. Feel free to close this if you want.

Update: I worked out what I wanted it for, the cloudflare encrypted dns container I am using uses a nonstandard port for some odd reason and I was having problems modifying the container to use port 53, I'm pretty sure that's part of the reason I just inserted the rules into pi-hole (because it allows for nonstandard upstream ports on upstream dns servers like the cloudflared container I'm using.

[DragonQ]

I actually can't remember why I was trying to do that, I know I no longer use the lancache-dns container and have just added the cache-domains into pi-hole because I was already using that on my network and it was easier to just insert the rules into the existing pi-hole containers.
I probably ran into the same problems trying to get nonstandard ports to work and just went another route. Feel free to close this if you want.

Update: I worked out what I wanted it for, the cloudflare encrypted dns container I am using uses a nonstandard port for some odd reason and I was having problems modifying the container to use port 53, I'm pretty sure that's part of the reason I just inserted the rules into pi-hole (because it allows for nonstandard upstream ports on upstream dns servers like the cloudflared container I'm using.

Do you have any more detailed steps for doing this? I'm trying to do exactly the same thing (Pi-hole -> Lancache -> Cloudfared) and am hitting the same problem, i.e. the lancache-dns docker container doesn't allow me to set a non-standard port for UPSTREAM_DNS. I guess I could run the Cloudfared container on yet another VM and bind port 53 on the VM to port 5053 in the container, but that just eats resources. I already have Pi-hole and Lancache on separate VMs so a 3rd VM would be rather annoying for something that can surely be done with only 1 or 2.

[VibroAxe]

My issue is that resolv.conf doesn't support custom supports so there is no way to bootstrap the container using the custom_dns specified.

If I've missed something and you can work out how to do it in resolv.conf then we can have a look at it?

@Deanosim

[Deanosim]

I just stopped using lancache-dns and use the scripts from https://github.com/uklans/cache-domains/tree/master/scripts to create the .conf files for dnsmasq and then just put them in the dnsmasq.d folder on the pihole container, problem solved and everything now works. all traffic goes to pi-hole and them any traffic that can be cached goes to lancache-monothic which I just left using the standard upstream dns of 8.8.8.8 and all other traffic goes from pi-hole to either being blocked or passed to cloudflared.
It's all been running perfectly for months.

[VibroAxe]

@Deanosim I think thats probably the best option. OOI, did you manage to configure any client devices to talk to the cloudflare dns container without the interim PiHole acting on port 53? I can't find any documentation for the system resolvers in either windows or linux which would allow you to do this

[Deanosim]

@VibroAxe Umm no I didn't, I assume it'd be possible with docker by setting the port on that docker sets as 5053:53, I don't think I ever tried that with cloudflared that way, cloudflared can be run on port 53 and that's the default option according to the documention so with the docker container it's probably pretty easy to fork it and just change the port in the config file from 5053 to 53.

Edit: Yeah just double checked, the dockerfile for the cloudflared container I use just needs two entries edited for the CMD and HEALTHCHECK to change the port from 5054 to 53.

[DragonQ]

I just stopped using lancache-dns and use the scripts from https://github.com/uklans/cache-domains/tree/master/scripts to create the .conf files for dnsmasq and then just put them in the dnsmasq.d folder on the pihole container, problem solved and everything now works. all traffic goes to pi-hole and them any traffic that can be cached goes to lancache-monothic which I just left using the standard upstream dns of 8.8.8.8 and all other traffic goes from pi-hole to either being blocked or passed to cloudflared.
It's all been running perfectly for months.

Thanks for the tip, I'll give that a go. The only annoying thing I can see about this approach is the need to manually update the CDNs every so often from the cache-domains repo but I guess that can be scripted.

[DragonQ]

So I think I have the above approach working (LANCache is caching as expected, DNSSEC/ESNI tests all passing, Pi-hole blocking ads), but I have one remaining issue. Previously, I set DISABLE_WSUS=true in my lancache-dns container because I have a WSUS server already and don't need double caching. Now that I'm not using lancache-dns at all, I need a new way to disable this. My cache-domains config.json looks like this:

{
        "ips": {
                "generic":      "192.168.1.92"
        },
        "cache_domains": {
                "default":      "generic"
        }
}

I assume I can disable WSUS caching by removing the "default" cache domain and explicitly listing every domain I want to cache in this file (e.g. Steam, Blizzard)...but is there an easier way that allows me to keep the "default" cache domain?

[astrolox]

This seems to have gotten really far of topic.
The request seems simple to me: Allow use of DNS servers that are on a port other than 53.
Sounds like a good idea to me. We don't currently support it.

[VibroAxe]

@astrolox as far as I can tell from googling and the above, non standard ports aren't supported by resolv.conf which means the container wouldn't be able to pre seed using the system resolver.

Giving separate env commands for the system resolver and the internal bind resolver feels like this is more likely to cause extreme confusion. Anyone capable of running non standard port DNS is most likely running their own resolver at this point (as deano proved above)

Anyone else got thoughts on this @Lepidopterist @JasonRivers

[astrolox]

@VibroAxe Understood.

I also agree that this is probably only a power user feature. Although DNS over HTTPS is becoming a lot more widely discussed/adopted now.

So the conclusion is that we'd have to switch away from using the system resolver to support this request. Some thoughts ...

We could use the recursive forwarding feature in bind, I've checked and it does support custom ports. However I'm not sure what headaches that would cause, and it would leave us with two different resolution paths - although at that point perhaps we point resolv.conf back on to our bind instance.

We could we mark this as won't fix and/or document that we only support upstream servers on port 53.

We could just leave this open and see if anyone else comments with a +1

[VibroAxe]

Hmm, technically at the point we preseed the config files we don't have bind up and running to replace the resolver. But I guess that could be a resolvable problem.

I reckon we document that we don't support it for the moment but leave this open incase it garners more support to warrant the effort

[sugoidogo]

I would argue that anyone running lancache is already a power user, and this situation will only get more common as DoH continues to become widespread. It's the same story as ipv6: it's the new standard, and will replace the old one (at the end of time apparently) so support should be completed before then. Obviously not a pressing issue but definitely not something that should be wontfix.

[naimulh247]

I just stopped using lancache-dns and use the scripts from https://github.com/uklans/cache-domains/tree/master/scripts to create the .conf files for dnsmasq and then just put them in the dnsmasq.d folder on the pihole container, problem solved and everything now works. all traffic goes to pi-hole and them any traffic that can be cached goes to lancache-monothic which I just left using the standard upstream dns of 8.8.8.8 and all other traffic goes from pi-hole to either being blocked or passed to cloudflared. It's all been running perfectly for months.

Hi @Deanosim I am trying to replicate your setup on a single machine. I was able to set up pihole on a docker container and copy the uklans' cache domains. I had a clarifying question, when you said that "any traffic that can be cached goes to lancache-monolithic" are you setting piholes upstream to be lancahce-monolithic's port 443?

Thanks in advance!

[astrolox]

@WilliDieEnte

Honestly, I take offence to your use of words insulting and foolish. Not only do I not understand that point, I think it's quite unnecessary to use such language. I've certainly never wanted to insult anyone, and I've certainly never said "never gonna happen".

As for talking about attitude, well ... I'd also like to point that that getting my back up and annoying me is not a good way to get my help or convince me to write software for free. In fact comments like this are why a lot of developers stop bothering to share (open source) projects which they're working on.

But hey, it's try to keep it civil.

---

As explained above this issue relates to a feature which the underlying software does not support.
This is not a simple config change. It's implement new functionality territory.

I don't believe many people want or need it, but I've left this issue open so that those who do can let me know. In the five years this has been open, only seven people have expressed interest. Out of over five million downloads, that's a very small number.

I think the reason for this is that the power users who want this feature are quite capable of figuring it out on their own, so they don't ask us for it.

I marked the issue as wontfix, not because it will never happen, but because we do not plan or intend to fix it. Addressing this would require replacing key software in the stack with something untested and unproven, just to introduce a feature that almost nobody needs or wants. This doesn't seem like a good use of my time.

Additionally, this isn't something I need. If it were, I would create it and share it with you — which is how this whole project got started!.

For clarity, if someone else were to come along and want to take on this work, I wouldn't refuse their help. That would be absurd.

So what should happen next ...

If you want this functionality ...

1. you could +1 above (like I asked) and wait
2. you could ask nicely for us to make it for you
3. you could work it out for yourself
4. you could start a conversation (either here, or on our discord), and see if other people would help you work it out

If you do make it yourself, please submit a Pull Request.

However, if you just wish to complain and be impolite, please go somewhere other than our bug tracker.