Port: 53 UDP (til server)
Port: vilkårlig (fra server, av sikkerhetsgrunner)
RFC 1034

DNS Er en tjeneste vi alle har gjort oss svært avhengig av for å oversette lett huskbare navn til IP-adresser. Når du skriver inn http://andynor.net i adresselinjen må maskinen din finne ut hvilken maskin på Internett den skal kontakte for å spørre om siden du bad om. For å oppnå kontakt må den ha en IP-adresse ( IPv4 )

Opprinnelig fra Internetts barndom ble dette problemet løst ved at det eksisterte én fil der alle navn med tilhørende IP ble registrert i. Denne filen kunne enhver laste ned via FTP og legge på sin egen maskin. Vi kjenner den som host filen. Den eksisterer den dag i dag i de fleste operativsystem. Filen ble etter hvert veldig stor, uhåndterlig og den hadde den ulempe at den måtte lastes ned manuelt.

Noen glupe hoder tenkte ut at det ville være lurt å spre ansvaret utover i et hierarkisk system slik vi kjenner det i dag. La oss ta et eksempel:

http://msdn.microsoft.com/en-us/default.aspx

Enhver adresse starter med angivelse av protokoll, som her er HTTP.

Videre kommer msdn.microsoft.com som angir IP-adressen protokollen skal snakke med. Det er denne vi skal gå inn på her. For opplysnings skyld brukes "/" som mappe separator. en-us er derfor en mappe på systemet vi kontakter og default.aspx er en fil inne i mappen. Vanligvis ...

"msdn.microsoft.com" må oversettes til en IP. Hvordan skjer dette?

Jeg nevnte et hierarki i stad. Toppen av hierarkiet kalles root servere. Det er 13 slike IP-adresser (mange flere servere) plassert rundt om på planeten vår. De er alle ekvivalente, og inneholder alle et register over toppdomeneserverne. Altså .com .net .org .no .edu osv...

Hver toppdomeneserver har så oversikt over alle domener under seg. I vårt eksempel må vi først kontakte en root server for å finne en com server. com serveren forteller oss så hvor navneserveren til microsoft.com befinner seg. Herifra overtar Microsoft ansvaret og må selv ha en navneserver for å holde oversikt over egne maskiner og sub domener. Vi må nå kontakte en av Microsofts navneservere for å finne msdn.microsoft.com. Etter å ha nøstet oss igjennom hele navneadressen fra høyre til venstre, får vi tilbake en IP-adresse vi kan bruke for å spørre etter websiden.

Informasjonen er nå spred, men vi vil generere ekstremt mye trafikk om alle skal foreta denne dansen frem og tilbake for hver side vi vil se. Derfor er det innført et buffersystem. Hostfilen eksisterer fortsatt på hver enkelt maskin og er det første stedet maskinen din leter etter et treff. Denne filen er standard helt tom, men du kan selv putte noe i den. For eksempel adresser du ikke ønsker at maskinen sin skal besøke. (Dette ved å sette IP-adressen til 127.0.0.1 som er deg selv)

Maskinen din har også et buffer i minne med de adressene du har besøkt den siste tiden. Hvis du besøker en ny side må maskinen din ut å spørre. Den spør ikke direkte selv, da dette som kjent ville skape mye unødvendig trafikk. Det er derfor satt opp egne maskiner på Internett som tar seg av spørringen på vegne av mange. Som du sikkert vet er de fleste Internett brukere samlet under Internettilbydere som Telenor, NextGenTel og Tele2. Alle slike ISP setter derfor opp slike servere. På denne måten kan disse DNS-serverne ha egne buffer, noe som er svært hendig da veldig mange oppslag går igjen, slik som VG, Facebook, Microsoft.

Fordelen med buffer i denne sammenheng er naturligvis at de hindrer behovet for at alle må gjenta de samme spørringene gang på gang. Internett forandrer seg hele tiden, og da må også bufferne rundt om på alle DNS-serverne oppdateres. Derfor inkluderer alle oppslag en verdi for hvor lenge resultatet kan lagres før det må spørres på nytt.

Hele Internett er bygget opp rundt navn i stedet for IP-adresser. Slutter DNS å fungere, da går Internett nedenom og hjem. Vi er også helt avhengig av at vi kan stole på resultatet vi får når vi spør. Kan vi det? Normalt sett...

En spørring er veldig enkel. "Hva er IP adressen til vg.no?", svar: "Den er 193.69.165.21". Som transportprotokoll er UDP valgt. Dette fordi den er lettvektig, man slipper opp- og nedkobling. Ulempen er at den er lett å lure. Du kan aldri vite at et svar via UDP faktisk kommer fra den IP-adressen som står i avsenderfeltet. Dette fordi denne verdien kan settes vilkårlig, noe vi kaller spoofing. Dette er grunnen til alt oppstyret rundt DNS sårbarheten som har florert nå på sensommeren 2008. Det er en kompleks sårbarhet, men kan heldigvis løses ved å gjøre det vanskeligere å spoofe et ugyldig svar. Dette ved å velge tilfeldige portnummer, transaksjonsIDer og ved å blande store og små bokstaver i spørringen. Dette er tiltak "resolver" maskiner må implementere, ikke vanlige brukere. Har ikke din ISP oppgradert? Bytt til OpenDNS davel!

208.67.222.222 eller 208.67.220.220