Domain Name Service, DNS

Domain Name System

Et kompendium til bruk ved Oslo By Steinerskole, IKT driftsfag.
(Kilder: RFC, ICANN, IANA, InterNIC, TechRepublic.com)
Innhold:

Resolusjon av hostnavn: __________________________________________________ 1
Definisjon av hostnavn:___________________________________________________ 1
Hostnavnhierarkiet: ______________________________________________________ 2
Navneresolusjon i praksis: ________________________________________________ 3
Noen vanlige problemer med DNS: _________________________________________ 5
Eksempel på DNS-oppslag ________________________________________________ 7
In-addr.arpa ____________________________________________________________ 8
WHOIS databasen: ______________________________________________________ 9
RFC som er viktige i forbindelse med DNS: __________________________________ 9

Resolusjon av hostnavn:
De fleste mennesker har problemer med å huske 32 bits IP adresser. Det samme gjelder nok
selv om vi angir adressene desimalt. Særlig hvis det blir mer enn 6 8 stykker. Dette er,
naturlig vis, en treningssak, men det er få som velger å bruke tid på å trene opp en slik evne.
Mennesker er ikke bestandig like tallorienterte, men datamaskiner er det. De kan ikke bruke
annet enn tall. For at datamaskiner i et TCP/IP nettverk skal kunne kommunisere, må de bruke
IP adresser, og de bruker dem alltid i binær form. Alt annet er bare for å lette arbeidet for
menneskene.
Mennesker er nok mer glad i å bruke ord enn tall. Derfor er det godt for oss at TCP/IP har et
innebygget system som tillater at vi bruker ord (navn) istedenfor numre. Dette systemet
(egentlig en tjeneste eller service) kalles DNS (Domain Name System) og selve handlingen
som foretas når en IP adresse oversettes til et navn, eller et navn oversettes til en IP adresse
kalles navneresolusjon (Host Name Resolution).
Definisjon av hostnavn:
Det første vi må se på er: hva er egentlig et hostnavn? Vel, det er egentlig et alias, en måte å
identifisere en TCP/IP node på en bestemt, logisk måte. I utgangspunktet kan et slikt alias
være opptil 256 bokstaver og tegn. Av forskjellige årsaker kan ikke alle tegn og bokstaver
brukes, noen er reserverte (for eksempel @) andre er spesielle bokstaver i sprog som ikke
finnes i grunnleggende ASCII (for eksempel Æ, Ø, Å). En datamaskin kan godt ha mer enn et
alias, i teorien kan den ha så mange du bare vil. Dette aliaset er ikke nødvendigvis det samme
som maskinens NetBIOS navn, men det kan godt være likt. Hostnavn er på mange måter som
NetBIOS navn, i det at funksjonen er den samme, å gjøre det lettere for mennesker å huske
enn lange numre. For eksempel kan NetBIOS navnet Elev3 resolveres (løses) til IP adressen
10.1.1.107. Som vi vet fra tidligere kan denne IP adressen senere resolveres til en bestemt
MAC adresse via protokollen ARP. På denne måten (og egentlig bare slik) kan vi få en unik
navneresolusjon. Strengt tatt er det alltid MAC adressen som brukes, i siste instans. Det er

