realme Smart TV | Ægte billede Ægte lyd

Når jeg køber et domæne, bliver jeg altid forvirret mellem de to og formår at ødelægge indstillingerne, før jeg endelig får det rigtigt, men stadig uden klart at forstå, hvad deres roller er i at hjælpe med at rette et domænenavn til IP-adressen for min webhost server.

  • DNS -> Domain Name System, også kendt som Name Server

Svarene hidtil skriver om navneservere og DNS, som om de var to forskellige ting. Det er de ikke. En DNS-server er en navneserver. Der er andre navnetjenester, f.eks. Corbas COSNaming, RPC Portmapper, Java RMI Registry osv., Men DNS er det, der normalt menes.

I modsætning til hvad der er angivet i andre svar, DNS indeholder DNS-posterne.

  • Fra et webmasters perspektiv skal NS-poster og A (eller CNAME) -optegnelser gå forskellige steder. Det er almindeligt at henvise til den første som "opsætning af din navneserver" og sidstnævnte som "opsætning af din DNS." Mens du har ret i, at begge er DNS-servere, ville det være lærerigt at medtage oplysninger i dit svar om, hvordan de to bruges, og hvordan de er relateret.
  • 3 Spørgsmålet var "Hvad er forskellen mellem navneservere og DNS", ikke "Hvad er forskellen mellem navneservere og DNS * servere *" . Svaret er: DNS er det komplette system, en navneserver er bare en del af dette system.
  • @DarkDust Præcis mit punkt.
  • Titlen var dårligt skrevet. Jeg præciserede det for at matche spørgsmålet.
  • 2 @StephenOstermiller Jeg er uenig i din redigering. Der er ingen omtale af NS-poster i spørgsmålet. Hvad din kommentar laver under mit svar er et andet spørgsmål.

Jeg tror, ​​at det for at afklare, hvad der foregår, hjælper med at have et overblik.

Den første ting at huske på er, at internettet kører på IP-adresser, men folk vil hellere huske ord (domæner) end tal. Dette er et nøgleproblem, som DNS forsøger at løse. En anden ting, som dette lader dig gøre, er at ændre din servers IP gennemsigtigt. Dette er fantastisk for webstedsejere som dig og mig, fordi vi kan skifte hostingudbydere uden at påvirke vores brugeres evne til at oprette forbindelse til os. Så alt i alt lader DNS os kortlægge tal til ord (domæner), hvilket er godt for både webstedsejere og brugere.

Med den base, lad mig besvare dit spørgsmål. EN navn server er den autoritative kilde til at oversætte navnet (domænet) på dit websted til tallene. Så du skal fortælle verden, hvor du skal hen for at finde ud af oplysningerne om dit domæne. Disse oplysninger lagres hos de samme personer, der vedligeholder det centrale lager for alle domænenavne, der er købt ICANN.org, og der kan søges i deres WHOIS-database.

Så nu hvor vi har fortalt folk, hvor de skal finde vores navneserver, skal vi fortælle vores navneserver, hvor de skal sende folk. Dette "hvor skal man sende folk" -problemet håndteres af vores andre DNS-indstillinger, som A-post, AAAA-poster, CNAME, MX osv.

Du kan visualisere disse ting som links i en kæde:

  1. Du køber et domænenavn.
  2. Du skal definere den autoritative kilde til oversættelse af domænenavnet til en IP-adresse, så du angiver din navneserver / DNS.
  3. På din navneserver / DNS skal du angive alle de routinginstruktioner, der er relevante for dit websted, såsom IP-adressen.
  4. Dine kunder dirigeres med succes til dit websted, hvor du tjener millioner af dollars og har masser af tilfredse kunder.

For at sætte dette konkret, når du køber et domæne gennem en registrator, vil de sandsynligvis standard til registratorens standardnavneservere.

Hvis du er glad for at lade din registrator være ansvarlig for dine DNS-poster (mest almindelige):

  • Du behøver ikke at røre ved navneserverne
  • Du foretager alle DNS-postopdateringer (A-post, CNAME osv.) Via din registrator.

