Beantwoord

iTV update mislukt met eigen DNS server

  • 16 June 2020
  • 16 reacties
  • 1354 keer bekeken

De updates van mijn tv decoders mislukken continu. Ik krijg de foutmelding dbl-307 en dbl-843.

Ik gebruik het modem van KPN V10A maar gebruik wel een eigen DNS server (Pi-hole). Als ik de DNS server in de dhcp server op het kpn modem weer terug zet naar ISP DNS dan werkt de update wel.

Ik heb gecontroleerd of er DNS query’s geblokkeerd worden op mijn dns server maar dit is niet het geval.

Tevens heb ik in Pi-hole als upstream dns server de KPN modem ingesteld om te testen, maar dit werkt helaas ook niet.

 

Ik heb hierover ook contact gehad met de KPN helpdesk maar zij konden het probleem ook niet verklaren.

icon

Beste antwoord door Natasja 25 June 2020, 10:43

Bekijk origineel

16 reacties

Reputatie 7

Je bent absoluut niet de enige die tegen dergelijke problemen aanloopt.

Theoretisch zou het prima mogelijk moeten zijn om een andere (eigen) DNS server te gebruiken zolang die maar doorverwijst naar de "publieke" DNS servers.

In principe zou het zelfs niet nodig moeten zijn om naar de DNS servers van KPN te verwijzen.

De praktijk blijkt echter een stuk weerbarstiger te zijn en ik heb de vinger nog niet op het pijnpunt kunnen leggen. Het fenomeen lijkt zich overigens wel te beperken tot de Arris VIP5202 en zelfs dan lijkt niet altijd op te treden.

Ik heb inderdaad ook de Arris VIP5202. 
Leek mij ook niet nodig om naar een dns forwarder naar kpn router in te stellen maar was het proberen waard.. dacht wellicht dat er op het kpn modem static dns records aanwezig zijn zodat de iptv decoder zijn weg weet te vinden. (Hoe vreemd dat ook zou zijn)

Hoe zit het als je zelf een router gebruikt? Dan is er helemaal geen kpn dns meer aanwezig in het netwerk , werkt het updaten dan wel?

Reputatie 7

Hoe zit het als je zelf een router gebruikt? Dan is er helemaal geen kpn dns meer aanwezig in het netwerk , werkt het updaten dan wel?

Ik gebruik een EdgeRouter en de upgrade van mijn ZTE ZXV8001 en Arcadyan HMB2260's verloopt altijd probleemloos.

Overigens heb ik naast de DNS servers van CloudFlare ook de DNS servers van KPN in mijn DNS forwarding staan.

 

Reputatie 2

Ik was vandaag aan de beurt voor de 8.0.98_1 update voor de VIP5202's.

Ik gebruik een FritzBox met alleen de Cloudflare DNS servers. Bij mij tot nu toe altijd en continue Error 307 tijdens het updaten van de STB's. De STB's werken overigens na de update wel prima achter de FritzBox. Ik heb destijds een keer de auto ISP (KPN DNS servers) geprobeerd maar dat werkte toen ook niet. Ik zie dat de EB V10a de KPN DNS servers aan de clients doorgeeft. Ik zal dat voor de volgende update eens proberen. Ik zou het overigens wel raar vinden als je persé de KPN DNS servers zou moeten gebruiken voor het updaten van de VIP5202.

Reputatie 6
Badge +9

Dag @VanDien. Van harte welkom hier. Ik zie dat @wjb al een en ander aanstipt. Ik heb navraag gedaan bij de iTV specialisten of zij dit signaal herkennen en of hier een oplossing voor komt. Als ik een reactie heb, deel ik die hier. 

Reputatie 6
Badge +9

Hallo allen, ik heb een reactie vanuit de organisatie. Dit probleem is bekend. Bij communicatie met de DNS servers verwachten onze Arris VIP5202 tv-ontvangers het antwoord in het nieuwere en efficiëntere compressed format. Als een server dat niet ondersteunt en nog het oudere uncompressed format gebruikt loopt de communicatie mis en kan de update niet doorkomen. Je kunt dit het beste bij je DNS provider aankaarten. Als workaround kun je tijdelijk een andere DNS gebruiken. 

Reputatie 7

Bij communicatie met de DNS servers verwachten onze tv-ontvangers het antwoord in het nieuwere en efficiëntere compressed format.

Maar als dat ook voor de ZXV8001, VIP2952 en de HMB2260 zou gelden waarom zien we dan alleen meldingen t.a.v. de VIP5202?

Ik ervaar ook geen problemen met de update van mijn 8001 en 2260's terwijl ook bij mij de DNS resolving gedaan wordt door de DNS server van CloudFlare.

Ook de update afgelopen nacht is gelukkig weer probleemloos verlopen.

Reputatie 6
Badge +9