derfor det er så viktig at denne er unik for hvert eneste nettverkskort som blir og er blitt
produsert.
Her er det viktig å merke seg en ting; det er ikke slik at NetBIOS brukes over alt. Det er ikke i
bruk i Unix eller GNU/Linux og heller ikke i en del andre systemer. Det er heller ikke bare
Microsoft som bruker dette systemet (IBM oppfant NetBIOS), men i våre dager er det stort
sett Microsoft det gjelder når vi snakker om NetBIOS. Unixmaskiner / GNU/Linux trenger
ikke NetBIOS. TCP/IP er spesielt lavet for og tilpasset Unix. Man kan derfor henvende seg
direkte til en Unixmaskin eller GNU/Linuxmaskin ved hjelp av IP adressen. Det kan se slik ut
på Windowsmaskiner også, men det er avhengig av hvilken port henvendelsen kommer til, og
det igjen er avhengig av hvilken protokoll som benyttes. Har du en webserver på en
Windowsmaskin og skriver http://ip-adresse i en browser vil du få kontakt med webserveren.
Microsoft har "bakover-tilpasset" systemene sine slik at TCP/IP kan brukes. Det har de for så
vidt fått til med god suksess. I dag bruker Microsoft også TCP/IP som transportprotokoll for
NetBIOS, slik NetBEUI eller IPX/SPX var vanlig tidligere.
Hostnavnhierarkiet:
Hvis vi ser på en adresse som for eksempel www.aftenposten.no så er dette det som kalles et
FQDN (Fully Qualified Domain Name). Når man bruker TCP/IP kan man oppløse (resolvere)
et FQDN fordi det er logisk bygget opp og fordi det er basert på et registrert domene som kan
identifiseres. Systemet er hierarkisk. Dette gjelder bare hostnavn (FQDN) ikke NetBIOS.
NetBIOS er bare logisk på et LAN.
Alle hoster (maskiner) har et navn som er basert på et domenenavn som igjen er organisert i
"emner" eller landskoder. Det kan være flere nivåer med domenenavn.
Det var opprinnelig meningen at man skulle kunne se på en FQDN hva slags maskin det var
(til en viss grad i alle fall). For eksempel ville www.aftenposten.no bli tolket som
webserveren host aftenposten i Norge. Likeledes ville ftp.rock.music.freestuff.com bli tolket
som FTP server som har rockemusikk hos selskapet Freestuff i området commercial, eller
kommersiell. Dette har sklidd ut for lenge siden, men ofte er det mulig å gjette ganske godt
hva som er hva.
Opprinnelig var det 7 toppnivå domenenavn, pluss alle de forskjellige landskodene. Disse var:

.EDU Undervisningsinstitusjoner (Universiteter)
.COM Kommersielle
steder

.GOV
Myndighetene i USA
.MIL Militære
i
USA
.NET Internets
egne
organisasjoner, ISP etc.
.ORG Organisasjoner
.INT Større,
internasjonale
organisasjoner

Det har senere kommet noen flere som .BIZ, .INFO, .NAME, .MUSEUM, .COOP, .AERO,.
Det forhandles om flere bl.a. .PRO. Det har også vært diskutert .XXX og lignende. Vi får se
hva som kommer, det er bare å smøre seg med tålmodighet.
Dersom du vil ha et domene som skal kunne resolveres i DNS på Internet må du registrere
dette. Grunnen er at navnene må være unike, ingen kan ha samme navn som en annen. Da
ville navnet bli resolvert til to IP adresser og dermed vet ikke ruteren hvor den skal sende
pakkene og det hele feiler. Det er teknisk mulig å ha et lukket system, et system som ikke er
tilknyttet Internet på noen måte, hvor man setter opp DNS servere og har et helt eget og
annerledes system. Et slikt nettverk vil aldri kunne tilknyttes Internet direkte.
Det er Sanford Research Institute Network Information Center også kjent som SRI
International/SRI NIC som har det endelige ansvaret for at det ikke oppstår to like navn.

