| Linux – Friheden til systemadministration: Version 2.8.20060113 – 2021-01-07 | ||
|---|---|---|
| forrige | Kapitel 6. TCP/IP og DNS | næste |
På internettet ser man ofte adresser, som hedder noget i retning af www.smartnavn.dk. De 3 w'er står for World Wide Web. Internettet er verdensomspændende og nogle betragter det som værende et stort spindelvæv.
Men faktisk gemmer der sig en IP-adresse bag hver enkelt af disse web-adresser. Dette er dog ikke noget den normale bruger lægger mærke til. Men faktisk er det således, at der slet ikke eksisterer egentlige web-adresser. Det er udelukkende IP-adresser.
Når en bruger skriver en web-adresse i sin browser, anmoder hans computer en DNS-server om IP-adressen på den pågældende web-adresse. Det er kun IP-adresser, som er brugbare på et TCP/IP-netværk.
En DNS-server er en service som en server kan køre ved siden af de almindelige services. Hvis der er meget belastning, kan man vælge at have en DNS-server, som udelukkende kører DNS-service.
Hver gang DNS-serveren får en anmodning om en web-adresse, slår den web-adressen op i sin database og finder den tilhørende IP-adresse.
For at dette kan virke over hele verden, er der et vist system i det. Det går ud på, at hvert land har et domæne. Ligesom institutioner og firmaer i det pågældende land har et "underdomæne/subdomæne". For eksempel hedder SSLUG's domæne sslug.dk, hvilket er et subdomæne til .dk-domænet. 'dk' angiver Danmark.
Hos SSLUG har man så tilføjet et yderligere subdomæne, www. Den komplette adresse hedder således www.sslug.dk. Hvis man skriver denne adresse i sin browser, vil computeren automatisk spørge sin DNS-server om IP-adressen på domænet og herefter lave en webforespørgsel til IP-adressen.
Det vil sige at domænenavne er hierarkisk opbygget. Landet er øverst, derefter navnet på firmaet/institutionen (eventuelt i en forkortet udgave), og til sidst subdomænet som "peger" på serveren for domænet.
De øverste domæner i hierarkiet kaldes også TLD (Top Level Domains = Topniveau-domæner), og disse administreres af de såkaldte root-servere. En root-server besvarer kun forespørgsler på TLD-niveau. I dag eksisterer der på verdensplan 13 root-servere, som hver besvarer cirka 200 millioner forespørgsler om dagen.
Almindelige computere kommunikerer ikke direkte med root-serverne. De sender i stedet en web-adresse-forespørgsel til enten en lokal DNS-server, eller DNS-serveren hos deres internetudbyder.
Hvis vi forestiller os at DNS-serveren ns.sslug.dk som er ansvarlig for domænet sslug.dk, modtager en forespørgsel på subdomænet www.sslug.dk, ser serveren med det samme at det er det domæne som den selv er ansvarlig for, og kan derfor besvare denne forespørgsel uden at skulle kontakte andre DNS-servere.
Hvis serveren i stedet modtog en forespørgsel på subdomænet www.linux.dk ville den straks kunne se at det ikke var et domæne den selv var ansvarlig for. Den ville derfor være nødt til at starte med det øverste rent hierarkisk set. Serveren vil derfor indlede med at spørge en root-server om topniveau-domænet .dk, den vil af root-serveren blive bedt om at kontakte DK-Hostmasters server, som er ansvarlig for det domæne. DK-Hostmasters server vil henvise til serveren ns.linux.dk som er ansvarlig for domænet linux.dk. Serveren vil derfor ende med at få besvaret sit spørgsmål når den spørger ns.linux.dk.
Man kan betragte en DNS-server som en telefonbog, hvor personerne er web-adresser. Begge steder får man et nummer (telefonnummer/IP-adresse), som systemet kan bruge til at lokalisere informationen/personen.
For at begrænse DNS-trafikken benytter DNS-servere sig af DNS-cache. Her bliver de svar serveren har fået fra øvrige DNS-servere gemt. Hvis man gentog ovenstående eksempel, ville serveren derfor ikke starte forfra med at spørge alle serverne, men i stedet blot kigge på det foregående svar.
Eftersom der dagligt bliver lavet ændringer på mange servere, er det vigtigt at en DNS-server ikke tror den bare kan gemme sin cache evigt. Hvis eksempelvis www.sslug.dk bliver ændret til at pege på en anden webserver, vil det ikke være meget værd hvis vores DNS-server stadig fortæller alle og enhver hvad den hed førhen! Derfor har DNS-servere det man kalder en TTL (Time To Live), hvilket simpelthen definerer hvor lang tid et svar må leve. Hvis vores server igen modtager forespørgslen på www.sslug.dk, og TTL'en er udløbet, vil serveren være nødt til at starte forfra med at spørge de forskellige DNS-servere.
Som et konkret eksempel på et DNS-opslag kan vi f.eks. bede om SSLUG's IP-adresse. Til dette bruger vi kommandoen nslookup.
[tyge@hven ~]$ nslookup www.sslug.dk Server: danpost.uni-c.dk Address: 129.142.6.64 Non-authoritative answer: Name: sslug.sslug.dk Address: 130.228.2.150 Aliases: www.sslug.dk
Vi kan i eksemplet se, at vi beder danpost.uni-c.dk med IP-adresse 129.142.6.64 om adressen på SSLUG's webserver. SSLUG har IP-adressen 130.228.2.150, og maskinen er åbenbart også kendt som sslug.sslug.dk. Svaret er "Non-authoritative", idet danpost DNS-serveren ikke er herre over sslug-domænet, men har fået informationen fra en anden navneserver.
DNS indeholder også andre informationer end IP-adresser. I DNS-sprog sætter man et punktum bag navnene for at angive, at disse er absolutte. Normalt kan man dog ignorere det sidste punktum.
DNS er baseret på filer. Disse filer indeholder zone-data. I mange tilfælde indeholder hver fil/zone ét domæne, i det følgende kan man derfor blot betragte "zone" som et synonym for "domæne".
Navneserverne for en zone listes ved:
[tyge@hven ~]$ host -t ns sslug.dk sslug.dk name server ns-soa.darenet.dk sslug.dk name server ns.sslug.dk sslug.dk name server ptah.dkuug.dk
For at finde post-serverne for et domæne skal man kende en af navneserverne for domænet. Derefter spørger man denne navneserver:
[tyge@hven ~]$ host -t mx domæne.dk navneserver.for.domæne.dk
Den ansvarlige administrator for en zone findes i zonens SOA-record (eng. Start Of Authority). SOA-recorden findes med:
[tyge@hven ~]$ host -t soa domæne.dk navneserver.for.domæne.dk
Hvis SOA starter med: sslug.dk. IN SOA ns.sslug.dk. root.sslug.dk. ( så er zonen sslug.dk, den primære navneserver ns.sslug.dk og den ansvarlige administrators e-post-adresse root@sslug.dk (udskift første . med @).
Nogle navne er blot et alias for et andet navn: de har et kanonisk navn (eng: "canonical name"). Dette kan ses ved at spørge navneserveren for domænet om alt, hvad den ved om et givet navn:
[tyge@hven ~]$ host -t any dette.navn.domæne.dk nameserver.for.domæne.dk
Til nogle domæner er knyttet tekstinformation. Denne kan kaldes frem med:
[tyge@hven ~]$ host -t txt navn.med.info.domæne.dk
Hvis informationen er til stede, indeholder den ofte information om hvem der bestyrer navn.med.info.domæne.dk
Da DNS ikke er helt simpelt at sætte op korrekt, kan de ovenstående eksempler bruges, hvis du skal fejlfinde din egen DNS. De kan også bruges til at finde ud af, hvorfor netværksfejl opstår eller til at finde en ansvarlig for et domæne, som man har modtaget reklamer fra.
I forbindelse med installationen af Red Hat Linux kan du vælge pakken "caching-nameserver". Pakken foretager en simpel opsætning af navneserveren bind. Fra starten kender den ikke selv svaret på navneopslag, men sender blot spørgsmålet videre og husker svaret (som beskrevet ovenfor). Den glemmer desværre alt, hvad den har lært, når maskinen lukkes ned, så du får mest glæde af en caching navneserver, hvis den kører på en maskine, der er i gang altid - f.eks. en server på et lille lokalnetværk. Den kan selvfølgelig sagtens bruges som navneserver for Windows-pc'er på netværket.
Hvis du vil bruge Linux på en server i et mindre netværk, kan du have glæde af at lade den fungere som navneserver for et lokalt domæne. Opsætningen af dette er ikke det første Linux-eksperiment, du skal starte med, så eventuelle interesserede henvises til den detaljerede beskrivelse i DNS-HOWTO (under Red Hat, se /usr/doc/HOWTO/DNS-HOWTO) og http://www.sslug.dk/artikler/dnsbind.shtml er sikkert også af interesse.