Hallo Liste,
ist jemandem das Problem bekannt das nach dem Update der IPFire DNS nicht mehr funktioniert?
Ich habe das Problem, dass sobald die IPFire nur noch DNSSEC Server akzeptiert (Also ab Update 105?), er keine Verbindung mehr herstellt. Selbst wenn ich DNSSEC Server eintrage wie zum Beispiel 8.8.8.8.
Kennt das Jemand?
Grüße
Michael
Hallo Michael,
das hatte ich gerade gestern auch. Wir verwenden DynDNS zum Filtern und der IPFire hat die nicht akzeptiert beim Neustart des IPFire, obwohl DNSSEC hier funktioniert. IPFire nutzt dann den lokalen Resolver, was leider unsere Filter außer Kraft gesetzt hat.
Folgender Befehl hat die DNS-Server dann aktiviert:
Auf dem IPFIRE: /etc/init.d/unbound update-forwarders
Testen kann man die DNSSEC-Konformität:
/etc/init.d/unbound test-name-server
Viele Grüße
Knut
uuuhhhh das klingt nach einer Lösung
Muss ich morgen direkt mal abchecken
Ich danke dir 
Scheint funktioniert zu haben aber nach jedem neustart ist die funktion wieder futsch.
um das Problem in der Testumgebung zu lösen habe ich den befehl in /etc/sysconfig/rc.local eingefügt damit nach jedem neustart der Befehl durchgeführt wird.
Hoffe im Schulbetrieb klappt das auch so gut
Grüße
Michael
Hallo,
Ich habe heute in den logs unserer Firewall (ipfire core 109) folgende Fehlermeldung gelesen:
“Ignoring broken upstream name server(S): 129.143.2.4 129.143.2.1
Falling back to recursor mode”
Anschließend habe ich auf der Konsole folgende Befehle zur Diagnose abgesetzt:
“[root@ipfire ~]# /etc/init.d/unbound test-name-server 129.143.2.1
Unable to retrieve the following resource records from 129.143.2.1: RRSIG
129.143.2.1 is NOT DNSSEC-aware
129.143.2.1 supports TCP fallback
EDNS buffer size for 129.143.2.1: 4096
[root@ipfire ~]# /etc/init.d/unbound test-name-server 129.143.2.4
Unable to retrieve the following resource records from 129.143.2.4: RRSIG
129.143.2.4 is NOT DNSSEC-aware
129.143.2.4 supports TCP fallback
EDNS buffer size for 129.143.2.4: 4096
[root@ipfire ~]# /etc/init.d/unbound test-name-server 8.8.8.8
8.8.8.8 is validating
8.8.8.8 supports TCP fallback
EDNS buffer size for 8.8.8.8: 4096”
Nur google als nameserver scheint in Ordnung zu sein.
Zwei Fragen dazu:
Viele Grüße
Wilfried
Hallo,
zu 1.: Der Befehl löst das Problem wohl nicht.
Ich habe mich an Belwü gewandt und folgende Antwort erhalten:
"Die BelWü-Resolver unterstützen noch keine DNSSEC-Validierung. Diese
Funktionalität steht auf der Agenda für 2017.
Das DNSSEC-Konzept geht eigentlich davon aus, dass DNSSEC-Validierung
möglichst von einem Server gemacht wird, dem man absolut vertraut - sprich: einem
Server im eigenen Administrationsbereich. Wenn Sie DNSSEC-Validierung einem
externen Resolver überlassen, besteht die Gefahr, dass die Antwort auf dem Weg zu
Ihnen verfälscht wird. Dieser Betriebsmodus ist natürlich bequemer.
Ihr Problem scheint mit einer zu strikten DNS-Konfiguration in ipfire
zusammenzuhängen:
http://patchwork.ipfire.org/patch/1021/
Sie könnten Ihren eigenen Resolver als Full-Service-Resolver mit DNSSEC-
Validierung betreiben (“local recursor mode”). Falls das nicht funktioniert, setzen
Sie die DNSSEC in “Permissive mode”, oder deaktivieren DNSSEC ganz:
https://unbound.net/documentation/howto_turnoff_dnssec.html
Wie gesagt: DNSSEC-Validierung auf 129.143.2.1/4 kommt demnächst."
Die in den Links vorgeschlagenen workarounds habe ich mal lieber bleiben lassen, weil mir Nutzen/Schaden nicht wirklich klar ist.-
zu 2.: Mit dem Befehl ‘setup’ auf dem IPfire kann man die DNS-Server ändern, habe ich aber auch nicht getan.
Viele Grüße
Wilfried
Hallo,
so wie es aussieht, funktioniert dann auch OpenDNS nicht. (oder kann jemand das Gegenteil bestätigen?)
Hier ist ein aktueller Thread aus dem IPFire-Forum: http://forum.ipfire.org/viewtopic.php?t=17660
Evtl. kann man auf Norton ConnectSafe umsteigen: https://dns.norton.com/configurePC.html
Aber vor den Osterferien teste ich das nicht…
Viele Grüße
Jürgen
Hallo,
ja OpenDNS funktioniert schon seit IPFire 106 nicht mehr. Wenn das
weiter funktionieren soll, dann muss man an der unbound-Konfiguration
des IPFire rumschrauben…Jens Baumgärtner hat das herausgefunden…ich
zitiere hier nur nochmal seine Lösung, die bei mir schon seit einem
halben Jahr gut läuft:
—Schnipp—
ich habe jetzt in den Tiefen von unbound gestochert.
Laut
https://www.unbound.net/documentation/howto_turnoff_dnssec.html
Kann man das ganze dnssec-Gedöns ausschalten. Leider bringt das
zunächst mal nichts, da der ipfire in seinem Startscript bereits vorab
die DNS-Server, die nicht qualifiziert sind, rausfiltert. Ich habe dann
mal dem Startscript das raussfiltern abgewöhnt:
/etc/init.d/unbound
test_name_server() {
local ns=3D${1}
# Return codes:
# 0 DNSSEC validating
# 1 Error: unreachable, etc.
# 2 DNSSEC aware
# 3 NOT DNSSEC-aware
*** return 2*
(…)
# Is DNSSEC-aware
return 2
}
In der /etc/unbound/unbound.conf habe ich dann noch ipsec abgeschaltet.
Ich habe gerade keine Lust mehr auf weiteres Testen - wer will schaue mal -
nach, welche der zwei Optionen minimal geändert werden müssen, damit
das jetzt mal tut:
(...)
# DNSSEC
auto-trust-anchor-file: "/var/lib/unbound/root.key"
# geaendert 2016/12/15: von no auf yes
val-permissive-mode: yes
val-clean-additional: yes
val-log-level: 1
# Hardening Options
harden-glue: yes
harden-short-bufsize: no
harden-large-queries: yes
# geaendet 2016/12/14: yes auf no
harden-dnssec-stripped: no
(...)
Danach habe ich von den OpenDNS-Servern wieder antwort auf dem
ipFire bekommen
Gruß
Dominik
Hallo,
hier wird der Bug und eine Lösung dargestellt:
bugzilla.ipfire
in Core 111 soll das gefixt sein…
Grüße,
gerd
Hallo,
da ich noch in der Testphase bin, habe ich das hier beschriebene Testing auf 111 ausprobiert:
ipfire testing 111
umstellen auf testing
Das würde ich im produktiven System eher nicht empfehlen.
Mein ergebnis ist allerdings -leider leider- keine Änderung:
Auch nach dem Reboot erhalte ich:
ignoring broken upstream name server(s): 194.24.2.129 217.0.43.1
DNSSEC has been set to permissive mode
in der dnssec-status steht off:
[root@ipfire unbound]# cat /var/ipfire/red/dnssec-status
off
Wenn ich dann allerdings von Hand unbound DNS neu starte, dann läufts:
[root@ipfire unbound]# /etc/init.d/unbound restart
Stopping Unbound DNS Proxy... [ OK ]
Starting Unbound DNS Proxy... [ OK ]
Configuring upstream name server(s): 194.25.2.129 217.0.43.1 [ OK ]
[root@ipfire unbound]#
und jetzt steht in der dnssec-status ==> on:
[root@ipfire unbound]# cat /var/ipfire/red/dnssec-status
on
Das bedeutet also dass ich nach jedem Neustart des IPFire (was selten vorkommt) gegenwärtig jedesmal noch den unbound Dienst neu starte
EDIT:
siehe auch folgende Diskussion im IPFire Forum:
forum.ipfire.org
Grüße,
gerd
Hallo,
die Entwickler von IPFire, die am Coare 111 arbeiten, konnten am Wochenende obigen Fehler nicht nachvollziehen:
Wo kein Fehler gefunden wurde, kann auch keiner behoben werden
Wie verbreitet ist denn dieser “Bug” in linuxmuster? Oder anders gefragt, können sich noch weitere Betroffene an dieser Diskussion im IPFire Forum beteiligen?
Durch diese Antwort, stellt sich mir auch die Frage, dass das DNSSEC Problem durch das Setup von linuxmuster net mit verursacht wird?
Grüße,
gerd
Hallo zusammen,
Ja. Habe bei einer Neuinstallation dieses Verhalten festgestellt. Vor linuxmuster-ipfire alles ok, danach dieses Verhalten. ;-( Leider habe ich nicht heraus gefunden, worin genau die Ursache besteht.
Workaround für mich:
Das Problem ist das Skript „05-update-dns-forwarders“ unter „/etc/init.d/networking/red.up“. Das Skript funktioniert, wenn es erst nach Script „20-firewall“ ausgeführt wird.
Also z.B.:
mv 05-update-dns-forwarders 25-update-dns-forwarders
Grüße
Ja klasse! Hallo morpweb,
schön dass du das herausgefunden hast.
Weil bei mir der „upstream name servers“ sowohl beim hoch- als auch beim runterfahren hing, habe ich beide Skripte umbenannt:
unter:
/etc/init.d/networking/red.up
/etc/init.d/networking/red.down
jeweils
mv 05-update-dns-forwarders 21-update-dns-forwarders
Und siehe da, der Fehler ist weg, alles OK und grün, anstatt drei Minuten Verzögerung läuft das jetzt keine drei Sekunden! Ein:
cat /var/ipfire/red/dnssec-status
ergibt jetzt sofort => on
Danke!
gerd
Hi. Ich habe das Thema nur am Rande verfolgt … daher nochmal die Rückfrage:
Sehe ich das richtig, dass alle, die OpenDNS zusammen mit dem IPFire einsetzen, diesen Bugfix einsetzen sollten und danach problemlos auf Core 111 (oder was gerade aktuell ist?) updaten können? Anschließend funktionieren OpenDNS + IP-Fire ganz normal weiter?? Oder war sonst noch etwas zu tun?
Hallo Michael,
Nein. Nach http://wiki.ipfire.org/en/dns/public-servers sind die OpenDNS Server nicht „DNSSEC-aware“.
Es geht darum, dass offensichtlich irgendeine Änderung, die linuxmuster-ipfire an der Konfiguration des Ipfire durchführt, zur Folge hat, dass beim Starten (und Herunterfahren) Unbound mit Servern, die „DNSSEC-aware“ sind nicht funktioniert und Des Weiteren der Start und das Herunterfahren ewig dauert.
Derzeit verwende ich aus der Liste 85.214.20.141 und 213.73.91.35.
Nein.
Grüße und ein erholsames Wochenende.
Hallo Michael,
ich denke: nein
Das müsste eigentlich alle betreffen.
Und zwar unabhängig von OpenDNS und unabhängig von den letzten Versionen seit etwa 106 .
So verstehe ich das. Ich nutzte kein OpenDNS. Die Unbound und DNSSEC Problematik ist eine eigenständige Funktion des IPFire und braucht für den Hänger kein OpenDNS.
EDIT: ohh fast gleichzeitig, aber schön dass wir zur vergleichbaren Aussage kommen 
Grüße,
gerd
OK. Dann frage ich mal anders: was ist denn alles zu tun, wenn man OpenDNS weiter nutzen will und dem IPFire dennoch das Core-Upgrade verpassen will??
Hmm, wie schon gesagt, bei dem Teil des „Bugs“ auf den ich mich beziehe, gibt es keinen Zusammenhang zu OpenDNS, was ich gar nicht nutze.
Aber im Link weiter oben „17660“ schreibt doch Arne aus dem IPFire Entwicklerteam:
As long OpenDNS strips the signatures it is incompatible with DNSSec and IPFire.
Ich kenne dazu den aktuellen Stand nicht,
Grüße
Ok, gut zu wissen … aber wenn man OpenDNS weiter nutzen will, dreht man sich hier im Kreis, oder?
Also das Core-Upgrade ist einerseits fällig und kann mit diesem Bugfix auch zum Laufen gebracht werden – aber dennoch läuft OpenDNS mit DNSSec und IPFire nach letztem Stand der Dinge nicht zusammen.
Das heißt also entweder, dass man das Core-Upgrade nicht machen kann oder dass man auf OpenDNS verzichten muss (was ich nur ungern tun würde, da es seit Jahren “keinerlei Stress” mit Facebook & Co in der Schule gibt).
Guten Morgen,
Weiter oben ist doch schon beschrieben, wie man mit etwas Handarbeit (Deaktivierung von DNSsec) das Ganze zum Laufen bekommt. Allerdings wird man sich wohl bei jedem Upgrade die Arbeit noch einmal machen müssen. 
Das Sperrren von Seiten bekommt man sicherlich auch selbst mit Hilfe des URL-Filters) hin.
Grüße