10 berichten aan het bekijken - 1 tot 10 (van in totaal 10)
  • Q:
    Bijdrager
    Atjous

    Migratie website: *sommige* klanten blijven de oude site zien

    Beste mensen,
    ik loop tegen een curieus geval aan: afgelopen vrijdag is een zakelijke website gemigreerd van “Server A in Berlijn” naar “Server B in Nederland”.
    Die migratie is eigenlijk redelijk probleemloos verlopen, op een kleinigheid na: sommige klanten komen terecht op de “Sorry, we zijn er even niet”-pagina, zoals we die nog tonen op de oude server. Mijn vraag: hoe is dat op te lossen?

    Als voorbeeld een deel uit het verhaal van een van mijn klanten. Ik had deze klant het ip-adres van de nieuwe locatie van de site gegeven.

    “Met het invullen van het ip-adres kom ik op de site echter,…
    Zodra ik doorklik, of inlog met mijn accountgegevens stuurt hij mij weer
    naar de “sorry” pagina.
    Ik wacht nog maar af als het echt een kwestie van tijd is.

    Feit is wel dat mijn PC ( internet explorer) wel verbinding met de site
    heeft. Deze loopt over dezelfde router en hub als de twee mac¹s die het niet
    doen.
    Als ik de bijbehoorde wifi van de router pak (op mijn i-pad) dan doet die
    het ook niet.
    Binnenshuis (ziggo) kan ik wel met diezelfde i-pad op de site komen.

    Wat er aan de hand is is een volslagen raadsel voor mij.

    Voor mij dus ook. Iemand ideetjes?

    Bijdrager
    mtooster

    DNS caching, en dan op meerdere lagen.
    (dus het apparaat cached de gegevens van de router die weer de gegevens van de internetprovider cached die weer gecachete gegevens bevat.)

    Meestal op te lossen door gewoon geduld te hebben.
    (mits de DNS gegevens op de DNS server wel goed aangepast zijn, en niet beide IP-adressen van zowel de oude als de nieuwe server uitgedeeld worden.)

    Dat bij het ‘doorklikken’ of inloggen weer naar de oude site verwezen wordt komt weer door datzelfde DNS probleem. Het oude IP adres is nog gekoppeld met de domeinnaam.

    Tip: een aantal dagen voorafgaand aan een migratie de TTL-waarde van de DNS omlaag zetten.

    Bijdrager
    Atjous

    Dank voor je reactie!
    Mag ik daaruit concluderen dat “geduld hebben” tevens betekent dat ik er nu zelf weinig aan kan doen?

    Bijdrager
    mtooster

    In feite wel.
    Behalve zorgen dat de DNS records inderdaad echt correct zijn.
    Je hebt namelijk geen controle over de caches van de internet-providers en gebruikers.

    Mag je de domeinnaam en het ip-adres waar deze heen zou moeten verhuizen hier vermelden?

    Controleer in ieder geval of niet zowel het oude als het nieuwe ip-adres nog in de DNS-gegevens staan.
    Want in dat geval worden die om-en-om (round-robin) door de DNS server geretourneerd.

    Bijdrager
    Atjous

    Mag je de domeinnaam en het ip-adres waar deze heen zou moeten verhuizen hier vermelden?

    Voor de zekerheid maar even in een PM verstopt;-)

    Moderator
    Raymon Mens

    Dit is een typisch geval van DNS Caching. Je zou de Time To Live van DNS-records eens kunnen bekijken. Dit is de indicatie die DNS-servers vertelt hoe vaak naar nieuwe records gezocht moet worden. Je kunt die vaak op 1 minuut of 60 seconden zetten. Dan gaat het het snelst. Bijvoorbeeld:

    De ervaring leert dat als de DNS records op 1 minuut staan, alles binnen een halve dag over is. (We hebben het CDN van OMT wel eens op die manier gemigreerd)

    Aanvullend zou je je klanten op Windows kunnen vragen om in de commandline het volgende commando uit te laten voeren. Dan wordt de DNS Cache lokaal geleegd:

    Klanten die een Mac gebruiken kunnen bij Apple lezen hoe ze hun DNS cache legen. Je kunt altijd checken of je bij het juiste IP-adres uitkomt door op de commandline het volgende in te typen: “nslookup domeinnaam.nl”. Je krijgt dan het IP-adres terug. Dit werkt zowel op Mac als Windows.

    Bijdrager
    Atjous

    Grote dank voor de reacties!

    Inmiddels even ge”dig”d, ook via @resolver.xs4all.nl.
    Bij beide commando’s kreeg ik keurig het “nieuwe” ip-adres terug.

    Dan zou je inderdaad zeggen dat er lokaal iets geks aan de hand is. *Schijnbaar* onthoudt een iDevice per verbinding ook dns-gerelateerde info.

    Want:


    Als ik de bijbehoorde wifi van de router pak (op mijn i-pad) dan doet die
    het ook niet.
    Binnenshuis (ziggo) kan ik wel met diezelfde i-pad op de site komen.

    Bijdrager
    EagerB0bNerd

    Het kan enige tijd, soms wel tot twee dagen, duren voor de dns servers overal zijn bijgewerkt.
    De TTL op een hele lage tijd zetten, zoals Raymon omschrijft, helpt.
    Maar dan moet je dat wel doen enige tijd voor je de site migreert.
    Nu heeft dat geen zin meer. Wat je natuurlijk wel kan doen is een kopie van de nieuwe site op de oude server zetten.

    Bijdrager
    Atjous

    Wat je natuurlijk wel kan doen is een kopie van de nieuwe site op de oude server zetten.

    Deze gaat dan helaas niet werken: er zit een shop in de site; die kent unieke nummers toe aan bestellingen. Twee shops -> oeps!

    Bijdrager
    Atjous

    Opgelost!

    In dit artikel zit de hint.

    Wat bleek nou? In het IPv6-record stond nog een verwijzing naar de oude server, omdat we het IPv6-adres niet kenden en er geen rekening mee hadden gehouden dat dit protocol de voorrang had.

    Controle via http://www.ipv6proxy.net/

    Weer iets geleerd.

10 berichten aan het bekijken - 1 tot 10 (van in totaal 10)

Je moet ingelogd zijn om een reactie op dit onderwerp te kunnen geven.