Deres myndighet er delegert til en lang rekke underorganisasjoner, en for hvert land for
eksempel. I Norge er det organisasjonen NORID som har ansvaret. De finner du på
www.norid.no. Der kan du lese mer om de Norske reglene for navneregistrering og finne en
liste over registrarer du kan kontakte for å registrere et domene under toppdomenet .NO.
Legg merke til at det kreves organisasjonsnummer i Brønnøysund registeret for å registrere
domene under .NO.
Navneresolusjon i praksis:
Navneresolusjonen i DNS kan ligne på deler av navneresolusjonen i NetBIOS, men bare deler
av det. Lokal broadcast WINS og LMHOSTS har vi snakket om før, denne gangen skal vi se
nærmere på HOSTS filen og DNS. Vi skal først se på hvordan dette virker i Unixverdenen
(gjelder også GNU/Linux) og efterpå hvordan dette gjøres og tilpasses under Windows.
Standard resolusjon:
Local Host Name: Dette er det lokale navnet på maskinen (FQDN). Dette brukes for
eksempel til loopback eller rekursive oppslag (har adressen, trenger navnet). Det kan, i tillegg
til maskinens FQDN være et alias til dette eller "localhost".
HOSTS filen: Dette er en enkel tabell som ligger lagret på den lokale maskinen, og som
brukes til å løse (resolvere) hostnavn til IP adresse. Denne filen følger den standarden som er
lavet av BSD (Berkeley Software Distribution) versjon 4.3 UNIX HOSTS fil. Denne filen må
oppdateres manuelt, men kan være grei å ha for eksempel for å kunne gi et alias til en maskin.
Du bør, strengt tatt, alltid ha den fordi det er et navn på maskinen din som ikke vil bli løst av
DNS, og det er aliaset "localhost". Du kan åpne og redigere HOSTS i en hvilken som helst
tekst editor som kan lagre dokumenter i ren-tekst-format. Opprinnelig var det bare HOSTS
filen som ble brukt (tilbake på ARPANET for mange år siden) og den måtte oppdateres
manuelt hver gang en ny maskin ble koblet til nettverket, uansett hvor på nettverket den nye
maskinen kom. Efter hvert som det ble hundrevis og til og med tusenvis av maskiner på denne
forløperen til Internet, ble det en helt uoverkommelig oppgave å oppdatere denne filen for så å
lagre en kopi lokalt på hver eneste maskin. Husk at det ofte var langsomme linjer og hver
eneste oppkobling måtte gjøres manuelt. Det fantes ikke noe bredbånd .
Det er viktig å være klar over hvordan HOSTS filen blir brukt av systemet. For det første:
hver eneste linje som inneholder et hostnavn eller et alias til et hostnavn kan bare
korrespondere til en IP adresse. Filen leses alltid ovenfra og nedover, inntil navnet er løst til
en IP adresse. Dersom en maskin har flere oppføringer vil bare den første som løser navnet til
en IP adresse bli brukt. Duplikater lenger ned i listen vil bli ignorert. (Viktig!) Husk derfor å
sette de vanligst brukte navnene høyest opp i filen, da spares det litt tid, særlig hvis HOSTS
filen er stor.
Selve navneresolusjonen begynner i det øyeblikk et program, eller en bruker gir en
kommando som krever at maskinen forstår forskjellen på et navn og en adresse. Det første
som skjer er at maskinen vil sjekke destinasjons (mottager) navnet mot sitt eget navn. Dersom
dette er likt er problemet løst og intet mer skjer. Hvis nå destinasjonsnavnet ikke er det samme
som maskinens eget navn, altså det er en annen maskin, eller det er et alias til nodens eget
navn vil maskinen (systemet) sjekke HOSTS filen. Hvis det ikke finnes noe i HOSTS filen
som kan løse navnet og HOSTS er den eneste resolusjonsmetoden, vil det bli generert en
feilmelding og prosessen vil stanse her. Hvis det finnes en "match" i HOSTS filen så har vi en
IP adresse og vi kan bruke ARP til å finne hardwareadressen (MAC adressen). Hvis IP
adressen tilhører et annet nettverk vil ARP be om MAC adressen til "default gateway", altså
til en ruter (dedikert ruter, eller multi-homed server). Det er meget viktig å se på både
NetBIOS resolusjon og DNS resolusjon samlet. De gjør mye likt og det er viktig å kjenne til
både likhetene og forskjellene. På det lokale nettet (LAN) er det alltid MAC adressen som er

det endelige svaret. Det er det for så vidt også over et WAN, men dette løses ved at ARP
finner frem til MAC adressen til ruteren istedenfor MAC adressen til mottakerens
nettverkskort.
Eksempel på HOSTS fil:
# Copyright (c) 1993-1999 Microsoft Corporation
#
# Dette er en eksempel på en HOSTS fil som brukes av Microsoft TCP/IP for Windows.
#
# Denne filen inneholder tilordninger av IP adresser til vertsnavn. Alle
# oppføringer må være på hver sin linje. IP adressen plasseres i den
# første kolonnen, etterfulgt av det tilsvarende vertsnavnet. IP adressen
# og vertsnavnet må være adskilt av minst ett mellomrom.
#
# I tillegg kan kommentarer (som denne) settes inn på egne linjer, eller
# etter maskinnavnet, anført med et nummertegn ("#")
#
# Eksempel:
#
# 102.54.94.97 rhino.acme.com # kildeserver
# 38.25.63.10 x.acme.com # x-klientvert

127.0.0.1 localhost
192.168.0.1 putte
192.168.0.2 mandrake
192.168.0.3 sinatra
192.168.0.4
Domain Name Service (DNS): Denne tjenesten ble raskt en hjørnesten i Unixverdenen og
den ble lagt til systemene ved at DNS service deamon ble installert. Deamon er et UNIX
uttrykk som nogenlunde tilsvarer begrepet "prosess" på en DOS / Windowsmaskin. På mange
måter kan man tenke seg at dette var som om vi hadde lagt HOSTS filen ut på en delt
nettverksressurs og at alle maskinene sjekket en og samme fil over nettverket istedenfor sin
egen lokale kopi av filen. Formålet med DNS er (alltid) å resolvere (løse) et FQDN til en IP
adresse.
La oss se på en navneresolusjon gjennom Microsoftbriller (fra Microsofts ståsted). NT baserte
systemer kan konfigureres til å bruke enten HOSTS eller DNS, men vanligvis er det satt opp
til å bruke begge. Pluss litt til. Microsofts metode er en seks trinns prosedyre.
· Step A: Det hele begynner med en kommando (for eksempel PING, TELNET, FTP
etc.) som krever navneresolusjon. Først blir destinasjonsnavnet sjekket mot maskinens
eget navn. Hvis det matcher er alt greit og prosessen stopper fordi navnet er løst. Ingen
nettverkstrafikk blir generert.
· Step B: Hvis navnet ikke matcher eget maskinnavn vil HOSTS filen bli lest og sjekket
for en match. Hvis det matcher er alt greit og prosessen stopper fordi navnet er løst.
Ingen nettverkstrafikk blir generert.
· Step C: Hvis navnet ikke blir funnet i HOSTS filen vil neste trinn være å forsøke å
løse det via DNS. Hvis det ikke kommer svar fra DNS serveren vil maskinen spørre
om igjen efter 5, 10, 20, 40, 5, 10 og 20 sekunder, progressivt. Hvis systemet ditt er
avhengig av DNS og DNS serveren ikke svarer vil du ofte få en følelse av at alt har
crashet. Det kan ta lang tid før det dukker opp en feilmelding som forklarer hva som
egentlig foregår. Hvis det matcher er alt greit og prosessen stopper fordi navnet er løst.