Hvis du beslutter, at du vil have en anden til at administrere dine DNS-poster (ikke-typisk for små websteder):

  • Du bliver nødt til at opdatere navneserverne på din registrator for at pege på de navneservere, som det nye firma giver dig.
  • Du skal foretage alle DNS-postopdateringer via det nye firma.

Enkelt sagt:

Navneserveren fortæller internettet, hvor DNS-posterne er placeret, f.eks. ns1.example.com og ns2.example.com

Derefter DNS kl example.com fortæller internettet, hvor man kan finde forskellige tjenester. A-posten er webstedets IP-adresse. MX-posten er placeringen (e) af mailserverne og den rækkefølge, som de skal vælges i.

Oftere end ikke peger DNS-posterne til serveren, hvor de er placeret, dvs. dit websted og din e-mail er hostet, hvor navneserverne peger. Dette gør det meget lettere for nybegyndere.

Der er MEGET mere, der kunne medtages om DNS, såsom at der er andre poster for forskellige funktioner, men det er ikke det, spørgsmålet handler om, så jeg vil ikke tilføje mere kompleksitet.

  • Der er andre svar her, og de har for det meste ret. Mit forsøg var at forklare det i enkle vendinger for nogen, der ikke forstår konceptet, ikke går så meget i dybden. Det er for en anden gang, regner jeg med.
  • Hvad mener du med Navneserveren fortæller internettet, hvor DNS-posterne er placeret? Dette kan være korrekt eller forkert, afhængigt af hvad du mener.
  • Hvad mener du med "Så fortæller DNS på eksempel.com internettet, hvor man finder forskellige tjenester"?

Det korte svar er, at en DNS og NS (navneserver) er mere eller mindre den samme, men ikke rigtig. Udtrykket Navneserver henviser til en rolle, som en DNS-server opfylder.

En DNS-server er en form for databaseopslagstjeneste, der tildeler forskellige poster til værdier, der skal returneres afhængigt af forespørgslen. Duh! Højre? Dog kan en DNS bruges til mange ting udover at oversætte domænenavne til IP-adresser og de forskellige poster, der er knyttet til det. En DNS kan bruges til andre formål, hvor et hierarkisk skema skal repræsenteres.

Uanset hvad det er, er en navneserver en DNS-server, og udtrykket navneserver gælder for IP-baserede netværk, især for internettet. Typisk har en NS autoritative svar på DNS-forespørgsler på et IP-netværk. Udtrykket NS er specielt for Internettet, da IP-protokollen og DNS først blev udviklet til ARPA-Net og derefter overført til Internettet. Private IP-baserede netværk fulgte.

Så mens en NS teknisk set er en DNS, henviser den faktisk til de mange autoritative DNS-servere, der returnerer IP-adresser tildelt ethvert domænenavn og de tilknyttede poster / værdier. En NS kaldes andre NS-servere for at være medlem af det autoritative hierarki af DNS-servere, der begynder med rodnavneserverne. Enhver DNS, der ikke er inden for dette definerede hierarki, er kun en DNS og ikke en navneserver.

For eksempel var jeg en webhost i lang tid. Jeg havde mange DNS-servere, men kun to var navneservere. Mens hver af 5 eksternt tilgængelige DNS-servere havde de samme poster, blev kun to spurgt autoritativt, når nogen ville indtaste et domænenavn i deres browser og derfor navneservere. De resterende eksternt tilgængelige DNS-servere var ikke-autoritative. For at give adgang fra værtsnetværket, hvor eksterne IP-adresser var hostet på routeren eksternt for værtsnetværket, blev der også brugt en intern DNS. Denne interne DNS ville indeholde de samme poster som de eksternt tilgængelige DNS-servere, bortset fra at IP-adresserne var interne i værtsnetværket. Mit punkt ville være, at selvom jeg ville kalde de interne DNS eller ikke-autoritative eksterne DNS'er, en DNS-server, kunne jeg ikke med rette kalde dem en navneserver, da de ikke er en del af det autoritative hierarki, der udgør Internettet.

