Onderwerp: Oude provider knalt me eruit na verhuizing

Hoi,

Ik verzorg voor een bedrijf de verhuizing van de ene hosting-provider
naar de andere.

Na het ontvangen van het bericht van de domain-registry stopt de oude
provider plots alles, waardoor email niet meer geaccepteerd wordt, want
de nieuwe MX is nog niet overal bekend op de nameservers. Daardoor wordt
alle email gebounced.

Bij de oude provider beweren ze dat dit normaal is. Dat ze het domein
van de "ns1" moeten halen van de domain-registry, en daardoor ook de
pop-boxen onbereikbaar worden.

Het lijkt me dat dit bedrijf volledig fout zit, wat vinden jullie?

Wat is normaal & correct?

Met vriendelijke groet,
Paul van der Vlis.

In article <3f4daf18$0$49111$e4fe514c@news.xs4all.nl>,
Paul van der Vlis <paul@vandervlis.nl> wrote:
>Hoi,
>
>Ik verzorg voor een bedrijf de verhuizing van de ene hosting-provider
>naar de andere.
>
>Na het ontvangen van het bericht van de domain-registry stopt de oude
>provider plots alles, waardoor email niet meer geaccepteerd wordt, want
>de nieuwe MX is nog niet overal bekend op de nameservers. Daardoor wordt
>alle email gebounced.
>
>Bij de oude provider beweren ze dat dit normaal is. Dat ze het domein
>van de "ns1" moeten halen van de domain-registry, en daardoor ook de
>pop-boxen onbereikbaar worden.
>
>Het lijkt me dat dit bedrijf volledig fout zit, wat vinden jullie?
>
>Wat is normaal & correct?

Zie http://www.domain-registry.nl/sidn/f...ies/Verhuizen/

Alvorens het domein te verhuizen bij SIDN, zet je alvast de DNS op
bij de nieuwe provider, exact zoals die nu bij de oude provider draait.
Je zet alleen de TTL van de zone lekker kort (5 minuten ofzo).

Daarna vraag je aan de oude provider om secondary DNS te draaien
voor het domein met de nieuwe provider als primary.

Vervolgens wacht je de "oude TTL" (typisch 1 dag). Dan vraag je
de verhuizing aan bij SIDN.

Nu kan je de gegevens in de zone voor het domein aanpassen zoals
je wilt voor de nieuwe provider, en alle wijzigingen in A en MX
records zullen over de hele wereld bekend zijn binnen 5 minuten.

Als je dit /niet/ van tevoren geregeld hebt ben je SOL.

Mike.
--
RAND USR 16514

Miquel van Smoorenburg wrote:
> In article <3f4daf18$0$49111$e4fe514c@news.xs4all.nl>,
> Paul van der Vlis <paul@vandervlis.nl> wrote:
>
>>Hoi,
>>
>>Ik verzorg voor een bedrijf de verhuizing van de ene hosting-provider
>>naar de andere.
>>
>>Na het ontvangen van het bericht van de domain-registry stopt de oude
>>provider plots alles, waardoor email niet meer geaccepteerd wordt, want
>>de nieuwe MX is nog niet overal bekend op de nameservers. Daardoor wordt
>>alle email gebounced.
>>
>>Bij de oude provider beweren ze dat dit normaal is. Dat ze het domein
>>van de "ns1" moeten halen van de domain-registry, en daardoor ook de
>>pop-boxen onbereikbaar worden.
>>
>>Het lijkt me dat dit bedrijf volledig fout zit, wat vinden jullie?
>>
>>Wat is normaal & correct?
>
>
> Zie http://www.domain-registry.nl/sidn/f...ies/Verhuizen/

Heel erg bedankt voor de link en de informatie. Die secondary DNS,
daarvan had ik te weinig kennis. Via "dig" vond ik nog steeds hun MX.

> Alvorens het domein te verhuizen bij SIDN, zet je alvast de DNS op
> bij de nieuwe provider, exact zoals die nu bij de oude provider draait.
> Je zet alleen de TTL van de zone lekker kort (5 minuten ofzo).

Er is bij de nieuwe provider een DNS opgezet, maar de MX wijst dus naar
de nieuwe mailserver. Of de TTL extra kort staat weet ik niet.

> Daarna vraag je aan de oude provider om secondary DNS te draaien
> voor het domein met de nieuwe provider als primary.

Ik heb dat niet expliciet gevraagt, ik ging ervan uit dat ze dat al wel
eens vaker hebben gedaan. Het gaat om een grote provider (top 10), en de
laatste tijd maken ze daar minder fouten dan vroeger.

> Vervolgens wacht je de "oude TTL" (typisch 1 dag). Dan vraag je
> de verhuizing aan bij SIDN.

Ik heb een dag gewacht en de verhuizing aangevraagt.

> Nu kan je de gegevens in de zone voor het domein aanpassen zoals
> je wilt voor de nieuwe provider, en alle wijzigingen in A en MX
> records zullen over de hele wereld bekend zijn binnen 5 minuten.
>
> Als je dit /niet/ van tevoren geregeld hebt ben je SOL.

