Skip to main content
Vraag

KPN DNS blokkeert reverse DNS queries vanaf Hetzner (VPS) – verzoek om whitelisting

  • December 15, 2025
  • 9 reacties
  • 63 keer bekeken
H
Nieuwkomer

Ik huur een VPS bij Hetzner. Als ik op die VPS een reversed lookup doe van mijn thuis ip-adres, dan ontstaat er een timeout:

# host 77.174.x.x
;; communications error to 185.12.64.2#53: timed out
;; communications error to 185.12.64.2#53: timed out
;; communications error to 185.12.64.1#53: timed out
;; communications error to 2a01:4ff:ff00::add:2#53: timed out
;; no servers could be reached

Als ik bijvoorbeeld 9.9.9.9 als DNS server gebruik, krijg ik direct antwoord.


Ik heb daarover navraag gedaan bij Hetzner en ze komen tot de conclusie dat hun DNS server geblocked worden door KPN. Hun antwoord:

---

It appears that the authoritative DNS designated for the specific domain are blocking our recursive DNS queries.We will contact the operators of the authoritative DNS to ask them to lift the block. Please also contact them. This may help speed up the process.Here are the authoritative DNS designated for the respective domains according to their SOA records:   254.77.x.x.in-addr.arpa:    DNS: ns7.kpn.net, ns8.kpn.net    Contact: zonemaster@kpn.comIf you are in any kind of relationship with the domain's owner or the DNS provider (e.g. if you are a customer yourself), I recommend that you contact them using the correct communication method as their customer, for example, a support request.Our recursive DNS queries originate from the following IP ranges:  5.161.7.192/26 ash-dc1  2a01:4ff:ef::/64 ash-dc1  78.46.173.64/26 fsn1  88.198.139.0/26 fsn1  2a01:4f8:0:a104::/64 fsn1  2a01:4f8:0:a231::/64 fsn1  95.217.254.192/26 hel1  95.217.255.64/26 hel1  2a01:4f9:0:a010::/64 hel1  2a01:4f9:0:a011::/64 hel1  5.78.7.192/27 hil-dc1  2a01:4ff:1ef::/64 hil-dc1  78.47.119.192/26 nbg1  78.47.149.65/26 nbg1  2a01:4f8:0:a0a1::/64 nbg1  2a01:4f8:0:a0a2::/64 nbg1  5.223.7.192/26 sin-dc1  2a01:4ff:2ef::/64 sin-dc1We also publish the IP ranges that we use to perform DNS queries via the TXT record 'locations.recursivedns.hetzner.com'.Until the operator of the authoritative DNS lifts the block, we regretfully will not be able to help you further; it is not in our power to lift the block.However, it is possible for you to use alternative open DNS servers such as 8.8.8.8 or 1.1.1.1 in your server's configuration (in Linux usually /etc/resolv.conf) in the meantime to work around the issue.Kind regardsMatthias StahlPlease help us to improve our processes (~10sec): https://feedback.hetzner.com/?id=eiIKzX&i=2025120903038469Hetzner Online GmbHIndustriestr. 2591710 Gunzenhausen / GermanyTel: +49 9831 505-0Fax: +49 9831 505-3www.hetzner.com---

Ik wil de KPN vragen hier wat aan te doen, maar ik weet niet waar ik dat kan doen….

9 reacties

Erwin van KPN
Moderator

Hoi ​@Heraldvanderbreggen . Welkom bij de KPN Community!

Dank voor je duidelijke uitleg en het uitgebreide voorbeeld. Dat maakt het een stuk makkelijker om mee te denken.

Wat je beschrijft lijkt niet zozeer een algemeen DNS probleem aan jouw kant, maar specifiek te spelen tussen de recursieve DNS servers van Hetzner en de autoritatieve reverse DNS servers van KPN voor dit IP bereik. Dat je via 9.9.9.9 wel direct antwoord krijgt, bevestigt eigenlijk dat de zone zelf gewoon bereikbaar is, maar dat bepaalde resolvers geen antwoord krijgen.

Bij KPN worden reverse DNS zones streng gemonitord en er zijn filters actief om misbruik, excessieve queries of afwijkend gedrag tegen te gaan. Het is dus goed mogelijk dat de queries vanuit (een deel van) de Hetzner ranges tijdelijk of structureel worden geweigerd. Dat betekent niet automatisch dat er “iets kapot” is, maar wel dat het verkeer als ongewenst wordt gezien.

De juiste route is inderdaad niet via de reguliere klantenservice. Voor dit soort zaken kan Hetzner, of jij als klant, contact opnemen via zonemaster@kpn.com, zoals zij zelf ook aangeven. Dat is het team dat deze reverse DNS zones beheert. Het helpt daarbij als Hetzner expliciet de gebruikte IP ranges en een concrete timestamp van de timeouts meestuurt, zodat het intern te herleiden is.

Heb jij zelf nog gemaild met zonemaster@kpn.com?  

Blij met een antwoord? Geef een like! Is een bericht het beste antwoord op je vraag? Markeer het dan als oplossing.
H
Nieuwkomer

Dank ​@Erwin van KPN voor je reactie. Ik heb inderdaad gemaild naar zonemaster@kpn.com, twee keer zelfs, vanaf twee verschillende e-mailadressen (een keer ook vanaf mijn xs4all.nl account), maar geen reactie gekregen. Het probleem duurt nog steeds voort.

Heb je misschien nog een tip?

 

M
Topper
  • Marlon92
  • December 17, 2025

Ik dacht eigenlijk dat KPN dit überhaupt helemaal niet ondersteunde. Klanten die thuis een mailserver willen draaien hebben reverse DNS nodig om goed door alle anti spam checks te komen. Maar KPN werkt daar bij particuliere klanten niet aan mee. Althans niet naar hun eigen domeinnaam in ieder geval.

Waarom wil je de DNS server van Hetzner gebruiken?

TDN
Wijsgeer
Forum|alt.badge.img+13
  • TDN
  • Wijsgeer
  • December 17, 2025

Het is toch logisch dat DNS servers van KPN niet van vreemde adressen (niet klanten) kunnen gebruikt worden.

nslookup kpn.com ns7.kpn.net
Server:  ns7.kpn.net
Address:  195.121.97.196

Name:    kpn.com
Addresses:  2600:9000:a400:dede:1a1c:a23f:9ae6:7bbc
          2600:9000:a504:9080:40c0:d138:ca59:2e3d
          75.2.72.204
          99.83.136.155


nslookup google.com ns7.kpn.net
Server:  ns7.kpn.net
Address:  195.121.97.196

*** ns7.kpn.net can't find google.com: Query refused

 

When you can’t sleep at night, it’s because you’re awake in someone else’s dreams
H
Nieuwkomer

​@Marlon92  en ​@TDN : Bedankt voor jullie reacties.

Ik wil graag even verduidelijken wat er precies speelt en waarom ik om hulp vraag.

 

Wat ik probeer te doen

Ik run een VPS bij Hetzner en gebruik de recursieve nameservers van Hetzner (bijvoorbeeld 185.12.64.1/2). Vanuit die VPS doe ik een reverse‑lookup van mijn thuis‑IP‑adres (bijvoorbeeld 77.174.x.x). Het doel is simpelweg om te controleren of er een correcte PTR‑record bestaat – iets wat nodig is wanneer ik later eventueel een mailserver of andere diensten vanaf mijn thuisnetwerk wil laten draaien.

Wanneer ik dezelfde reverse‑lookup uitvoer met publieke resolvers (bijv. 9.9.9.9, 1.1.1.1 of 8.8.8.8) krijg ik direct een antwoord. Met de Hetzner‑nameservers krijg ik echter alleen time‑outs:

host 77.174.x.x
;; communications error to 185.12.64.2#53: timed out
...
;; no servers could be reached

Uit het onderzoek van Hetzner blijkt dat de autoritatieve nameservers van KPN de recursieve queries blokkeren. Dit verklaart de time‑outs.

 

Waar de verwarring zit

  1. Gebruik van KPN‑nameservers
    Ik probeer geen KPN‑recursieve nameserver te gebruiken. De enige namen die ik aanspreek zijn die van Hetzner. De blokkade gebeurt aan de kant van de autoritatieve KPN‑servers omdat ze queries afkomstig van Hetzner’s resolver‑IP‑blokken weigeren.

  2. Reverse‑DNS voor thuis‑IP
    Voor een thuis‑mailserver (of andere uitgaande services) is een geldige PTR‑record inderdaad belangrijk. De PTR‑record wordt beheerd door de eigenaar van het IP‑blok – in dit geval KPN. Mijn verzoek is dus niet om KPN te laten “ondersteunen” dat ik hun eigen recursieve resolvers gebruik, maar om de blokkade op hun autoritatieve servers op te heffen zodat externe resolvers (zoals die van Hetzner) wel een antwoord kunnen geven.

  3. Waarom ik de Hetzner‑resolver wil gebruiken
    Op mijn VPS staat standaard de resolver van de hostingprovider ingesteld. Het aanpassen van /etc/resolv.conf naar een publieke resolver (bijv. 9.9.9.9) is een tijdelijke workaround, maar ik zou liever de normale configuratie behouden zodat de VPS automatisch profiteert van de interne caching en eventuele optimalisaties van Hetzner.

Verzoek aan KPN

Zou u alstublieft kunnen onderzoeken waarom queries naar de PTR‑record van mijn thuis‑IP (bijvoorbeeld 77.174.x.x.in‑addr.arpa) vanuit de IP‑ranges van Hetzner (185.12.64.0/24 en de IPv6‑range 2a01:4ff:ff00::/48) worden geweigerd? Een mogelijke oorzaak is een firewall‑ of anti‑abuse‑regel die per ongeluk legitieme recursieve queries blokkeert.
 