En typisk måde at vide, om en DNS er en NS, er at lede efter en SOA-post, når du forespørger om et domænenavn på Internettet. Alle andre er kun DNS-servere. For at gøre tingene mere forvirrende kan enhver DNS dog have en SOA-post, når den bruges dig med +trace option, returneres kun de ægte autoritative navneservere, der indeholder de officielt anerkendte SOA-poster, og ikke andre.

  • DNS er et løst defineret udtryk, og nogle bruger det til at betyde "Domain Name System", mens det for andre er "Domain Name Service" eller "Domain Name Server". Det hele afhænger af sammenhængen, men "Domain Name Server" og "Name Server" er bare synonymer, og suffikset "Domain" er ubrugeligt. Alle autoritative navneservere svarer med SOA-poster for de domæner, de administrerer, dette er pr. Definition. De er kun relevante, hvis forælderzonen viser dem som autoritative. Ellers er de bare servere, som ingen implicit spørger, mens de stadig er NS / DNS / navneservere i den forstand, at de taler DNS-protokollen.
  • @PatrickMevzek Sagde med et smil, jeg er enig! Skål min ven!!

For at følge fra start til slut, hvis jeg vil føje en MX-post til min DNS, så klienter kan sende e-mail til mig:

  1. Jeg bruger en webgrænseflade eller kontakter min navneserverudbyder for at ændre mine poster.
  2. Domain Name System-server opdaterer regelmæssigt deres ENORME database med domæner> IP'er ved at tale med navneservere. Den nøjagtige timing afhænger af opsætningen. Nogle gange er det 5 minutter, andre gange kan det være 24-48 timer.
  3. Når DNS har fået tilføjet min nye MX-post, kan klienter, der opretter forbindelse til den specifikke DNS, nu sende mig e-mail.

En klient opretter forbindelse til en DNS-server for at ændre domænenavne til IP-adresser. Sådan går du fra Eksempel.com> '11 .22.33.44 '. En IP-adresse kræves for at kommunikere med den server, der er registreret med det navn.

DNS-servere (Domain Name System) opretter forbindelse til navneservere for at kompilere deres database. Forskellige registratorer og andre tjenester opretholder lister over, hvor man finder detaljerne i de aktuelle domæner> IP-tabeller. Klienter gør ikke dette, kun DNS-servere.

Når du ændrer din navneserver, ændrer du, hvem der styrer dit domænes optegnelser. Hvis jeg skifter fra en navneserver, der ejes af firma X til firma Y, skal jeg nu beskæftige mig med firma Y, når jeg opdaterer mine optegnelser.

  • 3 Terminologi. DNS står for domænenavn system (ikke server), hvilket er: roddomæne plus et rigt hierarki af dets børn. Du tilføjer MX til dit domæne (eller til din zone), ikke til dit "domænenavn system". Medmindre du har et sådant privat system.
  • 1 Dette indlæg er grundlæggende unøjagtigt. Rekursive opløsere (som dette indlæg forkert henviser til som "Domain Name System-servere") modtager ikke periodiske opdateringer fra autoritative navneservere - de henter poster efter behov og kasserer cache-værdier baseret på postens TTL.
  • "Domain Name System-server opdaterer regelmæssigt deres ENORME database med domæner> IP'er ved at tale med navneservere. Den nøjagtige timing afhænger af opsætningen. Nogle gange er det 5 minutter, andre gange kan det være 24-48 timer." Dette er helt forkert, som usant, og det gennemsyrer myten om "udbredelse", som hvis DNS er ovenfra og ned for spredning af opdateringer, hvilket ikke er, som skumringssvamp klart anførte. Også DNS ​​er ikke kun navnet på IP-adressekortlæggelser, der er langt mange andre poster i det. "DNS-servere (Domain Name System) opretter forbindelse til navneservere for at kompilere deres database." absolut ikke.

Hvad er navneservere?

