Missbehavior or hardcoded DNS-server in ipfire?

mumpitz · 14 April 2026 08:45

Hello , I did a next step and take the firewall option for outgoing on blocked, before I set the rules for a normal ipfire behavior. DNS e.g. uses TLS over TCP port 853. Whois uses TCP Port 41, Pakfire updates TCP 443, etc.

So, but why is there a connection trying at UDP Port 53 to an DNS root Server?

I did not configure this at all and source is my own IP so ipfire itself. How this can happens?

Btw. my ipfire was a complete new installation.

Best Regards

bbitsch · 14 April 2026 09:06

What is the destination of the DNS request?

mumpitz · 14 April 2026 09:44

Destination always till now:

dig DNSKEY 198.41.0.4 +dnssec

; <<>> DiG 9.20.18 <<>> DNSKEY 198.41.0.4 +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 38643
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;198.41.0.4. IN DNSKEY

;; AUTHORITY SECTION:
. 85291 IN NSEC aaa. NS SOA RRSIG NSEC DNSKEY ZONEMD
. 85291 IN RRSIG NSEC 8 0 86400 20260427050000 20260414040000 54393 . ZPFWoegJX5PUJ2StKkPTG13Eugs9D95CAA4fcYSqkYJ49fYzU7Gp3MQP ry9B3eQJmWjB4IXxEblEma/KQoVoscdVERdRA8mBsR5+3WY5cy6vqMr7 n2LZ+gyQlg3ETZDA0r5IFFegKjQ/qHxxC5iT/i73wM+L5u604VS81Ekc W7sj44br8xGVVNlzkjAwuEFzykBqvuV1gslZHBTgcw3xxEm8GDlN8EQK owCqqGK/eei202edFnA+mc/HP1OuH00ahdZHvmDka26q2UZDJyiX5DZp iB+YM058Y0GuRoqoajPeFqa/UHYuQszEPzw8L+Q/ivlKYHQw8e357iEg qTS1Gw==
. 2747 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2026041400 1800 900 604800 86400
. 85293 IN RRSIG SOA 8 0 86400 20260427050000 20260414040000 54393 . nmOgutW8YSAEXH57/Z5BFcHhldW22QPDJk+lBKPrblO7CJxaTvVOkUnP ufdV6JUsTTT0p2Ly/12Ywxz4rShbf3kQQL7gRrcI8D5/YScL2qu92Qda p0Xmz83V2bxWhxWshT0AnDCIzlwaPJZazpfB1vYLobG4jtr2ho1PFBr7 DdDycMaDD4H6frbd1w2LsGf/sUw/wpvcJuK3iWe4J2fpOKduACHccEQr WzH4emYh2YTeb0VmKJ789fnn+TQvILuin9kYHm9H4IN/6u97bnMy0RcY 3DLZlCHDljOj6zcfJBpnkFn1RZOaM1g87z+ubVmbf+2wzp7qKz9F6GvX 3+TcOw==

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Tue Apr 14 11:42:56 CEST 2026
;; MSG SIZE rcvd: 712

bonnietwin · 14 April 2026 09:45

For a fresh install the DNS Server will be set up to access the DNS server(s) from your ISP and that will be done via UDP (53).

So itt could be that the unbound server on your IPFire is trying to get some required info from a DNS Root Server.

mumpitz · 14 April 2026 09:47

no it is not, it is “VeriSign Global Registry Services a.root-servers.net” also see above the dig command

Edit:also i did an offline Installation, so the DNS Server from ISP should always been disabled.

bonnietwin · 14 April 2026 09:59

What do you have on your DNS Server WUI page then?

That is a root server. It is the destination where the info is being requested from, not the source making the request.

You said that the source was your IPFire IP using port 53 and that is confirmed by the DIG output.

That makes me suspect that the unbound system is making the request as that is the standard default system that would be making requests on port 53.

mumpitz · 14 April 2026 10:30

I added some from the ipfire wiki

Request is ipfire itself all 30 minutes 5 times in row

