Reverse-DNS record werkt niet meer

Beide staan inmiddels uit. Ik kom er ZSM op terug.

Ik ben er ook niet blij mee dat het niet werkt, maar dit valt wel gewoon te herstellen als ze het goed oppakken, laten we dat dus eerst even afwachten. Een eventuele compensatie oid kan altijd hierna nog aangevraagd worden.

Het heeft voorheen ook gewoon altijd gewerkt, dus ook met dynamische addressen kan dit gewoon correct functioneren mits de boel goed ingeregeld is.

Ik ben net zoals anderen hier een privé klant. Echter sinds begin 2000 heb ik een eigen domein en dat draait nu al jaren op een virtuele server bij een provider (TransIP). Om mijn mail -- op naam van mijn domeinen -- te versturen gebruiken ik mijn eigen mailserver. Omdat die belaagt wordt door spammers heb ik daar een paar jaar geleden een reverse DNS controle als eis ingesteld.

Iedereen die contact maakt -- dus ook ikzelf -- doet dat via een IP-adres en deze is in de praktijk lastig te vervalsen. Spammers geven vervolgens een naam door en die is gemakkelijk te vervalsen. Ook misbruiken ze vaak ranges waarvan beheerders voor ongebruikte adressen geen reverse DNS hebben ingesteld. Ofwel de controle IP-adres naar naam en dan die naam weer naar IP-adres -- dit noemen we reverse DNS controle -- gaat bij spammers vaak mis.

Tot 5 november ging de controle van mijn (Telfort) IP-adres goed. Ofwel deze gaf als naam ip<hex adres>.speed.planet.nl en die opzoeken gaf weer mijn IP-adres. Perfect. Die tweede stap ging echter op 5 november mis en nader onderzoek leerde dat ze alle ip<hex adres>.speed.planet.nl records hebben verwijderd. Waarom mag Joost weten. Mogelijk willen ze af van die oude planet naamgeving? Tenslotte ben ik Telfirt klant -- totdat het opgaat in KPN.

Hoe dan ook, ik heb nu dus deze controle moeten uitzetten, waardoor de spam is vertienvoudigd. Ik weet niet of het een wettelijke vereiste is, maar volgens de RFCs zorgen netwerkbeheerders ervoor dat deze controle werkt. Naast mail wordt het ook in andere controles gebruikt. Vaak in het bedrijfsleven en wie gebruikt niet de privé verbinding om bij de zaak in te loggen. Al met al is het niet slim om zulke controles te slopen op het hedendaagse internet...

@Henk van de Kamer : Ik begrijp het. Kun jij je profiel aanvullen en hier een seintje geven. Ik ga je niet onnodig topics laten aanmaken op het telfort forum en zal achter de schermen een telfort collega vragen om je gegevens er bij te zoeken. 

hvdkamer@obelix:~$ dig xxx.xxx.80.86.in-addr.arpa ptr
...
;; ANSWER SECTION:
xxx.xxx.80.86.in-addr.arpa. 86400 IN PTR ip5650xxxx.speed.planet.nl.

hvdkamer@obelix:~$ dig ip5650xxxx.speed.planet.nl a
...
;; ANSWER SECTION:
ip5650xxxx.speed.planet.nl. 86288 IN A 86.80.xxx.xxx

Als het dan ook nog voor ipxxxxxxxx.adsl-surfen.hetnet.nl opgelost kan worden dan houd ik me aanbevolen. @Erwin_, @Erik_, @Dennis ABD?!

Eerlijk gezegd geloof ik daar niet zo in. Ik heb hier zelf ooit eens zo’n internet worm binnen gehad middels random code injection in PHP en die dingen zitten best vernuftig in elkaar. Even heel simplistisch: als jij het PTR record kan opvragen, dan kan die worm dat ook. De voornaamste kracht van deze methode en zoals bijvoorbeeld Outlook-365 dat ook inzet, is dat generieke namen waar het IP adres in is verwerkt automatisch op de blacklist belanden. Dat houdt in dat zelfs wanneer ik alles helemaal volgens de regels instel, ik nog steeds niet rechtstreeks met 365 servers kan communiceren. Dat lukt uitsluitend via de KPN relay die daarmee de verantwoordelijkheid in de schoenen geworpen krijgt om te controleren of ik niet een bepaalde verzendfrequentie overschrijdt.

Maar goed, ik begrijp dat de A records weer teruggegeven worden en dat ik de identificatie in mijn email server dus weer conform de RFC norm mag instellen. Mijn dank is, nu ja, naar proportie zullen we maar zeggen. Ik heb in ieder geval voor de zekerheid maar een backup MX record aangemaakt op basis van mijn eigen domeinnaam. Mocht mijn aansluiting op enig moment als dynamisch zijn aangemerkt, dan wens ik daar nog wel contact over aangezien dat niet is waarvoor ik indertijd heb getekend en ten behoeve waarvan ik ook al eens een lucratief aanbod van een concurrent heb afgewezen. Een onaangekondigde wijziging van mijn IP adres zou tevens inhouden dat ik wordt uitgesloten van door mijzelf beheerde machines elders op het internet, dus dit is zeker geen kleinigheidje!

Beetje off-topic, maar ... ik vraag mn eigen af of het verstandig is om machines zo te configureren. Kan wel zo wezen dat je toendertijd getekend hebt voor een vast ip. Maar het kan verbolgens later ook zo zijn dat die afspraak opeens niet meer nagekomen word. Om 1 of andere reden. Kabelbreuk bijboorbeeld, die heel lang duurt voordat die opgelost is. U krijgt een noodpakket en daarbij dus ook een ander ip. Wat moet je dan?

@Dennis ABD hij werkt voor mij ook weer, bedankt!

Is er nog enige feedback hoe dit heeft kunnen gebeuren, en hoe voorkomen gaat worden dat dit weer eventueel gebeurt?

En hoe zit het met een eventuele vergoeding hiervoor? Ik vind enige compensatie eigenlijk niet meer dan terecht.

Zet voor de gein maar eens een ssh poort open zonder IP restricties. Dat is letterlijk vliegen op de stroop, vaak heb je binnen de eerste 5 minuten al zeker duizend inlogpogingen gehad. Vinden ze overigens ook leuk op de smtp poort, maar daar wordt wat minder fanatiek op ingehakt.

Eh… ja… Maar dat vereist dus wel dat je ervan op de hoogte bent dat je een dynamisch toegekend IP adres hebt. Dat is nooit van toepassing geweest omdat het aanbod een vast IP adres betrof. Zoals gezegd heb ik nooit aanleiding gezien om dat in twijfel te trekken.

Ik ben me echt wel bewust van hoe dat soort systemen werken. En wat jij noemt klinkt niet bepaald realistisch. Dat probleem heb ik nog nooit gehad, en heb ook gewoon poorten openstaan zonder problemen. Er zullen altijd bots zijn die continue IP-adressen scannen en acties op poorten proberen uit te voeren.

Zet voor de grap maar es een webserver neer en kijk wat voor idiote dingen je daar in de access log wel niet voorbij ziet komen. Zolang je systeem echter gewoon veilig is, is er niks aan de hand.

Overigens, als je je echt zo druk maakt om hackers die op je SSH weten in te breken, dan zou ik gewoon SSH-keys gaan gebruiken ipv een user/pass combinatie. Ik wens ze veel success met die te kraken.

Maar zet dan ook maar gelijk de WPS op je access point uit, anders hebben al deze acties alsnog geen enkel nut, en zit er zo iemand die dat wil alsnog in je netwerk.