I forbindelse med administration af dit domæne (r), Navneservere er autoritative DNS-navneservere til dit domæne (f.eks. coolsite.com). De har NS-poster.

Praktisk set er de ansvarlige for at fungere som et referencepunkt for at vende tilbage de faktiske DNS-poster der kortlægger en bestemt domæne-URL (f.eks. www.coolsite.com) til en bestemt IP-adresse (f.eks. 99.100.101.102).

Overforenklet lidt handler "andre DNS-servere" generelt for at hjælpe med at opfylde det generelle mål om at returnere relevante DNS-poster for et givet domæne.

Hvad er DNS?

Per Wikipedia:

Domain Name System (DNS) er et hierarkisk decentraliseret navngivningssystem til computere, tjenester eller andre ressourcer, der er forbundet til internettet eller et privat netværk.

I almindelighed henviser "DNS" ofte til processen med at opbevare og betjene dit domænes særlige DNS-poster. Dette inkluderer kørsel af "navneservere", som hjælper med at levere disse poster til alle, der spørger.

For at være klar betyder det effektivt, at "Navneservere" og "DNS" (eller "DNS-servere") ofte kun er dele af den samme tjeneste.

Der opstår en masse forvirring omkring det faktum, at næsten alle kan administrere dine DNS-poster (og dermed dine navneservere). Men mens du har brug for det nogen for at gøre det (selvom du selv kører navneserverne), er der ikke behov for nogen bestemt enhed.

Kan jeg se nogle smukke billeder?

For at hjælpe med at afklare stjal jeg en praktisk illustration og modificerede den for forhåbentlig at give en bedre idé om, hvordan processen med at anmode om en IP til dit givne domæne (f.eks. www.coolsite.com) fungerer muligvis:

Spring over DNS-record caching og abstraktion lidt (meget) ...

  • Root DNS-serveren (trin 3-4) indeholder oplysninger om, hvor man finder den relevante Generic Top Level Domain (gTLD) -server, der bruges i trin 5-6.

  • Selve gTLD-serveren (trin 5-6) indeholder oplysninger om navneservere. I dette tilfælde vil vi tale med den server, der håndterer alle * .com domæner. Dette skyldes, at anmodningen er på udkig efter www.coolsite.com og vi har brug for at kende navneserverne, der er knyttet til det.

  • I trin 7, anmodningen langt om længe bliver dirigeret til dine navneservere ("DNS"). I dette eksempel dns1.provider.com eller dns2.provider.com hjælpe med at returnere en DNS-post (trin 8-9) til klienten. Denne rekord kan se ud som:

    coolsite.com. IN A 99.100.101.102 ; An 'A' record e.g. an IP from ABC Hosting www IN A 99.100.101.102 ; More commonly a 'CNAME' entry 

    Dette fortæller os det www.coolsite.com er placeret på 99.100.101.102 (f.eks. din webhosting-udbyder), og klienten kan nu kontakte denne IP direkte (trin 10).

  • Navneserverne (trin 7-8) kan håndteres af enhver - dig, din webhostingudbyder, din registrator, kun DNS-udbydere, den imaginære enhjørning på din sofa, der i hemmelighed ejer en regnbuefarvet serverfarm i skyerne .. .

  • Bemærk, at trin 10 udelader mange detaljer ;-)

Men hvad sker der, når jeg opdaterer mine navneserverposter?

Når du opdaterer dine navneserverposter i din registrators domænenavnkontrolpanel, opdaterer du (i en rund vej) faktisk en gTLD-server (vist tidligere i trin 5-6).

Når de korrekte korrekte gTLD-servere er opdateret med dine navneserveroplysninger, træder registratoren ud af den del af processen.

Dette kan være forvirrende, fordi mange registratorer nu tilbyder "DNS-tjenester" (trin 7-8) adskille fra deres registraraktiviteter (fx hjælp til opdatering af gTLD-serverne).

For at gentage, returnerer en gTLD-server (ikke din registrator eller anden DNS-udbyder) svaret på forespørgsler om dit domænes navneservere (uanset hvad du sidst indtastede hos din registrator).

Eks. Registrar Domain Control Panel (navneservere)

Eks. Hvilke registratorer domæenkontrolpaneler faktisk opdaterer (navneservere)

  • Hvorfor koncentrere eller endda udelukke alt andet end gTLD'er? Dit svar skal omskrives ved at tale om TLD'er. Der er ikke kun gTLD'er derude, og de "andre" fungerer nøjagtigt på samme måde.

DNS (Domain Name Service) er en SERVICE.

Navneservere findes i mange varianter.

  1. Root-navneservere -

En udvalgt gruppe af navneservere, der er på faste ip-adresser, der er spredt over hele verden. De indeholder de DNS-poster, der peger på de aktive navneservere på topniveau-domæne (TLD).
Eksempler på TLD-domæner er '.com', '. Org', '. Ca'

  1. Top-niveau-domæne (TLD) navneservere

Disse er navneservere, der indeholder DNS-poster, der peger på den aktive liste over autoritative navneservere til domæner i deres TLD.

(Sidebemærkning - De burde virkelig kaldes 'underdomæner' i deres TLD ... men de fleste bliver forvirrede, når denne terminologi bruges ... da de fleste mennesker er vant til at henvise til 'google.com' som et domæne og ikke er bruges til at kalde 'com' et domæne)

TLD-navneserveren '.com' ville have autoritative navneserverposter for domænerne anført nedenfor

  • google.com
  • amazon.com

    men ikke til

  • google.ca

Eksempler på domæner i TLD'erne er 'google.com', 'amazon.com', 'google.ca'

  1. Autoritative navneservere

Navneservere, der indeholder DNS-poster for et fuldt kvalificeret domænenavn (FQDN). Et eksempel på en FQDN er 'www.google.com'. Den indeholder både en 'værtsdel' ('www') og en domænedel ('google.com').

Eksempler på de typer optegnelser, der findes på en autoritativ navneserver, ville være - 'SOA' -post, der indeholder et serienummer, der blandt andet bruges til revisionskontrol af alle poster i domænet.
(SOA = Start of Authority-post) - 'A' -post, der indeholder ip-adressen, der er knyttet til et 'værtsnavn'. Et eksempel på et værtsnavn ville være 'www'. 'Værtsnavnet' antages at have domænet sammenkædet til slutningen af ​​det, medmindre værtsnavnet ender med et '.'
(A = adresseoptegnelse)

Der er mange andre DNS-poster mulige, men de tilføjer ikke noget til dette svar. Hver, hvis disse poster har et felt, der betegner 'Time-To-Live' (TTL), hvilket er det mindste antal sekunder, som en Caching-navneserver skal cache posten.

  1. Caching-navneservere

Disse navneservere har typisk ingen autoritative optegnelser. De modtager DNS-forespørgsler fra brugerne og har evnen til at gå rekursivt gennem DNS-strukturen beskrevet ovenfor for at løse en 'FQDN' til en 'IP'. For eksempel siger vi typisk

  • FQDN 'www.google.ca'

    beslutter at

  • IP '172.217.0.99'

Det gemmer denne opslagsopslag i en defineret tidsperiode (TTL) sammen med SOA-registreringen for det relaterede domæne. I løbet af denne definerede periode vil Caching Nameserver svare på eventuelle yderligere brugerforespørgsler til den samme FQDN med den IP, den har i sin cache.

Efter en defineret tidsperiode, hvis en bruger spørger efter den samme FQDN, vil Caching-navneserveren gå til DNS-strukturen, der er beskrevet ovenfor, og først hente SOA-posten for domænet. Hvis serienummeret på SOA-posten matcher det, det har i sin cache, antager det, at der ikke har været nogen ændringer i nogen DNS-poster for det domæne, så det bevarer og videresender det allerede cachelagrede resultat videre til brugeren og forlænger cachens levetid med yderligere TTL sekunder.

