DNSSEC broken with dnsmasq 2.80 #163
Comments
|
Defer DNSMASQ startup until a valid time was set - a possible solution: https://github.com/PeterPawn/YourFritz/blob/master/tools/waittimeset ... but this doesn't work for x86 systems on Puma devices, because the timer value isn't always initialized with an epoch value of zero there (you need a bigger value in line 4 for this models). Add your own attempt to set a valid time at startup - I personally use a local time server according to RFC 868 and the An alternative approach is a simple HTTP GET request to any (at its best also a local) host, which has (for sure) a valid date/time value. If you use There are some programs, that offer this function (reading date/time via HTTP) - but this task is sooo simple, that I would never use one of these offers and implement it with the "basic applets" from BusyBox. Waiting for a valid value from an internet source is not always a good idea - but you have to wait, until the local network of your FRITZ!OS device is up and running. Therefore I've used this (late) hook with A broken internet connection (no matter, what's the reason for) would render your local infrastructure unusable, if you restart the router (with the hope, a previous problem would vanish now), but it can't get a new internet connection immediately and nevertheless the startup of your local DNS server would be deferred, until a new internet connection gets available (if the DNSMASQ instance isn't only the forwarder for requests of external addresses) - as a result, your local devices would be unable to communicate with others (using their names). If there's a small deviation from the time, that gets set later by AVM's And if you have a 24/7 running, local NTP server anyway (from a local Linux server with a RTC (RasPi?) or a NAS device or somewhere else), you may set its local address as NTP server for FRITZ!OS, too - then there's no need for a single line of additional script code. |
|
There is no bug in dnsmasq and dnssec. himself Refer also here these links to understand the mechanism : https://www.linksysinfo.org/index.php?threads/fork-freshtomato-arm.74117/page-24#post-304535 i forgot - short workaround / solution in the default freetz config : Note : from this point timecheck for dnssec would NOT not be automatically activated by Freetz ! You need to sent SIGINT to dnsmasq for doing this by commandline or by a script that not (yet) |
|
[PeterPawn]
Not a reliable/always-up one in my case. The reason I use Freetz is that I want to have “the essentials” (DHCP, DNS, NTP, VPN/SSH, VoIP, tiny NAS) directly on the router. [feedzapper]
Thanks. I considered combining this with the script approach PeterPawn suggested. But the
I could not find writable permanent storage, but |
Would you provide a patch for |
A lot of boxes have a minimum of internal NAS space 7360SL does not ? dnssec-timestamp=/tmp/flash/mtime Also it is possible to create a EMTPY file e.g. with nano "mtime" in /tmp/flash directory. this file got a FIXED system time. Doing a "modsave" to make this permanent in the flash. |
|
In my opinion, the solution using a file from the SquashFS image is absolutely sufficient, if it works as expected and looking into the source code (http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/dnssec.c;h=9bf43a2e1b70792bd769ac37e10d62ad1a46b30a;hb=HEAD), it should solve the problem, because only the modification time of the specified file is used instead of the fixed value "2015-01-01" (if the file does not exist). There's no need to invent any new file for this check. There's no later obvious attempt visible to write or change the file, beside the one in line 170 and this one is only executed, if the file did not exist (ENOENT). But I would suggest to use another file for this timestamp ... simply due to the fact, that AVM itself uses the date/time of Therefore this value should always be valid, the file will always exist and it's a "fixed" reference for all Freetz images built from the same AVM version. Using "/bin/busybox" as source leads to a varying time source and in worst case, when things are going really badly, the build system doesn't have a valid time set while creating the image (OK, that's only a theoretical problem). But because the time of the original file is preserved while modifying the firmware, a valid (and common) timestamp is ensured while using this file. |
|
[PeterPawn]
Sure. I didn't rebuild my firmware yet but following the other parts of that file, this should do the trick. [feedzapper]
You are right. There is writable storage in
It just looked weird to me that there are supposedly 452KB of data there, but I can find no files. So I didn't want to use that filesystem. And a firmware file (now |
I agree - and thanks for the (smart) solution and the patch. But it seems, my question was too vague. The best (and easiest) manner to incorporate the change(s) to Freetz master is a "pull request" and lastly I wanted to know, whether you will provide this PR yourself or if someone else should create one and refer to this issue. |
When DNSSEC is enabled, disable its time checks until NTP set the system time properly. Reuse /etc/version as reference file. Closes Freetz#163
When DNSSEC is enabled, disable its time checks until NTP set the system time properly. Reuse /etc/version as reference file. Closes #163
|
Btw. cuma's solution for the same problem: https://trac.boxmatrix.info/freetz-ng/changeset/15335/freetz-ng |
|
Fortsetzung von #187 (comment): Der Fehler dürfte auch nur bei einem Neustart des Daemons auftreten, wenn die Box bereits eine gültige Uhrzeit hat. Dann muß man allerdings tatsächlich noch etwas unternehmen, wenn man diesen Fehler (der ansonsten aber keinerlei Auswirkungen haben dürfte) nicht haben möchte. Auswirkungen hat er (neben der erwähnten Fehlermeldung) deshalb nicht, weil trotzdem die nachfolgenden Zeilen ausgeführt werden und der Daemon mit der Signaturprüfung beginnt. Entweder man patcht die Fehlermeldung generell weg oder man baut vor dem "utimes"-Aufruf noch einen Test ein, ob das Dateisystem mit dieser Datei generell änderbar ist oder nicht. Ich wäre für einen einfachen "utimes()"-Aufruf mit Ignorieren eines Fehlers ... zwar kommt der Daemon da auch nur einmal beim Start vorbei, aber solange die Meldung zu erwarten ist (das ist nun mal bei einem r/o-Filesystem so) und ohnehin nur auftritt, wenn man bereits eine Uhrzeit hat (woher auch immer), wenn der Daemon gestartet wird UND wenn außer der Meldung nichts weiter geschieht, braucht es diese Meldung auch nicht. Ich würde deshalb jedenfalls nicht in Erwägung ziehen, eine andere Datei an einer anderen Stelle zu verwenden. |
|
Spricht was dagegen, die /etc/version nach /var/tmp zu verschieben und per symlink zu referenzieren?! Dann wäre sie beschreibbar. |
|
Handelt es sich bei Deinem Vorschlag um Deinen eigenen? Bitte, sofern es sich nicht um Deinen eigenen Vorschlag handelt, immer explizit und ohne explizite Aufforderung die Quelle bzw. den Author angeben. Dein Vorschlag entspricht dem in freetz-ng umgesetzten. Ansonsten habe ich mir noch keine Meinung bilden können. Denn, Stand jetzt, verstehe ich noch nicht mal, wozu man überhaupt |
|
Ich verstehe ohnehin nicht, warum der Schaut man sich die Zwar wird dort dann mittels geflutet wird, nur der Tatsache zuzuschreiben, daß parallel noch Das Setzen von Wenn ich da nichts Fundamentales übersehe, interessiert sich Da ist eine Datei im r/o-Speicher sogar noch ein Schutz gegen das "Abschalten" der Signaturprüfung ... denn wenn es einem Angreifer gelingt, das Datum dieser Datei weit genug in die Zukunft zu verschieben (wenn sie an einer beschreibbaren Stelle liegt), wird die Signaturprüfung solange ausgesetzt, bis es wieder später ist, als das Dateidatum es vorgibt. Solche Angriffe sind auch nicht nur graue Theorie, hierfür reicht wieder ein manipulierter NTP-Server, wenn der Client nur einen einzigen befragt (m.W. macht das FRITZ!OS genau das). |
|
@er13 Es war mein eigener Gedanke!!! Weil in meinem LOG eben der Hinweis auf "read only filesystem" auftaucht... Daher liegt's einfach nahe, per Symlink die Datei auf ein beschreibbares FS auszulagern! |
|
@er13 erledigt, anbei das LOG beim Startup meiner 3490 mit DNSMasq: |
|
Da fehlt jetzt aber der Eintrag
im Protokoll. Dem Patch nach zu urteilen, sollte die Nachricht aber trotzdem erscheinen, bevor Der Ausschnitt aus dem Protokoll reicht also nicht aus, um die Funktion des Patches nachzuweisen - ob die Fehlernachricht wg. des Patches unterbleibt oder weil der Daemon die Änderung der Uhrzeit gar nicht geschnallt hat, kann man nicht sagen ... wobei die Wahrscheinlichkeit für letzteres deutlich höher liegt. Es kann aber auch am Puffern der Log-Einträge im "dnsmasq"-Daemon liegen, daß die noch nicht ausgegeben wurden bis zu diesem Punkt. |
|
Das ist alles, was mein Log bei einem Boot der 3490 bzgl. DNSMasq hergibt: |
|
Nach einem restart des DNSMasq: |
|
Das wäre wieder normal nach dem Restart, weil hier ja jetzt nicht die Signaturprüfung zurückgestellt wurde, bis die Uhrzeit gültig ist, wie das beim ersten Start noch der Fall war:
Es wäre ja nur wichtig zu klären, ob das beim ersten Startversuch noch irgendwo anders wieder auf "Prüfung ein" gesetzt wurde (und nur die Message fehlt), weil ansonsten halt die Signaturprüfung (genauer: die Prüfung der Zeitstempel) die gesamte Zeit deaktiviert ist. Es könnte auch eine Race-Condition sein, wenn die Zeit zwischen zwei Tests dann doch noch gesetzt wird und die Prüfung damit - trotz der anderslautenden Meldung - gar nicht wirklich zurückgestellt wird, bis die Zeit gesetzt wurde. Nur sollte man das dann auch mit passenden Messages protokollieren ... es ist schon "schwierig", wenn man eigentlich der Ansicht ist, die Signatur von DNSSEC-Antworten würde (in vollem Umfang) geprüft, obwohl das am Ende gar nicht der Fall ist. |
|
@WileC: In diesem Fall reicht es nicht aus, die Log-Datei unmittelbar nach dem Starten zu posten. Denn die Prüfung (und damit die entsprechende Log-Meldung), ob die Zeit nun valide geworden ist, wird postponed bis zu dem Zeitpunkt, zu dem einer der konfigurierten DNS-Server die erste mit DNSSEC versehene Antwort schickt. Oder andersrum, Du musst ein DNS-Request für eine Adresse absenden, bei der Du weist, dass die DNS-Responses für diese mit DNSSEC versehen sind. Erst dann ist
in den Log-Ausgaben zu erwarten. Test-Case 2: dnsmasq wird zu einem Zeitpunkt gestartet, zu dem die Zeit bereits valide ist. Ansonsten gehe ich davon aus, dass in Deiner dnsmasq-extra-Konfiguration die Option |
|
Also so sieht nun das Log vom DNSMasq mit dem aktuellen commit aus: hier noch die dnsmasq.conf, erstellt aus dem Optionen des WebIFs |
Das ist wohl das Log für den Test-Case 1. Sieht gut aus:
Jetzt fehlt nur noch das Log für den Test-Case 2. Wenn in diesem dann unmittelbar beim Starten von dnsmasq sowas auftauchen würde, dann kann man sagen, alle Patches greifen und das Ticket kann geschlossen werden. |
|
Also muss ich nur den DNSMasq neu starten? |
Ja. |
|
|
@WileC: Danke fürs Testen! |
|
Gerne |
When DNSSEC is enabled, disable its time checks until NTP set the system time properly. Reuse /etc/version as reference file. Closes #163 (cherry picked from commit c616c7b)
I'm running dnsmasq as DHCP and DNS server with DNSSEC enabled. A recent upgrade of Freetz also upgrades dnsmasq which broke DNS. After each reboot any DNS query would fail with
reply <TLD> is BOGUS DS. Disabling DNSSEC for a short time fixed the problem permanently (until the next reboot that is) and also DNSSEC worked fine again.After looking into the issue I figured out the problem and a found a similar bug report for Pihole:
--dnssec-check-unsignedis the default now, which is actually goodJan 1 01:01:14 fritz syslog.info syslogd started: BusyBox v1.27.2). I was surprised to find the Fritz box does not have an RTC.Disabling DNSSEC resolves the deadlock by allowing NTP to set the correct time which in turn allows DNSSEC validation. The current state is just plain bad: DNSSEC fails without any obvious reason. The obvious “solution” is to disable DNSSEC, but that's not good. One real option would be not to use Dnsmasq as the local resolver. That also means not to have DNSSEC for the box. Not too nice either. Probably the best choice is to only do this until NTP updated the clock. Any idea how to handle this properly?
[edit] The bug is generic, but for completeness: I have a FritzBox 7360SL running on
freetz-devel-15014.[/edit]The text was updated successfully, but these errors were encountered: