You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

TDAT2004 Datakommunikasjon med nettverksprogrammering
Oppgave 16: DNS-protokollen
Av Roger Rambjør Holten

1. Innledning

DNS (Domain Name System) er et desentralisert system for navngivning av enheter og tjenester på nettverk. DNS er også navnet på protokollen som brukes av klienter for å gjøre oppslag mot DNS-tjenere. Den hører hjemme i applikasjonslaget i OSI-modellen.
DNS er standardisert av Internet Engineering Task Force (IETF) gjennom en rekke RFC-dokumenter datert tilbake til november 1983 (RFC 882).

2. Ønsket funksjonalitet

Ved å tilegne navn til tjenere på nettverk så slipper man å huske IP-adressene de har. Det er også mulig å legge til flere IP-adresser under samme navn, som peker til forskjellige tjenere etter hvilke tjenester de tilbyr.

Utviklingen av DNS kan spores tilbake til ARPANET. På denne tiden ble det brukt en tekstfil, vedlikeholdt av Stanford Research Institute, som holdt styr på hvilket navn hver maskin på ARPANET hadde. Etter hvert som nettverket vokste, ble dette upraktisk og
Paul Mockapetris hos University of Southern California utviklet DNS i 1983 hvor en mengde tjenere hver har ansvar for visse domenenavn og de kan oppdateres uavhengig av hverandre.

DNS brukes av alle program som støtter tilkobling til tjenere ved hjelp av domenenavn. De kanskje mest kjente er nettleserne, hvor man kan bruke domenenavn som ntnu.no for å besøke NTNU's nettside istedenfor å måtte huske IP-adressen 129.241.56.116.

Et domene i en DNS-tjener inneholder som oftest flere såkalte Resource Records (RR). En spørring kan henten hente ut alle eller bare de av en viss type.

3. Virkemåte

Bruken av DNS er vanligvis transparent for sluttbruker. Når en nettleser skal åpne en nettside, vil spørringene mot DNS-tjeneren skje automatisk i bakgrunnen.

En klient gjør oppslag mot en DNS-tjener ved å sende spørringer til den. Spørring blir vanligvis sendt som UDP-pakker på port 53. TCP blir brukt hvis svaret overstiger 512 byte i størrelse. En spørring fra klient fører til ett svar fra tjener.

Anatomi av en DNS-pakke

Spørringer og svar består av pakker med samme oppbygning. De begynner med en UDP- eller TCP-header avhengig av protokollen som blir brukt.

Query ID (16 bit): En unik ID skapt av klienten og sendt med i spørringen. Tjeneren inkluderer denne i svaret. Også kalt Transaction ID.
 QR (1 bit): Query/Response. Satt til 0 i spørring fra klient til tjener, 1 i svar fra tjener til klient.
Opcode (4 bit): Satt til 0 klient ved standard spørring mot tjener. Denne blir inkludert uforandret i svar fra tjener. Resten av disse er enten utgåtte, reserverte eller brukes ikke ved vanlige spørringer fra klient til tjener. Komplett liste i lenken til IANA under kilder.

Flagg (7 bit):

  • AA (1 bit): Authoritative Answer: Satt til 1 i svar fra tjener til klient hvis tjeneren er autoritativ tjener for domenet i svaret.
  • TC (1 bit): Truncated. Satt til 1 i et svar fra tjener hvis svaret ikke får plass i en standard 512 byte stor UDP-pakke og har derfor blitt kuttet ned. For å få hele svaret må klienten sende en ny spørring med TCP.
  • RD (1 bit): Recursion Desired. Klienten setter denne til 1 hvis den ønsker at tjeneren skal utføre rekursive spørringer i tjenerhierarkiet for å finne all info. Klienten setter den til 0 hvis den er fornøyd med infoen som tjeneren har på nåværende tidspunkt.
  • RA (1 bit): Recursion Available. Settes til 1 i svar fra tjeneren hvis den tilbyr rekursive spørringer.
  • Z (3 bit): Reservert for fremtidig bruk. Må alltid settes til 0.

rcode (4 bit): Response Code. Settes i svar fra tjener til klient:

  • 0: Ingen feil.
  • 1: Formateringsfeil. Tjeneren kunne ikke forstå spørringen.
  • 2: Tjenerfeil. Tjeneren kunne ikke utføre spørringen på grunn av feil med tjeneren.
  • 3: Navnefeil. Domenenavnet i spørringen eksisterer ikke.
  • 4: Ikke implementert. Tjeneren støtter ikke denne type spørring.
  • 5: Avslått. Tjeneren nekter å utføre spørringen.
  • 6-15: Reservert til fremtidig bruk.

Question count (16 bit): Antall spørringer inkludert i pakken fra klient.
Answer count (16 bit): Antall RR i svaret fra tjener.
Authority count (16 bit): RR i svaret som peker på de autoritative navnetjenerne for domenet.
Additional Record count (16 bit): Tilleggs-RR inkludert i svaret fra tjener. Kan f.eks. være IP-adressene til de autoritative navnetjerne hvis de inkludert i forrige felt. Brukes for å slippe flere spørringer mot samme tjener.
DNS Question or answer data (variende lengde): Inkluderer spørringer fra klient eller svar fra tjener.

