[mijn.host] Ervaringen & Discussie

[Oon]

Ruzor schreef op woensdag 8 april 2026 @ 13:28:
[...]

Naast dat heeft mailbox ook een sterke focus op beveiling:
https://mailbox.org/en/why-mailbox/

Dat zijn allemaal marketingpraatjes, alles dat ze noemen is vrij standaard

[Ruzor]

Oon schreef op woensdag 8 april 2026 @ 13:30:
[...]

Dat zijn allemaal marketingpraatjes, alles dat ze noemen is vrij standaard

Ja? Ik zie de meeste zaken anders niet in het overzicht van mijn.host:
https://mijn.host/e-mail-hosting/

Kijk vooral hier eens:
https://mailbox.org/en/security/

[ Voor 13% gewijzigd door Ruzor op 08-04-2026 13:42 ]

[Oon]

Ruzor schreef op woensdag 8 april 2026 @ 13:39:
[...]

Ja? Ik zie de meeste zaken anders niet in het overzicht van mijn.host:
https://mijn.host/e-mail-hosting/

Kijk vooral hier eens:
https://mailbox.org/en/security/

Ja, nogmaals, als iemand die jarenlang een eigen mailserver heeft gehost en recent is overgestapt naar shared hosting, dit zijn allemaal standaard dingen. Misschien een handjevol die optioneel zijn, maar ze doen echt niks heel spannends.
Puur marketing dus.

[Ruzor]

Oon schreef op woensdag 8 april 2026 @ 13:49:
[...]

Ja, nogmaals, als iemand die jarenlang een eigen mailserver heeft gehost en recent is overgestapt naar shared hosting, dit zijn allemaal standaard dingen. Misschien een handjevol die optioneel zijn, maar ze doen echt niks heel spannends.
Puur marketing dus.

Moet zeggen dat ik zaken zoals:

• Anonymous registration
• Anonymous payment options by cash, by post, or by cash deposit into a bank account
• Clearly communicated storage and deletion periods for log files and connection data
• Anonymised mail headers that do not contain user information about IP addresses or software used

Nog niet veel ergens anders ben tegengekomen. Denk ook dat dat ze onderscheid van bijvoorbeeld een mijn.host. Kun je daar überhaupt 2FA of bijvoorbeeld PGP en S/MIME op de mailbox instellen?

De vergelijking ging namelijk tussen mailhosting van mijn.host en mailbox.

[dbzokphp]

Ik heb dit kunnen vinden: https://mijn.host/blog/nieuwe-webmail-live/

Dus o.a:
🔐 OpenPGP Encryptie
🔢 2FA ondersteuning

Gelijk even ingelogd op de webmail omgeving en zie dat deze features er inderdaad inzitten.
S/MIME kan ik niet vinden. Je kan dat wel gewoon gebruiken in een mailapplicatie die dit ondersteund natuurlijk, maar in de webmail zie ik hier geen ondersteuning voor.

[mdlaat]

Hi
Ik overweeg een aantal domeinen te verhuizen naar mijn.host.

Ik begrijp dat ik (middels een template) de DNS bij mijn.host kan instellen voordat de verhuizing in werking gaat. Zo kan ik downtime voorkomen.

Ik zie het niet, maar misschien kijk ik er overheen: is er een mogelijkheid om een bestaande zonefile in een template in te lezen? Daarmee zou ik bij een zonefile met veel records, manuele fouten kunnen voorkomen en tijd besparen.

Dank!

[idef1x]

Zit net even te kijken, maar ik zie wel een optie om een template toe te passen, maar niet hoe deze dan te maken. Ik kan wel de zonefile bewerken. Wellicht heb je daar wat aan?

[neokarasu]

mdlaat schreef op vrijdag 24 april 2026 @ 22:35:
Ik zie het niet, maar misschien kijk ik er overheen: is er een mogelijkheid om een bestaande zonefile in een template in te lezen? Daarmee zou ik bij een zonefile met veel records, manuele fouten kunnen voorkomen en tijd besparen.

Zo te zien heb je bij de Zonefile Bewerken optie wel de mogelijkheid om een gehele zone erin te plakken (in het BIND zonefile formaat), maar dat is dus voor een domein dat al bij ze staat.

Maar vreemd genoeg heb je bij het aanmaken van een template die optie weer niet.
Bij het aanmaken van een template tonen ze alleen de mogelijkheid het handmatig record per record in te voeren. Zou een mooie feature zijn als ze wel het inladen van zonefiles voor templates gaan ondersteunen, net als voor individuele domeinen.

Wellicht dat je met hun support contact op kan nemen om te zien of ze toch een verborgen optie hebben of dat zij het handmatig voor je kunnen inladen.

[Room42]

Tip: Zodra je een domein hebt gekocht bij mijn.host voor verhuizing, kun je hem al vinden in het control panel en kun je de DNS-records bewerken. Zo kun je alle records voorbereiden voordat je de verhuiscode opgeeft en komt het domein dus in een warm bedje.

[ Voor 6% gewijzigd door Room42 op 25-04-2026 10:07 ]

[Nachtkastje]

Het is inderdaad niet mogelijk om een file in te laden helaas, ook niet binnen DirectAdmin (mocht je gebruik maken van hun hosting). Maar wat @Room42 al zegt, je kan het domeinnaam verhuizen en daarna gelijk de DNS-recrords goed zetten.

DNS heeft toch minimaal 30 min nodig om te wijzigen (vaak zelfs langer) dus het verkeer zal er niks van merken

[Nachtkastje]

dbzokphp schreef op woensdag 8 april 2026 @ 14:48:
Ik heb dit kunnen vinden: https://mijn.host/blog/nieuwe-webmail-live/

Dus o.a:
🔐 OpenPGP Encryptie
🔢 2FA ondersteuning

Gelijk even ingelogd op de webmail omgeving en zie dat deze features er inderdaad inzitten.
S/MIME kan ik niet vinden. Je kan dat wel gewoon gebruiken in een mailapplicatie die dit ondersteund natuurlijk, maar in de webmail zie ik hier geen ondersteuning voor.

Momenteel zit er geen S/MIME in de huidige Roundcube versie (althans versie van mijn S10 server draait op 1.6.11) maar in de nieuwe releases van Roundcube is het wel aanwezig. Dit zijn nog beta versies dus zal verklaren waarom de Roundcube versie nog niet geupdated is.

Komt er aan dus

[Room42]

Nachtkastje schreef op zaterdag 25 april 2026 @ 10:08:
[...]
DNS heeft toch minimaal 30 min nodig om te wijzigen (vaak zelfs langer) dus het verkeer zal er niks van merken

Dat valt mee, vooral als je de TTL laag hebt staan. Kan echt in een knip gebeurd zijn.

[Nachtkastje]

Room42 schreef op zaterdag 25 april 2026 @ 12:52:
[...]

Dat valt mee, vooral als je de TTL laag hebt staan. Kan echt in een knip gebeurd zijn.

Zeker waar, maar domeinnaam verhuizen is vaak ook andere nameservers en die hebben vaak weer hogere TTL

[Room42]

Nachtkastje schreef op zaterdag 25 april 2026 @ 12:53:
[...]

Zeker waar, maar domeinnaam verhuizen is vaak ook andere nameservers en die hebben vaak weer hogere TTL

Maar ook daar kun je net op het moment van het verlopen van de TTL checken en dus direct frisse records krijgen. Hoe dan ook, daar kun je niet op vertrouwen als je een 100% uptime wilt.

[mdlaat]

idef1x schreef op zaterdag 25 april 2026 @ 00:20:
Zit net even te kijken, maar ik zie wel een optie om een template toe te passen, maar niet hoe deze dan te maken. Ik kan wel de zonefile bewerken. Wellicht heb je daar wat aan?

Nee, dat bedoelde ik niet. Het gaat mij erom dat ik niet met handje alle bestaande dns records in wil kloppen. Dan kan ik er gemakkelijk eentje overslaan, of een tiepfout maken. En het is saai werk. Van het eerste domein waar ik mee aan de slag wil heeft de bind zonefile net geen 100 regels. Ik zoek dus een automatische mogelijkheid.

En, @Room42 en @Nachtkastje:
Nee, volgens mij kun je dan te laat zijn. Eenmaal domein gekocht voor verhuizing kunnen er al dns requests naar de nieuwe nameservers gaan. Bovendien zit ik dan nog steeds handmatig een hoop records aan te passen, met kans op fouten.

neokarasu schreef op zaterdag 25 april 2026 @ 00:36:
[...]


Zo te zien heb je bij de Zonefile Bewerken optie wel de mogelijkheid om een gehele zone erin te plakken (in het BIND zonefile formaat), maar dat is dus voor een domein dat al bij ze staat.

Maar vreemd genoeg heb je bij het aanmaken van een template die optie weer niet.
Bij het aanmaken van een template tonen ze alleen de mogelijkheid het handmatig record per record in te voeren. Zou een mooie feature zijn als ze wel het inladen van zonefiles voor templates gaan ondersteunen, net als voor individuele domeinen.

Wellicht dat je met hun support contact op kan nemen om te zien of ze toch een verborgen optie hebben of dat zij het handmatig voor je kunnen inladen.

Ah kijk. Dat lijkt de beste optie inderdaad. Ik heb nog geen domeinen bij ze, dus wist ook nog niet dat ik voor een bestaand domein een zonefile in kan laden. Ik ga het support vragen of ze dat ook voor een template mogelijk willen maken.

Thx allen!

[mdlaat]

Wauw, wat een superservice en snelle reactie van mijn.host! Op een niet werkdag notabene!
31 minuten na mijn vraag hebben ze de mogelijkheid van zonefile bewerken/uploaden aan een template toegevoegd.

Het door mijn.host gewenste formaat is niet exact gelijk aan een bind zonefile, maar dat is een minor detail en simpel aan mijn kant aan te passen.

[BaSsDruM]

Nog meer mensen die problemen ondervinden bij mail welke bij mijn.host draait?

[Wom]

Merk ik niks van. Verzenden en ontvangen op meerdere inboxen geen probleem.

[BaSsDruM]

Wom schreef op zondag 17 mei 2026 @ 22:49:
Merk ik niks van. Verzenden en ontvangen op meerdere inboxen geen probleem.

Thnx, dan lijkt er iets met mijn account aan de hand ofzo. Dan wacht ik wel tot morgenochtend tot mijn.host mij duidelijkheid kan geven waarom de mail van al m'n domeinen daar niet meer werkt.

Zelfs als ik de webmail benader op https://s1.webhost.company/roundcube/ en ik vul dan mijn emailadres in en ik tik als wachtwoord iets randoms in ipv m'n correcte wachtwoord krijg ik "Connection to storage server failed"

Aanvulling: ik had een tijdelijke ip blokkade blijkbaar door een (vermoedelijk) verkeerd ww wat door een client werd gebruikt.

[ Voor 49% gewijzigd door BaSsDruM op 17-05-2026 23:07 ]

[Room42]

Ik krijg net een mail van mijn.host over phishing mails die lijken alsof ze van mijn.host zijn:

We willen je waarschuwen voor een phishingmail die op dit moment in onze naam wordt rondgestuurd. De mail doet zich voor als afkomstig van mijn.host en wordt verstuurd naar info@-adressen van klantdomeinen. Mogelijk heb je deze mail dus al ontvangen. 

Hoe herken je de phishingmail?

•  De mail komt binnen op een info@-adres van een van je domeinen, in plaats van op je gebruikelijke contactadres.

•  De afzender is niet een adres van @mijn.host, maar een willekeurig ander domein.

•  In de mail staat een knop of link die leidt naar een nagemaakte loginpagina. Daar worden je inloggegevens buitgemaakt. 

Wat moet je doen?

•  Klik niet op de link in die mail en vul nergens je inloggegevens in.

•  Log alleen in via onze officiële URL: https://mijn.host/cp/. Controleer altijd of de URL in de adresbalk exact mijn.host is voordat je je gegevens invult.

•  Verwijder de mail of stuur hem door naar [e-mail] als je twijfelt. 

We hebben direct extra beveiligingsmaatregelen genomen
Om misbruik van eventueel buitgemaakte gegevens te voorkomen, hebben we de beveiliging van inloggen verscherpt. Klanten die geen tweestapsverificatie (2FA) hebben ingesteld, moeten hun login vanaf nu extra verifiëren via een code per SMS. Je ontvangt deze code automatisch op het telefoonnummer dat bij je account bekend is. 

Heb je geen toegang meer tot het telefoonnummer dat bij je account bekend is en lukt het inloggen daardoor niet? Neem dan contact op met onze support via [e-mail], dan helpen we je verder. 

Tip: zet 2FA aan voor je account
Heb je nog geen tweestapsverificatie (2FA) ingesteld, dan adviseren we met klem om dit alsnog te doen. Dat is de sterkste bescherming tegen phishing en ongewenste toegang. Je kunt 2FA inschakelen in je account via https://mijn.host/cp/account/profile/.

Heb je al op de link geklikt en je gegevens ingevuld?
Onderneem dan zo snel mogelijk de volgende stappen:

•  Wijzig direct je wachtwoord in je account via https://mijn.host/cp/account/profile/.

•  Schakel 2FA in als je dat nog niet had.

•  Controleer je account op verdachte wijzigingen: nieuwe API-keys, gewijzigde contactgegevens, extra gebruikers of onbekende bestellingen.

•  Gebruikte je hetzelfde wachtwoord ook op andere websites? Wijzig het daar dan ook.

•  Twijfel je of zie je iets dat niet klopt? Neem direct contact op met [e-mail]. 

Goed om te weten
mijn.host vraagt nooit per e-mail, telefoon of chat om je wachtwoord, 2FA-code of andere inloggegevens. Krijg je daar wel een verzoek voor, dan is het sowieso niet van ons. 

Phishingcampagnes komen vaak in golven terug, soms via een andere afzender of met een iets andere boodschap. Blijf dus alert op verdachte mails in onze naam. 

Heb je vragen over deze melding of twijfel je over een mail die je hebt ontvangen, neem dan gerust contact op met onze support.
Je kunt ons iedere dag bereiken per e-mail op [e-mail].

[IceBlackz]

Ah, wil hem net al hier posten en aan mijn.host vragen, we hebben inderdaad voor al onze domeinen het onderstaande phishing bericht gehad. Gelukkig was mijn vrouw helder genoeg om het niet te vertrouwen, op de portal zelf was netjes te zien dat we recent al hebben verlengd..

[idef1x]

ik heb hem ook gehad. Het mailadres van mij klopte al niet en zag ik het aan meerdere email adressen per domein verstuurd.

[rvk]

Heel 'handig'. Want ik kan nu met 3 accounts niet meer inloggen bij mijn.host omdat ze 'geen sms kunnen versturen', probeer het later nog eens.

[mijn.host]

Er gaan inderdaad phishingmails rond die uit naam van mijn.host worden verstuurd. Hierin wordt gevraagd om je inloggegevens, en in sommige gevallen ook om creditcardgegevens.

We hebben onze klanten inmiddels per e-mail op de hoogte gebracht en hiervoor gewaarschuwd.

Omdat wij niet kunnen zien welke klanten hun gegevens wel hebben gedeeld, hebben we extra veiligheidsmaatregelen moeten nemen voor klanten die geen 2FA actief hebben. Deze klanten ontvangen voortaan een SMS-code voor extra verificatie.

We begrijpen dat deze extra stap vervelend kan zijn, maar we willen voorkomen dat onze klanten enig risico lopen. Wanneer kwaadwillenden toegang krijgen tot je account, kunnen de gevolgen namelijk groot zijn.

Mocht je geen SMS-code ontvangen, neem even contact op met onze support. We herstellen de toegang dan direct voor je.

[idef1x]

mijn.host schreef op maandag 18 mei 2026 @ 08:57:
We hebben onze klanten inmiddels per e-mail op de hoogte gebracht en hiervoor gewaarschuwd.

Kennelijk nog niet alle klanten, want ik heb nog geen e-mail van jullie ontvangen?

[mijn.host]

@idef1x ik hoor zojuist van mijn collega dat een deel van de e-mails nog in de queue staan. Uiterlijk deze ochtend zou iedereen op de hoogte gebracht moeten zijn.

[Room42]

IceBlackz schreef op maandag 18 mei 2026 @ 08:14:
Ah, wil hem net al hier posten en aan mijn.host vragen, we hebben inderdaad voor al onze domeinen het onderstaande phishing bericht gehad. Gelukkig was mijn vrouw helder genoeg om het niet te vertrouwen, op de portal zelf was netjes te zien dat we recent al hebben verlengd..

[Afbeelding]

Dit was al de allereerste rode vlag die je direct tot het verwijderen van de mail had moeten zetten:


Daarmee weet je in ieder geval ook meteen dat mijn.host er niks aan kan doen. Dit is geen domein dat onder hun controle ligt. Mogelijk dat er wel een lek is geweest waardoor ze mijn.host klantadressen kunnen achterhalen? (@mijn.host ?)

[ Voor 12% gewijzigd door Room42 op 18-05-2026 09:18 ]

[Drardollan]

Ik zet met tegenzin een zeer kritische noot bij deze phising mails.

Heb ze ook ontvangen. Op domeinen die helemaal niet geregistreerd zijn bij mijn.host. De hosting draait wel bij mijn.host, maar dat is het dan ook.

Maak mij dan ook oprecht zorgen over de bron van de informatie, dat is niet een simpele whois geweest zoals ik eerst dacht. Blijkbaar een scan op wat er achter een IP hangt, maar het is goed dat mijn.host ook een onderzoek gestart is.

[ Voor 35% gewijzigd door Drardollan op 18-05-2026 10:17 ]

[IceBlackz]

Room42 schreef op maandag 18 mei 2026 @ 09:16:
[...]

Dit was al de allereerste rode vlag die je direct tot het verwijderen van de mail had moeten zetten:
[Afbeelding]

Daarmee weet je in ieder geval ook meteen dat mijn.host er niks aan kan doen. Dit is geen domein dat onder hun controle ligt. Mogelijk dat er wel een lek is geweest waardoor ze mijn.host klantadressen kunnen achterhalen? (@mijn.host ?)

Klopt, maar in de gauwigheid en via een app op mobiel kan zit zomaar 'echt' lijken.

Wat ze volgens mij doen is expiry datums van een domein opzoeken, en dan simpelweg naar info@domein versturen. Voor mij geen indicatie van een lek.

[Drardollan]

IceBlackz schreef op maandag 18 mei 2026 @ 09:31:
[...]

Klopt, maar in de gauwigheid en via een app op mobiel kan zit zomaar 'echt' lijken.

Wat ze volgens mij doen is expiry datums van een domein opzoeken, en dan simpelweg naar info@domein versturen. Voor mij geen indicatie van een lek.

Mijn domeinen bevatten geen whois info naar mijn.host.

Ik krijg ze op domeinen waarvan de expire date helemaal niet publiekelijk bekend is. Maar dat zegt niet zoveel, want de expire date die genoemd wordt in de mail is dan weer niet juist. Die staat volgens mij bewust op 29-5 (gok in alle mails) om de druk van 14 dagen erop te leggen bij mensen.

[ Voor 36% gewijzigd door Drardollan op 18-05-2026 10:17 ]

[DBreda]

Dit is een van de weinige spam waarbij ik echt even enkele seconden moest kijken, zo goed zag de mail eruit.

[Oon]

Drardollan schreef op maandag 18 mei 2026 @ 09:25:
Ik zet met tegenzin een zeer kritische noot bij deze phising mails. Mijn gevoel zegt dat er iets niet klopt en mijn gevoel zit op dit soort gebieden vaak goed.

Heb ze ook ontvangen. Op domeinen die helemaal niet geregistreerd zijn bij mijn.host. De hosting draait wel bij mijn.host, maar dat is het dan ook.

Maak mij dan ook oprecht zorgen over de bron van de informatie, dat is niet een simpele whois geweest zoals ik eerst dacht. Alles wijst erop dat er een systeem gehacked is bij mijn.host ergens. Ook de opzet van de e-mails is te professioneel voor een simpele phising aanval waarvan we er 1001 zien in een week. Het ziet er allemaal bijzonder gericht en doordacht uit.

Gaat dadelijk ook een mail richting mijn.host en ben zeer benieuwd naar de reactie.

Ik vind het allemaal wel meevallen, de mails zijn niet foutloos en ze hebben niet eens de moeite gedaan om een domeinaam die lijkt op mijn.host te gebruiken als afzender.
Ze hebben gewoon mails naar info@ adressen gestuurd van de domeinnamen waarvan de whois zegt dat ze bij mijn.host staan, kan goed een geautomatiseerde scan zijn en dan gokken.

IceBlackz schreef op maandag 18 mei 2026 @ 09:31:
[...]

Klopt, maar in de gauwigheid en via een app op mobiel kan zit zomaar 'echt' lijken.

Wat ze volgens mij doen is expiry datums van een domein opzoeken, en dan simpelweg naar info@domein versturen. Voor mij geen indicatie van een lek.

Niet eens, ze hebben alleen gekeken naar welke registrar in de whois stond. De domeinnamen waar ik mails op heb ontvangen (alleen via catch-all, want info@ voor die domeinnamen bestaat helemaal niet) verlopen pas ergens volgend jaar.

[Drardollan]

Oon schreef op maandag 18 mei 2026 @ 09:34:
[...]

Ik vind het allemaal wel meevallen, de mails zijn niet foutloos en ze hebben niet eens de moeite gedaan om een domeinaam die lijkt op mijn.host te gebruiken als afzender.

Er is moeite genoeg voor gedaan, ik zie ze zelden zo professioneel als deze. En ik zie er behoorlijk wat per jaar.

Ze hebben gewoon mails naar info@ adressen gestuurd van de domeinnamen waarvan de whois zegt dat ze bij mijn.host staan, kan goed een geautomatiseerde scan zijn en dan gokken.

Dat kan dus niet mijn inziens. Ik krijg ze op domeinen die helemaal niet bij mijn.host geregistreerd zijn en dus geen whois informatie hebben die daarop wijst.

[mijn.host]

We hebben geen concrete signalen dat er een lek is geweest. We zijn dit nog aan het uitzoeken om het te kunnen bevestigen, maar het lijkt er (gelukkig) niet op.

Op basis van de informatie die we nu hebben lijkt het volgende te zijn gebeurd:

1. Een kwaadwillende heeft domeinnamen van klanten verzameld via reverse IP-lookups. Doordat meerdere domeinen op hetzelfde IP-adres worden gehost, is publiekelijk te achterhalen welke domeinen op één IP-adres staan.
2. Vervolgens stuurt deze partij phishingmails naar info@ of vergelijkbare standaardadressen van die domeinnamen, in de hoop dat het adres bestaat en de mail daadwerkelijk aankomt.

Het lijkt erop dat de phishing campagne gisteravond is gestart. Gezien dit pas zo recent speelt zijn wij hier uiteraard nog druk mee bezig.

[Drardollan]

DBreda schreef op maandag 18 mei 2026 @ 09:33:
Dit is een van de weinige spam waarbij ik echt even enkele seconden moest kijken, zo goed zag de mail eruit.

Ik ook. Was natuurlijk gewaarschuwd dus dat kijkt makkelijk. Er zitten wel wat schoonheidsfoutjes in, maar de opmaak en inhoud van de mail is bedrieglijk echt.

[rvk]

Oon schreef op maandag 18 mei 2026 @ 09:34:
[...]

Ik vind het allemaal wel meevallen, de mails zijn niet foutloos en ze hebben niet eens de moeite gedaan om een domeinaam die lijkt op mijn.host te gebruiken als afzender.

Bij mij zat ie in de spambox. Je zou overigens inderdaad verwachten, als ze de moeite doen om een login-website na te maken (ik heb niet gekeken maar neem aan dat de link naar zo'n website gaat) ze ook de [e-mail] zouden gebruiken. Maar misschien weten ze dat die vaak niet door de spamfilter komt omdat de DKIM dan niet klopt (en ja, die hing eraan). Bij mij kwam ie overigens alleen in de spambox doordat ie door "France" heen ging (waardoor er bij mij een hogere waarde aan hing).

[Drardollan]

mijn.host schreef op maandag 18 mei 2026 @ 09:37:
We hebben geen concrete signalen dat er een lek is geweest. We zijn dit nog aan het uitzoeken om het te kunnen bevestigen, maar het lijkt er (gelukkig) niet op.

Op basis van de informatie die we nu hebben lijkt het volgende te zijn gebeurd:

1. Een kwaadwillende heeft domeinnamen van klanten verzameld via reverse IP-lookups. Doordat meerdere domeinen op hetzelfde IP-adres worden gehost, is publiekelijk te achterhalen welke domeinen op één IP-adres staan.
2. Vervolgens stuurt deze partij phishingmails naar info@ of vergelijkbare standaardadressen van die domeinnamen, in de hoop dat het adres bestaat en de mail daadwerkelijk aankomt.

Het lijkt erop dat de phishing campagne gisteravond is gestart. Gezien dit pas zo recent speelt zijn wij hier uiteraard nog druk mee bezig.

Ik geef jullie sowieso het voordeel van de twijfel en hoop dat het klopt wat jullie onderzoek oplevert. Maar ik maak mij oprecht zorgen, ik heb de mails gezien voor domeinen die allemaal op andere servers (IP adressen) staan bij jullie. Dit moet een mega verzameling geweest zijn, iets wat je niet vaak ziet. En ook redelijk recent, ik heb ze van domeinen gezien die amper 2 weken webhosting hebben bij jullie.

[ Voor 11% gewijzigd door Drardollan op 18-05-2026 09:49 ]

[CubicQ]

Ik heb voor het domein naam die ik via mijn.host heb geregistreerd waarbij:

- A DNS wijst naar een IP adres van mijn.host (5.254.117.41)
- MX DNS wijst naar een andere partij
- Er geen web hosting is

(nog) geen phishing mail ontvangen.

[Verwijderd]

Hier inderdaad ook mails ontvangen. In eerste instantie hebben ze geprobeerd om het te sturen naar info@domeinnaam te sturen, maar die heb ik standaard uitstaan. Later zag ik zelfde afzender voorbijkomen op kontakt@domeinnaam. Overigens werd bij mij tot nog toe slechts 1 domein geraakt, terwijl ik er meerdere bij mijn.host heb. En via de dns-instellingen meerdere subdomeinen.

[Drardollan]

Verwijderd schreef op maandag 18 mei 2026 @ 09:48:
Hier inderdaad ook mails ontvangen. In eerste instantie hebben ze geprobeerd om het te sturen naar info@domeinnaam te sturen, maar die heb ik standaard uitstaan. Later zag ik zelfde afzender voorbijkomen op kontakt@domeinnaam. Overigens werd bij mij tot nog toe slechts 1 domein geraakt, terwijl ik er meerdere bij mijn.host heb. En via de dns-instellingen meerdere subdomeinen.

De kontakt kwam hier ook voorbij, dat is typisch iets wat in Duitsland veel gebruikt wordt. Maar niet iets waar ik vaak spam op krijg eigenlijk omdat het wereldwijd niet veel gebruikt wordt.

[idef1x]

mijn.host schreef op maandag 18 mei 2026 @ 09:16:
@idef1x ik hoor zojuist van mijn collega dat een deel van de e-mails nog in de queue staan. Uiterlijk deze ochtend zou iedereen op de hoogte gebracht moeten zijn.

Nu wel gehad inderdaad!
Overigens ik kreeg de phishing ook op kotakt@<mijn domein>

[ Voor 8% gewijzigd door idef1x op 18-05-2026 09:54 ]

[Drardollan]

idef1x schreef op maandag 18 mei 2026 @ 09:52:
[...]

Nu wel gehad inderdaad!
Overigens ik kreeg de phishing ook op kotakt@<mijn domein>

Heb hier wat spamfilters gechecked en zie ze enkel naar info@ en kontakt@ gaan. Dat zegt niets over de hele run, maar het lijkt wel beperkt tot. Wel een gekke keuze, kontakt@ is niet echt een standaard adres voor Nederlanders. Denk dat de boefjes denken dat DE en NL hetzelfde land zijn, zoals wel vaker gebeurd in de wereld.

[krakendmodem]

HIer ook de mail ontvangen, echter is de domeinnaam zelf bij Transip in beheer. De mailserver wijst dan weer naar mijn.host. Ik had dus redelijk snel in de gaten dat de mail niet klopte, maar moest inderdaad even 2 keer kijken.

[Drardollan]

Ondertussen de legitieme mail van mijn.host zelf tweemaal ontvangen.

[ Voor 3% gewijzigd door Drardollan op 18-05-2026 10:21 ]

[RobertMe]

mijn.host schreef op maandag 18 mei 2026 @ 09:37:
Een kwaadwillende heeft domeinnamen van klanten verzameld via reverse IP-lookups. Doordat meerdere domeinen op hetzelfde IP-adres worden gehost, is publiekelijk te achterhalen welke domeinen op één IP-adres staan

Een reverse lookup verwijst normaliter toch vaak naar een server naam? En niet naar een klant-domeinnaam. Zeker in het geval van shared hosting. Hoe bepalen jullie dan welke klant-domeinnaam aan een server gekoppeld worden als er natuurlijk meerdere klanten / hosting pakketten op één server / IP actief zijn?
Reverse DNS met een "echte" domeinnaam is bij mijn weten iets dat normaliter alleen bij mail vereist is en daarmee juist iets is dat een eindgebruiker / klant alleen instelt bij een VPS waarbij de klant ook daadwerkelijk "eigenaar" van het IP adres is (/het IP huurt). Maar bij shared hosting is er natuurlijk ook geen "eigendom" van het IP en zou het raar zijn dat als pietje.nl en klaasje.nl die op dezelfde server draaien ineens een PTR record "pietje.nl" (of "klaasje.nl") hebben i.p.v. "server1337.mijn.host".

Edit:

$ dig -x 5.254.117.41 +short
h41.mijn.host.

Dit dus. Dat is met het IP dat hier eerder vermeld is. Waarbij reverse DNS dus een mijn.host domeinnaam oplevert, en geen domeinnaam van een klant zoals je in de mogelijke verklaring aangeeft.

Enige waarbij reverse DNS zou kunnen werken is AFAIK dan bij VPSen waarbij de klant zelf de reverse DNS entry kan instellen voor het IP. Maar mijn indruk uit de reacties hier is dat ook (/alleen?) klanten met een (shared) hosting pakket getroffen zijn.

Zelf neem ik alleen een domeinnaam af, zelfs de nameservers verwijst ergens anders naar. En geen phishing mail gehad. Ook niks te zien in rspamd dat er aangeklopt zou zijn en hard afgewezen.

[ Voor 24% gewijzigd door RobertMe op 18-05-2026 10:36 ]

[True]

Drardollan schreef op maandag 18 mei 2026 @ 10:21:
Ondertussen de legitieme mail van mijn.host zelf tweemaal ontvangen.

Same, om 1u vannacht en zojuist nog een keer.

[stegosaurus]

mijn.host schreef op maandag 18 mei 2026 @ 09:37:
We hebben geen concrete signalen dat er een lek is geweest. We zijn dit nog aan het uitzoeken om het te kunnen bevestigen, maar het lijkt er (gelukkig) niet op.

Op basis van de informatie die we nu hebben lijkt het volgende te zijn gebeurd:

1. Een kwaadwillende heeft domeinnamen van klanten verzameld via reverse IP-lookups. Doordat meerdere domeinen op hetzelfde IP-adres worden gehost, is publiekelijk te achterhalen welke domeinen op één IP-adres staan.
2. Vervolgens stuurt deze partij phishingmails naar info@ of vergelijkbare standaardadressen van die domeinnamen, in de hoop dat het adres bestaat en de mail daadwerkelijk aankomt.

Het lijkt erop dat de phishing campagne gisteravond is gestart. Gezien dit pas zo recent speelt zijn wij hier uiteraard nog druk mee bezig.

Ik moet eerlijk toegeven dat jullie hier heel transparant én proactief in zijn. Ik zie dat wel eens anders dus ik vind dit heel fijn om te lezen!

[HexaLogic]

RobertMe schreef op maandag 18 mei 2026 @ 10:31:
Een reverse lookup verwijst normaliter toch vaak naar een server naam? En niet naar een klant-domeinnaam.

Ja rDNS lookups wel, die verwijst vaak naar de hostnaam. Maar er zijn online ook tools te vinden die grotendeels alle domeinen op 1 IP kunnen onthullen. Dat wordt vaak Reverse IP Lookup genoemd.

[Nachtkastje]

RobertMe schreef op maandag 18 mei 2026 @ 10:31:
[...]

Een reverse lookup verwijst normaliter toch vaak naar een server naam? En niet naar een klant-domeinnaam. Zeker in het geval van shared hosting. Hoe bepalen jullie dan welke klant-domeinnaam aan een server gekoppeld worden als er natuurlijk meerdere klanten / hosting pakketten op één server / IP actief zijn?
Reverse DNS met een "echte" domeinnaam is bij mijn weten iets dat normaliter alleen bij mail vereist is en daarmee juist iets is dat een eindgebruiker / klant alleen instelt bij een VPS waarbij de klant ook daadwerkelijk "eigenaar" van het IP adres is (/het IP huurt). Maar bij shared hosting is er natuurlijk ook geen "eigendom" van het IP en zou het raar zijn dat als pietje.nl en klaasje.nl die op dezelfde server draaien ineens een PTR record "pietje.nl" (of "klaasje.nl") hebben i.p.v. "server1337.mijn.host".

Edit:

$ dig -x 5.254.117.41 +short
h41.mijn.host.

Dit dus. Dat is met het IP dat hier eerder vermeld is. Waarbij reverse DNS dus een mijn.host domeinnaam oplevert, en geen domeinnaam van een klant zoals je in de mogelijke verklaring aangeeft.

Enige waarbij reverse DNS zou kunnen werken is AFAIK dan bij VPSen waarbij de klant zelf de reverse DNS entry kan instellen voor het IP. Maar mijn indruk uit de reacties hier is dat ook (/alleen?) klanten met een (shared) hosting pakket getroffen zijn.

Zelf neem ik alleen een domeinnaam af, zelfs de nameservers verwijst ergens anders naar. En geen phishing mail gehad. Ook niks te zien in rspamd dat er aangeklopt zou zijn en hard afgewezen.

Als jij het ip-adres van de webserver bij ipinfo.io invult, krijg je alle domeinnamen te zien die hier op gehost zijn. Ook dat zou een manier kunnen zijn geweest om de domeinnamen achter te halen


—

Zelf heb ik alle domeinnamen bij OXXA staan, maar toch kregen alle klanten die ik op mijn.host heb staan een mailtje over het domeinnaam. Klinkt dus echt meer als een bepaalde lookup die gedaan is o.b.v. IP

Websites die achter Cloudflare hangen kregen de mail namelijk niet.

[True]

Ik heb een .nl domein via mijn.host sinds feb. '25 en heb hier geen website op gehost en heb geen phishing mail ontvangen op het mailadres zichtbaar bij een whois lookup, überhaupt geen phishingmail ontvangen.

[idef1x]

Als ik 2FA aan wil zetten in mijn account, krijg ik de melding dat het Token onveilig zou zijn vanwege zwakte cryptografische parameters en dat ik mijn.host hiervoor diende te waarschuwen.....dat dan maar gedaan ;-)

