Bekijk Volledige Versie : Website niet te bereiken na omzetten NameServers
Geachte,
Vandaag tegen het volgende probleem aangelopen:
Ik heb een domein draaien bij een specifieke hoster. Nu wil ik de data bij een andere hoster op een VPS gaan plaatsen. Hiervoor heb ik via DirectAdmin een backup gemaakt en deze daarna op de VPS in de DirectAdmin omgeving van de nieuwe hoster gerestored.
Hierna eenvoudig bij hoster 1 de beide nameservers aangepast zodat alles richting hoster 2 wordt gestuurd qua verkeer.
Echter kreeg ik, na het refreshen van de DNS-records, geen verbinding meer met met de website bij de nieuwe hoster. Diverse online whois lookups gaven mij wel de namen van de nameservers door, maar gaven aan dat er geen IP-record beschikbaar was voor de website.
Nu heb ik via DNS management de opties bekeken in de DirectAdmin omgeving van hoster 2. Hier staan netjes alle records goed opgesteld, maar toch krijg ik geen verbinding naar de website. Ook een ping of traceroute geeft me als resultaat dat het domein niet gevonden kan worden.
Daarom maar weer even de NameServer records teruggezet naar hoster 1. Binnen twee uur kon ik weer terug op de website komen.
Hierdoor had ik het vermoeden dat ik wellicht iets verkeerd had gegaan bij het omzetten van beide nameservers. Nog een keer de actie uitgevoerd (dus nameserver aangepast naar hoster 2) . En ook nu weer kon ik na 2 uur ineens niet meer de website bereiken en gaven online whois results aan dat er geen IP-adres beschikbaar was voor de website. Echter na het, wederom, terugzetten van de nameservers naar hoster 1, kon na twee uurtjes weer terug op de website komen.
Volgens de hoster staan wel alle records goed ingesteld en zou een dergelijke omzetting zonder problemen moeten werken. Echter krijg ik het dus niet werkende...
Iemand een idee waar dit aan zou kunnen liggen ?
Flush je DNS eens. Normaal duurt het wel even voordat de nieuwe nameservers zijn opgehaald en verwerkt.
Je oude nameservers staan nog in jouw systeem. Dus vandaar dat het gewoon werkt als je het terugdraait.
Heb je de Glue records ook aangepast (of de hoster)?
Is het anders mogelijk om de domeinnaam te geven zodat anderen even kunnen kijken wat ze zien?
Flush je DNS eens. Normaal duurt het wel even voordat de nieuwe nameservers zijn opgehaald en verwerkt.
Je oude nameservers staan nog in jouw systeem. Dus vandaar dat het gewoon werkt.
Heb je de Glue records ook aangepast (of de hoster)?
Ik heb op diverse verbindingen een dns-flush uitgevoerd (lang leve 3 verschillende internet verbindingen met verschillende providers op het werk). Uiteindelijk, na de reguliere refresh van het DNS-record, kon ik weer gewoon de website bereiken. Ook zag ik het resultaat terugkomen op de diverse online NS-lookup websites. Hierna werkte een nslookup commando op mijn eigen PC ook weer.
De glue-records zijn geregeld door de hoster (tenminste, daar ga ik wel van uit). Dit ook aangezien zij beweren dat alles in orde is en de DNS-records in de DirectAdmin omgeving bij hoster 2 ook de IP-adressen van de nameservers weergeven.
Ik heb een dergelijke actie al meerdere malen uitgevoerd en dit ging altijd zonder problemen. Alleen vandaag kreeg ik twee andere nameservers door dan ik altijd had doorgekregen. Mijn vermoeden is dat het toch ergens in de configuratie van de nameservers zou kunnen liggen.
Is het anders mogelijk om de domeinnaam te geven zodat anderen even kunnen kijken wat ze zien?
Uiteraard kan dat, maar ik heb de nameservers alweer aangepast naar hoster 1, zodat de website gewoon weer te bereiken is.
Als we ervan uitgaan dat de nieuwe nameservers correct zijn geconfigureerd dan is de vraag hoeveel tijd en welke stappen er genomen zijn om de site over te zetten.
Het beste is om de nieuwe nameservers op de oude omgeving in te stellen met een lage TTL en dan een paar uur (bijvoorbeeld een nacht of 6 uur) later de site over te zetten naar de nieuwe omgeving.
Daarna de Glue records pas wijzigen naar de nieuwe nameservers. Zo zal de down-time of tijd dat je de website niet ziet vrij kort zijn.
Als we ervan uitgaan dat de nieuwe nameservers correct zijn geconfigureerd dan is de vraag hoeveel tijd en welke stappen er genomen zijn om de site over te zetten.
Het beste is om de nieuwe nameservers op de oude omgeving in te stellen met een lage TTL en dan een paar uur (bijvoorbeeld een nacht of 6 uur) later de site over te zetten naar de nieuwe omgeving.
Daarna de Glue records pas wijzigen naar de nieuwe nameservers. Zo zal de down-time of tijd dat je de website niet ziet vrij kort zijn.
Goede tip !
Zal dat van het weekend wel uitvoeren. Dan is het aantal bezoekers van de website het laagst :)
Wanneer je de nameservers hebt omgezet, controleer even op intodns.com of alles ook daadwerkelijk goed staat en resolved.
Ik heb op diverse verbindingen een dns-flush uitgevoerd (lang leve 3 verschillende internet verbindingen met verschillende providers op het werk). Uiteindelijk, na de reguliere refresh van het DNS-record, kon ik weer gewoon de website bereiken. Ook zag ik het resultaat terugkomen op de diverse online NS-lookup websites. Hierna werkte een nslookup commando op mijn eigen PC ook weer.
De glue-records zijn geregeld door de hoster (tenminste, daar ga ik wel van uit). Dit ook aangezien zij beweren dat alles in orde is en de DNS-records in de DirectAdmin omgeving bij hoster 2 ook de IP-adressen van de nameservers weergeven.
Ik heb een dergelijke actie al meerdere malen uitgevoerd en dit ging altijd zonder problemen. Alleen vandaag kreeg ik twee andere nameservers door dan ik altijd had doorgekregen. Mijn vermoeden is dat het toch ergens in de configuratie van de nameservers zou kunnen liggen.
Uiteraard kan dat, maar ik heb de nameservers alweer aangepast naar hoster 1, zodat de website gewoon weer te bereiken is.
Ik denk niet dat jij een DNS flush kunt doen.
Dat doe je als admin op een full resolver, die je zelf draait . Je kunt de cache van je modem (of pc) leeg gooien, maar niet de cache van de echte resolver die daarachter zit.
Alleen als je zelf een resolver draait kun je die echt flushen. Voor jou (niet voor de rest van de wereld).
Je kunt beter wat meer over DNS leren, dan kun je meteen opzoeken wat in welke DNS server staat en zien dat dat goed staat.
Als je domeinnaam geeft, en namen van de DNS'en waar het domein naar toe moet gaan (en liefst al in staat) dan kunnen we wat debuggen.
Als we ervan uitgaan dat de nieuwe nameservers correct zijn geconfigureerd dan is de vraag hoeveel tijd en welke stappen er genomen zijn om de site over te zetten.
Het beste is om de nieuwe nameservers op de oude omgeving in te stellen met een lage TTL en dan een paar uur (bijvoorbeeld een nacht of 6 uur) later de site over te zetten naar de nieuwe omgeving.
Daarna de Glue records pas wijzigen naar de nieuwe nameservers. Zo zal de down-time of tijd dat je de website niet ziet vrij kort zijn.
TS heeft zo te zien een vrij makkelijk scenario, want er is blijkbaar ruime overlap tussen het beschikbaar hebben van een server bij de nieuwe hoster en het weg moeten zijn bij de oude.
Als er geen onderliggend transactie systeem onder zit wat absoluut consistent moet blijven kan hij gewoon de oude en nieuwe server ophouden, DNS rustig omzetten en na een tijdje de oude server uitzetten.
Eitje, en zero downtime als hij 't goed doet.
Zitten er wel transacties onder zal hij idd de oude site moeten disablen, transacties overzetten en de nieuwe activeren,DNS omzwaaien. Dan heb je een kort window waarin de site niet, of niet volledig beschikbaar is voor een plukje bezoekers.
Ik heb op diverse verbindingen een dns-flush uitgevoerd (lang leve 3 verschillende internet verbindingen met verschillende providers op het werk). Uiteindelijk, na de reguliere refresh van het DNS-record, kon ik weer gewoon de website bereiken. Ook zag ik het resultaat terugkomen op de diverse online NS-lookup websites. Hierna werkte een nslookup commando op mijn eigen PC ook weer.
De glue-records zijn geregeld door de hoster (tenminste, daar ga ik wel van uit). Dit ook aangezien zij beweren dat alles in orde is en de DNS-records in de DirectAdmin omgeving bij hoster 2 ook de IP-adressen van de nameservers weergeven.
Ik heb een dergelijke actie al meerdere malen uitgevoerd en dit ging altijd zonder problemen. Alleen vandaag kreeg ik twee andere nameservers door dan ik altijd had doorgekregen. Mijn vermoeden is dat het toch ergens in de configuratie van de nameservers zou kunnen liggen.
Uiteraard kan dat, maar ik heb de nameservers alweer aangepast naar hoster 1, zodat de website gewoon weer te bereiken is.
Geef toch maar.
Zo te lezen ben je bezig om ook andere DNS servers te gaan gebruiken bij het verhuizen van je site.
(die twee uur windows zijn precies het update interval van sidn ) .
Je domein kan prima in die andere DNS servers staan, met nieuw IP , en die config kan dan gecontroleerd worden.
Pas als je de NS records bij SIDN voor je domein wijzigt wordt die configuratie effectief.
Je kunt dus alles voorbereiden zonder dat je bezoekers het merken.
Test ook je nieuwe server door bv het IP adres ervan op je compu even in /etc/hosts te zetten met de server naam. Dan kun je zien of je site het doet op de nieuwe server.
Je andere DNS servers test je met 'dig' .
Ik zal het proberen uit te leggen, voor zover ik het duidelijk kan uitleggen:
Op dit moment draait de site bij Versio. Hier gebruik ik de nameservers ns59.axc.nl en ns60.axc.nl
Ik maak via DirectAdmin een backup van de complete site, inclusief MySQL DB, emailaccounts, etc, etc.
Daarna importeer ik deze backup in de DirectAdmin omgeving bij de nieuwe hoster. Echter vink ik de optie uit om de DNS en MX-records te restoren (zoals mij is aangegeven).
Nadat de complete restore is uitgevoerd, verander ik bij Versio de beide nameservers naar de nieuwe nameservers. In dit geval zijn dat de ns1.correcthosting06.nl en ns2.correcthosting06.nl
Die twee uur zijn inderdaad de update interval van het SIDN. Echter zodra deze update interval voorbij is, is de site dus totaal niet meer bereikbaar.
Zoals aangegeven heb ik, nadat de omzetting is gedaan een test gedaan via de website intodns.com. Hierbij zie je, volgens mij, duidelijk dat er om de één of andere manier geen A-records zijn / worden aangemaakt voor het domein.
Ik heb een screen van deze website bijgevoegd.
Het voordeel dat ik heb, zoals je al aangaf, is dat er inderdaad geen druk zit om de domeinnaam weg te halen bij Versio. Ik wil deze daar alleen weg hebben omdat de snelheid van de websites die daar worden gehost, af en toe dramatisch is (maar dat is een andere discussie).
En Visser: je hebt inderdaad gelijk dat ik wel wat meer inzicht kan krijgen in hoe hosting en alles daarom heen werkt. Daarom heb ik ook dit topic aangemaakt om ervan te kunnen leren. Het beheren van webservers laat ik ook met plezier over aan degene die er echt volledig verstand van hebben :TLW. Maar ik wil er wel graag iets meer van leren.
Echter vink ik de optie uit om de DNS en MX-records te restoren
Hier zit de oplossing. Je moet op de nieuwe server natuurlijk wel DNS en MX records aanmaken (door te restoren). Anders zijn die er niet en kan je de website niet bereiken na het omzetten van de nameservers in de Whois.
Met "dig any s*cp*gn*.nl @ns1.correcthosting06.nl" (vanaf je mac of linux werkplek) kun je kijken of ze er zijn.
Hier zit de oplossing. Je moet op de nieuwe server natuurlijk wel DNS en MX records aanmaken (door te restoren). Anders zijn die er niet en kan je de website niet bereiken na het omzetten van de nameservers in de Whois.
Ik heb even via DNS-magenement gekeken op het domein bij c*rrecthosting. Daar staan echter wel de correcte records opgenomen. Dus ook het correcte A-record, etc.
Het vreemde is dat ik dergelijke acties al wel vaker heb gedaan. Echter wel met andere nameservers. En daarbij ook de opties om de DNS en MX-records te restoren niet aangevinkt. Dat is altijd zonder problemen gegaan.
Misschien een open deur, maar wat zegt de van correcthosting? Dit is namelijk heel simpel om correct op te lossen.
Volgens mij is de zone voor voor jouw domeinnaam niet toegevoegd op de nieuwe nameserver. Een nslookup met de NS-servers van correcthosting als resolvers geeft geen resultaat voor jouw domeinnaam..
Je kunt dit zelf testen in de Windows cmd door het gebruik van nslookup domein ns1.correcthosting06.nl.
ns1.correcthosting06.nl. ['87.233.188.48'] [TTL=7200]
ns2.correcthosting06.nl. ['87.233.188.49'] [TTL=7200]
Beiden blijken in hetzelfde netwerk te zitten,ook al zegt intodns.com blijkbaar van niet?
Als je een traceroute doet, zie ik ze uitkomen bij hetzelfde.
Misschien een open deur, maar wat zegt de van correcthosting? Dit is namelijk heel simpel om correct op te lossen.
Ik heb het ook al aangegeven bij de reseller van wie ik het pakketje afneem. Hij zou er verder mee aan de slag gaan :)
ns1.correcthosting06.nl. ['87.233.188.48'] [TTL=7200]
ns2.correcthosting06.nl. ['87.233.188.49'] [TTL=7200]
Beiden blijken in hetzelfde netwerk te zitten,ook al zegt intodns.com blijkbaar van niet?
Als je een traceroute doet, zie ik ze uitkomen bij hetzelfde.
Gezien de IP nummers en naamgeving denk ik dat de kans groot is dat ze op 1 server uitkomen (en als mijn vermoeden klopt staat de site op "server 06" van correcthosting). Overigens geven de naamservers van Versio ook het idee dat ze op de server zelf staan.
Iedereen die vandaag de dag nog denkt dat dat vereist is heeft misschien behoefte aan een op fris cursus. De eerste verwijzing van AXFR die ik net heb gevonden is uit 1983 (RFC883)...
Ik zal het proberen uit te leggen, voor zover ik het duidelijk kan uitleggen:
Op dit moment draait de site bij Versio. Hier gebruik ik de nameservers ns59.axc.nl en ns60.axc.nl
Ik maak via DirectAdmin een backup van de complete site, inclusief MySQL DB, emailaccounts, etc, etc.
Daarna importeer ik deze backup in de DirectAdmin omgeving bij de nieuwe hoster. Echter vink ik de optie uit om de DNS en MX-records te restoren (zoals mij is aangegeven).
Nadat de complete restore is uitgevoerd, verander ik bij Versio de beide nameservers naar de nieuwe nameservers. In dit geval zijn dat de ns1.correcthosting06.nl en ns2.correcthosting06.nl
Die twee uur zijn inderdaad de update interval van het SIDN. Echter zodra deze update interval voorbij is, is de site dus totaal niet meer bereikbaar.
Zoals aangegeven heb ik, nadat de omzetting is gedaan een test gedaan via de website intodns.com. Hierbij zie je, volgens mij, duidelijk dat er om de één of andere manier geen A-records zijn / worden aangemaakt voor het domein.
Ik heb een screen van deze website bijgevoegd.
Het voordeel dat ik heb, zoals je al aangaf, is dat er inderdaad geen druk zit om de domeinnaam weg te halen bij Versio. Ik wil deze daar alleen weg hebben omdat de snelheid van de websites die daar worden gehost, af en toe dramatisch is (maar dat is een andere discussie).
En Visser: je hebt inderdaad gelijk dat ik wel wat meer inzicht kan krijgen in hoe hosting en alles daarom heen werkt. Daarom heb ik ook dit topic aangemaakt om ervan te kunnen leren. Het beheren van webservers laat ik ook met plezier over aan degene die er echt volledig verstand van hebben :TLW. Maar ik wil er wel graag iets meer van leren.
Er zijn denk ik genoeg tutorials, maar ik heb niet meteen een link naar een goede voor je.
Er is wel een enorme berg misverstanden en voodoo verhalen over TTLs en caching en flushen die deels ook hier langs kwam.
Daarom zal ik maar een korte uitleg tikken hier.
DNS is een hierarchische boom .
De top is de root, en dat is de '.' . Daaronder zitten de toplevel (.com,.net) en country-toplevels (.nl,be) . En daaronder de geregistreerde domeinen , subdomeinen en hosts. (jouwdomein.nl , www.jouwdomein.nl ).
Elk bovenliggend niveau heeft informatie over nameservers voor lagere niveaus .
De root nameservers hebben NS records voor toplevel en country toplevel nameservers, en die levels hebben weer NS records voor de domeinen eronder , en zo voorts.
Een dns *resolver* is de DNS server die je instelt op je PC/router (of meekrijgt met dhcp) en doorloopt die boom als je vraagt naar het IP adres wat bij een naam hoort.
Die resolver cached antwoorden die hij eerder opgezocht heeft voor een bepaalde tijd. De hint voor hoe lang te cachen is wat in de TTL bij een DNS antwoord zit.
Zo'n resolver staat bij een provider, voor veel mensen is het google (8.8.8.8) of OpenDNS.
Je kunt nog een forwarding resolver ertussen hebben, dat is meestal dns servertje in een thuisrouter. Die cached ook, en die kun je wel flushen. Maar dat helpt niet voor de resolver van de provider, en nog minder voor de google resolver of resolvers bij andere ISPs.
Het eerste kip en ei probleem is dat de (full) resolver moet weten waar te beginnen, en dat is een statische lijst van 13 magische IP adressen waar de root servers op zitten. (de hints file ).
Het tweede kip en ei probleem is wanneer een nameserver binnen het domein valt waar hij authoritief voor is.
De root nameservers geven bijvoorbeeld ns1.dns.nl (e.a.) mee als NS voor .nl .
De NS voor dns.nl zou je aan een NS voor .nl moeten vragen, en dat is ns1.dns.nl .
Deze oplossing heet 'glue record', en dat is de term voor het meegeven van het IP adres van DNS als die binnen zijn eigen zone valt.
Let op : dat doe je dus alleen als de server binnen zijn eigen zone zit.
In jouw geval (DNSen van je provider voor een domein) is er dus geen sprake van glue records.
Met 'dig' kun je ook direct aan een DNS server vragen stellen, en kun je dus kijken wat een authoritieve server zegt zonder dat je antwoorden uit de cache van een resolver krijgt .
En vooral, je kunt wat een server zegt die de zone heeft, maar waar bovenin de boom nog niet naar toe gedelegeerd is.
Zo weet je of die server de zone echt binnenheeft zonder dat je ernaar om moet zetten en minimaal twee uur wachten om weer terug te zetten.
(het kan ook met nslookup, maar dat was erg lang deprecated. Anyway, dig heb ik sindsdien in de vingers en gebruik ik als voorbeeld )
In jouw geval zou ik gedaan hebben :
Opzetten van je server bij je nieuwe provider, en dns instellingen bij je nieuwe provider zetten.
Nu nog niet de DNS ook omzetten !
dig www.jedomein.nl @ns1.nieuweprovider.nl
dig www.jedomein.nl @ns2.nieuweprovider.nl
dig SOA jedomein.nl @ns1.nieuweprovider.nl (+ andere NSen natuurlijk)
dig NS jedomein.nl @ns1.nieuweprovider.nl
dig MX jedomein.nl @ns1.nieuweprovider.nl
Krijg je geen antwoord, dan ga je dat eerst goed oplossen voordat je maar denkt aan omzetten.
De antwoorden moeten zijn wat je ingesteld heb in je control panel.
gebruik je dig zonder een @server , dan vraag je het aan/via je eigen resolver.
Meekijken met de hele bevraging:
dig +trace www.jouwdomein.nl
recap : voordat je gaat verhuizen zet je de TTL van alle records die je wilt gaan wijzigen laag. (ik zou zeggen 300 of 600 seconden ) .
Dat doe je zolang tevoren als de oude TTL was.
Was de TTL 1 dag, doe je dat 1 dag tevoren.
Doe dat voor alle records die je gaat veranderen. (bij jou dus ook ns records, soa etc ).
Wat jij al zou kunnen doen is je webserver verhuizen, en in de zone (ook bij je oude provider) het nieuwe IP adres zetten.
Dan is de webserver verder klaar en verhuisd.
Richt nu de zone in bij je nieuwe provider.
Test uitgebreid door met dig (zie boven) te controleren dat de nieuwe dns servers antwoorden over je zone geven.
Verander dan nu de NS records bij sidn voor je zone met daarin de nieuwe dns servers.
Controleer dat alles werkt (ook met dig, want je wilt nu geen antwoorden van de cache).
Nu ben je om en bijna klaar.
Verander nu de TTL weer naar meer normale waarden.
En nu kun je alles opzeggen en afbreken bij je oude provider.
(let op je ook administratief los bent, hierboven heb je alles technisch weggehaald ).
systemdeveloper
05/03/14, 23:45
Kort noemt ie dat...
Kort noemt ie dat...
Wel, vergeleken bij wat er nog meer te vertellen zou zijn ..... ;)
Maar er staat precies genoeg in om de dingen waar TS tegenaan liep mee te onderzoeken en op te lossen.
systemdeveloper
06/03/14, 00:27
Wel, vergeleken bij wat er nog meer te vertellen zou zijn ..... ;)
Maar er staat precies genoeg in om de dingen waar TS tegenaan liep mee te onderzoeken en op te lossen.
Haha, true. Ik heb hier boekwerken genoeg over DNS. Eigenlijk ongelofelijk hoeveel er te schrijven valt bij iets dat op het eerste oog zo 'normaal' is :)
Visser; hartelijk dank voor de duidelijke uitleg. Een zeer groot gedeelte was al bij mij bekend. Maar nogmaals dank voor de refresh cursus.
Op dit moment heb ik een resultaat vanuit intodns.com doorgestuurd naar de reseller. Omdat we er niet snel aan uitkwamen waar het probleem door wordt veroorzaakt, is er besloten om de domeinnaam op een andere server te plaatsen. En hierbij ook een andere nameserver.
Vermoedelijk is er iets mis gegaan bij het aanmaken van het A-record op de nameserver ns1.correcthosting06.nl of ns2.correcthosting06.nl. Dit zou men nog verder gaan uitzoeken.
Omdat ik wel benieuwd ben naar de oorzaak heb ik gevraagd of ik de oorzaak zou mogen weten. Daarop nog geen antwoord gekregen.
patrickekkel
06/03/14, 17:04
Visser; hartelijk dank voor de duidelijke uitleg. Een zeer groot gedeelte was al bij mij bekend. Maar nogmaals dank voor de refresh cursus.
Op dit moment heb ik een resultaat vanuit intodns.com doorgestuurd naar de reseller. Omdat we er niet snel aan uitkwamen waar het probleem door wordt veroorzaakt, is er besloten om de domeinnaam op een andere server te plaatsen. En hierbij ook een andere nameserver.
Vermoedelijk is er iets mis gegaan bij het aanmaken van het A-record op de nameserver ns1.correcthosting06.nl of ns2.correcthosting06.nl. Dit zou men nog verder gaan uitzoeken.
Omdat ik wel benieuwd ben naar de oorzaak heb ik gevraagd of ik de oorzaak zou mogen weten. Daarop nog geen antwoord gekregen.
Bij een hoster die zijn zaakjes goed op orde heeft zou dat helemaal niet nodig zijn.
En al helemaal niet als men met gescheiden dns servers werkt.