Adguard Home - Localhost for some resolving ?

[R-Nabil]

Hi,

I'm using ADH in a K3S cluster. It works amazingly.
However, I would need to configure some upstream servers for the k3s dns (usually they are like ..svc.cluster.local), and I would need it to point to the kube-dns pod.

In simplest term, how can I make sure that ADH for these type of adress uses the container dns ? When I exec, I am able to resolve ..svc.cluster.local, but any of the below fails to work in the config.

[/bind-service.bind9.svc.cluster.local/]localhost:53
[/bind-service.bind9.svc.cluster.local/]127.0.0.1:53
[/bind-service.bind9.svc.cluster.local/]local:53

[rossigee]

I'm not too familiar with K3S, but typically for normal K8S clusters, a core-dns deployment runs in the kube-system namespace, which accessible from other pods in the cluster using the service hostname kube-dns (i.e. kube-dns.kube-system.svc.cluster.local).

I've found this usually gets assigned as the tenth address in the ClusterIP range for the cluster. For example, if my ClusterIP is 10.123.4.0/22, then the cluster DNS service would appear at 10.123.4.10.

# kubectl -n kube-system get svc kube-dns
NAME       TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)                  AGE
kube-dns   ClusterIP   10.123.4.10   <none>        53/UDP,53/TCP,9153/TCP   105d

# dig +short @10.123.4.10 kube-dns.kube-system.svc.cluster.local.
10.123.4.10

As long as ADH is running on the local cluster, it should be enough to add the following to the top of the upstream_dns section in your ADH config, followed by any other fallback servers you may need...

upstream_dns:
  - "[/svc.cluster.local/]10.123.4.10"

Specifying the :53 port explicitly is optional.

[R-Nabil]

Hey, Thanks for your answer. Indeed this works. But is it guaranteed to be allocated this address ? As I wouldn’t want to end up with a clunky setup if that were to change :-) Thanks

…

On 5 Jul 2024 at 15:44 +0800, Ross Golder ***@***.***>, wrote: I'm not too familiar with K3S, but typically for normal K8S clusters, a core-dns deployment runs in the kube-system namespace, which accessible from other pods in the cluster using the service hostname kube-dns (i.e. kube-dns.kube-system.svc.cluster.local). I've found this usually gets assigned as the tenth address in the ClusterIP range for the cluster. For example, if my ClusterIP is 10.123.4.0/22, then the cluster DNS service would appear at 10.123.4.10. # kubectl -n kube-system get svc kube-dns NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kube-dns ClusterIP 10.123.4.10 <none> 53/UDP,53/TCP,9153/TCP 105d # dig +short @10.123.4.10 kube-dns.kube-system.svc.cluster.local. 10.123.4.10 As long as ADH is running on the local cluster, it should be enough to add the following to the top of the upstream_dns section in your ADH config, followed by any other fallback servers you may need... upstream_dns: - "[/svc.cluster.local/]10.123.4.10" Specifying the :53 port explicitly is optional. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[rossigee]

That depends on how the kube-dns service is created and maintained. Unless you are running something special that might need to delete/re-create the service? Even so, I think if you were to delete the service and upgrade the cluster it would just re-create it with the same address. Not sure if that'd be the case with K3S, so might be worth a quick try before you set anything in stone.

In my case, I just ensure it remains present with a specific static IP by having my CI system (flux2) manage it.

[R-Nabil]

Thanks a lot for your inputs. Appreciate your advice.

…

On 5 Jul 2024 at 15:58 +0800, Ross Golder ***@***.***>, wrote: That depends on how the kube-dns service is created and maintained. Unless you are running something special that might need to delete/re-create the service? Even so, I think if you were to delete the service and upgrade the cluster it would just re-create it with the same address. Not sure if that'd be the case with K3S, so might be worth a quick try before you set anything in stone. In my case, I just ensure it remains present with a specific static IP by having my CI system (flux2) manage it. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>