DNS
informasjon
oppdatert: 7. mars 2014
Domenenavnsystemet
Domenenavnsystemet er hierarkisk oppbygd av toppdomener (TLD), hoveddomener og flere nivåer med underdomener. TLD (Top Level Domain) kan inndeles i generiske (gTLD) og geografiske (ccTLD) domener, hvor sistnevnte har tilknytning til geografiske områder idenfisert etter kodene i standarden ISO 3166.
eksempler
 gTLD:  com    net    org    mil    biz    name    info 
 ccTLD:  no   se   de
 hoveddomener:   registrar.no    norid.no    oracel.com 
 underdomener:   www.registrar.no    samtykke.norid.no    java.oracel.com 

Hvert enkelt (under-)domenenavn identifiserer en gruppe med Resource Record. Resource Record lagrer informasjon om (under-)domenet og innholder 4-fire felt: type, class, TTL og RDATA.
type indikerer hvilken type informasjon recorden innholder.
class indikererer hvilken protokoll-familie informasjonen har gyldighet for (IN=Internett).
TTL indikerere maksimalt hvor lenge informasjonen bør lagres/benyttes av mottager. 7200 sekunder tilsvarer 2 timer
RDATA er selve informasjonsverdien
Resource Record
 type   class   TTL   RDATA 
 A   IN   7200   IP-nummer 
 AAAA   IN   7200   IP-nummer versjon 6 
 MX   IN   7200   Tall  Domenenavn 
 CNAME   IN   7200   Domenenavn 
 NS   IN   7200   Domenenavn 
 SOA   IN   7200   Div 
 PTR   IN   7200   Domenenavn 
 TXT   IN   7200   Ascii-tekst info 
 SPF   IN   7200   SPF-versjon-number x-antall ganger kan 8 ulike mekanismer oppgis. Mekanismenen er prefikses med qualifers. Modifier 
 DKIM   IN   7200   Ascii-tekst info 
 SRV   IN   7200   Prioritet Lastbalanse Port Domenenavn 
 DNSKEY   IN   7200   Diverse 
 RRSIG   IN   7200   Ascii-tekst info 
 DS   IN   7200   Ascii-tekst info 
 NSEC   IN   7200   Ascii-tekst info 
 NSEC3   IN   7200   Ascii-tekst info 
  • A-record leses ved for å finne ip-nummer tilhørende domenenavnet ved bruk IP-protokoll versjon 4 (standard idag). Denne record leses ved weboppslag.
  • AAAA-record leses ved for å finne IP-nummer tilhørende domenavnet ved bruk av IP-protokoll versjon 6. Denne record lese ved weboppslag.
  • MX-record leses av e-postklienter for å finne domenenavn til mailserver (MX-record gjør det mulig å få weboppslag på og e-post til et domene f.eks. "registrar.no" å gå til to forskjellige maskiner).
  • CNAME-record peker et underdomene til et annet domene.
  • NS-record innholder domenenavn på navntjeneren som lagrer alle resource record tilhørende domenet.
  • SOA-record inneholder domenenavn til "primary authorative" navntjener, e-postadresse til administrator for zonen, serienummer og hvor lenge recordene i zonen kan leve i nettet.
  • TXT-record kan inneholde hva som helst av tekst. Brukes av Google Apps til bekrefte at en eier domenet.
  • SPF-record kan brukes til å angi hvilke e-postservere som har lov til å sende meldinger med avsender adresse tilhørende domenet. En begynner recorden med å angi versjons nummer. Deretter følger en eller flere mekanismer prefikset med en qualifier. Det er definert 8 ulike mekanismer i rfc 4408: all, a, ip4, ip6, mx, ptr, exists og include. Dokumentasjon av SPF-standarden og regler finner du her SPF.
  • DKIM-record brukes for å hindre at spammere sender e-post med din avsenderadresse, se dokumentasjon DKIM.
  • SRV-record Istedet for at det blir definert opp en nye type-record for hver enkelt ny tjeneste kan SRV-record benyttes. SRV-record gir nye tjenester sin egen record med omtrent de samme egenskaper som \"MX\"-recorden har for e-postjenesten med tillegg av lastbalanse.
    • subdomene: Feltet innholder to verdier avskilt med punktum. Første verdien er tjenestenavnet og den andre verdien er protokoll. Både tjenestesnavn og protokollnavn er tillagt start-tegnet lav bindestrek. Protokollen er vanligvis TCP, men kan godt være et annet IANA-definerte protokollnavn.
    • RDATA: Feltet innholder fire verdier avskilt med blanke tegn.
      • Prioritet: Lavere verdi gir høyere prioritet. Tall mellom 0 og 65535. O-null verdi tolkes som ingen prioritstyring.
      • Lastbalanse: Høyere verdi gir større last (velges oftere hvis flere SRV-record har samme prioritet for samme tjeneste). Tall mellom 0 og 65535. O-null verdie tolkes som ingen lastbalansestyring.
      • Port: Hvilken \"dør\" på datamaskinen tjenesten lytter på. Tall mellom 1 og 65535.
      • Domene: Domenenavnet hvor tjenesten befinner seg (identifiserer en datamaskinen på Internett)
  • PTR-recorden er litt spesiell. Recorden innholder domenenavn og benyttes til å oversette IP-nummer til domenenavn. PTR-record benyttes innenfor IN-ADDR.ARPA zonen (gren av domenetreet). IN-ADDR.ARPA grenen har 255 grener under seg, hver gren har igjen 255 grener under seg som igjen har 255 grener under seg som igjen har 255 grener under seg. Hvert blad i dette treet idenfifisers med et IP-nummer.F.eks IP-nummert til "ns1.registrar.no" er 217.116.81.10. Dette er IP-nummert blir til identifikasjonen 10.81.116.217.IN-ADDR.ARPA. I identifikatoren blir rekkefølgen på de fire tallene (bytene) i IP-nummeret snudd og tillagt IN-ADDR.ARPA. For å finne domenavnet til IP-nummer 217.116.81.10 må en lese ut PTR-recorden til 10.81.116.217.IN-ADDR.ARPA.
  • RRSIG-record signerer en resource record (eller en gruppe med record av samme type for samme underdomene). Først beregnes hashverdien til recorden(e) som skal signeres. Deretter krypteres denne hashverdien. Kryptert hashverdi lagres i RRSIG-reocrd. Eksempel på MX-record med tilhølgende RRSIG-record følger nedenfor.
       a.z.w.example. 3600 IN MX  1 ai.example.
       a.z.w.example. 3600 IN RRSIG  MX 5 2 3600 20040509183619 (
                                  20040409183619 38519 example.
                                  OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
                                  f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
                                  tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
                                  TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
                                  4kX18MMR34i8lC36SR5xBni8vHI= )
    
    MX = Hvilken record signaturen gjelder
    5 = Signatur algoritme
    2 = noe aa gjore med wildcards
    3600 = TTL for signaturen
    20040509183619 = Utlopsdato for signaturen
    20040409183619 = Dato for noer signaturen ble generert
    38519 = Tag til key bruk for generer signaturen, nodvendig hvis flere key er tilstede i sonefilen
    example = eier av key = lik navn paa zonen som innholder recordenen
    resten = base64 signatur
  • DNSKEY innholder sertifikat. For å verifisere at MX-recorden i eksemplet over ikke endret og kommer fra den korrekt utgiver beregner mottaker hashverdien til MX-recorden og dekrypter signeringen i RRSIGN ved hjelp av nøklen/sertifikatet nedenfor. Er hashverdiene like gjenstå det bevise at nøklen kommer fra korrekt utstedet fø en kan konkludere med at MX-recorden er korrekt.
       example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
                                              Cbl+BBZH4b/0PY1kxkmvHjcZc8no
                                              kfzj31GajIQKY+5CptLr3buXA10h
                                              WqTkF7H6RfoRqXQeogmMHfpftf6z
                                              Mv1LyBUgia7za6ZEzOJBOztyvhjL
                                              742iU/TpPSEDhm2SNKLijfUppn1U
                                              aNvv4w==  )
    
    256 = betyr at dette er en zone key
    3 = protokol versjon (alltid lik 3)
    5 = signatur algoritme
    Den tidlige omtalte tagen 38519 er gjemt i base-64 key
  • DS-record. En benytter vanligs ZSK (Zone Sign Key) for signere alle record i zone-fil. ZSK bør hver 3 måned endres for zonen. Derfor signerer man ZSK med KSK (Key Sign Key) som en en vanlig kun trenger å endre 1 gang i &arign;. ZSK og KSK lagres i hver sin DNSKEY-record. Hashverdien til KSK legge inn i DS-record i foreldre zonen. I vårt tilfelle i zonefilen til .no. Her m&arign; DS-recorden signeres med privat nøklen til .no-zonen. Besitter vi en troverdi offentlig nøkkel til .no har vi bevist at utsteder KSK er korrekt. DS blir et anker vi stoler på
       dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
                                                  98631FAD1A292118 )
    
  • NSEC-record. For verifisere at det eksisterer en resource record for en underdomene benyttes NSEC-record. NSEC-record forteller hva som er etterfølgende underdomene til en gitt domene. Nedenfor følger eksempel p&arign; en NSEC-record.
       b.example.com. 86400 IN NSEC d.example.com. (A RRSIG NSEC)
    
    d.example.com = neste record i alfabetisk rekkefolge
    A RRSIG NSEC = hvilke record som er definert for b.example.com
  • NSEC3-record. Ved gjentatt spørring om NSEC kan en få utilsiktet oversikt over alle underdomener i en zone. For å unngå dette kan en bruke NSEC3-record i stedet. NSEC3 inneholder en hashverdi av domenenavnet. Den som spør må finne hashverdien til domenet en ønsker å spørre om.
  • DLV-record. se RFC 4255
  • SSHFP-record. se RFC 4255
  • TLSA-record. se RFC 6698
  • IPSECKEY-record. se RFC 4025
