Geen reverse hostname bij IP van Odido

PS. voor de andere. Als je direct een andere nameserver opgeeft dan werkt het wel. Er is dus iets wat die nameserver niet doorgeven aan de “wereld” root servers.

C:\Users\Rik>nslookup 188.90.x.x ns4.versatel.net
Server:  ns4.versatel.net
Address:  62.58.126.130

Name:    x-x-90-188.ftth.glasoperator.nl
Address:  188.90.x.x
 

C:\Users\Rik>nslookup 188.90.x.x
Server:  home
Address:  192.168.2.1

*** home can't find 188.90.x.x: Non-existent domain
 

​@Tommie van Odido Het gaat niet om een persoonlijke kwestie maar een niet correct ingerichte configuratie bij Odido.

Zie hier wat andere Odido ip subnets voorbeelden waar het gewoon netjes correct is geconfigureerd:

~# nslookup 82.172.32.1 1.1.1.1
1.32.172.82.in-addr.arpa        name = 1-32-172-82.ftth.glasoperator.nl.

~# host 82.172.32.1
1.32.172.82.in-addr.arpa domain name pointer 1-32-172-82.ftth.glasoperator.nl.

~# nslookup 143.178.144.1 1.1.1.1
1.144.178.143.in-addr.arpa      name = 1-144-178-143.ftth.glasoperator.nl.

~# host 143.178.144.1
1.144.178.143.in-addr.arpa domain name pointer 1-144-178-143.ftth.glasoperator.nl.

~# nslookup 87.209.20.1 1.1.1.1
1.20.209.87.in-addr.arpa        name = 1-20-209-87.ftth.glasoperator.nl.

~# host 87.209.20.1
1.20.209.87.in-addr.arpa domain name pointer 1-20-209-87.ftth.glasoperator.nl.

Het ip subnet 188.88.0.0/14 AS50266  ·  Odido Netherlands B.V waar ik in zit (188.90.248.0/23) is het dus (nog) niet correct geconfigureerd:

~# nslookup 188.90.248.1 1.1.1.1
** server can't find 181.248.90.188.in-addr.arpa: NXDOMAIN

~# host 188.90.248.1
Host 1.248.90.188.in-addr.arpa. not found: 3(NXDOMAIN)

Dat wijst bijna zeker op een ontbrekende of foutieve reverse delegation voor het /23-reverse-zone van mijn IP en de andere subnetten die hier onder vallen.

Een: ~# dig +trace -x 188.90.248.1 zie je dus dat het naar de verkeerde nameservers staat te kijken ns1.info.nl

• De keten loopt netjes van . --> in-addr.arpa --> 188.in-addr.arpa --> 90.188.in-addr.arpa.

• Daar eindigt hij met de SOA van ns1.info.nl en geen NS-records voor 248.90.188.in-addr.arpa (en dus ook niet voor 249.90.188.in-addr.arpa).

~# dig NS 248.90.188.in-addr.arpa @ns1.info.nl

; <<>> DiG 9.16.50-Debian <<>> NS 248.90.188.in-addr.arpa @ns1.info.nl
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24227
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;248.90.188.in-addr.arpa.       IN      NS

;; AUTHORITY SECTION:
90.188.in-addr.arpa.    604800  IN      SOA     ns1.info.nl. postmaster.info.nl. 2011031100 3600 900 1209600 604800

;; Query time: 10 msec
;; SERVER: 80.79.192.32#53(80.79.192.32)
;; WHEN: Fri Aug 22 12:56:03 CEST 2025
;; MSG SIZE  rcvd: 110

~# dig -x 188.90.248.1 @ns1.versatel.net

; <<>> DiG 9.16.50-Debian <<>> -x 188.90.248.1 @ns1.versatel.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8363
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 7
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 951b5f4fb7c8beb0002108df68a84d60e249e7ccb83d504e (good)
;; QUESTION SECTION:
;1.248.90.188.in-addr.arpa.     IN      PTR

;; ANSWER SECTION:
1.248.90.188.in-addr.arpa. 86400 IN     PTR     1-248-90-188.ftth.glasoperator.nl.

;; AUTHORITY SECTION:
248.90.188.in-addr.arpa. 86400  IN      NS      ns2.versatel.net.
248.90.188.in-addr.arpa. 86400  IN      NS      ns4.versatel.net.
248.90.188.in-addr.arpa. 86400  IN      NS      ns3.versatel.net.
248.90.188.in-addr.arpa. 86400  IN      NS      ns1.versatel.net.

;; ADDITIONAL SECTION:
ns1.versatel.net.       86400   IN      A       62.58.62.132
ns2.versatel.net.       86400   IN      A       62.58.94.130
ns3.versatel.net.       86400   IN      A       62.58.222.130
ns4.versatel.net.       86400   IN      A       62.58.126.130
ns1.versatel.net.       86400   IN      AAAA    2a01:380:1f00::2
ns4.versatel.net.       86400   IN      AAAA    2a01:380:1f00:1::2

;; Query time: 10 msec
;; SERVER: 62.58.62.132#53(62.58.62.132)
;; WHEN: Fri Aug 22 12:58:40 CEST 2025
;; MSG SIZE  rcvd: 333

Conclusie: de child-zones voor mijn /23 subnet zijn niet gedelegeerd vanaf 90.188.in-addr.arpa. Daarom geven publieke resolvers NXDOMAIN, terwijl ns1/2/3/4.versatel.net mijn PTR record wel kent.

Met welke andere nameserver behalve versatel werkt het?

nslookup 188.90.248.1 unfiltered.joindns4.eu
Server:  unfiltered.joindns4.eu
Address:  86.54.11.100

*** unfiltered.joindns4.eu can't find 188.90.248.1: Non-existent domain

nslookup 188.90.248.1 dns9.quad9.net
Server:  dns9.quad9.net
Address:  9.9.9.9

*** dns9.quad9.net can't find 188.90.248.1: Non-existent domain

nslookup 188.90.248.1 ns1.versatel.net
Server:  ns1.versatel.net
Address:  62.58.62.132

Name:    1-248-90-188.ftth.glasoperator.nl
Address:  188.90.248.1

De oorzaak voor deze fout denk ik ligt in de "pool voor mobiel”

inetnum:        188.90.0.0 - 188.91.255.255
netname:        Odido-Netherlands
descr:          Pool for mobile internet users

Geen enekele dns server werkt behalve de versatel.

Voor mij is het 188.90.236.x

Maar het is dus duidelijk dat de delegatie voor de reverse zone 236.90.188.in-addr.arpa (en waarschijnlijk meer) niet correct is ingesteld in de RIPE-database.

Toch bijzonder dat een IT-team van Odido hier niet uit kan komen. Dat geeft ook gelijk de reden aan waarom ze niet aan IPv6 beginnen (te weinig kennis in huis 😉 ).

​@Tommie van Odido Wij hebben alles kant-en-klaar voor je uitgewerkt om door te zetten naar de IT-afdeling/Managed Service partij.

Kunnen we een update hierover krijgen?

Hallo,

In ben recentelijk weer klant geworden bij Odido en ik heb hetzelfde probleem. Mijn ip 188.90.250.x heeft ook geen reverse dns/PTR-record, wat bij een aantal diensten problemen oplevert.

Het valt mij op dat net als bij notR1CH zes maanden geleden in dit topic ook ik een IP heb die bij RIPE geregistreerd staat als Pool for mobile users. 

​@rvk01 hierboven heeft alles al netjes uitgelegd. ​@Tommie van Odido ik zie dat een maand geleden aan jou om een update is gevraagd. Is deze update er al? 

Kan trouwens het beantwoord-label niet van deze post af? Het is in ieder geval nog niet opgelost ;).

Inmiddels zijn we een week verder. ​@Tommie van Odido wanneer kan er een antwoord verwacht worden? 

​@Teresa van Odido ​@Tommie van Odido Kan er nou is actie worden ondernomen?

Trouwens, niet alleen Odido heeft problemen met reverse DNS. Ook KPN heeft problemen dit te fixen en veroorzaakt routingsproblemen. Beter geen reverse DNS dan een ongeldige reverse DNS

nslookup 195.190.228.3
Name:    static.kpn.net

nslookup 195.190.228.4
Name:    static.kpn.net

nslookup static.kpn.net 9.9.9.9
*** dns9.quad9.net can't find static.kpn.net: Non-existent domain

