Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RPI image not resolving DNSSEC (recursive server) #43

Open
fede843 opened this issue Feb 14, 2023 · 2 comments
Open

RPI image not resolving DNSSEC (recursive server) #43

fede843 opened this issue Feb 14, 2023 · 2 comments

Comments

@fede843
Copy link

fede843 commented Feb 14, 2023

Describe the bug
RPI image does not resolve insecure DNS properly when used as recursive server.

To Reproduce
Steps to reproduce the behaviour:

  1. Composite file:
  unbound:
    image: mvance/unbound-rpi:1.17.0
    container_name: unbound
    hostname: unbound
    restart: always
    volumes:
    - /home/pi/docker/volumes/unbound:/opt/unbound/etc/unbound
    networks:
      mainnet:
        ipv4_address: 172.20.0.10 # Used in Pi-Hole "Upstream DNS Servers" config
    ports:
      - "5335:53/tcp"
      - "5335:53/udp"
  1. Customizations (config files)
server:
    logfile: "/opt/unbound/etc/unbound/unbound.log"
    verbosity: 2
    port: 53
    do-ip4: yes
    do-udp: yes
    do-tcp: yes
    do-ip6: no
    prefer-ip6: no
    root-hints: "/opt/unbound/etc/unbound/root.hints"
    harden-glue: yes
    harden-dnssec-stripped: yes
    use-caps-for-id: no
    edns-buffer-size: 1232
    prefetch: yes
    num-threads: 1
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: 172.16.0.0/12
    private-address: 10.0.0.0/8
    private-address: fd00::/8
    private-address: fe80::/10
    access-control: 172.16.0.0/12 allow_snoop
    interface: 0.0.0.0@53
    chroot: "/opt/unbound/etc/unbound"
    directory: "/opt/unbound/etc/unbound"
    auto-trust-anchor-file: "var/root.key"
    tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt
    cache-max-ttl: 86400
    cache-min-ttl: 300
remote-control:
    control-enable: no

Expected behavior
Running from the host RPI system:

dig fail01.dnssec.works @127.0.0.1 -p 5335

; <<>> DiG 9.16.37-Debian <<>> fail01.dnssec.works @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46756
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;fail01.dnssec.works.		IN	A

;; Query time: 0 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Tue Feb 14 09:55:58 -03 2023
;; MSG SIZE  rcvd: 48

Error messages
Running from the host RPI system:

dig fail01.dnssec.works @127.0.0.1 -p 5335 +trace

; <<>> DiG 9.16.37-Debian <<>> fail01.dnssec.works @127.0.0.1 -p 5335 +trace
;; global options: +cmd
.			86317	IN	NS	j.root-servers.net.
.			86317	IN	NS	k.root-servers.net.
.			86317	IN	NS	l.root-servers.net.
.			86317	IN	NS	m.root-servers.net.
.			86317	IN	NS	a.root-servers.net.
.			86317	IN	NS	b.root-servers.net.
.			86317	IN	NS	c.root-servers.net.
.			86317	IN	NS	d.root-servers.net.
.			86317	IN	NS	e.root-servers.net.
.			86317	IN	NS	f.root-servers.net.
.			86317	IN	NS	g.root-servers.net.
.			86317	IN	NS	h.root-servers.net.
.			86317	IN	NS	i.root-servers.net.
.			86317	IN	RRSIG	NS 8 0 518400 20230227050000 20230214040000 951 . VXSm59w17QNYoRwEE0GiV2q7+rjstTER5+axR8/FdNNUGy4CeRkgNsde Hf8Z7w76aAev6NeZeRIAkhQBDzxlqruMR1t+7u3X+d+xp1eF9qib4Avd v8FnnHE1kUN8/uux6kN8vZ+aBM4eZ9pCyC2XdRz2IKVNsDOrasxEMl1x E0hBDD6EU/KPYwOiAf+B1XeKtSYf640mdG4FEgdhKvjeV1TofcMjZT9e KNEUoSi7oQqQEYllR/58TcoOf0S8zo1U9YnRniG9NzW30XjIXeZ9VK5U LdQ++X9oMP1foSvV7jpuSr8fxmqqjT7+zx/Wg/tTByTgxCPp2fNCbjmt AVXwtg==
;; Received 525 bytes from 127.0.0.1#5335(127.0.0.1) in 15 ms

;; connection timed out; no servers could be reached

Additional context
Host RPI is

Linux raspberrypi 6.1.11-v8+ #1630 SMP PREEMPT Fri Feb 10 12:11:31 GMT 2023 aarch64 GNU/Linux

To add more into this, it works intermittently. At random intervals it resolves as expected, and many other times it does not. Maybe a missconfiguration on my side?

@hqnicolas
Copy link

dear friend, you are sending request to 127.0.0.1 LOCAL MACHINE
you need to send this request to 192.168.0.XXX THE CONTAINER

@fede843
Copy link
Author

fede843 commented May 29, 2023

Hi @hqnicolas thanks for reaching out.

I am using dig from the raspberry host itself. Also I am mapping 5335 port to the internal resolver. Request to my local RPI are passed trough unbound container this way. I am using this setup exposing the port externally just for testing purposes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants