Forum: PC Hard- und Software Maroder Internetzugang obwohl DNS und einzelne Downloads problemlos sind


von Erwin M. (nobodyy)


Lesenswert?

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
von Erwin M. (nobodyy)


Lesenswert?

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

von Jim M. (turboj)


Lesenswert?

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.

von LOL (Gast)


Lesenswert?

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.

von LOL (Gast)


Lesenswert?

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".

von Erwin M. (nobodyy)


Lesenswert?

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
};

von (prx) A. K. (prx)


Lesenswert?

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.

von Erwin M. (nobodyy)


Lesenswert?

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;

von (prx) A. K. (prx)


Lesenswert?

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.

von Erwin M. (nobodyy)


Lesenswert?

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
von Erwin M. (nobodyy)


Lesenswert?

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

von Martin (Gast)


Lesenswert?

Und was sagt das DNS Logfile beim Aufruf der seite?

von Erwin M. (nobodyy)


Lesenswert?

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
von Erwin M. (nobodyy)


Lesenswert?

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.
von Erwin M. (nobodyy)


Lesenswert?

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.
von Dr. Google (Gast)


Lesenswert?

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.

von Dr. Google (Gast)


Lesenswert?


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
Noch kein Account? Hier anmelden.