· Step D: Hvis DNS serveren ikke svarer er egentlig håpet ute, men det finnes noen
nødløsninger som kan virke og de blir forsøkt. Det første er å kontrollere NetBIOS
name cache, og derefter 3 forsøk på å få svar fra en WINS server. Det er lite trolig at
navnet finnes, men det er verdt et forsøk. Dersom det har vært løst helt nylig kan det
hende at det fremdeles er i cachen, men det er en NetBIOS cache og vil bare virke på
et LAN.
· Step E: His ingen av de tre forsøkene på å få svar fra WINS lykkes vil det sendes ut et
b-node broadcast (se RFC 1001 / 1002).
· Step F: Hvis heller ikke det virker vil systemet forsøke en siste, desperate utvei og det
er å lese LMHOSTS filen. Dette tilsvarer det som kalles en "enhanced b-node" (se
RFC 1001 / 1002).
Her er det også en liten "huskeregel" på linje med "Please Do Not Throw Sausage Pizza
Away". Denne er: Let's Have Dinner When Bondevik Leaves; (eller et annet navn på B)
som står for: Local, HOSTS, DNS, WINS, Broadcast, LMHOSTS og er standard
resolverings rekkefølge på et NT basert system (Win NT, Win 2000, Win XP, Win .NET).
Spesifikk resolusjon:
Lokal broadcast: En melding som sendes ut til alle noder på et LAN for å kunne løse IP
adressen til en maskin mot maskinens NetBIOS navn eller Hostnavn. Dette kalles også et b-
node broadcast (se RFC 1001 / 1002).
WINS (Windows Internet Name Service): En navneresolveringstjeneste som forholder seg til
standardene som er beskrevet i RFC 1001/1002, og som resolverer hostnavn eller NetBIOS
navn til IP adresser. Dette skjer ved at man installerer en WINS server i nettverket. OBS!
Dette gjelder bare innenfor et LAN, ikke for adresser på Internet. Dette med Internet og
internett er lett å glemme, men det er essensielt å forstå. Internet er det "store nett av nett over
hele verden", internett kan være enhver sammenkobling av to eller flere private LAN.
(Intranett er innenfor det lokale LAN).
LMHOSTS filen: Dette er en tekstfil som ligger lokalt på maskinene og som gjør det samme
for NetBIOS navn som HOSTS filen gjør for FQDN. På samme måte kan vi si at WINS har
overtatt rollen til LMHOSTS på samme måte som DNS har overtatt for HOSTS filen. Dersom
du vil kikke på HOSTS eller LMHOSTS filen på din Windows 2000 maskin ligger de i
mappen C:\winnt\system32\drivers\etc\. På Unix og GNU/Linuxmaskiner er det normalt
ingen LMHOSTS fil og HOSTS filen ligger vanligvis i /etc/, men dette kan variere.
Noen vanlige problemer med DNS:
Det er flere vanlige problemer som assosieres (forbindes) med navneresolusjon. Det er vanlig
å bruke PING til å verifisere (kontrollere) adresser. Dette går fint helt til det er en annen
maskin som har fått IP adressen og det viser seg at du kontrollerer feil maskin. Ping a gir
navneresolusjon. Vi skal se på et par vanlige problemer, og vær snill å legge merke til at det
er mye likt i hvordan DNS løser navn og hvorledes NetBIOS gjør det. Dersom det oppstår feil
i en av dem vil du som systemadministrator få nøyaktig den samme hodepinen, og det er i alle
fall en likhet! .
HOSTS / DNS har ikke navnet:
Akkurat som om du skulle lete efter det tapte kontinent Atlantis, så kan du lete til du blir blå
og grønn, du vil ikke finne noe, rett og slett fordi det ikke er der. Det er vanlig å ha DNS
servere i et nettverk hvis det er litt større enn et hjemmenettverk. Hvis du setter opp
arbeidsstasjonene og gjør feil i TCP/IP egenskapene slik at de henvender seg til feil DNS
server vil du ikke få resolusjon for alle navn. Det kan hende det vil virke allikevel, men da er
det fordi det finnes en annen løsning (WINS eller broadcast er vanligst). Det er da ikke DNS

