05/03/14 10:37
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.
05/03/14 10:53
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.
05/03/14 11:06
Ik heb het ook al aangegeven bij de reseller van wie ik het pakketje afneem. Hij zou er verder mee aan de slag gaanOorspronkelijk geplaatst door t.bloo
05/03/14 12:41
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)...
Tools die handig zjn voor ISPs vind je natuurlijk bij Tools 4 ISP.
05/03/14 22:07
Er zijn denk ik genoeg tutorials, maar ik heb niet meteen een link naar een goede voor je.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. Maar ik wil er wel graag iets meer van leren.
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 ).
05/03/14 23:45
Kort noemt ie dat...
SystemDeveloper.NL - 64BitsWebhosting.EU : Softwareontwikkeling & Hosting freaks
06/03/14 00:22
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.
06/03/14 00:27
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' isWel, 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.NL - 64BitsWebhosting.EU : Softwareontwikkeling & Hosting freaks
06/03/14 15:08
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.
06/03/14 17:04
Likes: 
Quote