Skip to main content
Beantwoord

Geen reverse hostname bij IP van Odido


Toon eerste reactie

88 reacties

rvk01
  • Auteur
  • November 15, 2025

Door het MAC-adres van de Zyxel te kopiëren kreeg ik een ip uit een andere range en daarmee is het probleem voor mij (wat Odido maar niet oplost) opgelost. :)

Ik probeer alleen te zeggen dat dat klonen/kopieren helemaal niet nodig was.

Fijn dat je het zo op hebt kunnen lossen. Alleen niet iedereen zal een eigen router (willen) hebben. 

 


  • is een King Poster
  • November 15, 2025

Ik krijg met het aanpassen van mac adres heletijd dezelfde range helaas, alleen de laatste 2 octetten veranderen, 188.90.2xx.xxx Dit is dus die rotte range waarvan Odido het niet voor elkaar krijgt..


188.88.0.0/15 heeft hetzelfde probleem.

inetnum:        188.88.0.0 - 188.89.255.255
netname: Odido-Netherlands
descr: Pool for mobile internet users

Toch maar weer een tag, want nog steeds geen reactie gezien: ​@Tommie van Odido  ​@Teresa van Odido

Helaas ook nog geen reactie van de klantenservice.


OpenSourceRouter

Gebruik DNSCrypt is ook stuk veiliger en meer betrouwbaar internetten! https://dnscrypt.info/


rvk01
  • Auteur
  • November 23, 2025

Gebruik DNSCrypt is ook stuk veiliger en meer betrouwbaar internetten! https://dnscrypt.info/

Dat verbergt het DNS verkeer voor je provider (door encryptie van dat DNS verkeer). Het doet niets voor de reverse DNS pointer (is een soort reverse hostname) van je eigen IP adres, te zien vanuit de uiteindelijke server. Ik denk dat je dus niet begrijpt wat het probleem hier is. 

 


Weer een week verder, weer niets gehoord. ​@Tommie van Odido en ​@Teresa van Odido, heeft de gehele helpdesk toevallig tegelijk vakantie? Ik wordt steeds naar de community gestuurd, dus blijkbaar is dit de plek waar je moet klagen.. Hopelijk informeert dit potentieel nieuwe klanten over de staat van de helpdesk.


Tommie van Odido
Moderator
Forum|alt.badge.img+13

Hey ​@cFvcPXdNFv4278v6DSw4U, zodra ik een update heb zal ik die zeker delen. Dit lijkt lastiger op te lossen zijn dan normaal zo te zien. Het onderzoek is namelijk nog in volle gang. Als ik nieuws of de oplossing heb deel ik die meteen!  


Hey ​@cFvcPXdNFv4278v6DSw4U, zodra ik een update heb zal ik die zeker delen. Dit lijkt lastiger op te lossen zijn dan normaal zo te zien. Het onderzoek is namelijk nog in volle gang. Als ik nieuws of de oplossing heb deel ik die meteen!  

Goed om te horen! Welk onderzoek moet er nog gebeuren? b0rg heef al het voorwerk al gedaan en geeft precies aan waar het probleem zit, en dat was 3 maanden geleden. Zou fijn zijn als ik weer gewoon normaal gebruik kan maken van mijn aansluiting, zonder steeds als verdachte verbinding gemarkeerd te worden.


  • November 26, 2025

Hey ​@cFvcPXdNFv4278v6DSw4U, zodra ik een update heb zal ik die zeker delen. Dit lijkt lastiger op te lossen zijn dan normaal zo te zien. Het onderzoek is namelijk nog in volle gang. Als ik nieuws of de oplossing heb deel ik die meteen!  

Hoi ​@Tommie van Odido, na een stroomstoring heb ik ook weer een ip uit een reeks waarbij er geen reverse host is. Bij mij is het probleem dus uiteindelijk niet opgelost. Ik ben benieuwd of er vanuit Odido een verwachting is wanneer dit wordt opgelost?


  • December 18, 2025

