Your problem with TLS is that you just changed the protocol from UDP to TLS but TLS requires the TLS Hostname to be filled in.
With the UDP protocoll you have a different problem not related to DNS.
The Network unreachable messages are related to the ipv6 addresses which is not surprising as IPFire does not use ipv6.
The ipv4 ip addresses are coming back with Connection refused. This indicates that the connection was made to the server but that it was then rejected for some reason.
You could try
ping -c4 91.189.88.152
You should get back 4 responses with no problems, which is what I get when I run that command from the console.
EDIT: you should do the ping with security.ubuntu.com as that will also confirm DNS working or not.
Then I ran
dig security.ubuntu.com
and got the following good response.
; <<>> DiG 9.11.32 <<>> security.ubuntu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19779
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;security.ubuntu.com. IN A
;; ANSWER SECTION:
security.ubuntu.com. 60 IN A 91.189.91.39
security.ubuntu.com. 60 IN A 91.189.91.38
security.ubuntu.com. 60 IN A 91.189.88.152
security.ubuntu.com. 60 IN A 91.189.88.142
;; Query time: 47 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Nov 06 14:31:44 CET 2021
;; MSG SIZE rcvd: 112
This indicates that DNS access for that url is working fine.
EDIT:
You can also see that security.ubuntu.com has 4 different ip addresses. When you ping security.ubuntu.com then each time you could get a different one of these resolved.
If you get something different for the ping and dig commands then there is still a problem with communication to the ubuntu server but I don’t expect it based on your unbound log messages.
[root@ipfire ~]# grep unbound /var/log/messages
Nov 7 00:01:40 ipfire unbound: [1772:0] error: SERVFAIL <ups.analytics.yahoo.com. A IN>: all the configured stub or forward servers failed, at zone .
Nov 7 00:08:09 ipfire unbound: [1772:0] error: SERVFAIL <pixel.advertising.com. A IN>: all the configured stub or forward servers failed, at zone .
[root@ipfire ~]# date
Sun Nov 7 02:05:26 AM GMT 2021
[root@ipfire ~]#
If you only have the two SERVFAIL messages that is not a big issue.
Occasionally there will be an error getting a DNS response for a certain url from a DNS server and you will get a SERVFAIL and then unbound will try the other DNS servers in your list.
If it is a continuous list of SERVFAIL messages then you have a problem.
Also if your DNS Servers are all showing a green OK and the overall is a green Working then there is no problem from the unbound DNS service. Also if your pings or digs work from your computer on green that also indicates no problem with IPFire because all of those have to go via the IPFire unbound service.
So your dig commands for the security.ubuntu.com site are showing a totally correct response and exactly the same from both your Ubuntu machine and from IPFire. It is showing no problem with accessing the website by DNS.
Hi Adolph,
All looks good, except from any of the x86_64 and 9 Ubuntu based SBC’s when update attempted.
No trouble at all with Fedora 34 x84_64 or 3 openSUSE x86_64 boxes.
There is something that’s causing the problem when trying to update from the LAN while there is no problem on Wifi which bypasses the IPfire box.
I notice an identical problem being worked on by you in another post.
I am now on the MiniPC which has Core154 installed.
Everything works! It’s some gremlin in Core 160.
root@sdrbox1:~# aptitude update
Hit Bytemark - Mirror impish InRelease
Hit Bytemark - Mirror impish-updates InRelease
Hit Bytemark - Mirror impish-security InRelease
Hit Bytemark - Mirror impish-backports InRelease
Get: 1 Index of /ubuntu impish-security InRelease [103 kB]
Get: 2 Index of /ubuntu impish-security/main i386 Packages [20.7 kB]
Get: 3 Index of /ubuntu impish-security/main amd64 Packages [81.0 kB]
Get: 4 Index of /ubuntu impish-security/main Translation-en [20.5 kB]
Get: 5 Index of /ubuntu impish-security/main amd64 DEP-11 Metadata [4,680 B]
Get: 6 Index of /ubuntu impish-security/universe i386 Packages [11.5 kB]
Get: 7 Index of /ubuntu impish-security/universe amd64 Packages [15.3 kB]
Get: 8 Index of /ubuntu impish-security/universe Translation-en [8,204 B]
Get: 9 Index of /ubuntu impish-security/multiverse i386 Packages [1,080 B]
Get: 10 Index of /ubuntu impish-security/multiverse amd64 Packages [1,088 B]
Get: 11 Index of /ubuntu impish-security/multiverse Translation-en [324 B]
Get: 12 Index of /ubuntu impish-security/restricted i386 Packages [12.9 kB]
Get: 13 Index of /ubuntu impish-security/restricted amd64 Packages [73.8 kB]
Get: 14 Index of /ubuntu impish-security/restricted Translation-en [10.4 kB]
Fetched 365 kB in 2s (185 kB/s)
Current status: 1 (+1) upgradable, 66324 (+217) new.
root@sdrbox1:~# aptitude full-upgrade
The following packages will be upgraded:
linux-libc-dev
1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,287 kB of archives. After unpacking 8,192 B will be used.
Do you want to continue? [Y/n/?]
Get: 1 Index of /ubuntu impish-security/main amd64 linux-libc-dev amd64 5.13.0-21.21 [1,287 kB]
Fetched 1,287 kB in 1s (1,402 kB/s)
(Reading database … 322418 files and directories currently installed.)
Preparing to unpack …/linux-libc-dev_5.13.0-21.21_amd64.deb …
Unpacking linux-libc-dev:amd64 (5.13.0-21.21) over (5.13.0-20.20) …
Setting up linux-libc-dev:amd64 (5.13.0-21.21) …
Current status: 0 (-1) upgradable.
root@sdrbox1:~#
Still absolutely fine on Core 154 on the MiniPC. I’ll probably swap back to the PC and try Core 161 Beta later in the week.
root@sdrbox1:~# aptitude update
Hit Bytemark - Mirror impish InRelease
Hit Bytemark - Mirror impish-updates InRelease
Hit Bytemark - Mirror impish-security InRelease
Hit Bytemark - Mirror impish-backports InRelease
Hit Index of /ubuntu impish-security InRelease
root@sdrbox1:~# aptitude full-upgrade
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
I am now on core-163 and still experiencing problems. The problem originally seen on Core-160.
If I disable the LAN connection on any PC/SBC and connect to my cable modem via Wifi there is no problem.
PC → IPfire → Cable Modem → (PROBLEM)
PC → Cable Modem via WiFi (AOK).
root@sdrbox1:~# nslookup www.arduino.cc
Server: 127.0.0.53
Address: 127.0.0.53#53
On the IpFire box (No Wifi) – nslookup www.arduino.cc or dig www.arduino.cc return – Connection timed out: no server could be reached.
This is with DNS set to UDP, TLS or TCP.
