Onderschept [Ziggo] mijn queries naar publieke DNS-servers?

[2playgames]

Een week geleden heeft Ziggo werkzaamheden aan mijn verbinding uitgevoerd. Sindsdien valt internet soms ineens een tijd weg. Ik heb al contact opgenomen met de klantenservice en het modem hersteld naar fabriekinstellingen, maar dat heeft nog niet mogen baten.

Ik open dit topic omdat mij wat vreemds is opgevallen, namelijk dat er bij deze problemen vaak een tijdje is waarbij IP zelf goed werkt, of althans, ping naar bijvoorbeeld 1.1.1.1 gaat goed, maar waarbij "internet" nog niet werkt omdat DNS nog problemen geeft. Bij een poging dat te debuggen zag ik het volgende:

code:

% dig youtube.com @1.1.1.1

; <<>> DiG 9.16.25 <<>> youtube.com @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51546
;; flags: qr aa rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;youtube.com.                   IN      A

;; ANSWER SECTION:
youtube.com.            0       IN      A       192.168.123.123

;; Query time: 93 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Mar 31 01:55:59 CEST 2022
;; MSG SIZE  rcvd: 45

Ik stuur dus een DNS query naar de publieke 1.1.1.1-server (dus niet naar de forwarder in het modem of een server van Ziggo), maar daar komt een onzinantwoord op terug, 192.168.123.123. Wanneer ik met een VPN verbind en dit nog eens doe krijg ik wel meteen het juiste antwoord.

Hieruit concludeer ik dat Ziggo deze verzoeken niet naar 1.1.1.1 stuurt, maar onderschept, en daarbij niet eens het juiste antwoord kan geven. Is dit een correcte conclusie? En is dit normaal, of hebben we dan met zeer discutabele praktijken te maken?