Distribuert databasesystem
For å hindre flaskehalser på Internett er lagringen av domenenavnsystemet (resource record) spredd på mange servere (navntjenere). Navntjeneren er organisert i en hiarkisk struktur. På toppen er det 15 servere med domenavn "a.root.-servers.net" til "m.root-servers.net". Disse navnserverene innholder NS-record for alle TLD (Top Level Domain). NS-recorden forteller hvilke navntjener som betjener TLD. For "no" er det pt. følgende navntjenere: x.nic.no, y.nic.no, z.nic.no, not.norid.no, njet.norid.no, slave1.sth.netnod.se. Navntjenerene for "no" innholder NS-record for alle domener registrert under ".no". NS-recordene forteller hvilke navntjener som betjener domenavnet.

Den hiarkiske strukturen vil trolig ha ført til store trafikk problemer om ikke navntjenerene utførte midlertidig lagring (cache) av recorder. TTL-verdien i recorden angir hvor lenge navntjenere kan lagre en record. Kommer det med kort mellomrom flere henvendelser på samme domenenavn vil navntjeneren returne recorder fra cachen. Uthenting fra cache er såkalt ikke "authorativt" svar.

Navntjenere kan settes opp til å behandle domeneoppslag rekursivt eller ikke. Ved ikke rekursivt oppsett vil navntjeneren kun returnere resource record den selv har i databasen. Authorative navntjenere, som nevnt over, tillater vanligvis ikke rekursivt oppslag. Ved å tillate rekursivt opplag vil navntjeneren returner resource record for domener den selv ikke er authorativ for og foreta et søk på nettet etter ønskete recorder.