som faktisk gir resolusjonen. Dette er det samme som skjer dersom det er feil HOSTS fil som
brukers eller det er feil i selve filen.
HOSTS / DNS har et feilstavet navn
DNS benytter også tekstfiler og disse kan manipuleres og editeres manuelt. Det er derfor
fullstendig mulig at et menneske gjør feil og skriver inn det som er en "trykkleif". Mennesker
som sier at du ikke skal la deg plage av småting har aldri tilbragt en natt i et soverom, i
selskap med en summende, blodtørst mygg. Småting kan være meget plagsomme! Feil kan
oppstå både i hostnavn og IP adresser. I begge tilfelle betyr det at navneresolusjonen feiler,
men du får IKKE en feilmelding som sier "trykkfeil i HOSTS filen", du får "host not found",
eller noe lignende. Du kan ikke se om det er fordi hostnavnet ikke finnes, om du har skrevet
feil, eller om feilen er i DNS / HOSTS.
HOSTS / DNS har en feil registrert IP adresse
Som i eksempelet over vil feil innskrivning av IP adresse føre til uoverstigelige problemer for
navneresolusjonen. Husk at en maskin kan ha mer enn et entry i DNS. For eksempel kan vi ha
en maskin som heter webserver.oslo.aftenposten.no Dette er et FQDN. Allikevel vil vi at
denne maskinen skal svare på henvendelser til www.aftenposten.no som er et annet navn. Da
setter vi opp et alias til webserver.oslo.aftenposten.no hvor aliaset et www.aftenposten.no I
tillegg til dette kan vi sette opp et alias til; nemlig at aftenposten.no (som egentlig er et
domenenavn, ikke et FQDN) som alias til webserver.oslo.aftenposten.no. Dette er årsaken til
at du får forsiden til aftenpostens nettutgave hvis du bare skriver http://vg.no i en browser.
HOSTS / DNS har gjentatte entries:
Dersom en maskin har flere alias vil bare det første bli lest og løst. Så snart det er funnet en
navneløsning vil prosessen stanse. Hvis det nå er nye alias med andre IP adresser lenger nede
i filen vil de ikke bli løst. I et slikt tilfelle har vi en administrator som ikke har gjort jobben
sin. Fy skam!
En DNS server er en service en server kan kjøre ved siden av de alminnelige services. Hvis
der er meget belastning, kan man velge å ha en DNS server, som utelukkende kjører DNS
service (en dedikert server).
Hver gang DNS serveren får en anmodning (forespørsel) om en web adresse, slår den opp
web adressen i sin database, og finner den tilhørende IP adressen.
For at dette skal kunne virke over hele verden er der et visst system i det. Det går ut på, at
hvert land har et domene. Akkurat som institusjoner og firmaer i det aktuelle land kan ha et
"underdomene / subdomene". For eksempel heter Oslo By Steinerskoles domene oslo-
bysteinerskole.no, som er et subdomene til no domenet, (no angir Norge).
Hos Oslo By Steinerskole har man tilføyd ytterligere et subdomene, nemlig: www. Den
komplette adressen blir da www.oslo-bysteinerskole.no. Dette er fordi vi har en hjemmeside
som vi vil at andre skal kunne finne. Hvis man skriver denne adressen i en browser vil
computeren automatisk spørre sin DNS server om IP adressen til maskinen som heter "www"
på domenet oslo-bysteinerskole.no og derefter lave en web forespørsel (en henvendelse over
http protokollen) til IP adressen.
Det vil si at domenenavn er hierarkisk oppbygget. Landet er øverst, derefter navnet på firmaet
/ institusjonen (eventuelt i en forkortet utgave), og til sist subdomenet som "peker" på
serveren for domenet.
De øverste domenene i hierarkiet kalles også TLD (Top Level Domains = topp nivå
domener), disse administreres av de såkalte root-servere. En root server besvarer kun
forespørsler på TLD nivå. Pr. April 2000 eksisterte det, på verdensbasis, 13 root-servere, som
hver besvarte cirka 200 millioner forespørsler om dagen. Hvor mange forespørsler per dag det