[Turmin]

Ik heb mijn hosting al sinds 2006 bij, toen nog, PcExtreme, nu Versio.
Maar de kosten rijzen de pan uit. Ik begon met 30/40 euro per jaar.
2020-2022 87 euro, 2023 186 euro, 2024 252 euro, 2025 330 euro, 2026 408 euro.
Alleen voor het domein (.com) betaal ik al meer dan 30 euro!

Nadelen zijn ook een eigen CP. Dingen als cronjobs moeten via SSH met bijv Putty en kan niet vanuit de CP. Mails worden niet beantwoord. Ik ga steeds naar Versio delen die niet voor mij toegankelijk zijn omdat ik een "previously pcextreme" klant ben. Handleidingen zijn veroudert en bevatten antwoorden voor Versio, PcExtreme, Neostrada en Flexwebhosting. Dus er zijn nogal wat overnames geweest.

Geen idee waarom ze mij zo graag weg willen jagen, maar per toeval kwam ik op dit topic. Trending vanwege een phisingmail

Waarom ben je niet eerder verhuist?

Ik heb nog al wat data in die 20 jaar verzamelt! Veel subdomeinen, configuraties, databases, etc.
Zijn er binnen mijn.host tools om hiermee te helpen? Of moet ik zelf alles over gaan zetten? Data van FTP naar FTP is wel te doen, databases en mail is iets lastiger.
Ik weet ook niet precies hoeveel GB ik nu in gebruik heb en dus welk pakket ik nodig heb.

Nu heb ik domein (.com), Basic pakket, WHOIS Privacybescherming en kortingscode geselecteerd voor 63,38

[idef1x]

Tsja verhuizen ligt er maar net aan hoe je alles opgebouwd hebt. Ik heb alles nu in containers draaien (incus/docker). Voor mij zou het een kwestie van containers kopieren zijn en klaar. Nou ja en DNS records wijzigen uiteraard ;-)

[PickMeh]

Ik merk op dat ik nu plots ook geen enkele mail meer ontvang op mijn info@domeinnaam adres.

Noch in mijn extrerne mail client, noch in de webmail van mijn.host zelf.

Iemand anders ook eenzelfde ervaring?


Opgelost

[ Voor 7% gewijzigd door PickMeh op 18-05-2026 13:29 ]

[renemax]

mijn.host schreef op maandag 18 mei 2026 @ 09:37:
We hebben geen concrete signalen dat er een lek is geweest. We zijn dit nog aan het uitzoeken om het te kunnen bevestigen, maar het lijkt er (gelukkig) niet op.

Op basis van de informatie die we nu hebben lijkt het volgende te zijn gebeurd:

1. Een kwaadwillende heeft domeinnamen van klanten verzameld via reverse IP-lookups. Doordat meerdere domeinen op hetzelfde IP-adres worden gehost, is publiekelijk te achterhalen welke domeinen op één IP-adres staan.
2. Vervolgens stuurt deze partij phishingmails naar info@ of vergelijkbare standaardadressen van die domeinnamen, in de hoop dat het adres bestaat en de mail daadwerkelijk aankomt.

Het lijkt erop dat de phishing campagne gisteravond is gestart. Gezien dit pas zo recent speelt zijn wij hier uiteraard nog druk mee bezig.

Ik maak enkel gebruik van mijn.host voor e-mails en heb geen info@ een standaard mailadres. Toch heb ik die phishing-mail ook gehad.

Ik ben het eens met die andere gebruiker hier, ik vermoed ook een ander lek. Dit lijkt mij niet enkel via een whois.

[D4NG3R]

Maar deze meuk komt (kwam?) dus vrijwel uitsluitend binnen op 'standaard' adressen als info@ ?

Dat zal verklaren waarom ik ze zelf niet langs zag komen, op wat generieke spam na (thanks Odido ) ook niks wat er in de spamfilter is blijven hangen.

[mijn.host]

renemax schreef op maandag 18 mei 2026 @ 13:17:

Ik maak enkel gebruik van mijn.host voor e-mails en heb geen info@ een standaard mailadres. Toch heb ik die phishing-mail ook gehad.

Zou je de betreffende domeinnaam in een bericht naar onze support kunnen doorsturen? Dat helpt ons bij het onderzoek.

Als het MX-record van de betreffende domeinnaam naar onze servers zou verwijzen zou dat het verklaren. Maar we zoeken het graag verder uit.

Nogmaals, er zijn geen aanwijzingen dat er een datalek heeft plaatsgevonden. We onderzoeken dit nog wel.

[Verwijderd]

renemax schreef op maandag 18 mei 2026 @ 13:17:
[...]

Ik maak enkel gebruik van mijn.host voor e-mails en heb geen info@ een standaard mailadres. Toch heb ik die phishing-mail ook gehad.

Ik ben het eens met die andere gebruiker hier, ik vermoed ook een ander lek. Dit lijkt mij niet enkel via een whois.

Ik gebruik ook geen info@ en kontakt@ voor mijn domeinnamen. Toch kwamen hier vannacht vanaf hetzelfde mailadres mails op binnen. Overigens nog steeds op slechts 1 domein. Andere domeinen lijken buiten schot te zijn gebleven. Ik heb alleen domeinnamen bij mijn.host staan.

[renemax]

Er was tijdig gereageerd i.i.g. en sowieso goed voor mensen/klanten om 2fa in te schakelen. Goed dat dit nu verplicht wordt.

Zal ik doen, maar ik ben er verder niet ingetrapt. Ik hou altijd mijn muis op een button of link in een 'verdacht'-mailtje en check dan de url waar het naar toe wijst. Zag al gelijk een rare url.

Verder zag de mail er wel heel professioneel uit.

[renemax]

mijn.host schreef op maandag 18 mei 2026 @ 13:29:
[...]

Zou je de betreffende domeinnaam in een bericht naar onze support kunnen doorsturen? Dat helpt ons bij het onderzoek.

Als het MX-record van de betreffende domeinnaam naar onze servers zou verwijzen zou dat het verklaren. Maar we zoeken het graag verder uit.

Nogmaals, er zijn geen aanwijzingen dat er een datalek heeft plaatsgevonden. We onderzoeken dit nog wel.

Er was tijdig gereageerd i.i.g. en sowieso goed voor mensen/klanten om 2fa in te schakelen. Goed dat dit nu verplicht wordt.

Zal ik doen, maar ik ben er verder niet ingetrapt. Ik hou altijd mijn muis op een button of link in een 'verdacht'-mailtje en check dan de url waar het naar toe wijst. Zag al gelijk een rare url.

Verder zag de mail er wel heel professioneel uit.

[Diederik]

@mijn.host ik heb op 2 account problemen met ophalen e-mail en inloggen webmail.

Ticket insturen lijkt ook niet te werken, wat is er aan de hand?

[nescafe]

Er lijkt wat mis met de configuraties van de (shared) webhostingservers, als ik internet.nl mag geloven.. de kwaliteit neemt wat af - omgekeerd evenredig met het servernummer.