Ik heb een OpenWRT router achter het modem die ook als DNS forwarder dienst doet, dus ik ga in ieder geval maar eens uitzoeken hoe ik die de verzoeken via TLS of op een andere beveiligde manier naar de publieke DNS-servers kan sturen...
(Voor de dig-test heb ik m'n PC direct aan het modem aangesloten dus die router is hier niet de oorzaak van.)

Ik woon in het voormalig UPC-gebied en heb de Arris ConnectBox.

Edit: ik had beter dig +trace kunnen doen, bedenk ik nu, maar inmiddels is de probleemsituatie weer even weg
Edit2: Nou dat is ook vrij summier:

code:

% dig +trace youtube.com @1.1.1.1

; <<>> DiG 9.16.25 <<>> +trace youtube.com @1.1.1.1
;; global options: +cmd
;; Received 17 bytes from 1.1.1.1#53(1.1.1.1) in 3 ms

[ Voor 7% gewijzigd door 2playgames op 31-03-2022 04:10 ]

[FreakNL]

Lijkt me sterk. Ik heb er zelf in ieder geval nog nooit last van gehad of opgemerkt.

Kun je eens een andere machine direct aan het modem hangen? Heb je het ook met 9.9.9.9?

Andere richting:
Je kunt bijvoorbeeld PRTG elke 30 seconden een dns query laten doen en dan check je de historie.

Valt eventueel ook wel makkelijk zelf te scripten. Gewoon 24 uur elke minuut een DNS query en loggen.

[canonball]

Kan het zijn dat op het moment dat er geen verbinding is (waar je volgens mij last van had tijdens de dig), de router het ip-addres van router zelf teruggeeft op een dns verzoek. Dan zou in jouw geval het ip-addres van de ziggo router ook 192.168.123.123 moeten zijn.

Mijn asus router doet dat ook: normaal gaat het gewoon na mijn isp, maar als de verbinding weg ik geven alle dns verzoeken het ip-addres van de router terug. Waarschijnlijk is het idee dat als er geen verbinding is met het internet en ik http://www.nu.nl in mijn browser intypt, het niet uit-timed maar ik de pagina van mijn router terecht kom.

[SambalBij]

canonball schreef op donderdag 31 maart 2022 @ 08:34:
Kan het zijn dat op het moment dat er geen verbinding is (waar je volgens mij last van had tijdens de dig), de router het ip-addres van router zelf teruggeeft op een dns verzoek. Dan zou in jouw geval het ip-addres van de ziggo router ook 192.168.123.123 moeten zijn.

Nee dat kan niet. Althans, dat zou niet moeten kunnen, tenzij of het modem, of Ziggo discutabele dingen uithalen met dat verkeer.

Als jij een DNS request stuurt aan 1.1.1.1, terwijl er geen verbinding is, dan kan dat packet dus nooit het internet op gestuurd worden, en zal er dus simpelweg nooit antwoord op kunnen komen. (Eventueel een ICMP packet met destination host unreachable, maar absoluut geen DNS reply met daarin een adres)

(En blijkbaar heeft jouw Asus router dus ook een stevige corrigerende tik nodig)

[ Voor 5% gewijzigd door SambalBij op 31-03-2022 08:41 ]

[coolkil]

192.168.xxx.xxx is een interne reeks niet bedoeld voor gebruik op het internet. Het lijkt me ook niet zo dat Ziggo daar gebruik van maakt. Meeste bedrijven kiezen intern voor 10/8 of een 172.16/12

Heb je niet een local DNS cache draaien? En is 192.168.123.123 gewoon je eigen ip

[Pietervs]

Misschien kun je even wat dingetjes duidelijker maken:
- hoe ziet je netwerk eruit? Je hebt je PC (of laptop), hoe is die verbonden met je netwerk? Wireless of bedraad? Het apparaat waarmee je PC verbinding maakt, is dat een AP of een managed switch? Heeft die instellingen die aangepast zijn?
- Je hebt een Arris router en een Asus modem begrijp ik. Staat die Arris in Bridge modus?

- is je interne netwerk 192.168.123.x/24 of een andere reeks? Als het inderdaad 192.168.123.x is, kun je dan traceren welk apparaat die 192.168.123.123 heeft? Het lijkt er namelijk op dat dat het IP adres van je router is.
Als dat laatste klopt, dan doet Ziggo dus niks met de DNS requests, maar reageert je router op je DNS requests.


overigens, als je je zorgen maakt over je DNS verkeer, kun je kijken of je Unbound op je OPENWRT router kan installeren. Anders Pihole en daar Unbound op installeren

[2playgames]

Pietervs schreef op donderdag 31 maart 2022 @ 12:51:
Misschien kun je even wat dingetjes duidelijker maken:
- hoe ziet je netwerk eruit? Je hebt je PC (of laptop), hoe is die verbonden met je netwerk? Wireless of bedraad? Het apparaat waarmee je PC verbinding maakt, is dat een AP of een managed switch? Heeft die instellingen die aangepast zijn?
- Je hebt een Arris router en een Asus modem begrijp ik. Staat die Arris in Bridge modus?

- is je interne netwerk 192.168.123.x/24 of een andere reeks? Als het inderdaad 192.168.123.x is, kun je dan traceren welk apparaat die 192.168.123.123 heeft? Het lijkt er namelijk op dat dat het IP adres van je router is.

Jazeker. Ik heb een witte Arris ConnectBox modem/router, in vrijwel standaardconfiguratie, niet in bridge-modus (want wil wel IPv6). Deze noem ik modem.
Daarachter heb ik een OpenWRT router, deze noem ik verder router. De rest van m'n apparaten zit achter die router, behalve wanneer ik voor een test iets direct in het modem klik (zoals hier). Ze gebruiken deze router als gateway en als DNS server.

M'n interne range vanaf het modem is 192.168.178.0/24. Daarbij is .1 voor het modem zelf. Het LAN achter de router heeft daar een /26 subnet van. Proxy ARP op de router zorgt ervoor dat verkeer voor dat subnet bij de router terechtkomt. Er is dus geen dubbele NAT.
Verder draait er ook IPv6, ook op het LAN met Prefix Delegation.

Alles is bedraad behalve m'n telefoon.

FreakNL schreef op donderdag 31 maart 2022 @ 06:40:
Lijkt me sterk. Ik heb er zelf in ieder geval nog nooit last van gehad of opgemerkt.

Kun je eens een andere machine direct aan het modem hangen? Heb je het ook met 9.9.9.9?

Andere richting:
Je kunt bijvoorbeeld PRTG elke 30 seconden een dns query laten doen en dan check je de historie.

Valt eventueel ook wel makkelijk zelf te scripten. Gewoon 24 uur elke minuut een DNS query en loggen.

Ik had er ook nooit last van tot na de werkzaamheden van een week geleden, dus dat kan goed. Naast m'n laptop die direct aan het modem hing heb ik het ook geprobeerd vanaf m'n router die ook direct achter het modem zit (met nslookup ipv dig) met hetzelfde resultaat. 9.9.9.9 heb ik niet geprobeerd, wel 8.8.8.8 en 8.8.4.4.

canonball schreef op donderdag 31 maart 2022 @ 08:34:
Mijn asus router doet dat ook: normaal gaat het gewoon na mijn isp, maar als de verbinding weg ik geven alle dns verzoeken het ip-addres van de router terug. Waarschijnlijk is het idee dat als er geen verbinding is met het internet en ik http://www.nu.nl in mijn browser intypt, het niet uit-timed maar ik de pagina van mijn router terecht kom.

Hm, zoiets zou het kunnen zijn. Het modem draait normaal niet onder 192.168.123.123 maar 192.168.178.1, en reageert nu niet op .123, maar dat neemt niet weg dat het dat tijdens verbindingsproblemen wel zou kunnen doen. Ik heb dat niet getest. Echter, de automatische foutpagina die weleens wil spontaan wil openen draaide als ik het goed zag ook gewoon op .178.1.
Overigens doet DNS dus raar terwijl er verder wel gewoon een IP-verbinding naar het internet is, dus als probleemoplossing werkt dit dan nogal averechts.
Edit: zojuist is het probleem weer voorgekomen, en toen ik .123.123 in m'n browser typte werd ik doorgestuurd naar de foutpagina op .178.1.

SambalBij schreef op donderdag 31 maart 2022 @ 08:40:
[...]

Nee dat kan niet. Althans, dat zou niet moeten kunnen, tenzij of het modem, of Ziggo discutabele dingen uithalen met dat verkeer.

Als jij een DNS request stuurt aan 1.1.1.1, terwijl er geen verbinding is, dan kan dat packet dus nooit het internet op gestuurd worden, en zal er dus simpelweg nooit antwoord op kunnen komen. (Eventueel een ICMP packet met destination host unreachable, maar absoluut geen DNS reply met daarin een adres)

(En blijkbaar heeft jouw Asus router dus ook een stevige corrigerende tik nodig)

Yep, mee eens. Hoe hulpvol het eventueel ook bedoeld is, dit soort truukjes kunnen alleen maar meer problemen opleveren. Bijvoorbeeld dat de cache in m'n router vervolgens het foute adres onthoudt

coolkil schreef op donderdag 31 maart 2022 @ 11:11:
Heb je niet een local DNS cache draaien? En is 192.168.123.123 gewoon je eigen ip

Ja die heb ik, in m'n router, maar die speelt geen rol omdat ik expliciet naar 1.1.1.1 dig. En draait bovendien niet op dat IP.

Pietervs schreef op donderdag 31 maart 2022 @ 12:51:
overigens, als je je zorgen maakt over je DNS verkeer, kun je kijken of je Unbound op je OPENWRT router kan installeren. Anders Pihole en daar Unbound op installeren

Daar heb ik aan gedacht, maar zou het resolven dat Unbound doet (naar nameservers) dan niet ook via evengoed onderschepte queries via poort 53 gaan?

In ieder geval heb ik het nu omzeild door de router een m'n VPN te hangen en verkeer naar 8.8.4.4 via het VPN te routen. Dit maakt 8.8.4.4 onbereikbaar voor apparaten achter de router (dat is vast nog wel op te lossen), maar die maken allemaal gebruik van de dnsmasq in de router die de verzoeken mooi via het VPN doorstuurt (met fallback naar 1.1.1.1 en 8.8.8.8 als het VPN problemen heeft). Daarbij heb ik "Rebind protection" aangezet om de 192.168.123.123 antwoorden te weigeren, mochten die toch binnenkomen.

[Pietervs]

Ik heb een witte Arris ConnectBox modem/router, in vrijwel standaardconfiguratie, niet in bridge-modus (want wil wel IPv6). Deze noem ik modem.
Geen idee hoe dat dat in het voormalig UPC gebied zit, maar ik heb mijn modem in bridge staan en de Asus die erachter zit kan prima IPv6 doen. Maar ik heb begrepen dat de verschillende gebieden binnen het Ziggo netwerk verschillende configuraties hebben, dus misschien dat dat inderdaad bij jou (nog) niet mogelijk is.

Maar dan vraag ik me wel af: stel dat je je PC een adres geeft in het netwerk 192.168.123.x/24 en aan de Arris hangt, kun je dan wel verbinding maken met https://192.168.123.123? Of met ssh of telnet?
Ik heb namelijk het vermoeden dat de Arris dan zal reageren.

Daar heb ik aan gedacht, maar zou het resolven dat Unbound doet (naar nameservers) dan niet ook via evengoed onderschepte queries via poort 53 gaan?
In theorie wel. Maar ik betwijfel of Ziggo daadwerkelijk van hun x miljoen klanten de DNS requests onderschept: wat zouden ze daarmee opschieten? Ik zou dan eerder verwachten dat ze verkeer richting concullega's droppen, maar zelfs dat zie ik niet gebeuren.
Overigens is met Pihole ook DNSSEC mogelijk.

[2playgames]

Pietervs schreef op donderdag 31 maart 2022 @ 14:22:
Geen idee hoe dat dat in het voormalig UPC gebied zit, maar ik heb mijn modem in bridge staan en de Asus die erachter zit kan prima IPv6 doen. Maar ik heb begrepen dat de verschillende gebieden binnen het Ziggo netwerk verschillende configuraties hebben, dus misschien dat dat inderdaad bij jou (nog) niet mogelijk is.

Dat is helaas inderdaad een beperking van dit gebied. Zo kan ik ook nog geen eigen modem gebruiken, terwijl dat al wel zou moeten kunnen. Wordt aan gewerkt, zeggen ze, maar ondertussen is KPN hier glasvezel aan het aanleggen, dus hopelijk hoef ik dat niet af te wachten.

Maar dan vraag ik me wel af: stel dat je je PC een adres geeft in het netwerk 192.168.123.x/24 en aan de Arris hangt, kun je dan wel verbinding maken met https://192.168.123.123? Of met ssh of telnet?
Ik heb namelijk het vermoeden dat de Arris dan zal reageren.

Yep, zoals ik in een edit aan m'n vorige reactie heb toegevoegd, hij reageert erop. Daarvoor hoeft m'n laptop niet eens in dat subnet, want al het verkeer buiten 192.168.178.0/24 gaat automatisch toch naar het modem.

In theorie wel. Maar ik betwijfel of Ziggo daadwerkelijk van hun x miljoen klanten de DNS requests onderschept: wat zouden ze daarmee opschieten? Ik zou dan eerder verwachten dat ze verkeer richting concullega's droppen, maar zelfs dat zie ik niet gebeuren.

Afdwingen dat alles via hun cache gaat, om upstream verkeer te vermijden. Of data verzamelen. Beide mogelijk maar niet superrealistisch natuurlijk. Het zal dus wel gewoon een slecht geimplementeerde poging tot gebruiksvriendelijkheid zijn.
Edit: ik heb de klantenservice nu ook doorgegeven dat ik deze "feature" niet zo fijn vind, ook al is 'ie goed bedoeld.

Trouwens, als toevoeging aan m'n openingspost heb ik nog een dig +trace gedaan, wat geen resultaat gaf. Zou Unbound niet precies datzelfde probleem hebben dan?

Overigens is met Pihole ook DNSSEC mogelijk.

Ik heb me nog niet verdiept in DNSSEC, maar is dat niet alleen een techniek om de geldigheid van het antwoord te controleren? De ongeldigheid van 192.168.123.123 is hier al vrij duidelijk, en daarmee ben ik er nog niet, want moet dan alsnog een manier vinden om wel het juiste antwoord te krijgen.
Maar los van deze specifieke problematiek is dat natuurlijk wel een mooie toevoeging aan de veiligheid van het netwerk.

[ Voor 4% gewijzigd door 2playgames op 31-03-2022 14:57 ]

[fastedje]

Maar dan vraag ik me wel af: stel dat je je PC een adres geeft in het netwerk 192.168.123.x/24 en aan de Arris hangt, kun je dan wel verbinding maken met https://192.168.123.123? Of met ssh of telnet?
Ik heb namelijk het vermoeden dat de Arris dan zal reageren.

De 192.168 CIDR heeft normaal een netmask van 16 bits: Wikipedia: RFC 1918

Het hangt echter puur af van welke netmask er is ingesteld op het netwerk device.