Apr 14 11:28:52 kernel: DROP_OUTPUT IN= OUT=red0 SRC=IPFIREREDIP DST=198.41.0.4 LEN=214 TOS=0x00 PREC=0x00 TTL=64 ID=52767 PROTO=UDP SPT=54467 DPT=53 LEN=194
Apr 14 11:58:43 kernel: DROP_OUTPUT IN= OUT=red0 SRC=IPFIREREDIP DST=198.41.0.4 LEN=214 TOS=0x00 PREC=0x00 TTL=64 ID=13020 PROTO=UDP SPT=54467 DPT=53 LEN=194
Apr 14 11:58:46 kernel: DROP_OUTPUT IN= OUT=red0 SRC=IPFIREREDIP DST=198.41.0.4 LEN=214 TOS=0x00 PREC=0x00 TTL=64 ID=15759 PROTO=UDP SPT=54467 DPT=53 LEN=194
Apr 14 11:58:49 kernel: DROP_OUTPUT IN= OUT=red0 SRC=IPFIREREDIP DST=198.41.0.4 LEN=214 TOS=0x00 PREC=0x00 TTL=64 ID=15865 PROTO=UDP SPT=54467 DPT=53 LEN=194

]# cat resolv.conf
search home
nameserver 127.0.0.1
options edns0 trust-ad

cat /etc/unbound/unbound.conf

server:

Common Server Options

chroot: “”
directory: “/etc/unbound”
username: “nobody”
do-ip6: no

    # System Tuning
    include: "/etc/unbound/tuning.conf"

    # Logging Options
    use-syslog: yes
    log-time-ascii: yes

    # Unbound Statistics
    statistics-interval: 86400
    extended-statistics: yes

    # Prefetching
    prefetch: yes
    prefetch-key: yes

    # Privacy Options
    hide-identity: yes
    hide-version: yes

    # DNSSEC
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    val-log-level: 1
    log-servfail: yes

    # Hardening Options
    harden-large-queries: yes
    harden-referral-path: yes

    # TLS
    tls-cert-bundle: /etc/ssl/certs/ca-bundle.crt

    # Harden against DNS cache poisoning
    unwanted-reply-threshold: 1000000

    # Listen on all interfaces
    interface-automatic: yes
    interface: 0.0.0.0

    # Allow access from everywhere
    access-control: 0.0.0.0/0 allow

    # Timeout behaviour
    infra-keep-probing: yes

    # Bootstrap root servers
    root-hints: "/etc/unbound/root.hints"

    # Include DHCP leases
    include: "/etc/unbound/dhcp-leases.conf"

    # Include hosts
    include: "/etc/unbound/hosts.conf"

    # Include any forward zones
    include: "/etc/unbound/forward.conf"

remote-control:
control-enable: yes
control-use-cert: no
control-interface: 127.0.0.1

Yeah but i found the troubler maker

cat /etc/unbound/root.hints

shows the root server and some more A to M.

Is this really necessary? till now i have no problems with dns resolution ?

This behavior starts 3 days ago at 8 pm. My actual DNS servers were all set at 03.04.2026 after the first start of this ipfire. Maybe the tor extension is the issue? Because this is also not working this time.

bonnietwin · 14 April 2026 10:54

It is there for a reason and it will be required under certain circumstances.

A quick search found this info from the IANA web site

Configuring the Root Servers

Operators who manage a DNS recursive resolver typically need to configure a “root hints file”. This file contains the names and IP addresses of the root servers, so the software can bootstrap the DNS resolution process. For many pieces of software, this list comes built into the software.

mumpitz · 14 April 2026 12:32

so i will comment out all this servers because i need no recursive resolver, i use enough thank you,

Btw. which info will ipfire send to this server, because i use DNS over TLS with configured DNS Server no recursive resolver?

bonnietwin · 14 April 2026 12:50

See the first sentence in the Unbound documentation.

https://unbound.docs.nlnetlabs.nl/en/latest/index.html

That tells you that it is a validating, recursive, caching DNS resolver. So yes you are using a recursive resolver.

mumpitz · 14 April 2026 13:29

That tells me that unbound can be, but must not, because now it does not work as recurser and it works like it should.. as i told here and you can read here, it is optional.

I do not need plaintext DNS querys out of my firewall to tell everybody which websites i am read. Thank you!

bbitsch · 14 April 2026 16:02

have you recorded the packets? Why do you know, it is plain text DNS query?
You posted DROP_OUTPUT messages. This means these are not sent outside.

mumpitz · 21 April 2026 01:24

Yes that is right and no i did not check the packets, but what else send ipfire over UDP Port 53 to one of 13 root DNS server ? I recognized this behavior for the first time, so for a long time this connections were made without my knowing. anyway…

So if now they are blocked, it means nothing for the past, BUT ….. I have found a very nice feature for unbound and will tell the story here a little further.