h63 scoort slecht (58%)

quote: https://internet.nl/site/h63.mijn.host/4149843/

Website test: h63.mijn.host

❌ Not reachable via modern internet address, or improvement possible (IPv6)
✅ Passed : Domain name signed (DNSSEC)
🗲 Error : Unreachable web server (HTTPS)
⚠️ Recommendation : One or more recommended security options not set (Security options)
✅ Passed : Authorised route announcement (RPKI)

h62 t/m h61 scoren matig (86%-90%)

quote: https://internet.nl/site/h62.mijn.host/4149840/

Website test: h62.mijn.host

❌ Not reachable via modern internet address, or improvement possible (IPv6)
✅ Passed : Domain name signed (DNSSEC)
❌ Failed : Connection not or insufficiently secured (HTTPS)
⚠️ Recommendation : One or more recommended security options not set (Security options)
✅ Passed : Authorised route announcement (RPKI)

quote: https://internet.nl/site/h61.mijn.host/4149835/

Website test: h61.mijn.host

❌ Not reachable via modern internet address, or improvement possible (IPv6)
✅ Passed : Domain name signed (DNSSEC)
❌ Failed : Connection not or insufficiently secured (HTTPS)
⚠️ Recommendation : One or more recommended security options not set (Security options)
✅ Passed : Authorised route announcement (RPKI)

h57 scoort beter (95%)

quote: https://internet.nl/site/h57.mijn.host/4149857/

Website test: h57.mijn.host

✅ Reachable via modern internet address (IPv6)
✅ Passed : Domain name signed (DNSSEC)
❌ Failed : Connection not or insufficiently secured (HTTPS)
⚠️ Recommendation : One or more recommended security options not set (Security options)
✅ Passed : Authorised route announcement (RPKI)

Frontpage scoort 100%:

quote: https://internet.nl/site/mijn.host/4149849/

✅ Reachable via modern internet address (IPv6)
✅ Passed : Domain name signed (DNSSEC)
✅ Passed : Connection sufficiently secured (HTTPS)
✅ Passed : All security options set (Security options)
✅ Passed : Authorised route announcement (RPKI)

Dan nog een bijzondere standaard vhost op h63 - IPv4 only:

code:

$ curl -v4 http://h63.mijn.host/
> GET / HTTP/1.1
> Host: h63.mijn.host
> User-Agent: curl/7.86.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Connection: Keep-Alive
< Keep-Alive: timeout=5, max=100
< Content-Type: text/html
< Content-Length: 795
< Date: Sun, 21 Jun 2026 09:14:59 GMT
< Server: LiteSpeed
< Location: (andere url)
< Vary: User-Agent

Waarbij h10 t/m h62 netjes een 'Domain parked'-pagina geven of een blanco pagina (h13, h16, h21).

Het lijkt er dus op dat de configuraties niet helemaal centraal beheerd of toegepast worden bij mijn.host.

Support reageert dat ik moet testen met klantdomein i.p.v. servernaam. Toegegeven, dat maakt uit voor je redirects e.d. maar ik zie de outdated cipher suites, verschillen tussen IPv4 en IPv6 en de matige IPv6-connectiviteit (zowel op server als op ns3) bij zo'n beetje alle tests terug, ook op klantdomein.

[remyz]

nescafe schreef op zondag 21 juni 2026 @ 11:48:
[...]

Support reageert dat ik moet testen met klantdomein i.p.v. servernaam. Toegegeven, dat maakt uit voor je redirects e.d. maar ik zie de outdated cipher suites, verschillen tussen IPv4 en IPv6 en de matige IPv6-connectiviteit (zowel op server als op ns3) bij zo'n beetje alle tests terug, ook op klantdomein.

Ik monitor de drie DNS-servers van mijn.host al een paar weken (met Gatus, records van mijn eigen domein, elke 30 minuten van zowel een KPN als een Ziggo internetaansluiting). De ns3 geeft zeer regelmatig niet thuis (time-out). Volgens support zou dat komen door het out-of-sync zijn van een cluser node van ns3. Dat is verholpen, maar de slechte response van ns3 blijft. Nu al ruim een week geen terugkoppeling op mijn ticket gehad.

[Wietsee.]

New Vimexx is born?

[nescafe]

@remyz Nice dashboard! Monitor jij alleen/gericht IPv4 / IPv6 of niet bepaald?

[remyz]

nescafe schreef op zondag 21 juni 2026 @ 16:51:
@remyz Nice dashboard! Monitor jij alleen/gericht IPv4 / IPv6 of niet bepaald?

Ik monitor of de DNS-records te resolven zijn (óf er een resultaat terugkomt en of dat dan het juiste resultaat is). Mijn KPN-aansluiting doet dat over IPv4 en de Ziggo-aansluiting doet dat over IPv6. De schermafbeelding die ik plaatste was van de KPN-aansluiting, maar de monitoring op de Ziggo-aansluiting laat een gelijk beeld zien.

Het probleem dat ns3 regelmatig niet antwoordt zie ik ondertussen al drie maanden. Toen viel het mij pas op, dus het mogelijk al veel langer aan de gang.

[mijn.host]

Bedankt voor het melden van deze punten.

Wat betreft de score op internet.nl: het IPv6-adres van internet.nl werd geblokkeerd op meerdere servers. Daardoor mislukten meerdere checks. Dit is nu opgelost en alle servers zouden een score van 100% moeten hebben. Het was dus puur de check die (deels) faalde. De server config stond wel goed.

We hebben de redirect op de hostnaam ook gelijk geregeld, wel zo netjes voor de score.

Voorbeeld: https://internet.nl/site/h63.mijn.host/4150093/

Wat betreft de time-outs die soms voorkomen op ns3: hier zijn we nog mee bezig en vergt helaas wat meer tijd. Hopelijk kunnen we binnenkort een update melden dat het opgelost is. Dit zou nu opgelost moeten zijn.

[nescafe]

@mijn.host geweldig bedankt!

Door de score op internet.nl te verbeteren, vallen nu de andere zaken waar we zelf voor verantwoordelijk zijn (bijv. hsts) op en kunnen daar nu gericht aandacht aan besteden. Fijn dat de zaken worden opgepakt dan wel bestaande issues benoemd en bevestigd.

[ Voor 81% gewijzigd door nescafe op 21-06-2026 19:56 ]

[True]

Even op de zondagavond reageren, tijd om die laatste paar .nl domeinen bij een concurrent weg te halen ..

[king006]

@mijn.host,

De mx1.mijn.host en mx2.mijn.host hebben geen 100% score bij de e-mail check. Maar geen idee of jullie dat kunnen oplossen? Of dat dat SpamExperts is?

[Nachtkastje]

mijn.host schreef op zondag 21 juni 2026 @ 18:27:
Bedankt voor het melden van deze punten.

Wat betreft de score op internet.nl: het IPv6-adres van internet.nl werd geblokkeerd op meerdere servers. Daardoor mislukten meerdere checks. Dit is nu opgelost en alle servers zouden een score van 100% moeten hebben. Het was dus puur de check die (deels) faalde. De server config stond wel goed.

We hebben de redirect op de hostnaam ook gelijk geregeld, wel zo netjes voor de score.

Voorbeeld: https://internet.nl/site/h63.mijn.host/4150093/

Wat betreft de time-outs die soms voorkomen op ns3: hier zijn we nog mee bezig en vergt helaas wat meer tijd. Hopelijk kunnen we binnenkort een update melden dat het opgelost is.

Is dit iets wat jullie ook op een s10.webhost.company kunnen regelen? Deze faalt namelijk op SHA1 hashing (Hashfunctie voor sleuteluitwisseling)

[mijn.host]

@Nachtkastje dit is nu ook opgelost, alle servers zijn nu nagelopen.

@king006 we zullen hiervoor contact met SpamExperts opnemen, zodat dit ook weer 100% wordt.

[king006]

@mijn.host,

Thanks voor de reactie en zelfs op zondagavond nog. Complimenten 👍🏻

[mijn.host]

We hebben een leuke feature update te melden wat door veel Tweakers is gevraagd: we ondersteunen nu native Dynamische DNS (DDNS).

We zagen dat sommige klanten een eigen intergratie hiervoor maakten met onze API, maar dat hoeft nu niet meer.

Meer info: https://mijn.host/kb/domeinnaam/dynamische-dns-ddns-instellen

[Room42]

Mooie feature, @mijn.host! Zal ik vanavond eens gaan testen!

Hoe vaak per minuut mag ik dit draaien, c.q., hebben jullie ook een 'what is my ip' dienst (a la api.ipify.org) ernaast die ik elke 5 seconden mag queryen om te zien of mijn IP gewijzigd is?

