Afdrukvoorbeeld
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.
Ik heb het ook al aangegeven bij de reseller van wie ik het pakketje afneem. Hij zou er verder mee aan de slag gaan :)Citaat:
Oorspronkelijk geplaatst door t.bloo
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.Citaat:
Oorspronkelijk geplaatst door IT-worX
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)...
Er zijn denk ik genoeg tutorials, maar ik heb niet meteen een link naar een goede voor je.Citaat:
Oorspronkelijk geplaatst door nextware
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 ).
Kort noemt ie dat...
Wel, vergeleken bij wat er nog meer te vertellen zou zijn ..... ;)Citaat:
Oorspronkelijk geplaatst door systemdeveloper
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 :)Citaat:
Oorspronkelijk geplaatst door visser
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.
Citaat:
Oorspronkelijk geplaatst door nextware
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.