En almindelig fejl ved første gangs DNS-vedligeholdere er at IKKE OPDATERE SOA-recordens serienummer efter at have foretaget DNS-ændringer.

  • "s" står for "server" ikke "service"
  • 2 Forkert. Det står for Domain Name System.
  • Der er kun en forskel: rekursiv eller autoritativ navneserver. Rodnavneserverne er nøjagtigt som TLD-navneserverne og nøjagtigt som enhver anden autoritativ navneserver er der ingen mening at adskille dem (før du begynder at tale om forestillinger eller ledelse, da begrænsningerne her vil være forskellige). Det faktum, at rekursive navneservere har en cache, er nyttigt, men ikke obligatorisk, så cachedelen er ikke den vigtige del. Den rekursive natur er det vigtige træk og forskellig fra hvad autoritative navneservere gør.

Mens de fleste svar kommer til kernen i det (DNS og NS kan ofte kun være synonymer, afhænger det af konteksten, hvis vi ved, at vi er i domænenavnbranchen, D for Domain tilføjer ikke mere information), jeg tror, ​​der er et punkt, der ikke er adresseret, som måske eller måske ikke er relateret til dit spørgsmål, men dets formulering er ikke 100% klar, og det kommer måske også fra en uklar brugergrænseflade hos din registrator.

For terminologi i "DNS" -verdenen henvises nu til RFC 8499 "DNS-terminologi". Udtrykkene "in-domain" og "in-bailiwick" er defineret i det.

Autoritative navneservere på domænet

Når du registrerer et domænenavn eller senere opdaterer det, kan du angive et sæt navneservere, der er autoritative for det. Dette er i det mindste et sæt navne, men i nogle tilfælde (se nedenfor) er også tilknyttede IP-adresser på de navne, der peger på specifikke værtsnavne, hvor en DNS-server kører og korrekt konfigureres til at svare på forespørgsler om dette domænenavn.

Det er nødvendigt at "vedhæfte" navneservere til et domæne for at få det til at vises på det verdensomspændende internet, så dets lukkede tjenester (websted, e-mails osv.) Løses og dermed kan nås. Det er dog ikke obligatorisk, du kan helt have et domænenavn uden (autoritative) navneservere knyttet til det. Det er som om du parkerede domænet: det er registreret, ingen andre kan have det, men det har ingen tilgængelige kørende tjenester.

In-bailiwick navneservere

Helt adskilt fra den foregående sag, så snart du registrerer et domænenavn, f.eks example.com, kan du have navneservere under det eller i det, hvis du vil: du kan give en vært nogen navnet i-am-a-nameserver.example.com. Hvis du vil have, at navnet skal løses, selvfølgelig example.com skal have autoritative navneservere. Men i-am-a-nameserver.example.com kan være en navneserver til ethvert domæne, f.eks something-completely-different.example.

Nu er det vigtige punkt følgende: i de fleste (men ikke alle) TLD'er håndteres en navneserver (eller vært, i denne sammenhæng) som et objekt, og som sådan skal oprettes i registreringsdatabasen, som ethvert domæne eller kontaktperson, og dette sker gennem en registrar (enten den registrator, der sponsorerer det specifikke domæne, under hvilket du ønsker at oprette et navneserverobjekt, hvis dette domæne er i dette register, eller en hvilken som helst anden registrator, hvis du prøver at oprette et "eksternt" navneserverobjekt, det vil sige hvis du vil oprette ns.example.net hvor du faktisk er i .example TLD-registreringsdatabase).

Hvilket kan forklare, hvorfor du hos en eller anden registrator vil have et afsnit kaldet "Registrer en navneserver" eller noget tæt på det. Det vil være at oprette navneserverværtsobjekter i registreringsdatabasen under ethvert af dit domænenavn.

Det er måske her, hvor man skelner mellem hvad du så eller måske din forvirring.

Bemærk, at du kun skal konsultere dette afsnit, hvis du har brug for at oprette "ekstra" navneservere: enhver registrator, når du beder den om at registrere example.com med navneservere ns1.hello.example og ns2.foobar.examplemed automatisk at oprette (om nødvendigt) de 2 navneserverobjekter i registreringsdatabasen, inden domæner oprettes, eller i det mindste inden de tilknyttes disse navneservere til domænet (navneserverobjekter skal eksistere, før de kan bruge dem og vedhæfte dem som autoritative til dit domænenavn) .