[ Voor 60% gewijzigd door Room42 op 23-06-2026 14:09 ]

[Wimbo]

mijn.host schreef op dinsdag 23 juni 2026 @ 13:21:
We hebben een leuke feature update te melden wat door veel Tweakers is gevraagd: we ondersteunen nu native Dynamische DNS (DDNS).

We zagen dat sommige klanten een eigen intergratie hiervoor maakten met onze API, maar dat hoeft nu niet meer.

Meer info: https://mijn.host/kb/domeinnaam/dynamische-dns-ddns-instellen

Goede toevoeging!
Voor Unifi is het wat complexer ivm het aanpassen van de URL, https is hierbij niet nodig.

code:

mijn.host/nic/update?hostname=%h&myip=%i

Werkende settings voor Unifi (UCG-Fiber 5.1.19 met Network 10.4.57):


Vraagje: als je het hoofddomein updated, wordt dan ook het *.hoofddomein.nl geupdated?
Ik kan namelijk niet * toevoegen, dat is dan een ongeldige hostnaam.
EDIT: helaas niet, het * record wordt niet gewijzigd... Is hier een andere manier voor?

[ Voor 11% gewijzigd door Wimbo op 23-06-2026 14:27 ]

[RobinJB]

Wimbo schreef op dinsdag 23 juni 2026 @ 14:10:
[...]


Goede toevoeging!
Voor Unifi is het wat complexer ivm het aanpassen van de URL, https is hierbij niet nodig.

code:

mijn.host/nic/update?hostname=%h&myip=%i

Werkende settings voor Unifi (UCG-Fiber 5.1.19 met Network 10.4.57):
[Afbeelding]

Vraagje: als je het hoofddomein updated, wordt dan ook het *.hoofddomein.nl geupdated?
Ik kan namelijk niet * toevoegen, dat is dan een ongeldige hostnaam.
EDIT: helaas niet, het * record wordt niet gewijzigd... Is hier een andere manier voor?

Ja, CNAME maken naar het aangemaakte DynDNS record
*.hoofddomein.nl CNAME hoofddomein.nl.

[mijn.host]

Bedankt voor jullie feedback! Onze developer is er vandaag mee bezig en neemt jullie feedback gelijk mee! Dus verwacht later vandaag een update

[RobinJB]

En IPv6 update hij niet (ziet hij wel) (weet ik eigenlijk niet, ik gebruikte %i in Unifi, maar zie geen IPv6 in mijn.host).

[ Voor 51% gewijzigd door RobinJB op 23-06-2026 14:43 ]

[Drardollan]

Leuke toevoeging @mijn.host !

Is er ook toevallig een planning wanneer er wat aan de portal gesleuteld gaat worden? Het filteren bij bijvoorbeeld domeinnamen is niet te doen, filters worden constant vergeten en de tags zijn onbruikbaar.

[idef1x]

mijn.host schreef op dinsdag 23 juni 2026 @ 13:21:
We hebben een leuke feature update te melden wat door veel Tweakers is gevraagd: we ondersteunen nu native Dynamische DNS (DDNS).

We zagen dat sommige klanten een eigen intergratie hiervoor maakten met onze API, maar dat hoeft nu niet meer.

Meer info: https://mijn.host/kb/domeinnaam/dynamische-dns-ddns-instellen

Mooie feature! Maar als het om het even is blijf ik mijn eigen script wel gebruiken, want:

1) hoef ik nergens aan te denken als ik de ISP router moet vervangen

2) Ik van ISP zou wisselen

3) ik er niet zo van houd om prive paswoorden e.d. op in bruikleen apparatuur te zetten

4) If it ain't broke, don't fix it ;-)

0h en 5) is makkelijker te monitoren..kan nu een mailtje naar mezelf sturen ofzo als het fout gaat ;-)

[ Voor 5% gewijzigd door idef1x op 23-06-2026 15:03 ]

[Room42]

idef1x schreef op dinsdag 23 juni 2026 @ 15:00:
[...]

Mooie feature! Maar als het om het even is blijf ik mijn eigen script wel gebruiken, want:
1) Dan hoef ik nergens aan te denken als ik de ISP router moet vervangen
2) Ik van ISP zou wisselen
3) ik er niet zo van houd om prive paswoorden e.d. op in bruikleen apparatuur te zetten

Maar je kunt je eigen script dus ook aanpassen om die URL te query'en. Dat lijkt me eenvoudiger dan de API. En het draait nog steeds op je eigen host.

4) If it ain't broke, don't fix it ;-)

('Broken' bedoel je, denk ik? )
Dat is een valide argument.

[anpat]

Ook maar is geinformeerd via hier, wat de verhuisservice precies inhoud, zitten nu bij het (veel) te dure ex PcExtreme waar we honderden euro per jaar betalen. Weliswaar destijds problemen met hun mail (na overname dacht ik) en dus (MX) DNS naar Microsoft gezet... Dit wil ik wel behouden indien mogelijk met verhuis...

[idef1x]

Room42 schreef op dinsdag 23 juni 2026 @ 15:04:
[...]

Maar je kunt je eigen script dus ook aanpassen om die URL te query'en. Dat lijkt me eenvoudiger dan de API. En het draait nog steeds op je eigen host.

[...]

('Broken' bedoel je, denk ik? )
Dat is een valide argument.

Ja maar simpel een url aanroepen kun je geen script meer noemen

Broken indeed indeed...

[Room42]

idef1x schreef op dinsdag 23 juni 2026 @ 15:11:
[...]

Ja maar simpel een url aanroepen kun je geen script meer noemen

Jawel, jij wilde nog foutcontrole en mails sturen op moment van change.

offtopic:
En ik wil niet pietluttig doen, maar elke file dat een of meer commando's uitvoert is per definitie een script.

[rvk]

Room42 schreef op dinsdag 23 juni 2026 @ 15:04:
[...]
Maar je kunt je eigen script dus ook aanpassen om die URL te query'en. Dat lijkt me eenvoudiger dan de API. En het draait nog steeds op je eigen host.

Het aanroepen van de API is gewoon een PATCH aanroep. Of je nu een GET (voor de URL) of een PATCH doet maakt dus niet zoveel uit. Met het aanroepen van die URL (GET) moet je ook weer dingen instellen in je mijn.host omgeving. Dat hoeft met de API (PATCH) niet

[ThinkPad]

Fijn die toevoeging van DDNS! Krijg het helaas met OPNsense nog niet werkend, hij blijft mekkeren over domein. Ook zonder "https://" zelfde.

Dit is met 'os-ddclient' plugin en op tabje 'Settings' aangepast naar 'native'.
<foutieve afbeelding weggehaald>

[ Voor 28% gewijzigd door ThinkPad op 23-06-2026 20:09 ]

[mijn.host]

Room42 schreef op dinsdag 23 juni 2026 @ 14:06:
Hoe vaak per minuut mag ik dit draaien, c.q., hebben jullie ook een 'what is my ip' dienst (a la api.ipify.org) ernaast die ik elke 5 seconden mag queryen om te zien of mijn IP gewijzigd is?

DDNS ondersteunt 1 update per minuut.

IP checken kan nu via het volgende endpoint https://mijn.host/api/doc/api-4406334. Publiekelijk hebben we daarnaast https://mijn.host/ip/.

Wimbo schreef op dinsdag 23 juni 2026 @ 14:10:
Vraagje: als je het hoofddomein updated, wordt dan ook het *.hoofddomein.nl geupdated?
Ik kan namelijk niet * toevoegen, dat is dan een ongeldige hostnaam.
EDIT: helaas niet, het * record wordt niet gewijzigd... Is hier een andere manier voor?

Wildcard wordt nu ook ondersteund. Als je device deze entry niet ondersteunt zou je inderdaad met een CNAME kunnen werken zoals @RobinJB aangaf.

RobinJB schreef op dinsdag 23 juni 2026 @ 14:37:
En IPv6 update hij niet (ziet hij wel) (weet ik eigenlijk niet, ik gebruikte %i in Unifi, maar zie geen IPv6 in mijn.host).

Dit zou nu ook opgelost moeten zijn.

Drardollan schreef op dinsdag 23 juni 2026 @ 14:55:
Is er ook toevallig een planning wanneer er wat aan de portal gesleuteld gaat worden? Het filteren bij bijvoorbeeld domeinnamen is niet te doen, filters worden constant vergeten en de tags zijn onbruikbaar.

Momenteel nog niet, maar we hebben wel plannen om dit inzichtelijk maken, onder andere met feature requests van klanten. Ook gaan we binnenkort dev updates op onze blog plaatsen, dus een soort changelog.

