Open IngwiePhoenix opened 3 months ago
Perhaps with verbosity higher, like 4 and 5, it would log more details on the connection, eg. it looks like the connection times out. So much about the upstream connection, the issue is that there is no answer from the local zones. The config has a wildcard in it, but local zones are not implemented to deal with wildcards, I mean, with the 'local-data' statement it does not do wildcards. There are several other ways to get wildcard processing though.
The simplest may be to change the config to:
local-zone: "birb.it." redirect
local-data: "birb.it. IN A 192.168.1.3"
This serves the 'A' record for all names under the birb.it zone, and that would work like the *.birb.it
notation seems to suggest. The wildcards actually work differently from regular expressions in DNS. The redirect feature is not that wildcard processing, it answers for all subdomains with the data from the domain, and also for the domain itself. And then for the overlay network the config would be
local-zone: "birb.it." redirect
local-data: "birb.it. IN A 100.64.0.2"
It is also possible to get a solution using authority zones, the auth-zone config for a zone, then the data for birb.it would have to be in a zonefile, and the auth zone receives wildcard processing, for the *.birb.it
element. That would perform, DNS wildcard processing, for the wildcard for that name. I think the result is likely similar to the redirect local zone. In addition an RPZ zone can be used to superimpose answers. Both of these are not view specific, but the local zone redirect is view specific.
also mvance image, have problem too. try else may madnuttah/unbound work?
his unbound should work, it's the same unbound as from this repo, from the repo where you got it, there are just older versions, you can just as well compile it from here from the direct source and you'll be more up to date.
Perhaps with verbosity higher, like 4 and 5,
That one's on me and my sleepy brain forgetting five minutes later that it can go much higher than three. No idea why I forgot that... Will retry, maybe it'll show me something.
The config has a wildcard in it, but local zones are not implemented to deal with wildcards,
They are not? Oh. I had just wanted to map everything to that host. The actual birb.it
host is my Headscale host, so I need it to retain it's actual IP - the subdomains, however, should point to my host at home. I'll explain what I tried to do in a bit.
Basically, I configured myself a cheap man's Cloudflare Tunnel. My VPS runs Caddy which reverse proxies requests down to the services at home - but selectively. Here is a snippet to illustrate:
*.birb.it {
import cloudflare_dns
respond "...o.o..."
}
video.birb.it {
reverse_proxy * http://100.64.0.11:8096
}
This way, only services I explicitly want to reach from not-at-home would be reached. But in reality, I have way more services there - for instance, the Postgres Operator frontend (ps.birb.it
) - but since it has no form of authorization, I wanted to make sure that I could only access it while at home, or while in the VPN - which is why the Unbound config was ment to span both. Headscale allows me to define a DNS server within the VPN that will be used - by doing that, I was hoping to resolve those services directly to my home maschine instead of going through the "public" one instead, which would obviously not allow this request to pass.
That is why I tried to implement a wildcard setup. However, I have no idea how to write plain zone files, so I attempted to cheat with a little bit of ChatGPT and reading the docs up and down and trying to figure something out. Since in CloudFlare's DNS settings I could just assign a wildcard domain, I was sure Unbound would let me do that too. Welp, it does not. x)
I'll see if I can make the suggested local-zone
/local-data
work though. Thank you for that suggestion!
As for the docker image, I just looked at Docker Hub for an arm64 version since I run on a set of RockChip RK3588 and my remote is an Ampere Altra (4 vCPU at Hetzner) - hence the usual amd64/x86_64 wouldn't work for me (though I could have configured binfmt/qemu but...thats a whole other can of worms right there).
In your unbound config, the forward upstream is as follows: forward-zone: name: "." forward-first: no forward-addr: 1.1.1.1@853#cloudflare-dns.com forward-addr: 1.0.0.1@853#cloudflare-dns.com forward-addr: 2606:4700:4700::1111@853#cloudflare-dns.com forward-addr: 2606:4700:4700::1001@853#cloudflare-dns.com replace the upper part with mine and try it to see if you can get an SSL connection to claudflare: forward-zone: name: "." forward-tls-upstream: yes forward-first: no forward-addr: 1.1.1.1@853#one.one.one.one forward-addr: 1.0.0.1@853#one.one.one.one forward-addr: 2606:4700:4700::1111@853#one.one.one.one forward-addr: 2606:4700:4700::1001@853#one.one.one.one
I did - and also increased verbosity. I haven't implement the other options yet.
Config:
server:
verbosity: 5
use-syslog: no
logfile: ""
interface: 0.0.0.0
port: 5353
do-ip6: yes
access-control: 192.168.1.0/24 allow
access-control: 100.64.0.0/24 allow
access-control: 0.0.0.0/0 refuse
do-not-query-localhost: yes
private-domain: "birb.it"
local-zone: "birb.it." transparent
local-data-ptr: "192.168.1.3 birb.it"
local-data-ptr: "100.64.0.2 birb.it"
access-control-view: 192.168.1.0/24 local-network
access-control-view: 100.64.0.0/24 overlay-network
forward-zone:
name: "."
forward-tls-upstream: yes
forward-first: no
forward-addr: 1.1.1.1@853#one.one.one.one
forward-addr: 1.0.0.1@853#one.one.one.one
forward-addr: 2606:4700:4700::1111@853#one.one.one.one
forward-addr: 2606:4700:4700::1001@853#one.one.one.one
view:
name: "local-network"
local-zone: "birb.it." transparent
#access-control: "192.168.1.0/24" allow
local-data: "*.birb.it. IN A 192.168.1.3"
#access-control: 100.64.0.0/24 deny
view:
name: "overlay-network"
local-zone: "birb.it." transparent
#access-control: 100.64.0.0/24 allow
local-data: "*.birb.it. IN A 100.64.0.2"
#access-control: 192.168.1.0/24 deny
(ignore the indention, I copied it out of my ConfigMap
)
The local-zone
/local-data
version works - but, as described, it know also responds on birb.it
itself:
root@cluserboi ~# dig -p 5353 @192.168.1.3 birb.it
; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> -p 5353 @192.168.1.3 birb.it
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10682
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;birb.it. IN A
;; ANSWER SECTION:
birb.it. 3600 IN A 192.168.1.3
;; Query time: 0 msec
;; SERVER: 192.168.1.3#5353(192.168.1.3) (UDP)
;; WHEN: Sat Aug 17 01:39:12 CEST 2024
;; MSG SIZE rcvd: 52
Alright, almost there. How do I make only the subdomains respond with that IP - do I really have to go and just define all of them this very way?
As far as I understand it, you simply wanted to encrypt the DNS requests in the local network, which are then forwarded so that no one can read them, right? And the result looks good, the server basically gave you an answer as to where you wanted to go (Claudflare). Tell me if I'm wrong. Yes, that's how you should set up an upstream server over unbound with DNS over TLS.
The local zone can match the most specific match. So it is possible to define all of them, and also birb.it
, and have specific handling for each of them. For example with a local-zone: "birb.it" transparent
and local-zone: "video.birb.it" redirect
. It is also possible to put it like local-zone: "birb.it" transparent
and then use local-data for the individual elements, if the local data matches that is returned, and if not it uses the 'local-zone transparent' setting, by adding the local-data local-data: "video.birb.it A 192.0.2.1"
with the IP address.
So with more specific entries, it is possible to give some local zone and local data handling to birb.it
and other entries for handling the subdomains of birb.it
. That needs listing them all.
From the logs, I see it prints that the TLS handshake failed, the certificate fails. Also, the config snippet does not load certicate bundles, so perhaps it could be useful to have something like, tls-system-cert: yes
to load the system default TLS certificate bundle. With tls-cert-bundle: "bundle.pem"
the certificate bundle can be loaded with a specified filename to load from.
Describe the bug I wanted to deploy Unbound into my Kubernetes cluster in order to host a local network DNS server with a few predefined records that I could take advantage of between my home network and it's VPN. However, whenever I run a query, it doesn't give me any particular information as to why it can not reach an upstream - did the TLS handshake fail or could it not establish an outbound UDP connection or something else perhaps?
This is basically what I see across all configured upstreams:
To reproduce You could use the kind tool in order to test this. Podman Desktop also has this option. Once you have a cluster, deploy the following:
If you are on an x86_64 platform, remove the
-rpi
suffix from theimage:
. Further, you may need to adjust the local network CIDR (192.168.1.0/24
). After deploying, attempt to resolvevideo.birb.it
. You should now see the output stating that an upstream connection failed - but with no further information.Expected behavior The expected value is the network local address as devined in the
local-network
view.System:
unbound -V
output:Configure line: --disable-dependency-tracking --prefix=/opt/unbound --with-pthreads --with-username=_unbound --with-ssl=/opt/openssl --with-libevent --with-libnghttp2 --enable-tfo-server --enable-tfo-client --enable-event-api Linked libs: libevent 2.1.12-stable (it uses epoll), OpenSSL 3.2.1 30 Jan 2024 Linked modules: dns64 respip validator iterator TCP Fastopen feature available
BSD licensed, see LICENSE in source package for details. Report bugs to unbound-bugs@nlnetlabs.nl or https://github.com/NLnetLabs/unbound/issues