Mit dem Internetzugang von Unitymedia zeigen sich heute wieder Probleme, die es bei anderen Providern nicht oder nur sehr selten gab: Einige Seiten sind auch nach 10 Stunden und über 10 Versuchen nicht abrufbar, heute: http://www.webupd8.org/ http://webcache.googleusercontent.com/ Erst nach 11 Stunden sind die Seiten nun plötzlich wieder abrufbar - ohne eine Änderung der Konfiguration und auch ohne Reboot, ohne Logout/Login und auch der Router lief ständig. Und weitere 3 Stunden später kommt wieder vom Firefox "Fehler: Server nicht gefunden Der Server unter www.webupd8.org konnte nicht gefunden werden". Einige Seiten sind etwas besser erreichbar, nach 3-10 Versuchen und nach einer Minute abrufbar: https://www.youtube.com/ http://www.pro-physik.de/ Das ist unabhängig vom Browser, mit Chrome auf Standard-Einstellungen ebenso wie mit Firefox und ebenso mit Konqueror. Die Fehlermeldung dazu ist das der Server nicht gefunden wurde. Chrome meldet es als DNS_PROBE_FINISHED_NXDOMAIN, Firefox als "Fehler: Server nicht gefunden". Es gibt auch Tage bei denen ich Emails von https://web.de/ kaum abrufen kann, weil mal eine Email angezigt wird, mal "Fehler: Server nicht gefunden", so das kaum eine Mail lesbar ist. Aber ich habe es am Mittag vom Rechner in der Firma probiert und alle diese Seiten sind problemlos erreichbar, so das am Internetzugang von Unitymedia etwas marode ist.Das zeigt sich schon an der Bandbreite: Gleichzeitg ein dutzend Links öffnen müsste einige MB Traffic erzeugen, bei angeblichen 400 Mbps die von der ConnectBox angezeigt werden, praktisch werden aber nie über 10 kB/s erreicht und die Seiten werden teilweise minutenlang geladen. Daneben gibt es auch den Fehler Error 502, Bad gateway von Cloudfare, z. B. zu http://www.torrents.net/. Aber das ist wohl ein ganz anderes Problem. Auf der Kommandozeile zeigen sich aber keine Probleme: Downloads mit wget zeigen meist 20 MB/s und DNS-Abfragen mit dig und nslooup liefern immer eine Antwort. Beispiel: > nslookup www.webupd8.org ;; Got SERVFAIL reply from 127.0.0.53, trying next server Server: 192.168.0.1 Address: 192.168.0.1#53 Non-authoritative answer: www.webupd8.org canonical name = ghs.google.com. ghs.google.com canonical name = ghs.l.google.com. Name: ghs.l.google.com Address: 172.217.23.147 Ich habe schon verschiedene DNS-Server eingestellt, z. B. 8.8.8.8, aber das änderte ab deb sporadischen Fehlern nichts. Lynx sagt dazu: > lynx www.webupd8.org Suche nach 'www.webupd8.org' erster Suche nach 'www.webupd8.org.com' (Versuch zu raten...) Suche nach www.webupd8.org erster Suche nach www.webupd8.org.com (Versuch zu raten...) Suche nach www.webupd8.org.com HTTP-Verbindung zu www.webupd8.org.com wird aufgebaut. HTTP Request wird geschickt. HTTP Request geschickt; warten auf Antwort. HTTP/1.1 301 Moved Permanently �bertragung komplett. HTTP/1.1 301 Moved Permanently Umgeleitet nach http://www.org.com?not_found=www.webupd8.org.com Suche nach www.org.com Remote Host www.org.com nicht gefunden. Obacht: Verbindung zum remote Host konnte nicht hergestellt werden. lynx: Unzug�ngliche Startdatei http://www.webupd8.org.com/ Aber 5 Minuten später ist die Seite wieder erreichbar, mit Lynx wie Firefox. Was ist da los?
:
Bearbeitet durch User
Update: Mir ist aufgefallen das die DNS-Antworten sich gändert haben.
Nicht ladbar war die Seite mit:
> nslookup www.webupd8.org
;; Got SERVFAIL reply from 127.0.0.53, trying next server
Server: 192.168.0.1
Address: 192.168.0.1#53
Non-authoritative answer:
www.webupd8.org canonical name = ghs.google.com.
ghs.google.com canonical name = ghs.l.google.com.
Name: ghs.l.google.com
Address: 172.217.23.147
Fünf Minuten später war sie ladbar mit:
> nslookup www.webupd8.org
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
www.webupd8.org canonical name = ghs.google.com.
ghs.google.com canonical name = ghs.l.google.com.
Name: ghs.l.google.com
Address: 172.217.22.51
Erwin M. schrieb: > ;; Got SERVFAIL reply from 127.0.0.53, trying next server 127.0.0.x ist localhost. Da spinnt der DNS Cache auf Deiner Kiste.
Jim M. schrieb: > Erwin M. schrieb: >> ;; Got SERVFAIL reply from 127.0.0.53, trying next server > > 127.0.0.x ist localhost. Da spinnt der DNS Cache auf Deiner Kiste. Nicht unbedingt, einige Linuxe (u.a. Ubuntu) setzen auf dnsmasq zur lokalen Auflösung, u.a. wegen der einfacheren Virtualisierung. Das Teil ist eigentlich ein caching DNS+DHCP Server für kleine Netze, daher hat man dann einen lokalen DNS-Server am laufen, der wiederum den DNS vom Router abfragt. Im konkreten Fall geht es vermutlich um den resolver von systemd, der nutzt glaube ich exakt diese Adresse, zumindest laut Google: https://github.com/systemd/systemd/issues/5051 https://github.com/systemd/systemd/commit/b30bf55d5c9942f15f27a641c2c34bbb646ec981 Die Frage ist aber trotzdem, warum die Domains teilweise nicht auflösbar sind - Seite nicht gefunden, NXDOMAIN als Fehlermeldungen sind da eindeutig. Erwin M. schrieb: > Ich habe schon verschiedene DNS-Server eingestellt, z. B. 8.8.8.8, aber > das änderte ab deb sporadischen Fehlern nichts. Da du das nicht explizit schreibst: Bitte mach das testweise an deinem Router, nicht auf deinem PC. Dadurch wirkt sich die Änderung automatisch auf alle Geräte aus (die den Router als DNS nutzen) und es ist auch weniger fehleranfällig: Ich weiß nicht, ob/wie das bei Systemd über resolv.conf geht.... Im Idealfall testest du nicht nur den DNS-Server von google, sondern einen der dem Provider (hoffentlich) nicht bekannt ist, z.B. https://dns.watch/index http://wiki.ipfire.org/en/dns/public-servers Nicht das Google-DNS abgefangen wird und an überlastete Server des Providers geleitet wird... (Wobei das dann eigentlich per Ziel-Port gemacht werden würde, nicht per IP, um alle DNS-Server gleichzeitig zu erfassen.) Das Problem ist aber vermutlich im Wesentlichen, das die Kabelanschlüsse (zumindest bei meinen Bekannten) zu Stoßzeiten hoffnungslos überlastet sind, weil es sich a) um ein shared Medium handelt, d.h. je mehr Benutzer, je langsamer und b) der Backbone die 100MBit pro Kunde nicht mal ansatzweise hergibt. Eindeutiges Indiz dafür, wäre das diese Probleme regelmäßig in Zeitfenstern (Wochentags und Wochenende ggf. verschieden) auftreten.
Nachtrag: Verschiedene DNS-Server kannst du auch am einfachsten direkt testen:
1 | $ dig www.webupd8.org @127.0.1.1 |
2 | ... |
3 | $ dig www.webupd8.org @8.8.8.8 |
4 | ... |
5 | $ dig www.webupd8.org @84.200.70.40 |
6 | |
7 | ; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.webupd8.org @84.200.70.40 |
8 | ;; global options: +cmd |
9 | ;; Got answer: |
10 | ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57460 |
11 | ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 |
12 | |
13 | ;; OPT PSEUDOSECTION: |
14 | ; EDNS: version: 0, flags:; udp: 4096 |
15 | ;; QUESTION SECTION: |
16 | ;www.webupd8.org. IN A |
17 | |
18 | ;; ANSWER SECTION: |
19 | www.webupd8.org. 300 IN CNAME ghs.google.com. |
20 | ghs.google.com. 602844 IN CNAME ghs.l.google.com. |
21 | ghs.l.google.com. 243 IN A 74.125.206.121 |
22 | |
23 | ;; Query time: 49 msec |
24 | ;; SERVER: 84.200.70.40#53(84.200.70.40) |
25 | ;; WHEN: Fri Jun 30 05:20:25 CEST 2017 |
26 | ;; MSG SIZE rcvd: 108 |
.... das geht auch mit dem Älteren "nslookup".
Also der Router ist eine ConnectBox von Unitymedia, an der ich kaum etwas einstellen kann. Deshalb habe ich einen Bind9 installiert und die empfohlenen Server eingetragen (wobei im Forum die Formatierung verloren geht):
1 | options { |
2 | directory "/var/cache/bind"; |
3 | |
4 | // If there is a firewall between you and nameservers you want |
5 | // to talk to, you may need to fix the firewall to allow multiple |
6 | // ports to talk. See http://www.kb.cert.org/vuls/id/800113 |
7 | |
8 | // If your ISP provided one or more IP addresses for stable |
9 | // nameservers, you probably want to use them as forwarders. |
10 | // Uncomment the following block, and insert the addresses replacing |
11 | // the all-0's placeholder. |
12 | |
13 | recursion yes; # enables resursive queries |
14 | //allow-recursion { trusted; }; # allows recursive queries from "trusted" clients |
15 | listen-on { 127.0.0.1; 192.168.0.0/16; }; # ns1 private IP address - listen on private network only |
16 | allow-transfer { none; }; # disable zone transfers by default |
17 | |
18 | forwarders { |
19 | 194.150.168.168; |
20 | 213.73.91.35; |
21 | 85.214.20.141; |
22 | 2001:1608:10:25::1c04:b12f; |
23 | 2001:1608:10:25::9249:d69b; |
24 | 84.200.69.80; |
25 | 84.200.70.40; |
26 | //2a02:908:2:a::1; |
27 | //2a02:908:2:b::1; |
28 | //80.69.100.174; |
29 | //80.69.100.198; |
30 | //8.8.8.8; |
31 | //8.8.4.4; |
32 | //192.168.0.1; |
33 | }; |
34 | |
35 | //======================================================================== |
36 | // If BIND logs error messages about the root key being expired, |
37 | // you will need to update your keys. See https://www.isc.org/bind-keys |
38 | //======================================================================== |
39 | //dnssec-validation auto; |
40 | forward only; |
41 | dnssec-enable yes; |
42 | dnssec-validation yes; |
43 | |
44 | auth-nxdomain no; # conform to RFC1035 |
45 | listen-on-v6 { any; }; |
46 | }; |
DNS Probleme gibts bei Unitymedia immer mal. Ich habe deshalb mittlerweile ebenfalls auf einen eigenen DNS-Cache gesetzt und seither habe ich Ruhe. Allerdings achte ich darauf, dass der Cache auf Server setzt, die per IPv6 erreichbar sind, weil ich einen Zusammenhang mit dem Carrier Grade NAT der Kabelanschlüsse für möglich halte. UDP wie in DNS-Requests ist für CGN ziemlich unangenehm.
A. K. schrieb: > Ich habe deshalb > mittlerweile ebenfalls auf einen eigenen DNS-Cache gesetzt und seither > habe ich Ruhe. Allerdings achte ich darauf, dass der Cache auf Server > setzt, die per IPv6 erreichbar sind, weil ich einen Zusammenhang mit dem > Carrier Grade NAT der Kabelanschlüsse für möglich halte. Und mit welchen Forward-Servern? Ich habe mal die Reihenfolge bei mir geändert auf: 2001:1608:10:25::1c04:b12f; 2001:1608:10:25::9249:d69b; 194.150.168.168; 213.73.91.35; 85.214.20.141; 84.200.69.80; 84.200.70.40;
Ich habe nur die beiden Googles drin: forwarders { 2001:4860:4860::8888; 2001:4860:4860::8844; }; Ok, in anderer Hinsicht ist das Teufel gegen Beelzebub, aber immerhin funktioniert das DNS so.
Ok, danke. Nun ist meine Konfiguration wie folgt:
1 | options { |
2 | directory "/var/cache/bind"; |
3 | |
4 | // If there is a firewall between you and nameservers you want |
5 | // to talk to, you may need to fix the firewall to allow multiple |
6 | // ports to talk. See http://www.kb.cert.org/vuls/id/800113 |
7 | |
8 | // If your ISP provided one or more IP addresses for stable |
9 | // nameservers, you probably want to use them as forwarders. |
10 | // Uncomment the following block, and insert the addresses replacing |
11 | // the all-0's placeholder. |
12 | |
13 | recursion yes; # enables resursive queries |
14 | //allow-recursion { trusted; }; # allows recursive queries from "trusted" clients |
15 | listen-on { |
16 | 10.0.0.0/8; |
17 | 127.0.0.0/8; |
18 | 169.254.0.0/16; |
19 | 172.16.0.0/12; |
20 | 192.168.0.0/16; |
21 | fec0::/10; |
22 | }; # ns1 private IP address - listen on private network only |
23 | |
24 | allow-transfer { none; }; # disable zone transfers by default |
25 | |
26 | forwarders { |
27 | 2001:1608:10:25::1c04:b12f; |
28 | 2001:1608:10:25::9249:d69b; |
29 | 2001:4860:4860::8888; |
30 | 2001:4860:4860::8844; |
31 | 194.150.168.168; |
32 | 213.73.91.35; |
33 | 85.214.20.141; |
34 | 84.200.69.80; |
35 | 84.200.70.40; |
36 | //2a02:908:2:a::1; |
37 | //2a02:908:2:b::1; |
38 | //80.69.100.174; |
39 | //80.69.100.198; |
40 | //8.8.8.8; |
41 | //8.8.4.4; |
42 | //192.168.0.1; |
43 | }; |
44 | |
45 | //======================================================================== |
46 | // If BIND logs error messages about the root key being expired, |
47 | // you will need to update your keys. See https://www.isc.org/bind-keys |
48 | //======================================================================== |
49 | //dnssec-validation auto; |
50 | forward only; |
51 | dnssec-enable yes; |
52 | dnssec-validation yes; |
53 | |
54 | auth-nxdomain no; # conform to RFC1035 |
55 | listen-on-v6 { any; }; |
56 | }; |
Bisher läuft das problemlos, aber bei sporadischen Fehlern muss man zumindest wochenlang beobachten ob sich wirklich eine Verbesserung zeigt. Was mir auffällt ist das wenn ein Dutzend Booksmarks auf einmal geöffnet wird nun mit über 1 MB/s geladen wird, also schon deutlich schneller. Habe ich alle privaten IP-Adressbereiche aufgelistet oder fehlen noch welche?
:
Bearbeitet durch User
Nun zeigte sich ein anderer Fehler: navigator.web.de hat die Verbindung abgelehnt. Versuchen Sie Folgendes: Verbindung prüfen Proxy und Firewall prüfen ERR_CONNECTION_REFUSED
Und was sagt das DNS Logfile beim Aufruf der seite?
Martin schrieb: > Und was sagt das DNS Logfile beim Aufruf der seite? Da steht nichts, obwohl ich daran gestern nichts geändert habe. Das Ende vom Logfile ist:
1 | 30-Jun-2017 20:03:15.381 general: notice: running |
2 | 30-Jun-2017 21:32:18.109 general: info: received control channel command 'stop' |
3 | 30-Jun-2017 21:32:18.109 general: info: shutting down: flushing changes |
4 | 30-Jun-2017 21:32:18.109 general: notice: stopping command channel on 127.0.0.1#953 |
5 | 30-Jun-2017 21:32:18.109 general: notice: stopping command channel on ::1#953 |
6 | 30-Jun-2017 21:32:18.109 network: info: no longer listening on ::#53 |
7 | 30-Jun-2017 21:32:18.109 network: info: no longer listening on 127.0.0.1#53 |
8 | 30-Jun-2017 21:32:18.109 network: info: no longer listening on 192.168.0.157#53 |
9 | 30-Jun-2017 21:32:18.109 network: info: no longer listening on 192.168.59.97#53 |
10 | 30-Jun-2017 21:32:18.109 network: info: no longer listening on 192.168.1.22#53 |
11 | 30-Jun-2017 21:32:18.109 network: info: no longer listening on 192.168.2.33#53 |
12 | 30-Jun-2017 21:32:18.114 general: notice: exiting |
13 | 30-Jun-2017 21:32:18.142 general: info: managed-keys-zone: loaded serial 0 |
14 | 30-Jun-2017 21:32:18.145 general: info: zone 0.in-addr.arpa/IN: loaded serial 1 |
15 | 30-Jun-2017 21:32:18.145 general: info: zone localhost/IN: loaded serial 2 |
16 | 30-Jun-2017 21:32:18.145 general: info: zone 127.in-addr.arpa/IN: loaded serial 1 |
17 | 30-Jun-2017 21:32:18.145 general: info: zone 255.in-addr.arpa/IN: loaded serial 1 |
18 | 30-Jun-2017 21:32:18.145 general: notice: all zones loaded |
19 | 30-Jun-2017 21:32:18.145 general: notice: running |
Und der Fehler bei web.de tritt sporadisch auf, so das Login und Mails online lesen geht, dann kommt der Fehler und meist ist er nach F5 (reload) weg.
:
Bearbeitet durch User
Ich habe die Ursache für den Abbruch vom Log, denn in der named.conf.log war ein Limit von 5M: file "/var/log/bind/bind.log" versions 3 size 5m; Ohne das Limit wird wieder aufgezeichnet.
Beitrag #5062332 wurde von einem Moderator gelöscht.
Beitrag #5062342 wurde von einem Moderator gelöscht.
Beitrag #5062367 wurde von einem Moderator gelöscht.
Das BIOS ist ubgedatet, auch mit einem Bugfix zum Intel Bug SKZ7, und das iAMT ist weitgehend abgeschaltet und dazu ist ein sicheres Passwort gesetzt. Bei den spradischen Problemen habe ich im Bind-Log nachgesehen, aber da steht nicht viel: 02-Jul-2017 12:20:02.935 general: debug 1: automatic interface rescan 02-Jul-2017 12:21:09.073 general: debug 1: automatic interface rescan 02-Jul-2017 12:22:10.642 general: debug 1: automatic interface rescan 02-Jul-2017 12:25:07.061 general: debug 1: automatic interface rescan 02-Jul-2017 12:27:45.685 general: debug 1: automatic interface rescan 02-Jul-2017 12:30:37.771 general: debug 1: automatic interface rescan Dabei ist in den Log-Einstellungen viel eingetragen:
1 | logging{ |
2 | channel bind_log { |
3 | file "/var/log/bind/bind.log" versions 3 size 10M; |
4 | severity debug; |
5 | print-time yes; |
6 | print-severity yes; |
7 | print-category yes; |
8 | }; |
9 | category update { bind_log; }; |
10 | category update-security { bind_log; }; |
11 | category security { bind_log; }; |
12 | category queries { bind_log; }; |
13 | category lame-servers { bind_log; }; |
14 | category resolver {bind_log;}; |
15 | category default {bind_log;}; |
16 | category client {bind_log;}; |
17 | category config {bind_log;}; |
18 | category notify {bind_log;}; |
19 | category unmatched {bind_log;}; |
20 | category dispatch {bind_log;}; |
21 | category dnssec {bind_log;}; |
22 | category database {bind_log;}; |
23 | }; |
:
Bearbeitet durch User
Beitrag #5062480 wurde von einem Moderator gelöscht.
Beitrag #5062567 wurde von einem Moderator gelöscht.
Das Problem: Ich arbeite auch mit dnsscript (mehrere Provider) unbound und VPN. Was habe ich zu verstecken? Genau gar nichts! Es stört einzelne von KabelBW, dass sie nicht mitlesen können. Mein Rechner wird effektiv ausgeschaltet, wenn ich Tails, Knoppix und BSD laufen lasse. Die Rechner (mehr als 10 verschiedene), sie stürzen nicht ab, der Strom wird abgeschaltet. Ich vermute mal, dass das auch Dein Problem ist. Du verwendest einen DNS-Cache was Tracing erschwert. Die Kommunikation mit dem BMC-Prozessor ist geheim. Man braucht dafür einen Intel Masterkey mit starker Verschlüsselung, den ein Knecht, der für einen OEM (Micronas) arbeitet aber irgendwie abgegriffen haben muss. Die Verbindung wird über eine Kombination von Port-Knocking initialisiert. Möglicherweise hackt der auch hier im Forum herum und "der Moderator" kriegt gar nix mit. Der ("Moderator") könnte sich wenigstens erkenntlich zeigen und dementieren (?). Jedenfalls sind die Symptome bei mir ganz ähnlich. Meistens habe ich 100% Speed. Wenn VPN zum Einsatz kommt oder dnsscript oder unbound dann geht nicht mal ein einziges Byte über die Leitung. Ich kann sowas konfigurieren. Auch VPN startet bei mir automatisch neu, wenn die Verbindung mal hängt. Das funktioniert einwandfrei unrooted. Wenn man dann den ARP-Cache löscht: arp -a -d geht alles wieder, zumindest für ein paar Sekunden oder sogar Minuten. Momentan arbeite ich mit Knoppix auf einer Hardware-Schreibgeschützten Festplatte und es gibt praktisch kein Problem mehr.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.