For å finne ut hvilke verktøy du kan benytte for å lese ut resource record fra navntjenere se FQA spørsmål spørsmål 7.2.

Eksempel 1: Webklient skal lese http://registrar.no
Webklient kontakter stub resolver i operativsystemet. Stub resolver kontakter default navntjener (resolver). Resolver er default navntjener som blir tilbudt av din ISP (Internett leverandør). Resolver sjekker i lokal cache om den har lagret A-record tilhørende registrar.no. Hvis svaret er nei sjekker den om den har cachet ip-nummeret til navntjenerene til .no, hvis svaret er nei kontaktes en av root navntjenerene. Resolver mottar ipnummer til navntjenere for .no. Resolver kontakter .no-navtjenerene og for opplyst om hvilke navntjenere som inneholder resource record for registrar.no. Resolver henter ut A-record fra navntjenerene til registrar.no og returner svar stub resolver som sender svaret videre til webklienten.

I Microsoft operativsystem er default navntjenere spesifisert i Kontroll-panel | Nettverk | Protokoller | TCP/IP | Gatway. I Unix operativsystemer er default navntjenere spesifisert i filen /etc/resolver.

Delegert administrasjon
Hvert TLD er underlagt en administrasjon (registry). NORID er registry for ".no". NORID drifter navntjenere for alle hoveddomener registrert under .no. I deres navntjenere er det registrert minst to NS-recorder som peker til seperate navntjenere som betjener hoveddomenet. NORID drifter i tillegg en database, whois-registeret, med opplysninger om eiere og kontaktpersoner til domenene. Whois-registeret logger også alle endringer av domene-opplysninger. Alle domeneregistreringer og endringer av opplysninger må godkjennes av NORID. Oppgavene til registry for de ulike TLD varierer noe.

Under de fleste TLD er det mulig å registrere hoveddomener (nivå-2 domener). Unntak er her f.eks. ".uk" der det kun er tillatt å registrere nivå-3 domener (eks: registrar.com.uk). Eier av hoveddomene har vanligvis rettighetene til alle underdomener, dette er tilfelle for .no.

De fleste registry har delegert selve registreringsjobben til registrarer. Registrarer for .no-domener tar imot bestillinger fra kunder og sender disse elektronisk til NORID. Vi drifter egne navntjenere og tilbyr deg som kunde webgrensnitt for rask og enkel oppdateringen navntjenerene.