Turris OS 3.8.1 is out with better DNS work and new Nextcloud!

Community office
1

Dear Turris users,
we just released Turris OS 3.8.1 for all users :wink:

Changes are:

  • forwarding to ISP’s DNS severs will be turned off automatically if the Internet connection is not working due to this setting
  • better check of DNS off in dnsmasq
  • new Nextcloud version with more features and better security :slight_smile:

Have a nice day!

3 Likes
2 
root@omnia:/usr/bin# updater.sh
WARN:Script revision-specific not found, but ignoring its absence as requested
WARN:Script serial-specific not found, but ignoring its absence as requested
WARN:Request not satisfied to install package: dnsmasq
DIE:
inconsistent: Requested package lftp that is not available.

still hasn’t been addressed.

3

Turris 1.1

After update I got from updater this warnings:

root@turris:~# updater.sh
WARN:Script revision-specific not found, but ignoring its absence as requested
WARN:Script serial-specific not found, but ignoring its absence as requested
WARN:Requested package luci-i18n-ddns-en that is missing, ignoring as requested.
There is no message to send.
4

Those are fine. First two are in place just in case we would need to address specific issue in some series of our routers and the third one is explained here on forum in different thread - it’s because luci-app-ddns has different style of localization than everything else and thus automatic rule generator can’t find extra package to install, so it is harmless.

5

Yes, as you can read lftp package that you have installed is currently not available. You can fix it by uninstalling it. It doesn’t build currently and nobody fixed it yet.

6

Installation of the TurrisOS 3.8.1 on my router Turris 1.x was done without any problems.
But I was a little surprised it was started immediately (without delay I was setup in my Foris).

root@jnturris:~# cat /etc/config/updater

config pkglists ‘pkglists’
list lists ‘openvpn’
list lists ‘netutils’
list lists ‘api-token’
list lists ‘nas’
list lists ‘majordomo’
list lists ‘luci-controls’
list lists ‘honeypot’
list lists ‘i_agree_datacollect’

config l10n ‘l10n’
list langs ‘cs’

config override ‘override’
option disable ‘0’

config approvals ‘approvals’
option need ‘1’

1 Like
7

Same happened to me. I have the Turris configured to require approval for updates, but 3.8.1 installed without requesting approval.

1 Like
8

Thanks for the update.

I’m also confirming this issue. 3.8.1 installed tonight without asking for approval. I have configured a 48 h delay.

9

This update doesn’t fix the issue described in https://forum.test.turris.cz/t/dhcp-not-working-after-update-from-factory-settings-and-update-3-8-issues/4956. Do you plan to fix that?

2 Likes
10

Firmware 3.8.1 on my TO doesn’t solved the problem with the DNS resolution if the option DNS forwarding is on. TO isn’t able to resolve e.g. servis24.cz. My ISP is netbox.cz, I’ve reported them the problem, on Thursday 21th they upgraded their DNS servers and asked me to check the problem and the situation is still the same - DNS forwarding doesn’t work…

11

@Radovan_Haban: 3.8.1 added code that should automatically switch off forwarding in case of problems, but 3.8.2 is expected to improve forwarding compatibility itself. You can check if that’s your case as well by dig @ServerOfISP servis24.cz +dnssec +cd and inspect if it contains unsigned NS records in authority section.

12

Answer on my TO is
root@router:/var$ dig @83.240.0.214 servis24.cz +dnssec +cd

; <<>> DiG 9.10.5-P3 <<>> @83.240.0.214 servis24.cz +dnssec +cd
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18922
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;servis24.cz. IN A

;; ANSWER SECTION:
servis24.cz. 120 IN A 194.50.240.199
servis24.cz. 120 IN A 194.50.240.71
servis24.cz. 120 IN RRSIG A 7 2 120 20170929114444 20170922114444 61262 servis24.cz. J4BfrAtXSlspELhwRzb9nCi4AGqoOiEyc+KVFjNPyJO+pPrXWFvqaoEk Ay7JzHcph2eZdntwNJN0EYmN6yZRB+ryVtrygEL75Bup95thdga1p0w3 gXdE6l6NG5x14oVclAmUzYz59MlEl4tBP72xzC7yw0rr3SS6ZEjU2/WL 07ZnRlUFzS6M/DXlfde/MNVZxw9jEGSGosKgMDQo7qzQsOjs70R6ynQ5 b2cCNi9d8+TeUYwHwo6OGRFyuAuF3Yz+rE/LZxTbX4PaXXagEIs4wq/Y +Ax+9hOIB7VlJs9Sgis2ziGx+h54FITd1EbNBqjD6W0yzuOSDanEHHsf 5l6mFw==

;; AUTHORITY SECTION:
servis24.cz. 818 IN NS ddnsa.csas.cz.
servis24.cz. 818 IN NS ddnsb.csas.cz.