Men for andre ekstra navneservere kan du bruge dette afsnit hos din registrator til at oprette navneserverne.

In-domain navneservere

Nu bliver plottet tykkere, og vi "fletter" de to tidligere sager: Du kan registrere domænenavn example.com OG brug som autoritativ navneserver for det ns.example.com (eller ethvert andet navn "nedenfor" example.comog faktisk example.com kunne også være et gyldigt værtsnavn for en navneserver, men dette er virkelig en sag, du foretrækker at undgå).

Dette har fordele og ulemper. Blandt ulemperne har du som konsekvens, at dette betyder, at opløsningen fungerer korrekt, at registreringsdatabasen skal offentliggøre en "limpost", som intet andet betyder end at offentliggøre IP-adresserne på ns.example.com på sit niveau (moderzonen for example.com). For at dette skal ske, skal du via registratoren registrere nameserver-objektet ns.example.com med IP-adresser. Selvfølgelig, hvis de ændres, skal du også opdatere dem på registreringsdatabasen, og manglende synkronisering er der en hyppig grund til, at sådanne opsætninger begynder at fejle.

Med din specifikke registrator

Du sagde

Når jeg køber et domæne, bliver jeg altid forvirret mellem de to

Men uden at specificere registratoren, så ingen kunne give dig specifikke instruktioner til dens specifikke brugergrænseflade.

Spurgte du det måske om instruktioner eller i det mindste at rapportere tilbage, at dets brugergrænseflade forvirrer dig? Forsøgte du at se på andre registrators brugergrænseflade? Måske vil en anden give dig en bedre oplevelse?

Registrator ≠ DNS-udbyder

Som for

hjælper med at pege et domænenavn til IP'en på min webhosting-server. dette tilføjer endnu et niveau af kompleksitet eller subtilitet i problemet og dermed svaret.

Hvis du går tilbage til ovenstående afsnit om autoritative navneservere, sagde vi, at du skal give nogle (ofte 2) autoritative navneservere, der skal knyttes til dit domæne, så det løser sig og dermed får alle tjenester på domænet til at fungere på Internettet.

Nu drives disse navneservere af en eller anden enhed. Denne enhed kan kaldes en DNS-udbyder, da dens opgave er at levere kørende navneservere til alle, der ønsker at bruge dem. Denne enhed kan være registrator, men behøver ikke være registrator.

Så snart domænenavnet er konfigureret til at bruge et specifikt sæt navneservere som autoritativt, for enhver ændring i indholdet af zonen (f.eks. "Peg et domænenavn til IP-adressen på min webhosting-server"), skal du gør ting gennem DNS-udbyderens brugergrænseflade, ikke gennem din registrator.

Du går til din registrator for at indstille eller ændre navneserverne, der er autoritative for dit domæne. Du går til din DNS-udbyder for at ændre indholdet af zonen, f.eks. Angive IP-adressen på dit websted.

Mange, hvis ikke alle, registratorer leverer DNS-service (gratis eller ej), og derfor kan du bruge dem, hvis du vil. Den umiddelbare fordel er normalt, at du har en enkelt destination at gå til for at styre alt, hvad du har brug for. Den øjeblikkelige ulempe er, at du har en enkelt destination at gå til for at administrere alt, hvad du har brug for, hvilket betyder ingen valg (med hensyn til serviceniveauer, priser osv.) Og større problemer, hvis du enten har et teknisk eller juridisk problem med den specifikke enhed .

Måske talte du også om, at registratorens brugergrænseflade (at være en DNS-udbyder) var forvirrende for dig, da du forsøgte at tilføje en A registrere (hvilket er hvad der er nødvendigt for at pege et navn til en IPv4-adresse).

arbejdet for dig: Charles Robertson | Ønsker du at kontakte os?