DNS Problem

Dirk_F · 2022-01-18T22:17:16+00:00

Sunrise Community - Kunden helfen anderen Kunden rund um die Themen Fernsehen, Internet, Telefon und Mobile. Jetzt registrieren!

Dirk_F

Hallo,

seit heute haben alle mit der Connect Box (IPv4 only) verbundenen Geräte ein DNS-Problem, egal ob manuell konfiguriert (DNS und Gateway: 192.168.0.1, also die Connect Box) ~~oder per DHCP~~. Mit der Eingabe von IP-Adressen funktioniert es:

pi@raspberrypi:~ $ ping -c 4 213.46.237.24
PING 213.46.237.24 (213.46.237.24) 56(84) bytes of data.
64 bytes from 213.46.237.24: icmp_seq=1 ttl=249 time=32.2 ms
64 bytes from 213.46.237.24: icmp_seq=2 ttl=249 time=30.0 ms
64 bytes from 213.46.237.24: icmp_seq=3 ttl=249 time=28.0 ms
64 bytes from 213.46.237.24: icmp_seq=4 ttl=249 time=26.3 ms

--- 213.46.237.24 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 7ms
rtt min/avg/max/mdev = 26.304/29.131/32.215/2.211 ms
pi@raspberrypi:~ $ ping -c 4 upc.ch
ping: upc.ch: Temporärer Fehler bei der Namensauflösung
pi@raspberrypi:~ $

In der Box habe ich im Networklog folgendes entdeckt:

Tue 18/01/2022 05:39:46 6 SW download Successful - Via NMS
Tue 18/01/2022 05:37:53 6 SW Download INIT - Via NMS

Ich gehe mal von einem FW-Update aus. Die Geräteinfo zeigt folgendes:

Information

Connect Box Geräteinfo

Die folgenden Informationen zeigen Ihnen den aktuellen Status Ihrer Connect Box.

Konform zur Standardspezifikation**: DOCSIS 3.1**
Hardware Version**: 11**
Software Version**: AR01.04.055.06_110421_7245.SIP.10.LG.X1(Open Source Information)**
Kabel MAC Adresse**: AC:F8:CC:25:80:65**
Kabelmodem Seriennummer**: ABAP03452149**
Systemverfügbarkeit**: 0 days 9h:37m:37s**
Netzwerkzugang**: Erlaubt**

WAN IP Einstellungen

Die aktuellen Internet Einstellungen Ihrer Connect Box sind unten aufgeführt

MAC Adresse**: AC:F8:CC:25:80:67**

IPv4 Adresse**: 178.82.209.236**
Standard Gateway**: 178.82.208.1**
IPv4 lease time**: 0 days 23h:40m:32s**
IPv4 lease expire**: 19/01/2022 22:44:15**
IPv4 DNS Servers**: 62.2.17.61,62.2.24.158**

Ich habe keinerlei Konfigurationsänderungen durchgeführt, ausser dass ich mit dem PC, vor dem ich jetzt sitze, via Proxy im Netz bin, das geht. Kann sich das bitte mal jemand vom Team angucken?

Vielen Dank

Dirk

Belegnor

Hallo Dirk_F

Gestern wurde scheinbar ein Update für die Connect Box eingespielt (bei mir war es auch der Fall). Dabei ist es normal, dass es kurzzeitig zu DNS Problemen kommt, da die Box neu gestartet wird.

Nach dem Neustart sollte die DNS-Auflösung jedoch wieder funktionieren. Allerdings nur wen der DHCP-Server der Connect Box aktiv ist. Bei inaktivem DHCP-Server kann die Connect Box nicht als DNS-Forwarder verwendet werden.

Wenn du einen eigenen DNS-/DHCP-Server betreibst, dann solltest du die UPC DNS-Server anstelle der Connect Box als DNS-Forwarder angeben …

Da sparst du dir einiges an Ärger … 😉

Ich hoffe, das hilft

Gruss

Belegnor

Dirk_F

Hallo,

nachdem ich den Fehler festgestellt habe, habe ich natürlich erst mal einen Neustart der Box und aller Clients gemacht, ohne Erfolg. Einen Reset will ich (erst mal) nicht machen, da dann alle Einstellungen incl. sämtlicher Portweiterleitungen weg sind. Und ich weiss nicht, ob ich mir bei einem Backup auch das “Problem” mit sichere…

Bei Geräten, die ihre IP per DHCP beziehen, besteht das Problem nicht (habe meinen ersten Post korrigiert). Sie erhalten dann den ersten bzw. beide DNS-Server der Box, so wie oben angegeben. Bei den Geräten mit fest zugewiesener IP habe ich jetzt die DNS-Server der Box eingefügt (anstelle der IP der Box), soweit funktioniert dann wieder alles. Das ist aber nicht die Lösung des Problems, denn die können sich ja ändern und ich müsste dann wieder an allen Geräten die DNS-Server korrigieren. Vielmehr sollte die Box das DNS-Forwarding bewerkstelligen.