N.a.v. jouw informatie heb ik gekeken of ze nu secondary DNS draaien,
dat blijkt nu het geval. Mail komt nu ook aan, gisteren was dit niet zo.

Is het nog zinvol me in de TTL bij de nieuwe provider te gaan verdiepen?

Met vriendelijke groet,
Paul van der Vlis.

In article <3f4dc012$0$49104$e4fe514c@news.xs4all.nl>,
Paul van der Vlis <paul@vandervlis.nl> wrote:
>Miquel van Smoorenburg wrote:
>> Alvorens het domein te verhuizen bij SIDN, zet je alvast de DNS op
>> bij de nieuwe provider, exact zoals die nu bij de oude provider draait.
>> Je zet alleen de TTL van de zone lekker kort (5 minuten ofzo).
>
>Er is bij de nieuwe provider een DNS opgezet, maar de MX wijst dus naar
>de nieuwe mailserver. Of de TTL extra kort staat weet ik niet.

TTL laag zetten is alleen zinvol als je dat van tevoren doet.

>> Daarna vraag je aan de oude provider om secondary DNS te draaien
>> voor het domein met de nieuwe provider als primary.
>
>Ik heb dat niet expliciet gevraagt, ik ging ervan uit dat ze dat al wel
>eens vaker hebben gedaan. Het gaat om een grote provider (top 10), en de
>laatste tijd maken ze daar minder fouten dan vroeger.

Ja, ze horen secondary te draaien voor 1-2 weken na de verhuizing,
maar eigenlijk is het dan al te laat - je kan dat beter /voor/
de verhuizing vragen. Dan heb je er meer controle over (zoals het
verlagen van de TTL voordat je wijzigingen gaat maken).

>N.a.v. jouw informatie heb ik gekeken of ze nu secondary DNS draaien,
>dat blijkt nu het geval. Mail komt nu ook aan, gisteren was dit niet zo.
>Is het nog zinvol me in de TTL bij de nieuwe provider te gaan verdiepen?

Nee, het verlagen van de TTL is zinvol om daarna (als iedereen die
de zone gecached heeft ook de nieuwe TTL kent) snel wijzigingen door
te kunnen voeren. Achteraf verlagen is zinloos.

Als je dit doet niet vergeten om als je klaar bent met de
wijzigingen de TTL uiteindelijk weer terug te zetten op een
redelijke waarde (1 dag).

Mike.
--
RAND USR 16514

Hoi,

> Ja, ze horen secondary te draaien voor 1-2 weken na de verhuizing,

Merk in de praktijk dat er collega-ISP's zijn die geen axfr's toestaan
zodat je als goedbedoelende ISP (waar klant vertrekt) geen secondary *kan*
draaien.

Zomaar een constatering.

Rj

> Ik verzorg voor een bedrijf de verhuizing van de ene hosting-provider
> naar de andere.
>
> Na het ontvangen van het bericht van de domain-registry stopt de oude
> provider plots alles, waardoor email niet meer geaccepteerd wordt, want
> de nieuwe MX is nog niet overal bekend op de nameservers. Daardoor wordt
> alle email gebounced.

Een verhuizing duurt 2 werkdagen, dan pas is de DNS omgezet naar de DNS
servers van de nieuwe ISP. Daarna kan het nog 24-48 uur duren voordat
iedereen ook daar van op de hoogte is.

Het is dus gewoon slordig van de oude ISP. Maar aan de andere kant: Als de
hosting is opgezegd op die datum.. Dan hebben ze ergens natuurlijk gewoon
gelijk.

> Bij de oude provider beweren ze dat dit normaal is. Dat ze het domein
> van de "ns1" moeten halen van de domain-registry, en daardoor ook de
> pop-boxen onbereikbaar worden.

Dat duurt dus nog minimaal 2 dagen nadat hun dat mailtje hebben. De eerst
volgende werkdag na het aanvragen van de verhuizing wordt de WHOIS
aangepast, de werkdag daarop de DNS.

> Het lijkt me dat dit bedrijf volledig fout zit, wat vinden jullie?
> Wat is normaal & correct?

Correct is dat ze slave gaan draaien voor de nieuwe ISP volgens de regels
van de SIDN. Echter, ik ken geen enkele ISP die het doet.. En ik doe het
zelf ook niet. De reden is vrij simpel: 9 van de 10 ISPs laat geen AXFR toe
(waardoor ik dus geen slave kan draaien), en daarnaast vind ik het onzin.
Je boekt er hooguit een winst mee van een dag of 2/3.

Of dit normaal is.. Het lijkt mij dat dat af hangt van wanneer het contract
opgezegd is. Als ze gewoon alles uit hun configuratie gehaald hebben op de
dag dat 't contract afliep, zijn ze gewoon correct bezig. Netjes is het
niet.

On Fri, 29 Aug 2003 00:07:21 +0200, Tozz <nntp-trap@kijkt.tv> wrote:

>Je boekt er hooguit een winst mee van een dag of 2/3.