Spørringer består av et visst antall spørringer satt i Question count (vanligvis 1). Det består av tre felt: QNAME, QTYPE og QCLASS. QNAME består av en eller flere "labels", som er domenenavnet i spørringen splittet opp på punktum. Hver label begynner med en byte som starter med 00. De seks siste bitene er lengden på resten av labelen i antall byte (maks 63). QTYPE er en 16-bits-verdi, som inneholder hvilken RR klienten ønsker. Komplett listen finnes i lenken til IANA. Vanlig verdier er 1 for A (IP-adresse) og 15 for MX (mail exchange, domenenavn til e-posttjener).

Alle svartyper er bygd opp på samme måte. De består av seks felt: NAME, TYPE, CLASS, TTL, RLENGTH og RDATA. NAME er samme som QNAME i spørringen. TYPE er tilsvarende QTYPE i spørringen. CLASS er en 16-bits-verdi som definerer navnerommet spørringen skal skje i. Så og si alltid satt til 1 for IN (Internett). TTL er på 32 bit og er antall sekunder RR-en kan lagres i cachen til klient før det må gjøres en ny spørring. RDLENGTH er på 16 bit og er lengden til RDATA i antall byte. RDATA har varierende lengde avhengig av hvilken type RR det gjelder.

Eksempel på en spørring.

Her gjøres en spørring mot en DNS-tjener for domenenavnet ntnu.no. Dette er lik det som skjer hvis man prøver å åpne denne nettsiden i en nettleser:

Domain Name System (query)
	[Response In: 4]
	Transaction ID: 0x0006
	Flags: 0x0100 Standard query
	0... .... .... .... = Response: Message is a query
	.000 0... .... .... = Opcode: Standard query (0)
	.... ..0. .... .... = Truncated: Message is not truncated
	.... ...1 .... .... = Recursion desired: Do query recursively
	.... .... .0.. .... = Z: reserved (0)
	.... .... ...0 .... = Non-authenticated data: Unacceptable
	Questions: 1
	Answer RRs: 0
	Authority RRs: 0
	Additional RRs: 0
	Queries
		ntnu.no: type A, class IN
			Name: ntnu.no
			[Name Length: 7]
			[Label Count: 2]
			Type: A (Host Address) (1)
			Class: IN (0x0001)


Spørringen begynner med en transaksjons-ID generert av klienten. Wireshark legger alle 16 bits med flagg og opkoder under flags-seksjonen. Bit 1 er satt til 0, som betyr at dette er en spørring. Bit 8 er satt til 1, som betyr at det er ønsket at DNS-tjeneren søker rekursivt gjennom tjenerhierarkiet for å finne domenenavnet.

Nederst kommer detaljer om spørringen. Den begynner med domenenavnet. Type er hvilken type RR som er ønsket. RR av type A inneholder IP-adressen som er knyttet til domenenavnet. Det er denne IP-adressen webtjeneren nettsiden ligger på benytter.

Svaret fra tjeneren:

Domain Name System (response)
	[Request In: 3]
	[Time: 0.027645000 seconds]
	Transaction ID: 0x0006
	Flags: 0x8180 Standard query response, No error
	1... .... .... .... = Response: Message is a response
	.000 0... .... .... = Opcode: Standard query (0)
	.... .0.. .... .... = Authoritative: Server is not an authority for domain
	.... ..0. .... .... = Truncated: Message is not truncated
	.... ...1 .... .... = Recursion desired: Do query recursively
	.... .... 1... .... = Recursion available: Server can do recursive queries
	.... .... .0.. .... = Z: reserved (0)
	.... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
	.... .... ...0 .... = Non-authenticated data: Unacceptable
	.... .... .... 0000 = Reply code: No error (0)
	Questions: 1
	Answer RRs: 1
	Authority RRs: 0
	Additional RRs: 0
	Queries
		ntnu.no: type A, class IN
			Name: ntnu.no
			[Name Length: 7]
			[Label Count: 2]
			Type: A (Host Address) (1)
			Class: IN (0x0001)
	Answers
		ntnu.no: type A, class IN, addr 129.241.56.116
			Name: ntnu.no
			Type: A (Host Address) (1)
			Class: IN (0x0001)
			Time to live: 390
			Data length: 4
			Address: 129.241.56.116

Transaksjons-ID-en er her den samme som klienten sendte i spørringen. Det gjør det mulig for klienten å holde styr på alle spørringer den utfører. Bit 1 er satt til 1, som betyr at dette er et svar på en spørring. Deretter følger flagg som sier at tjeneren er ikke-autorativ når det gjelder domenet, og at den tilbyr rekursive spørringer.
og at den kan utføre rekursive spørringer.
Answer RRs inneholder antall RR som finnes av type A. Deretter kommer en reprise av spørringen før pakken avsluttes med svaret fra tjeneren. Svaret inneholder da en RR av type A, som inneholder IP-adressen 129.241.56.116.

 

4. Kilder

https://tools.ietf.org/html/rfc1034
https://tools.ietf.org/html/rfc1035
http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml

  • No labels