er nå vet jeg ikke, men det kunne du jo prøve å finne ut selv. Kanskje IANA
(http://www.iana.org) er et godt utgangspunkt? Jeg sjekket selv hva en eneste root-server (F-
serveren / http://f.root-servers.org) betjener og det var 272 millioner forespørsler per dag på
denne ene av 13 servere (sjekket Desember 2002). Det er bare 13 servere, de aller fleste ligger
i USA (det er en i Stockholm og en i Japan, ellers ligger alle i USA). Tenk litt på hva som
ville skje dersom alle 13 skulle bli satt ut av spill, enten av naturlige årsaker, eller efter et
angrep av noen som ønsker å ødelegge Internet.
Det kan også være meget interessante tanker som beskrives på http://www.open-rsc.org/
Diskusjonen om Internets sårbarhet er viktig, men for lang til å ta her.
Bare vit at dersom noen "slår ut" de 13 top level domain root-servers vil ikke Internet fungere.
Det vil stanse en meget betydelig del av informasjonsflyten i verden, noe som nok kan virke
attraktivt på enkelte grupperinger.
Alminnelige computere kommuniserer ikke direkte med root-serverne, de sender i stedet en
webadresse forespørsel til enten en lokal DNS server, eller DNS serveren hos din Internet
tilbyder (ISP).
Hvis vi forestiller oss at DNS serveren ns.online.no (skolens ISP; sic!)som er ansvarlig for
domenet oslo-bysteinerskole.no, mottar en forespørsel på subdomenet www.oslo-
bysteinerskole.no ser serveren øyeblikkelig at det er et domene som den selv er ansvarlig for,
og kan derfor besvare denne forespørselen uten å skulle behøve å kontakte andre DNS
servere.
Hvis serveren i stedet mottok en forespørsel på domenet www.filmweb.no ville den raskt
kunne se at det ikke er et domene den selv har ansvaret for. Den ville derfor være nødt til å
starte med det øverste, rent hierarkisk sett. Serveren vil derfor innlede med å spørre en root-
server om TLD domenet no, den vil av rootserveren bli bedt om å kontakte NO-Hostmasters
server, som er ansvarlig for domenet NO.
Hostmasters server vil henvise til serveren ns.online.no som er ansvarlig for domenet
www.oslo-bysteinerskole.no. Serveren vil derfor ende med å få besvart spørsmålet sitt når den
spør ns.online.no.
Man kan betrakte en DNS server som en telefonkatalog, hvor personene er web adresser.
Begge steder får man et nummer (telefonnummer / IP adresse), som systemet kan bruke til å
lokalisere informasjonen / personen.
For å begrense DNS trafikken benytter DNS servere seg av "DNS cache". Her blir de svarene
serveren har fått fra øvrige DNS servere gjemt, men ikke glemt. Hvis man gjentar
ovenstående eksempel ville serveren derfor ikke starte forfra med å spørre alle serverne, men i
stedet gå direkte til sin egen cache og finne svaret der. Bare dersom det IKKE er i cache vil
det settes i gang en helt ny forespørsel.
Eftersom det daglig blir gjort endringer på mange servere er det viktig at en DNS server ikke
tror den bare kan gjemme cachen sin evig. Hvis eksempelvis www.oslo-bysteinerskole.no blir
endret til å peke til en annen web server (Hurra, vi har fått en egen server med egen IP
adresse! {in your dreams...}) vil det ikke være mye verdt hvis vår DNS server fremdeles har
den gamle informasjonen og ikke den nye. Derfor har DNS servere det man kaller en TTL
(Time To Live) på alle "records", hvilket simpelthen definerer hvor lang tid et svar på en
forespørsel får lov til å leve. Hvis vår lokale DNS server igjen mottar forespørsel om IP
adressen til www.oslo-bysteinerskole.no, og TTL'en er utløpt vil serveren være nødt til å
starte forfra med å spørre de forskjellige DNS serverne. Default TTL på Windows 2000 er 1
time.
Eksempel på DNS-oppslag
Når en pc skal finne ut av IP adressen på www.microsoft.com, spør den først sin lokale
navneserver (følg med på eksempelet under). Denne navneserveren vet hvilke navneservere

som bestyrer domenet den selv er medlem av pluss at den vet hvilke servere som er "root-
servere" eller TLD servere. Det legges inn når du installerer DNS på maskinen. Den spør så
navneserverne for (root): "Hva er IP adressen til www.microsoft.com?". (root)-serverne
svarer: "Det vet jeg ikke, men jeg ved hvem, som styrer .com". Den lokale navneserver spør
nå .com root serverne: "Hva er IP adressen til www.microsoft.com?". .com root serveren
svarer: "Det vet jeg ikke, men jeg vet, hvem som bestyrer microsoft.com". Den lokale
naveserveren spør nå .ns.microsoft.com: "Hva er IP adressen til "www.microsoft.com?".
.ns.microsoft.com svarer: "Adressen til www.microsoft.com er ...". Til slutt svarer den lokale
navneserveren PC en: . (Microsofts navneserver behøver ikke å hete ns, men det er svært
vanlig at de heter det.)
"Adressen til www.microsoft.com er ...". Derefter legges denne adressen i maskinens cache
og får lov til å ligge der til TTL utløper. Det cachede svaret er det svaret du får dersom du nå
ber om www.microsoft.com en gang til.
****************************
Eksempel på navneoppslag:
[PC] -> [Lokal NS] www.microsoft.com?
[Lokal NS]
->
[(root)
NS] www.microsoft.com?
[Lokal NS] <- [(root) NS]
NS for .com er .com-NS
[Lokal NS] -> [.com-NS] www.microsoft.com?
[Lokal NS] <- [.com-NS] NS for .microsoft.com er
.microsoft.com-NS
[Lokal NS]
->
[.microsoft.com-NS] www.microsoft.com?
[Lokal NS] <- [.microsoft.com-NS] Adressen på www.microsoft.com
er ... [PC]
<- [Lokal NS] Adressen på www.microsoft.com er
...
Fordi denne prosedyren kan ta lang tid, blir alle resultater
cachet av din lokale navneserver. Neste gang, den blir spurt om
www.microsoft.com, behøver den altså ikke å kontakte alle de
andre navneservere igjen, men kan gi svaret omgående:
[PC] -> [Lokal NS] www.microsoft.com?
[PC] <- [Lokal NS] Adressen til www.microsoft.com er...
In-addr.arpa
Dette er de "klassiske oppslagene i DNS. Men det kan også hende at vi har en IP og ønsker å
finne ut hva noden heter, dens FQDN. Da laves det et "reversoppslag". Dette foregår ved at
den autoritative (den som har ansvaret og bestemmer) NS i domenet har en sone som kalles
in-addr.arpa. Her reverseres adressene og på en måte kan vi tenke oss at vi har et slags
"bakvendt domene". ARPA står for Address and Routing Parameter Area domain. Dette
"domenet" er designert (bestemt for) å brukes eksklusivt (ingen andre bruk tillatt!) for Internet
infrastruktur. Dette "domenet" administreres av IANA (www.iana.org) i samarbeid med
Internet Architecture Board (www.iab.org).
Dette domenet har tre sub-domener pr. i dag. Disse er in-addr.arpa som brukes til
reversoppslag av vanlig IP adresser / domenenavn. Det neste er IP6.arpa som gjør det samme,
men protokollen er IP versjon 6. Det tredje underdomenet er e164.arpa som benyttes for IP
telefoni og vil kunne slå opp reverst telefonnumre (kun IP telefoni).
På skolen har vi IP adresser (innsiden) i et av de private rangene. Vi bruker 10.0.0.1 254.
Reversoppslaget vil da bli 0.0.10.in-addr.arpa, og denne sonen må vi ha på skolens DNS
server. Eftersom dette er private adresser som ikke rutes kan vi ikke ha reversoppslaget hos
vår ISP. Det går greit uten DNS også, men DNS er raskere og genererer mindre trafikk på
nettverket enn broadcast (b-node) gjør.

WHOIS databasen:
Det finnes en database som gir informasjon om hvem som eier et domene. Det er flere slike
databaser, men den som tilhører VeriSign er muligens den største. Den svarer på henvendelser
vedrørende .com .org .biz og flere, men ikke alle. For eksempel er det en egen whois for
Norge. Denne databasen vedlikeholdes av Norid og driftes av Uninett. Du finner den på
www.norid.no/domenenavnbaser/whois/.
RFC som er viktige i forbindelse med DNS:

Nummer Status
Tittel
1034
Standard
Domain Names - Concepts and Facilities
1035
Standard
Domain Names - Implementation and Specification
1123
Standard
Requirements for Internet Hosts - Application and Support
1886
Proposed
DNS Extensions to Support IP Version 6
1995
Proposed
Incremental Zone Transfer in DNS
1996
Proposed
A Mechanism for Prompt DNS Notification of Zone Changes
2136
Proposed
Dynamic Updates in the Domain Name System (DNS UPDATE)
2181
Standards Track Clarifications to the DNS Specification
2187
Proposed
Selection and Operation of Secondary DNS Servers
2308
Standards Track Negative Caching of DNS Queries (DNS NCACHE)
3172 Standard
In-addr.arpa

2308
Standards Track Negative Caching of DNS Queries (DNS NCACHE)