Belegnor Wenn du einen eigenen DNS-/DHCP-Server betreibst, dann solltest du die UPC DNS-Server anstelle der Connect Box als DNS-Forwarder angeben …

Ich betreibe keinen eigenen DNS- oder DHCP-Server. DHCP ist lediglich in der Box aktiviert und an allen anderen Geräten (ich benutze noch einige Router vom Typ TP-Link Wireless N Nano Router WR802N im Client-Modus) deaktiviert.

GrandDixence Wenn ein Problem mit DNS vorliegt, sollte man auch die richtigen Werkzeuge für die Suche nach DNS-Problemen einsetzen. Also für Windows:

$ ipconfig /all

Die Ausgabe, auf den wesentlichen Teil beschränkt (ich habe noch einige virtuelle Ethernet Adapter auf Grund einer VMWare-Installation), bevor ich die DNS-Server manuell geändert habe:

C:\Windows\System32>ipconfig /all

Windows-IP-Konfiguration

Hostname . . . . . . . . . . . . : dfii
Primäres DNS-Suffix . . . . . . . :
Knotentyp . . . . . . . . . . . . : Hybrid
IP-Routing aktiviert . . . . . . : Nein
WINS-Proxy aktiviert . . . . . . : Nein

Ethernet-Adapter LAN-Verbindung:

Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Realtek PCIe GBE Family Controller
Physikalische Adresse . . . . . . : BC-5F-F4-6A-C0-C5
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
IPv4-Adresse . . . . . . . . . . : 192.168.0.71(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.0.0
Standardgateway . . . . . . . . . : 192.168.0.1
DNS-Server . . . . . . . . . . . : 192.168.0.1
NetBIOS über TCP/IP . . . . . . . : Aktiviert

GrandDixence $ nslookup tick.switch.ch

C:\Windows\System32>nslookup tick.switch.ch
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.0.1

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.

*** Zeitüberschreitung bei Anforderung an UnKnown.

Mit manuell geändertem DNS-Server, wie eingangs beschrieben, funktioniert’s natürlich:

C:\Windows\System32>nslookup tick.switch.ch
Server: ns11.cablecom.net
Address: 62.2.17.61

Nicht autorisierende Antwort:
Name: tick.switch.ch
Addresses: 2001:620:0:ff::31

      130\.59.31.31

GrandDixence Bekanntes Problem. Siehe auch:
https://community.sunrise.ch/d/19101-dns-auflosung-funktioniert-nicht

Die Lösung kann nur seitens UPC erfolgen, nicht von seiten der User. Das DNS-forwarding der Box funktioniert seit dem Update nicht mehr. Aber eine Lösung ist bisher nicht erfolgt, oder ?!?

Gruss Dirk

GrandDixence

Bekanntes Problem. Siehe auch:
https://community.sunrise.ch/d/19101-dns-auflosung-funktioniert-nicht

Wenn ein Problem mit DNS vorliegt, sollte man auch die richtigen Werkzeuge für die Suche nach DNS-Problemen einsetzen. Also für Windows:

$ ipconfig /all
$ nslookup tick.switch.ch

Hilfestellung:
$ nslookup /?

Aus dem ersten Beitrag sind keinerlei Informationen zum DNS-Forwarder/DNS-Proxy im EuroDOCSIS-Kabelmodem (hier: Giga Connect Box) ersichtlich. Bitte die oben stehenden Informationen nachliefern.

Patrick_

Das ist mit ganz grosser Wahrscheiinlichkeit auch “das Problem seit der Nacht mit dem Januar-Firmware-Update des EuroDOCSIS-Kabelmodems” -> https://community.sunrise.ch/d/19173-giga-connect-box-internetaussetzer-nach-update/4 - ein Desaster!

GrandDixence

Dirk_F Aber eine Lösung ist bisher nicht erfolgt, oder ?!?

Wenn in der Nacht keine fehlerkorrigierte Firmware auf dem EuroDOCSIS-Kabelmodem installiert wurde, offenbar nicht. So oder so empfiehlt sich die strikte Einhaltung von “Gute Performance”-Regel Nr. 1 bis und mit Nr. 5 inklusive Nr. 23.
https://community.sunrise.ch/d/8569-gigaconnect-aussetzer/25

Für Internetanschlüsse, welche hochverfügbar sein müssen, empfiehlt sich der Einsatz von unbound, wie er in Gute Performance Regel Nr. 23 beschrieben ist.

Eine Umkonfiguration der DNS-Server wäre nicht erforderlich gewesen. Nslookup kann man mit dem 2. Parameter anweisen, die DNS-Anfragen an einen anderen DNS-Server zu senden:

$ nslookup tick.switch.ch 62.2.17.61

Deshalb auch der (offensichtlich ungelesene) Hinweis auf die Hilfestellung von nslookup (“/?”).

Belegnor

GrandDixence

Für Internetanschlüsse, welche hochverfügbar sein müssen, empfiehlt sich der Einsatz von unbound, wie er in Gute Performance Regel Nr. 23 beschrieben ist.

Nur eine einfache Frage: Ist dir bewusst, dass deine Aussage sehr “gewagt” ist, um sie nicht direkt als völliger Unsinn zu bezeichnen?

Erstens: Für Internetanschlüsse, welche hochverfügbar sein müssen, benötigt man nur mehrere ISPs. Dabei ist es völlig egal, welcher DNS-Server intern verwendet wird. Es gibt genug Alternativen, welche die gleiche Aufgabe wie Unbound erfüllen können, einige von ihnen aufgrund ihres Funktionsumfangs sogar besser

Zweitens: Die “DNS-Redundanz” kann man auch erreichen in dem man mehrere DNS-Forwarder in der Konfiguration einträgt., z. B. …

Primärer DNS: UPC DNS-Server 1
Sekundärer DNS: UPC DNS-Server 2
Tertiärer DNS: Google DNS Server 1

Je nach eingesetztem Produkt kann mehr oder weniger Forwarder eintragen …

Dirk_F

Meine Empfehlung wäre, einen eigenen DNS-/DHCP Server einzusetzen. So bist du flexibler unterwegs. Welches Produkt für dich geeignet ist, hängt von deinen Anforderungen an. Wenn du mehrere Scopes (Netzbereiche) einrichten willst, dann kannst du es mit Univention CS (Alternative zu Windows Server auf Linux Basis) versuchen. Ansonsten wären dnsmasq oder Pi-hole ebenfalls möglich

Eine weitere Variante wäre eine Firewall einzusetzen, und diese als DNS-/DHCP-Server zu verwenden. Auch in diesem Fall hast du mehrere Möglichkeiten, z. B. …

pfSense

pfSense® - World’s Most Trusted Open Source Firewall (pfSense Webseite)
OPNsense

OPNsense® a true open source security platform and more - OPNsense® is a true open source firewall and more (OPNsense Webseite)

OPNsense Firewalls | Thomas-Krenn.AG
Sophos XG Firewall Home

Free Home Firewall | Sophos Home Edition Firewall (Sophos Webseite)

Sophos für Heimanwender - Firewall und Endpoint (avanet.com)

Ich hoffe, das hilft weiter … 🙂

Dirk_F

Hallo,

GrandDixence Wenn in der Nacht keine fehlerkorrigierte Firmware auf dem EuroDOCSIS-Kabelmodem installiert wurde

leider nicht…

GrandDixence So oder so empfiehlt sich die strikte Einhaltung von “Gute Performance”-Regel Nr. 1 bis und mit Nr. 5 inklusive Nr. 23.
https://community.sunrise.ch/d/8569-gigaconnect-aussetzer/25

Diese ganzen Performance-Regeln sind für mich nicht von Belang, solange das DNS-forwarding des Routers nicht funktioniert. Eine (von vielen) Aufgaben eines Routers ist es, DNS-Anfragen, sofern nicht bereits im Cache vorhanden, weiterzuleiten. Oder siehst du das anders?

GrandDixence Eine Umkonfiguration der DNS-Server wäre nicht erforderlich gewesen. Nslookup kann man mit dem 2. Parameter anweisen, die DNS-Anfragen an einen anderen DNS-Server zu senden:

$ nslookup tick.switch.ch 62.2.17.61

Inwiefern soll das zur Lösung des eigentlichen Problems beitragen, bei der Anfrage mit nslookup einen anderen DNS-Server als Parameter zu übergeben? Dass es mit einem anderen DNS-Server funktioniert, habe ich ja schon in meinem vorherigen Beitrag geschrieben.

GrandDixence Deshalb auch der (offensichtlich ungelesene) Hinweis auf die Hilfestellung von nslookup (“/?”).

Die Funktion des Parameters “/?” ist mir durchaus bekannt. Aber liest du eigentlich, was ich hier schreibe? Bisher bist du noch mit keiner Silbe auf das eigentliche Problem eingegangen, welches recht eindeutig im FW-Update der Box zu suchen ist. Warum sollte ich als Endkunde in meiner bisher sehr gut funktionierenden Konfiguration rumfummeln, wenn es offensichtlich seitens des Providers mit diesem Update verbockt wurde? Dass hier nicht noch mehr Beschwerden kommen, liegt vermutlich daran, dass die meisten Kunden keinem Gerät in ihrem LAN eine feste IP zugewiesen haben und diese, zusammen mit den korrekten DNS-Servern, vom DHCP-Server der Box beziehen.

GrandDixence Für Internetanschlüsse, welche hochverfügbar sein müssen, empfiehlt sich der Einsatz von unbound, wie er in Gute Performance Regel Nr. 23 beschrieben ist.

Gute Idee, denke drüber nach unbound auf einem meiner Pis zu installieren, incl. eines DHCP-Servers, und den auf der Box zu deaktivieren, damit auch die Geräte mit nicht fest zugeteilter IP den Dienst nutzen können. Macht aber Arbeit.

Eine andere Möglichkeit wäre, die Box im Bridge-Modus zu betreiben und einen eigenen Router dran zu hängen, vorzugsweise einen mit weitaus mehr Konfigurationsmöglichkeiten als die Box. Macht aber auch Arbeit und kostet Geld.

Bei manchem User, die feste IPs innerhalb ihres LANs brauchen, mag es auch helfen, diese in den DHCP-Einstellungen der Box als reservierte Regel hinzuzufügen und dann wieder DHCP auf den Endgeräten zu aktivieren. Bei meiner Netzwerkkonfiguration geht es leider nicht. Ich habe hinter einigen der im vorherigen Beitrag erwähnten Wireless Routern, die im Client-Modus arbeiten, noch einen Switch hängen mit mehreren Geräten dran. In den verbundenen Geräten der Box erscheint dann zwar die (feste) IP der Endgeräte, aber immer mit der MAC-Adresse des jeweiligen Wireless Routers und die Switch kümmert sich um die Weiterleitung an die Endgeräte. Geht bei mir also nicht.

Wie auch immer, das ursprüngliche Problem kann nur UPC selbst lösen, meinetwegen mit einem Downgrade der Firmware. Im Übrigen unterhalten wir uns hier auf einem Niveau, das wohl nur die wenigsten Endkunden durchblicken. Da hat mal vielleicht einer eine feste IP eingestellt weil er von aussen Zugriff haben will, und wundert sich jetzt, dass sich seine geliebte Seite finanzen.ch nicht mehr öffnen lässt. Von nslookup und ipconfig hat er wahrscheinlich noch nie gehört, geschweige denn unbound installiert und konfiguriert, vorzugsweise auf einem Unix-System. Und dass es ein Problem gibt, scheinen die vermehrten Posts in letzter Zeit diesbezüglich ja zu bestätigen. Und es gibt bestimmt noch eine sehr hohe Dunkelziffer an Kunden, die nicht hier posten und gleich die Hotline anrufen. Wer sich in der Thematik ein wenig auskennt, kann sich vielleicht irgendwie helfen, die meisten aber wohl nicht.

Was mich allerdings schon wundert, ist, dass sich noch niemand vom UPC-Team hierzu geäussert hat. Daniele_UPC hat zwar einen Beitrag hier geliket, aber noch keinen Lösungsansatz oder sonstwas vorgetragen. Wäre schön wenn da mal was käme.

Gruss Dirk

_patrice_

Dirk_F

Du bist nicht der Einzige, welcher mit diesem fehlerhaften Update zu kämpfen hat.
Es gibt bestimmt eine grosse Dunkelziffer an Leuten, die sich nur telefonisch beim Support beschweren.

Weil dies für mich das erste grössere Problem mit dem UPC-Router ist, habe ich mich hier registriert und umgeschaut ob jemand den selben Bug entdeckte.

Durfte deswegen in den letzten Tagen die DNS Einstellungen bei etlichen Geräten um-konfigurieren, welche eine fixe IP Adresse haben. Vor dem Update hat es prima mit dem Setzen der Router-Adresse (192.168.0.1) geklappt.

Der Router funktioniert somit seit dem Update nicht mehr als DNS-Forwarder. Port 53 ist geschlossen und antwortet auf keine DNS-Anfragen, was mit den Open Source Werkzeugen nmap und dig sehr gut zu reproduzieren ist.

$ sudo nmap -sU -p 53 192.168.0.1
Starting Nmap 7.92 ( https://nmap.org ) at 2022-01-28 11:03 CET
Nmap scan report for 192.168.0.1
Host is up (0.0080s latency).

PORT   STATE  SERVICE
53/udp closed domain
MAC Address: XX:XX:XX:XX:XX:XX (Arris Group)

Nmap done: 1 IP address (1 host up) scanned in 0.32 seconds

$ dig @192.168.0.1 upc.ch

; <<>> DiG 9.16.24 <<>> @192.168.0.1 upc.ch
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Ich hoffe UPC kriegt das wieder in den Griff oder hat zumindest eine Erklärung bereit, warum sie sich für das Abschalten des DNS-Forwarders entschieden haben.

GrandDixence

um sie nicht direkt als völliger Unsinn zu bezeichnen?

Ob die Umsetzung der Gute Performance Regel Nr. 23 “völliger Unsinn” ist muss der/die mündige LeserIn selber herausfinden und beurteilen. Der/die LeserIn muss für seine/ihre “Heldentaten” in ihrem Heimnetzwerk oder Firmennetzwerk selber gerade stehen…

Ob der Einsatz von DNS-Server (Resolver) von der Datenkrake Google eine gute Idee ist, muss der Leser oder die Leserin selber für sich entscheiden.

Ob der Einsatz von öffentlichen DNS-Server (Resolver) eine gute Idee im Angesicht einer massiven DoS-Attacke ist, muss der Leser oder die Leserin selber für sich entscheiden.

Der Einsatz von Unbound gemäss Gute Performance Regel Nr. 1, 2, 3, 4, 5 und 23 bietet Vorteile:

in der Performance (dank Einsatz als zwischenspeichernden DNS-Forwarder und den nicht-öffentlichen UPC-Sunrise DNS-Servern sowie allfälligen weiteren nicht-öffentlichen DNS-Servern von weiteren ISP’s wie zum Beispiel Swisscom),
Vorteile in der Sicherheit (dank der Validierung von DNS-Antworten mit DNSSEC),
Vorteile in der Verfügbarkeit (Möglichkeit des automatischen Einsatzes einer Rückfallebene, die keinen einzigen fremden DNS-Forwarder oder fremden DNS-Resolver) erfordert.
und ist auf den LTS-LInuxdistributionen (> 5 Jahre Sicherheitsupdates) lauffähig oder enthalten (Red Hat Enterprise Linux und die CentOS-Nachfolgern AlmaLinux und Rocky Linux, SUSE Linux Enterprise, sowie Ubuntu Server). Wer hat schon die Nerven und die Zeit sich freiwillig mit “Rolling Release”-Betriebssystemen wie zum Beispiel: Microsoft Windows 10, Arch Linux, Gentoo Linux und FreeBSD rumzuärgern?
https://de.wikipedia.org/wiki/Rolling_Release
https://en.wikipedia.org/wiki/Long-term_support

Was der mündige Leser oder die mündige Leserin selber in ihrem Heim- oder Firmennetzwerk einsetzen will, muss er oder sie selber entscheiden (und dafür auch gerade stehen müssen)…

Belegnor

GrandDixence Ob die Umsetzung der Gute Performance Regel Nr. 23 “völliger Unsinn” ist muss der/die mündige LeserIn selber herausfinden und beurteilen

… Wenn du die Regel Nr. 23 hier zitierst, dann kann ich dir sagen, ob sie “völlig unsinnig” ist oder nicht …

Hast du mein Kommentar überhaupt richtig gelesen (und verstanden)? Ich wiederhole mich ungern, aber hochverfügbare Internetanschlüsse mit einem bestimmten DNS-Server in Verbindung zu bringen, weil beide Themen mit Netzwerken zu tun haben, ist das gleich wie Pizzas und Ferraris miteinander in Verbindung zu bringen, bloss weil sie mit Italien zu tun haben …

Also nochmals, für eine hochverfügbare Internetanbindung ist es völlig irrelevant, welcher DNS-Server verwendet wird. Wichtig ist nur, dass sie mit mehreren ISPs realisiert wird.

Ob der Einsatz von DNS-Server (Resolver) von der Datenkrake Google eine gute Idee ist …

Welchen Teil von “z. B.” hast du nicht verstanden? Wer sagt Google, kann auch Cloudflare, Quad9 oder etwas anderes sagen. Egal welcher Resolver schlussendlich eingetragen wird, es ändert sich nichts an der Gültigkeit meiner Worte: Um eine “DNS-Redundanz” zu erreichen, genügt es mehrere DNS-Forwarder (am besten von verschieden DNS-Anbietern) einzutragen …

Ob der Einsatz von öffentlichen DNS-Server (Resolver) eine gute Idee im Angesicht einer massiven DoS-Attacke ist

Und wieder verwechselst du Pizzas mit Ferraris. Wenn einer der in deiner Konfiguration eingetragenen Resolver Opfer einer massiven DoS-Attacke wird, dann kannst du weiterhin über die anderen Resolver Hostnamen auflösen. Wenn der massive DoS-Angriff dir gilt, dann spielt es keine Rolle, welcher DNS-Resolver du verwendest. Irgendwann ist deine Leitung tot, wenn der ISP den Angriff nicht abfedert oder dein Router bzw. deine Firewall nicht leistungsfähig genug ist, um den Angriff standzuhalten …

Der Einsatz von Unbound gemäss Gute Performance Regel Nr. 1, 2, 3, 4, 5 und 23 bietet Vorteile:

… OK … Schauen wir, welche Vorteile nur Unbound anbieten kann …

in der Performance (dank Einsatz als zwischenspeichernden DNS-Forwarder …

… Nope … Das ist kein exklusiver Vorteil von Unbound. Praktisch alle DNS-Server haben diese Funktion (ich kenne keinen, der sie nicht hat, aber es gibt nichts, was es nicht gibt …)

Vorteile in der Sicherheit (dank der Validierung von DNS-Antworten mit DNSSEC)

… Sorry, aber sogar dnsmasq (ein schlanker DNS-Server) unterstützt DNSSEC … Übrigens, der Einsatz von DNSSEC kann die Performance des DNS-Services negativ beeinflussen …

Vorteile in der Verfügbarkeit (Möglichkeit des automatischen Einsatzes einer Rückfallebene …

Es tut mir leid, aber dnsmasq kann das …

und ist auf den LTS-LInuxdistributionen (> 5 Jahre Sicherheitsupdates) …

… und das gleiche gilt für dnsmasq, bind und andere DNS-Server, d. h., kein exklusiver Vorteil von Unbound …

Anders gesagt, die Tatsache, dass du Unbound verwendest (vermutlich weil er in deiner Firewall integriert ist) und empfiehlst , bedeutet nicht, dass dieser Server die beste Lösung ist oder Funktionen anbietet, die anderen nicht haben. Da gibt es (je nach Szenario) bessere Varianten …

Was “deine Regeln” angeht, ich würde sie an deiner Stelle überarbeiten. Alles ändert sich mit der Zeit, auch die Gültigkeit “deiner Regeln” …

GrandDixence

Sorry, aber auf die meisten Beiträge von Nino_52 und Belegnor antworte ich nicht (mehr), da sinn- und zwecklos. Ich widme mich lieber sinnvolleren Tätigkeiten als “Wasser den Rhein hochtragen”.

Belegnor

GrandDixence

Sorry, aber auf die meisten Beiträge von Nino_52 und Belegnor antworte ich nicht (mehr), da sinn- und zwecklos.

Wenn das dein einziger Argument ist, um die meinen zu widerlegen, dann bestätigst du wohl, was ich schon seit langem vermute, nämlich dass dein Wissen aus der Quelle “Copy&Paste” stammt und dass du auch nicht bereit bist, dich weiterzuentwickeln. Andernfalls hättest du mit sachlicheren Gegenargumenten geantwortet …

Ich habe kein Problem damit, dass du auf meine Beiträge nicht mehr antwortest. Das ist mir ziemlich egal. Aber ich werde weiterhin auf Beiträge antworten, egal ob es sich um deine Beiträge handelt oder die eines anderen. Und wenn du bei einer deiner Aussagen Recht hast, dann werde ich dir Recht geben (wäre übrigens nicht das erste Mal). Aber wenn du meiner Meinung nach falsch liegst, werde ich mich auch dazu äussern, ob es dir passt oder nicht. Es liegt bei dir, ob du mit sachlichen Argumenten “debattieren” oder dich hinter der “Ich-rede-nicht-mehr-mit-dir-weil-zwecklos” Ausrede verstecken willst …

Dies gesagt, wünsche ich dir noch ein schönes Wochenende

Gruss

Belegnor

GrandDixence

_patrice_
Wie man unter:
https://www.elektronik-kompendium.de/sites/net/2103061.htm
leicht nachlesen kann, ist ein Portscan (mit nmap) auf einen UDP-Port eine höchst unzuverlässige Angelegenheit. Wenn die Firewall des EuroDOCSIS-Kabelmodems (aus Sicherheitsgründen) Portscan-unfreundlich konfiguriert ist, wird das Kabelmodem auf den Portscan von UDP-Serverport 53 nicht mit einer ICMP-Meldung “Destination port unreachable ” antworten.
https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol

Ein Portscan (mit nmap) liefert nur mit dem Netzwerkprotokoll TCP eine zuverlässige und aussagekräftige Ausgabe.

Sinnvoller als ein Portscan wäre das Liefern der Messresultate von einem mehrtägigen Leitungstest à la “Broadband Quality Monitor”. Weist dieser Internetanschluss seit dem EuroDOCSIS-Kabelmodem-Firmware-Update vom Januar 2022 auch eine Paketverlustrate > 10% auf?
https://community.sunrise.ch/d/18668-standig-kurze-unterbruche/17

Bitte den Screenshot vom “Broadband Quality Monitor” nach einer Mindestlaufzeit von 24 Stunden hier veröffentlichen. Zum Lesen und Einrichten des “Broadband Quality Monitor” findet man Hilfestellung unter:
https://community.sunrise.ch/d/8569-gigaconnect-aussetzer/25

Ich vermute, dass die DNS-Probleme nicht durch den DNS-Forwarder/DNS-Proxy im EuroDOCSIS-Kabelmodem ausgelöst werden. Sondern durch eine in:
https://community.sunrise.ch/d/18668-standig-kurze-unterbruche/17

https://community.sunrise.ch/d/18668-standig-kurze-unterbruche/21

https://community.sunrise.ch/d/18668-standig-kurze-unterbruche/22
gut dokumentierte Paketverlustrate von > 50% des falsch konfigurierten Internetanschlusses.
https://de.wikipedia.org/wiki/Paketverlustrate

_patrice_

GrandDixence

Aus dem internen Netz aus Sicherheitsgründen einen Portscan am Router filtern. So einen Unsinn kann ich mir schlicht nicht vorstellen.

Einen mehrtägigen Leistungstest? Wieso denn das, wenn es rein um das DNS-Forwarding geht???
Wie gesagt funktioniert das Forwarding erst seit kurzem nicht mehr. Hat seit vielen Jahren einwandfrei funktioniert.

Zur Zeit geht nur das manuelle Setzen von irgend welchen externen DNS Servern wie Google, Quad9, etc. Sogar die UPC DNS-Server funktionieren dadurch. Das ist aber keine Lösung für das Problem.

Funktioniert denn bei dir das Forwarding noch?

PS: Habe die selbe SW Version auf dem Router wie der OP.

GrandDixence

Funktioniert denn bei dir das Forwarding noch?

Ich habe noch nie (> 15 Jahre) den DNS-Forwarder von einem EuroDOCSIS-Kabelmodems verwendet, da alle EuroDOCSIS-Kabelmodeme im Bridge-Modus betrieben werden/wurden.

Gute Performance Regel Nr. 1, 2, 3, 4, 5 und 23 einhalten und die DNS-Forwarderprobleme sind weg…
=> Siehe meinen Beitrag vom 20.01.2022 um 19:24 Uhr.

Einen mehrtägigen Leistungstest? Wieso denn das, wenn es rein um das DNS-Forwarding geht???

Weil DNS nun mal das Netzwerkprotokoll UDP und nicht TCP einsetzt. TCP schützt dank automatischen Sendewiederholungen (TCP-Retransmissions) vor Paketverlusten. TCP kommt zum Einsatz beim Websurfen (HTTP/HTTPS), WhatsApp, E-Mailversand (SMTPS, IMAPS, POP3S etc.) und so weiter. So praktisch alle nicht zeitkritischen Dienste verwenden TCP. Abgesehen von irgendwelchem Google-Schrott, welcher QUIC einsetzt. QUIC basiert auf UDP.

UDP kommt zum Einsatz bei den Grunddiensten DHCP und DNS sowie allen zeitkritischen Diensten (VOIP-Sprachtelefonie, NTP, Gaming). Bei UDP muss die Anwendung (hier: DNS) Massnahmen gegen Paketverlust treffen (hier: Neuversand der unbeantworteten DNS-Anfrage nach 5 Sekunden Timeout). Bedingt durch UDP wird bei einer Paketverlustrate > 50% der DNS-Forwarder praktisch unbrauchbar.

_patrice_

GrandDixence

Ich habe noch nie (> 15 Jahre) den DNS-Forwarder von einem EuroDOCSIS-Kabelmodems verwendet, da alle EuroDOCSIS-Kabelmodeme im Bridge-Modus betrieben werden/wurden.

Dann kannst du dieses Problem leider nicht nachvollziehen oder reproduzieren.

Gute Performance Regel Nr. 1, 2, 3, 4, 5 und 23 einhalten und die DNS-Forwarderprobleme sind weg…
=> Siehe meinen Beitrag vom 20.01.2022 um 19:24 Uhr.

Sind das deine Performance Regeln?

Nach Punkt 1 habe ich aufgehört zu lesen, da ich meinen Router nicht im Bridged Mode betreiben möchte.
Es ist mir klar, dass in diesem Modus die Forwarderprobleme weg sind, da der Forwarder ja gar nicht mehr verwendet wird. 😅 Dies ist aber nicht mein Ziel.

Danke für die kleine Schulung über TCP und UDP. Diese Punkte kannte ich aber bereits.

Ich hoffe schwer, dass sich hier auch mal jemand vom UPC Team meldet. Bis jetzt fühle ich mich nicht richtig ernst genommen.

Edit: Sehe gerade, dass dieses Problem bereits im folgenden Thread angesprochen wurde: https://community.sunrise.ch/d/19101-dns-auflosung-funktioniert-nicht
Selbe Problematik und seit zwei Wochen keine Antwort vom UPC Team. Finde ich ein wenig seltsam…

Belegnor

Hallo _patrice_

Eigentlich ist das DNS-Thema eine alte Geschichte … 😉

https://community.sunrise.ch/d/5596-dns-server-nach-update-deaktiviert

D. h., auf eine Antwort/Stellungnahme seitens UPC zu warten, kann eine relativ lange Zeit in Anspruch nehmen …

Meine Empfehlung wäre, einen eigenen DHCP-/DNS-Server zu betreiben. Auf diese Weise wirst du flexibler fahren und vermutlich „glücklicher“ werden … 😉

Wenn du einen Synology Server hast, dann kannst du die entsprechenden Module aktivieren und einstellen. Die Konfiguration ist relativ einfach und der Server läuft recht stabil.

Alternativ kannst du auch auf eine andere Lösung (z. B. Pi-hole) setzen. Allerdings setzt diese gewisse Kenntnisse voraus (Installation auf Linux oder als Docker Container).

Es ist zwar ärgerlich, dass man zusätzliche Komponenten einsetzen muss, damit etwas funktioniert, aber bei UPC geht es leider sehr oft nicht anders …

ich hoffe, das hilft

Gruss

Belegnor

_patrice_

Belegnor

Besten Dank für deine Antwort und den Link zum Thread. Hat also damit begonnen, dass der DNS-Forwarder nur noch in Kombination mit dem DHCP-Server aktiv war… Und nun wurde er komplett abgeschaltet, egal ob der DHCP-Server ein oder aus ist. 🤦

Deine Empfehlungen sind gut gemeint, danke. Ein weiteres Gerät nur dafür einzusetzen finde ich für mein kleines Netzwerk aber etwas übertrieben. Ich behalte mir deine Lösungen aber im Hinterkopf.
Zurzeit habe ich alle Geräte mit einer fixen IP-Adresse dementsprechend angepasst, dass sie nun direkt die DNS Server von UPC im WAN anfragen. Funktioniert zwar, ist aber umständlicher als bis anhin.

Nun ist mir auch einiges klarer, dass UPC Schweiz dazu wohl nicht viel unternehmen wird/kann. Ich nehme an, dass sie nur sehr wenig zur Firmware-Entwicklung beitragen können und vieles von Liberty Global vorgegeben wird. Ich kann aber auch komplett daneben liegen und sie haben sehr wohl vollen Zugriff auf die Repositories, zurzeit jedoch mit zu vielen Support-Anfragen zu kämpfen. 🤷

Schlussendlich finde ich es halt trotzdem nicht sehr amüsant, wenn Funktionen, welche beim Kauf des Abos noch vorhanden waren, einfach ohne Vorwarnung deaktiviert werden. 😒 Werde somit wohl oder übel dem Support anrufen und nachfragen, was es damit auf sich hat.

Ob dann der extrem praktische DNS-Forwarder irgend wann wieder aktiviert wird, durch die UPC Schweiz / Liberty Global, steht somit in den Sternen… Die Hoffnung stirbt wohl zuletzt. 😉

Gruss
Patrice

_patrice_

Kleines Update zur aktuellen Situation:

Hatte heute einen sehr netten Kontakt auf der Support Hotline!

Man muss wohl etwas Glück haben, wer den Hörer abnimmt, denn die ersten zwei Anrufe vor ein paar Tagen haben mir nur einen Neustart und Reset des Routers vorgeschlagen, was natürlich den Fehler in der neuen Firmware nicht behoben hat. Diese ersten zwei Personen verstanden leider auch kein Schweizerdeutsch und sagten immer nur ja ja ja, ohne auf meine Problemschilderung einzugehen.

Konnte heute also das Problem schildern und es wurde weitergeleitet an das Firmware-Team. 😃

Ein weiterer Fehler, den ich auch gleich meldete, war, dass die Port-Weiterleitungen nur noch auf IP-Adressen innerhalb des DHCP-Ranges möglich ist, was natürlich überhaupt keinen Sinn ergibt. Vor dem Update ging das noch ohne Probleme und man konnte wie gewöhnlich auf fixe IP-Adressen ausserhalb der DHCP-Range weiterleiten (welche sich natürlich innerhalb der nutzbaren IP-Range, gegeben durch die Netzmaske befinden).

Bin nun gespannt, ob diese zwei Probleme im nächsten Update behoben werden. 🙂

Nächste Seite »