Hoi ​@Tommie van Odido, we zijn alweer 21 dagen verder. Is er al een update? 


Update? 


Tommie van Odido
Moderator
Forum|alt.badge.img+13

Hey ​@cFvcPXdNFv4278v6DSw4U, ze hebben het probleem kunnen achterhalen: 

Result:
All queries returned status NOERROR. No SERVFAIL, REFUSED, or NXDOMAIN responses were observed when querying versatel.net directly.

This confirms that ns1.versatel.net hosts a complete and functional reverse DNS zone for 188.88.0.0/16, but it is unreachable via public DNS because the RIPE reverse delegation points to info.nl, which serves an empty zone and does not delegate further.

Updating the RIPE reverse DNS object to delegate 188.88.0.0/16 to ns1.versatel.net will not remove or break any currently working PTR records, as none are visible through the current delegation. The change simply makes the already-existing PTR records reachable and restores proper reverse DNS resolution. 

 

Ze zitten er nu over na te denken om the RIPE Object te wijzigen, dat zou het moeten oplossen. Dit is de laatste update tot nu toe!


Hey ​@cFvcPXdNFv4278v6DSw4U, ze hebben het probleem kunnen achterhalen: 

Result:
All queries returned status NOERROR. No SERVFAIL, REFUSED, or NXDOMAIN responses were observed when querying versatel.net directly.

This confirms that ns1.versatel.net hosts a complete and functional reverse DNS zone for 188.88.0.0/16, but it is unreachable via public DNS because the RIPE reverse delegation points to info.nl, which serves an empty zone and does not delegate further.

Updating the RIPE reverse DNS object to delegate 188.88.0.0/16 to ns1.versatel.net will not remove or break any currently working PTR records, as none are visible through the current delegation. The change simply makes the already-existing PTR records reachable and restores proper reverse DNS resolution. 

 

Ze zitten er nu over na te denken om the RIPE Object te wijzigen, dat zou het moeten oplossen. Dit is de laatste update tot nu toe!

Bedankt! Precies wat hier 4 maanden geleden dus ook al door ​@rvk01 gepost was. Het updaten van de delegation is inderdaad de enige echte oplossing voor dit probleem, fijn dat men ook tot die conclusie gekomen is. Houd ons op de hoogte! 


Hey ​@cFvcPXdNFv4278v6DSw4U, ze hebben het probleem kunnen achterhalen: 

Result:
All queries returned status NOERROR. No SERVFAIL, REFUSED, or NXDOMAIN responses were observed when querying versatel.net directly.

This confirms that ns1.versatel.net hosts a complete and functional reverse DNS zone for 188.88.0.0/16, but it is unreachable via public DNS because the RIPE reverse delegation points to info.nl, which serves an empty zone and does not delegate further.

Updating the RIPE reverse DNS object to delegate 188.88.0.0/16 to ns1.versatel.net will not remove or break any currently working PTR records, as none are visible through the current delegation. The change simply makes the already-existing PTR records reachable and restores proper reverse DNS resolution. 

 

Ze zitten er nu over na te denken om the RIPE Object te wijzigen, dat zou het moeten oplossen. Dit is de laatste update tot nu toe!

Zijn ze er nog steeds over na aan het denken? Of is de TTL wel heel lang ingesteld..  We zouden eigenlijk eens met z'n allen eens moeten nadenken over een vergoeding voor het X aantal dagen dat wij geen volwaardige internetaansluiting hebben gehad, misschien dat er dan iets sneller beslissingen genomen kunnen worden.  


Teresa van Odido
Moderator
Forum|alt.badge.img+5

​@cFvcPXdNFv4278v6DSw4U Ik snap goed dat je benieuwd bent naar een update! Ik heb jouw vraag direct bij Tommie neergelegd. Hij is echter op dit moment niet aanwezig. Ik verwacht dat hij dit volgende week meteen oppakt en hier meer over kan vertellen. 