​@Tommie van Odido ​@Teresa van Odido wat moet er gebeuren om antwoord te krijgen? 

Lezen jullie dit überhaupt wel? 

​@Tommie van Odido ​@Teresa van Odido we zijn inmiddels weer een week verder.

Hey ​@denger, ik heb het zojuist opnieuw laten doorzetten met goede voorbeelden. Hopelijk kunnen ze aan de hand van deze voorbeelden het probleem verhelpen! 

​@Tommie van Odido Dit is standaard inrichting waarom duurt dit zo lang? Is het netwerk beheer uitbesteed aan partij zonder kennis of India ofzo?

Vorige keer is het inderdaad “gesloten” omdat ze niet verder konden ​@b0rg, nu heb ik een specialist bij ons gevraagd om zelf testen uit te voeren en die testen zijn nu aangeleverd aan het IP-team. Zij zullen dit nu verder moeten onderzoeken, als het goed is kunnen ze nu wel verder komen. 

Bedankt voor je hulp ​@Tommie van Odido; ik ben benieuwd naar het vervolg en je terugkoppeling. 

​@Tommie van Odido 

BUMP TOPIC

Wij hebben inmiddels bijna 2 maanden geleden melding gemaakt van ons probleem, maar merk helaas nog weinig terugkoppeling of voortgang. We begrijpen dat het druk kan zijn, maar we zouden het erg op prijs stellen als er wat meer proactiviteit en communicatie vanuit Odido komt. Een update of vooruitzicht zou veel vertrouwen geven.

Alvast bedankt voor jullie aandacht en hulp!

Ik ervaar hetzelfde probleem

​@Tommie van Odido 

​@Teresa van Odido 

Zojuist een nieuw IP adres gekregen met zowaar een reverse DNS 😁

​@Tommie van Odido Nu de reverse DNS inmiddels goed staat… kunnen we eens testen of het probleem van geen mail ontvangen van de community daaraan gelegen heeft.

Kun jij op account rvk02 het e-mail adres wijzigen in r..k@gr...nl (adres staat daar in moderator info)?

(E-mail van rvk01 moet blijven staan want die gebruik ik actueel en met rvk02 kan ik dan zien of mijn domein mail wel goed gepakt wordt door de community server.)

Fijn! Hopelijk kunnen ze voor mij ook een oplossing vinden ​@Tommie van Odido , al zal het natuurlijk beter zijn als het onderliggende probleem gewoon opgelost wordt. Genoeg klanten met eenzelfde probleem die dit niet doorhebben, maar wel geplaagd worden door maatregelen van anti-botdetectiesystemen als extra captchas en blacklists.

Ik heb contact gehad met de klantenservice, maar deze (1) begrepen er niets van (wat ik de 1e/2e lijn ook niet kwalijk neem) maar (2) gaven aan dit niet hogerop te kunnen spelen. Blijkbaar is er binnen Odido geen mogelijkheid om problemen met hun eigen systemen door te geven en te laten oplossen. De medewerker gaf aan alleen problemen bij mensen thuis op te kunnen lossen en verder niets door te kunnen geven. Sorry, te ingewikkeld, kunnen en gaan we niets aan doen. Ik kreeg daarna de vraag of ik doorverbonden wilde worden met de opzegafdeling..

Ticket is ondertussen wel weer geopend en ik heb het een en ander per mail kunnen toelichten, hopelijk deze keer meer geluk.

Fijn dat het bij jou weer goed zit, ​@rvk01! Bij mij is er nog niks veranderd.

​@Tommie van Odido ​@Teresa van Odido Kan er een update komen?

Update:

Ik heb het opgelost. Ik gebruik een eigen router en ik heb daarin nu het MAC-adres van de Zyxel gekopieerd op de WAN-interface. Dit heeft als gevolg dat ik uit een andere range een IP-adres heb gekregen en dit IP-adres heeft wel een geldig PTR-record.

Kopiëren van het MAC-adres van de Zyxel is niet eens nodig. Je kunt altijd je eigen router aansluiten zonder registratie (registratie is alleen nodig voor andere ONT). En bij een eigen router krijg je inderdaad een ip adres in de andere range.

Daar heb je helemaal gelijk in. 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. :)