Het is ook niet normaal om zoiets exact op de laatste dag van het
contract te doen. Als je oude provider nog naar zijn mailserver wijst,
kan de klant daar nog even de laatste resten mail ophalen. Nieuwe mail
komt langzaam maar zeker op de server van de nieuwe provider terecht.

--
Peter Peters, senior netwerkbeheerder
Dienst Informatietechnologie, Bibliotheek en Educatie (ITBE)
Universiteit Twente, Postbus 217, 7500 AE Enschede
telefoon: 053 - 489 2301, fax: 053 - 489 2383, http://www.utwente.nl/civ

Tozz wrote:
>>Ik verzorg voor een bedrijf de verhuizing van de ene hosting-provider
>>naar de andere.
>>
>>Na het ontvangen van het bericht van de domain-registry stopt de oude
>>provider plots alles, waardoor email niet meer geaccepteerd wordt, want
>>de nieuwe MX is nog niet overal bekend op de nameservers. Daardoor wordt
>>alle email gebounced.
>
> Een verhuizing duurt 2 werkdagen, dan pas is de DNS omgezet naar de DNS
> servers van de nieuwe ISP. Daarna kan het nog 24-48 uur duren voordat
> iedereen ook daar van op de hoogte is.
>
> Het is dus gewoon slordig van de oude ISP. Maar aan de andere kant: Als de
> hosting is opgezegd op die datum.. Dan hebben ze ergens natuurlijk gewoon
> gelijk.

Nee, de rekening was nog voor maanden betaald. Verder had ik
geinformeerd hoe de schriftelijke opzegging moest plaatsvinden, en ze
hebben me toen verteld dat dit bij hen niet hoefde. De brief van het
SIDN zagen ze als opzegging. En het resterende geld zouden ze zelfs
terugstorten (ik ben nieuwsgierig..).

>>Bij de oude provider beweren ze dat dit normaal is. Dat ze het domein
>>van de "ns1" moeten halen van de domain-registry, en daardoor ook de
>>pop-boxen onbereikbaar worden.
>
> Dat duurt dus nog minimaal 2 dagen nadat hun dat mailtje hebben. De eerst
> volgende werkdag na het aanvragen van de verhuizing wordt de WHOIS
> aangepast, de werkdag daarop de DNS.
>
>>Het lijkt me dat dit bedrijf volledig fout zit, wat vinden jullie?
>>Wat is normaal & correct?
>
> Correct is dat ze slave gaan draaien voor de nieuwe ISP volgens de regels
> van de SIDN. Echter, ik ken geen enkele ISP die het doet..

Ze hebben dat dus wel gedaan nadat ik klaagde. Maar zonder het mij te
vertellen.

> En ik doe het
> zelf ook niet. De reden is vrij simpel: 9 van de 10 ISPs laat geen AXFR toe

Ik weet niet wat AXFR is.

> (waardoor ik dus geen slave kan draaien), en daarnaast vind ik het onzin.
> Je boekt er hooguit een winst mee van een dag of 2/3.
>
> Of dit normaal is.. Het lijkt mij dat dat af hangt van wanneer het contract
> opgezegd is. Als ze gewoon alles uit hun configuratie gehaald hebben op de
> dag dat 't contract afliep, zijn ze gewoon correct bezig. Netjes is het
> niet.

Er is niet op het laatste nippertje gewerkt.

Bedankt voor je verhaal, ik weet nu dat "slave gaan draaien" vaak
helemaal niet gedaan wordt in de praktijk. Ik had van te voren gehoord
dat de mail een paar dagen van twee kanten kon komen, en daar had ik me
op ingesteld. Dat blijkt dus in de praktijk ook vaak voor te komen als
ik het goed begrijp.

Met vriendelijke groet,
Paul van der Vlis.

Peter Peters wrote:
> On Fri, 29 Aug 2003 00:07:21 +0200, Tozz <nntp-trap@kijkt.tv> wrote:
>
>>Je boekt er hooguit een winst mee van een dag of 2/3.
>
> Het is ook niet normaal om zoiets exact op de laatste dag van het
> contract te doen.

Inderdaad, maar zo was het ook niet.

> Als je oude provider nog naar zijn mailserver wijst,
> kan de klant daar nog even de laatste resten mail ophalen.

Dat kon dus niet meer.
Popbox bestond niet meer, mail werd gebounced.

> Nieuwe mail
> komt langzaam maar zeker op de server van de nieuwe provider terecht.

Ze zijn op een gegeven moment slave gaan draaien, en toen kwam de mail
bij de nieuwe provider terecht en kwam alles goed.

Hoe dat slave draaien nu precies werkt is me overigens nog niet helemaal
duidelijk.

Met vriendelijke groet,
Paul van der Vlis.

On 29 Aug, Paul van der Vlis wrote:
[...]
>> En ik doe het
>> zelf ook niet. De reden is vrij simpel: 9 van de 10 ISPs laat geen AXFR toe
>
> Ik weet niet wat AXFR is.

Een zone transfer, meestal betreft dat dan 'alle DNS gegevens voor
domein X.'

Erwin.