Laat je het mij weten als ik in de tussentijd ergens anders bij kan helpen?


Tommie van Odido
Moderator
Forum|alt.badge.img+13

Hey ​@cFvcPXdNFv4278v6DSw4U, ik ben meteen voor je gaan kijken en zie dat het voor de volgende adressen is aangepast:

domain: 88.188.in-addr.arpa
nserver: ns1.versatel.net
nserver: ns2.versatel.net
nserver: ns3.versatel.net
nserver: ns4.versatel.net

Deze zouden nu wel bereikbaar moeten zijn als het goed is! Zo niet, laat het dan weten, dan kan ik dit aangeven bij het IP-team. 


rvk01
  • Auteur
  • January 29, 2026

Hey ​@cFvcPXdNFv4278v6DSw4U, ik ben meteen voor je gaan kijken en zie dat het voor de volgende adressen is aangepast:

domain: 88.188.in-addr.arpa
nserver: ns1.versatel.net
nserver: ns2.versatel.net
nserver: ns3.versatel.net
nserver: ns4.versatel.net

Deze zouden nu wel bereikbaar moeten zijn als het goed is! Zo niet, laat het dan weten, dan kan ik dit aangeven bij het IP-team. 

Niet voor de “buitenwereld”. Die ns1 worden volgens mij nog steeds niet aan “the world” DNS servers doorgegeven. Of hebben jullie de 188.90.x.x niet meer in de pool zitten voor IP uitgiftes??

Dit is mijn oude IP (ik zit inmiddels bij KPN). Via 1.1.1.1 dus niets. Direct aan ns1.versatel.net vragen wel.

C:\Users\Rik>nslookup 188.90.236.10 1.1.1.1
Server: one.one.one.one
Address: 1.1.1.1

*** one.one.one.one can't find 188.90.236.10: Non-existent domain

C:\Users\Rik>nslookup 188.90.236.10 ns1.versatel.net
Server: ns1.versatel.net
Address: 2a01:380:1f00::2

Name: 10-236-90-188.ftth.glasoperator.nl
Address: 188.90.236.10

 


  • is een King Poster
  • January 29, 2026

​@Tommie van Odido 

Hier ook nog steeds niet goed voor range 188.90.0.0 - 188.91.255.255. 

😤

 

 

 


Het lijkt inderdaad opgelost voor 188.88.0.0/16, maar inderdaad nog niet voor 188.89.0.0/16, 188.90.0.0/16 and 188.91.0.0/16.


  • is een King Poster
  • January 29, 2026

Ik snap niet dat ze niet langer dan hun neus kijken, hokjes denken bij Odido.


  • is een King Poster
  • January 31, 2026

​@Tommie van Odido 

Wanneer worden de overige IP ranges aangepakt die zijn gemeld het begin van dit topic??

 


Tommie van Odido
Moderator
Forum|alt.badge.img+13

Hey allemaal, dit is voor nu wat ze hebben kunnen wijzigen, voor de rest loopt het onderzoek nog! Voor nu heb ik nog geen nieuwe update, zodra ik die heb zal ik hem met jullie delen.


  • is een King Poster
  • February 2, 2026

​@Tommie van Odido Wat raar, waarom word dit niet gelijk recht getrokken voor alle subnets? Onderzoek loopt nog? Aapje zien aapje doen want de oplossing van het andere subnet is er al.

 


Weer een week verder. Kunnen ze nou eens een keer gewoon alle foutief geconfigureerde subnetten oplossen? Het probleem is bekend, de oplossing is bekend, het hoeft alleen uitgevoerd te worden.. 


Tommie van Odido
Moderator
Forum|alt.badge.img+13

Hey ​@cFvcPXdNFv4278v6DSw4U, ik ga er vanuit dat ze dit nog gaan aanpassen, degene die dit kan wijzigen is op dit moment met verlof tot begin maart. Ik zal dan een betere update kunnen geven in dit topic!