Je feedback m.b.t. het filteren van domeinnamen zal ik doorgeven aan onze dev.

ThinkPad schreef op dinsdag 23 juni 2026 @ 16:14:
Fijn die toevoeging van DDNS! Krijg het helaas met OPNsense nog niet werkend, hij blijft mekkeren over domein. Ook zonder "https://" zelfde.

Zou het probleem wellicht de TLD kunnen zijn? Dat het niet goed werkt met .host? Test eventueel eens met een andere TLD, bijvoorbeeld .nl? Puur om te zien of de melding dan weg gaat.

[Wimbo]

mijn.host schreef op dinsdag 23 juni 2026 @ 16:21:
[...]

Wildcard wordt nu ook ondersteund. Als je device deze entry niet ondersteunt zou je inderdaad met een CNAME kunnen werken zoals @RobinJB aangaf.

Dit werkt nu prima, als ik een extra ddns entry voor *.hoofdomein.nl aanmaak.
Het vinkje Wildcard forceren werkt echter niet, als ik hoofdomein.nl gebruik, en dat vinkje aanzet.

[ThinkPad]

mijn.host schreef op dinsdag 23 juni 2026 @ 16:21:
[...]
Zou het probleem wellicht de TLD kunnen zijn? Dat het niet goed werkt met .host? Test eventueel eens met een andere TLD, bijvoorbeeld .nl? Puur om te zien of de melding dan weg gaat.

Probleem opgelost, de os-ddclient plugin in OPNsense verwacht alleen mijn.host in het 'Server' veld. Het deel '/nic/update' zit in de source al ingebakken schijnbaar als je DynDNS kiest. Het werkt nu met onderstaande settings:



Op het tabje 'General settings' nog de 'Backend' naar 'native' gezet en de check interval van 900 naar 3600 (zo vaak wijzigt m'n IP toch niet).

[RobertMe]

Grappig hoe dat gaat. mijn.host die dyndns toevoegt dat voor mij de trigger is om toch maar eens dyndns met DeSEC in te regelen Domein wel geregistreerd bij mijn.host, maar DeSEC dan als nameserver.

Ooit jaren terug een .nl bij TransIP gekocht. Jaren later wat exotische TLDs bij Porkbun. Nadat Porkbun een storing op hun DNS had + dat het een Amerikaanse partij is de boel van maar ondergebracht bij DeSEC, qua nameserver dan (Porkbun is wel, ook nu nog, de registar). Jaar of twee terug na de zoveelste prijsverhoging van TransIP de DNS ook naar DeSEC over gezet en dan verhuisd naar mijn.host.

De domeinen kan ik volgens mij wel ook naar mijn.host migreren. Zowel beschikbaar als geen enorme prijsverschillen. Zou ik alleen even moeten kijken hoe het zit met de looptijd. Heb die een tijd terug verlengd voor meerdere jaren. Maar ik meen dat verhuizen met behoudt van "aangekochte jaren" bij deze (.app, .dev en .xyz) geen issue was. Hoogstens dat je voor verhuizen betaalt maar daarvoor ook weer een jaar eraan vast plakt. (Dus effectief een jaar verlenging).

[anpat]

Gisteren na het lezen van alle positieve berichten ook maar de overstap gemaakt, Dat had ik veel eerder moeten doen, na jaren bij PCextreme/versio te hebben gezeten, is de site nu veel vlotter bereikbaar en de verhuisservice is perfect, DNS instellingen voor MS365 overgenomen waardoor mail is blijven werken, Enige puntje was dat er een aantal plaatjes niet bleken te werken, maar ook dat werd vlot opgepakt en opgelost.
Kan alleen maar zeggen 'Ga zo door'

Recentie ook geschreven op hostingvergelijker

[chaoscontrol]

Ook ik ben na 15jaar Hostnet weg naar mijn.host. Vroegen tegenwoordig echt belachelijke bedragen voor verlengen van .nl domeinen. So far erg tevreden met de interface en de api!

[EDIT]

Aangezien @mijn.host hier ook meeleest: wat is jullie overweging om het plakken van de 2FA code bij het inloggen in het controlepanel zo lastig te maken?
Ik vind het in ieder geval heel onhandig dat ik onder Android alleen het eerste cijfer kan plakken en de rest handmatig moet intypen. Het zou een stuk prettiger zijn (IMO) als ik die gewoon direct vanuit mijn 2fa manager kan plakken.

[mijn.host]

Wimbo schreef op dinsdag 23 juni 2026 @ 16:40:
[...]


Dit werkt nu prima, als ik een extra ddns entry voor *.hoofdomein.nl aanmaak.
Het vinkje Wildcard forceren werkt echter niet, als ik hoofdomein.nl gebruik, en dat vinkje aanzet.

Dat vinkje zou nu ook moeten werken.

EDIT schreef op woensdag 24 juni 2026 @ 11:26:
Aangezien @mijn.host hier ook meeleest: wat is jullie overweging om het plakken van de 2FA code bij het inloggen in het controlepanel zo lastig te maken?
Ik vind het in ieder geval heel onhandig dat ik onder Android alleen het eerste cijfer kan plakken en de rest handmatig moet intypen. Het zou een stuk prettiger zijn (IMO) als ik die gewoon direct vanuit mijn 2fa manager kan plakken.

We konden dit niet direct herproduceren, maar onze developer heeft enkele aanpassingen gedaan wat het misschien verholpen heeft. Zou je nog eens kunnen testen?

Mocht het nog niet werken, maak gerust een ticket aan, dan kan onze dev het verder uitzoeken.

[EDIT]

mijn.host schreef op woensdag 24 juni 2026 @ 14:39:
[...]

We konden dit niet direct herproduceren, maar onze developer heeft enkele aanpassingen gedaan wat het misschien verholpen heeft. Zou je nog eens kunnen testen?

Mocht het nog niet werken, maak gerust een ticket aan, dan kan onze dev het verder uitzoeken.

Het werkt nu inderdaad perfect, heel erg fijn, dank voor deze aanpassing!

[remyz]

remyz schreef op zondag 21 juni 2026 @ 15:45:
[...]

Ik monitor de drie DNS-servers van mijn.host al een paar weken (met Gatus, records van mijn eigen domein, elke 30 minuten van zowel een KPN als een Ziggo internetaansluiting). De ns3 geeft zeer regelmatig niet thuis (time-out). Volgens support zou dat komen door het out-of-sync zijn van een cluser node van ns3. Dat is verholpen, maar de slechte response van ns3 blijft. Nu al ruim een week geen terugkoppeling op mijn ticket gehad.

Mijn.host heeft mij gisteren laten weten dat de problemen met ns3 opgelost zouden moeten zijn. Als ik naar de monitoring van afgelopen 24 uur kijk klopt dat. Fijn dat het opgelost is!

[anpat]

Vraag, Ik zie via mxtoolbox op DNS check de volgende waarschuwingen.

SOA Serial Number Format is Invalid,
Suggested serial format year was 1782 which is before 1970.

SOA Expire Value out of recommended range,
Expire is recommended to be between 1209600 and 2419200.

Moet ik me zorgen maken of komt dit vanzelf goed?

@mijn.host je weet over welk domein dit gaat?

[ Voor 7% gewijzigd door anpat op 24-06-2026 15:07 ]

[remyz]

anpat schreef op woensdag 24 juni 2026 @ 15:06:
Vraag, Ik zie via mxtoolbox op DNS check de volgende waarschuwingen.

SOA Serial Number Format is Invalid,
Suggested serial format year was 1782 which is before 1970.

SOA Expire Value out of recommended range,
Expire is recommended to be between 1209600 and 2419200.

Moet ik me zorgen maken of komt dit vanzelf goed?

@mijn.host je weet over welk domein dit gaat?

Je hoeft je geen zorgen te maken. Het serienummer is vaak de datum en tijd van de laatste zone update, maar mag ook gewoon een opvolgend nummer zijn. De expire value van mijn domeinen staat op 604800 en dat is 7 dagen. Ook prima. Het advies dat mxtoolbox geeft is 14 tot 28 dagen.

[mijn.host]

Drardollan schreef op dinsdag 23 juni 2026 @ 14:55:
Leuke toevoeging @mijn.host !

Is er ook toevallig een planning wanneer er wat aan de portal gesleuteld gaat worden? Het filteren bij bijvoorbeeld domeinnamen is niet te doen, filters worden constant vergeten en de tags zijn onbruikbaar.

Onze dev heeft dit nu ook verbeterd, voel je vrij om je feedback te geven.