;; ADDITIONAL SECTION:
ddnsa.csas.cz. 5932 IN A 194.50.240.64
ddnsb.csas.cz. 5932 IN A 194.50.240.192
ddnsa.csas.cz. 5932 IN RRSIG A 7 3 7200 20170929114407 20170922114407 49799 csas.cz. kuE3LXUR1niQhtF+GXbX5kvdNg3YntcEEOimNATBhU9welRhyephkUpE pqeOBbQp/OjzDZsqF589GW+974++KJDKtNqmKQ1pe3q4xrafufg0wpY8 I35vdruA0K7W1uYqH+BiHs+1PUnj3GITFiLP+ybcMOJF/F1yRDRWTbfc aV4tZw1YIHKUY1G6pEWryvWOhtCUoJyAeLkNbp7IkM1zakQEHyEUsCK6 +bo0q7V6SV7Bl3MJ3uIQMOdkWbxzrv+bFJy4P4FABi9V4W+S1P6R1d0B cvcv2v+QEHFsT2+idZ/QVhXSgFrmq/JcvnEKYbQ5m2zqi9ZGGltyRq7v t2rDDg==
ddnsb.csas.cz. 5932 IN RRSIG A 7 3 7200 20170929114407 20170922114407 49799 csas.cz. YlbAeBZoFWh0zYs9JLECLf6GzR462OPJ65xfiPC4+aHsG/8g3s1F1bq9 RvCu3/rOlbqgs/NMKyhmdQlBkBEu4Z+KOAIou0mtW0bUdkEAkZaN83pw uuRrsRg45bWNABp3rsg7u0PG6Ae0YFihexOjeZ1Eh1Dzs/p0dwY2I8tT 2c8c7yTt3rxfOzJ87sJO3nTAH1YbLGahkYMj8JXWoe3jAd7t9flA4bZd fE980ZSnIOedoEW71TNFGbxEKG5Q/YyBr6mh46pW63alfw3BhIHIvu5R bYPhXHXvr84MSptGG/KAYpnxAF65b3GhjmZb8UExENKUetl1/IIXNBf+ 4sHHtQ==

;; Query time: 14 msec
;; SERVER: 83.240.0.214#53(83.240.0.214)
;; WHEN: Sat Sep 23 10:31:51 CEST 2017
;; MSG SIZE rcvd: 1038

13

Yes, affected by the problem, so probably will be OK with knot-resolver >= 1.4.0.

14

The problem is caused by Knot or by ISP?

15

As described on the upstream issue, I believe the ISP’s server shouldn’t be adding unsigned records into authority, but it was relatively easy to start ignoring them on knot-resolver side. (Certainly easier and faster than trying to persuade the ISP or their server’s authors to change behavior.)

1 Like
16

Thanks for explanation. Anyway I could try send this result to my ISP.

17

Thank’s for NFSv4. It’s so much better now.

NFSv4.JPG718×218 20.8 KB

1 Like
18

I’ve contacted by ISP netbox.cz to correct incorrect DNSSEC server answer. Today, they replied me that they had made configuration changes on their DNS. Now their DNSSEC answer is following

root@router:~# dig @83.240.0.214 servis24.cz +dnssec +cd
; <<>> DiG 9.10.5-P3 <<>> @83.240.0.214 servis24.cz +dnssec +cd
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26501
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;servis24.cz. IN A

;; ANSWER SECTION:
servis24.cz. 84 IN A 194.50.240.199
servis24.cz. 84 IN A 194.50.240.71
servis24.cz. 84 IN RRSIG A 7 2 120 20170929114444 20170922114444 61262 servis24.cz. J4BfrAtXSlspELhwRzb9nCi4AGqoOiEyc+KVFjNPyJO+pPrXWFvqaoEk Ay7JzHcph2eZdntwNJN0EYmN6yZRB+ryVtrygEL75Bup95thdga1p0w3 gXdE6l6NG5x14oVclAmUzYz59MlEl4tBP72xzC7yw0rr3SS6ZEjU2/WL 07ZnRlUFzS6M/DXlfde/MNVZxw9jEGSGosKgMDQo7qzQsOjs70R6ynQ5 b2cCNi9d8+TeUYwHwo6OGRFyuAuF3Yz+rE/LZxTbX4PaXXagEIs4wq/Y +Ax+9hOIB7VlJs9Sgis2ziGx+h54FITd1EbNBqjD6W0yzuOSDanEHHsf 5l6mFw==

;; Query time: 1 msec
;; SERVER: 83.240.0.214#53(83.240.0.214)
;; WHEN: Tue Sep 26 12:57:57 CEST 2017
;; MSG SIZE rcvd: 371

Is their solution OK now according to standards?

19

I expect forwarding with validation will work there now, even with Omnia 3.8.0 and 3.8.1. On future 3.8.2 it will probably work with either state.

After finding the root cause, I was trying not to claim that the behavior (adding unsigned records) is against RFC standards, as I’m not at all certain of that.

20

Does this mean that we can disable or remove the know resolver?