Excuses, @wjb. Dat heb ik niet handig verwoord. Het gaat hier natuurlijk over de Arris VIP5202. Met de andere tv-ontvangers die we hebben zien we die problemen niet. Ik pas mijn tekst aan. 

Reputatie 2

@Natasja Ik heb toch nog een opmerking en vraag over wat hier wordt aangedragen als oplossing:

De DNS RFC staat het toe dat een DNS server een response in uncompressed format mag verstruren. Wat CloudFlare in dit geval dus doet is niet gebruikelijk maar wel volgens de standaard. Het probleem ligt dus eigenlijk niet bij CloudFlare maar bij een onjuiste implementatie van de IP stack binnen de VIP5202. Wat het nog vreemder maakt is dat Arris de IP stack schijnbaar wel goed heeft geïmplementeerd binnen de VIP2952 omdat deze STB het probleem niet heeft i.c.m. CloudFlare. Kan KPN niet richting Arris aangeven dat zij dit patchen in de volgende Firmware update zodat de VIP5202 voldoet aan de DNS RFC?

 

Reputatie 7

Ik ben het volledig met je eens @Romul.

CloudFlare is de snelste DNS server die er op Internet te vinden is en tegelijkertijd helaas ook één van de weinige die uncompressed response geeft. Misschien doen ze dat wel met een reden (snelheid?).

Wereldwijd zijn er vele miljoenen aansluitingen die gebruik maken van de DNS servers van CloudFlare en zo goed als alleen de VIP5202 van KPN kan daar niet mee overweg.

De vraag wie er dan een aanpassing zou moeten doorvoeren is dan ook een terechte vraag.

Ik denk ook dat KPN het wettelijk niet mag verplichten om een DNS server anders dan die van CloudFlare te gebruiken.  Ik ben dan ook van mening dat KPN hier in een oplossing moet gaan voorzien.

Volgens mij wordt dit een eenzelfde verhaal als met vastbellen; TV en Vastbellen zijn in de kern geen internet, maar apart afgerekende services. Je haalt daarbij een leenkastje in huis (e.v.t. als onderdeel van een router). Als het leenkastje in de ogen van de klant niet voldoet of niet naar wens is, kan je de service opzeggen. KPN zou ook gewoon met vaste private IP-adressen kunnen werken, geheel geen DNS dus, of een ander methode om b.v. 10.x.x.x adressen een wat vrienderlijker/makkelijker label/uterlijk te geven.

 

Reputatie 7

KPN zou ook gewoon met vaste private IP-adressen kunnen werken, geheel geen DNS dus, of een ander methode om b.v. 10.x.x.x adressen een wat vrienderlijker/makkelijker label/uterlijk te geven.

Dat is nu juist iets waar KPN terecht vanaf gestapt is met de overgang van bridged IPTV naar routed IPTV en dat is ook iets waar je vooral niet naar terug moet willen.

KPN zou ook gewoon met vaste private IP-adressen kunnen werken, geheel geen DNS dus, of een ander methode om b.v. 10.x.x.x adressen een wat vrienderlijker/makkelijker label/uterlijk te geven.

Dat is nu juist iets waar KPN terecht vanaf gestapt is met de overgang van bridged IPTV naar routed IPTV en dat is ook iets waar je vooral niet naar terug moet willen.

Het wordt pas echt een stap anders als VLAN 4 wordt opgedoekt en de TV mediastreams via dezelfde IP netwerklaag gaan als ook b.v. een Netflix of AppleTV.

Reputatie 7

KPN zou ook gewoon met vaste private IP-adressen kunnen werken, geheel geen DNS dus, of een ander methode om b.v. 10.x.x.x adressen een wat vrienderlijker/makkelijker label/uterlijk te geven.

Dat is nu juist iets waar KPN terecht vanaf gestapt is met de overgang van bridged IPTV naar routed IPTV en dat is ook iets waar je vooral niet naar terug moet willen.

Het wordt pas echt een stap anders als VLAN 4 wordt opgedoekt en de TV mediastreams via dezelfde IP netwerklaag gaan als ook b.v. een Netflix of AppleTV.

Ik moet er niet aan denken, dat maakt QoS een stuk complexer. Nee, het is prima zo.

Reputatie 6
Badge +9

Ik snap je punt, @Romul. Ik kan je niets beloven, maar ik heb je vraag doorgezet naar de specialisten. Als ik een reactie heb, dan deel ik die hier.

Reputatie 6
Badge +9

Hallo allen, ik heb een reactie vanuit de iTV specialisten. Zij geven aan dat de IP-stack op de VIP2952 niet van Arris komt en de VIP5202 bovendien over nieuwere technologie beschikt. Wel zijn we aan het kijken of de VIP5202 ontvangers oudere, uncompressed formats kunnen gaan ondersteunen. Dat kan alleen nog wel even duren, omdat dit soort wijzigingen gemoeid gaan met veel ontwikkel- en testactiviteiten. 

Reageer