TDN
Wijsgeer
Forum|alt.badge.img+13
  • TDN
  • Wijsgeer
  • December 17, 2025

​@Heraldvanderbreggen Het is fout van Hetzner de ns7.kpn.net of ns8.kpn.net te gebruiken. Je kan niet verwachten dat KPN hun DNS server opent voor vreemde. Er zijn op internet veel klachten over deze problemen van Hetzner. Gewoon een andere DNS server gebruiken, het voordeel is te weinig om de nadelen te ervaren

[Resolve]
DNS=185.12.64.1 
FallbackDNS=1.1.1.1 8.8.8.8 9.9.9.9 185.12.64.2
DNSOverTLS=opportunistic

 

When you can’t sleep at night, it’s because you’re awake in someone else’s dreams
M
Topper
  • Marlon92
  • December 17, 2025

Als KPN Hetzner geblokkeerd heeft, dan zal dat vast niet voor niets zijn. En dan zullen ze die blokkade niet zomaar weer ongedaan maken. Als ik het ip adres 185.12.64.2 Google, dan zie ik ook heel wat Abuse websites in de resultaten. Zelfs het Al blokje van Google heeft het over misbruik enzo.

Het aanpassen van /etc/resolv.conf naar een publieke resolver (bijv. 9.9.9.9) is een tijdelijke workaround...

Waarom is dat een tijdelijke workaround? 

H
Nieuwkomer

​@TDN en ​@Marlon92 : Fijn dat jullie meedenken en de moeite nemen te reageren.

Wat betreft het beschikbaar maken van een DNS server voor de buitenwereld: als iedere DNS zijn zonefiles niet aan de buitenwereld bekend zou maken, zou het Internet niet kunnen werken. Het is gelukkig ook niet zo dat de KPN DNS servers afgeschermd zijn voor de buitenwereld, immers, om maar een voorbeeld te noemen,  ik kan mijn thuis-ip-adres prima resolven op een VPS van TransIP waarop een DNS server van TransIP gebruikt wordt. En zoals we gezien hebben lukt het ook via andere DNS servers.

Natuurlijk is een andere DNS instellen een eenvoudige optie (heb ik ook gedaan). Maar ik ben er om de volgende reden niet helemaal gelukkig mee:

  • Ik maak het liefst gebruik van de standaard netwerkinstelling, dit om verrassingen te voorkomen. Denk bijvoorbeeld aan gebruiken van services die lokaal op het netwerk aangeboden worden en waarvan de hostnames alleen lokaal bestaan.
  • Een DNS in het lokale netwerk is dichterbij en heeft doorgaans een korte response tijd.
  • De cache van de locale DNS server zal waarschijnlijk een hogere hit rate hebben

Dat er bij Hetzner gevallen van misbruik zijn, is niet gek. Het is gebruikelijk voor een provider waar computertijd te huren is. Het idee dat potentieel misbruik een reden kan zijn voor een block door KPN  ligt voor de hand, maar roept ook een aantal vragen op:

  • op wat voor manier kan het doen van een reverse lookup, misbruik in de kaar spelen? ik zou het niet weten. Voor spammers is alleen een MX record nodig, die kunnen ze gewoon krijgen.
  • kan je hier misbruik wel mee in de weg zitten als andere DNS-en wel over de informatie beschikken? Er is dus makkelijk omheen te werken.

Maar ik geloof dat ik inmiddels wel weet wat er aan de hand is. De DNS servers van Hetzner zijn pas sinds oktober 2025 in gebruik. Ik denk dat KNP nog niet op de hoogte is van dat dit legitieme DNS servers zijn die recursive queries moeten kunnen doen. Zie ook 

https://docs.hetzner.com/dns-console/dns/general/recursive-name-servers/

Als iemand een tip heeft hoe KPN hiervan op de hoogte te brengen, dan hoor ik het graag.

    Erwin van KPN
    Moderator

    Een officiële ingang hiervoor heb ik niet. Dit soort zaken worden in de regel tussen die diensten en KPN onderling geregeld. (zoals ze zelf ook aangeven).

    Ik ken gelukkig wel een hoop mensen binnen KPN en heb, vrijblijvend een mail gestuurd naar een contactpersoon.  Of die hier iets zinnigs over kan zeggen en/of betekenen moeten we afwachten.  

    Ga er niet van uit dat we dit jaar nog een antwoord hebben, ​@Heraldvanderbreggen .  Maar zodra hij terug mailt, laat ik het jou hier weten. 

    Blij met een antwoord? Geef een like! Is een bericht het beste antwoord op je vraag? Markeer het dan als oplossing.

      De Kennisbank

      Heb je vragen over diensten, producten of wil je weten hoe je modeminstellingen verandert? Vind het antwoord op de meest gestelde vragen in onze Kennisbank

      ...

      Community voorwaardenAccessibility statement