DNS Måns Nilsson mansaxel@sunet.se
Vad är DNS? DNS - Domain Name System Exempel på en domännamnsstruktur: net se swip nordu sunet kth paf mailbox nic nada
Vad är DNS utåt? - Översätter från domännamn till IP-nummer - Översätter från IP-nummer till domännamn - Pekar ut postkontor i en viss domän - Hierarkiskt, har en trädstruktur som följer domännamnshierarkin överst i hierarkin har man en rot.
Vad är DNS inåt? * Distrubuerad Databas för uppslagnig av data bl a namnuppslagning från domännamn till IP-nummer, även baklängesuppslagning, Annat som stöds är information om närmsta post-kontor (e-mail server) * IP- baserat protokoll som använder UDP, dvs förbindelselöst för det mesta Man skiljer på en DNS-server och en DNS-klient. klienten frågar en server och får tillbaka ett svar. Klient Server Protokollet hör hemma på Applikationsnivån (nivå 7 i OSI-modellen)
Exempel på en domännamnsstruktur: net se swip nordu sunet kth paf mailbox nic nada Uttalas: nic.nordu.net
Varför behövs DNS? Namn är lättare att komma ihåg än siffror Centraliserade komponenter/algoritmer/tabeller fungerar inte i en distribuerad värld p g a dålig skalbarhet. Distribuerad kunskap om distribuerade förhållanden. Ofta stor skillnad på organisatorisk struktur och fysisk/topologisk. detta medför att det finns ett behov av avbildning mellan dessa sätt att dela upp världen. IP-nummer Domännamn Fysisk uppdelning Organisatorisk uppdelning
Hur fungerar DNS? DNS är en hierarkisk databas med en mängd olika typer av information, bl a adressinformation. Genom den hierarkiska namngivningen så kan man se hela hierarkin som en trädformad struktur, ungefär som UNIX-filsystem. De olika typerna av information lagras i olika typer av poster, t ex: Adress A Postkontor MX Alias CNAME Namntjänst NS Baklängesuppslagning PTR När man söker information så gör man det för en viss typ av poster och ett visst namn, t ex en MX-post för nada.kth.se. Man måste alltså ha både typ av post och namn för att få tillbaka ett svar.
Hur det hela började Det var en gång för länge sedan... 1969 var ARPANET en liten grupp datorer där alla kände till alla. ARPANET designades för att klara av kärnvapenkrig och motsvarande, d v s att stora delar av infrastrukturen kunde slås ut på en gång. Paketförmedlade nät där varje paket innehåller avsändar och mottagar adress. HOSTS.TXT var namnet på den fil som man distrubuerade ut bland de datorer som fanns anslutna till nätet, en eller två gånger per vecka med FTP. Filen innehöll namn och adress för alla andra datorer. För att kontakta en annan dator så slog man upp adressen i denna fil. Efterhand blev filen längre och längre... Överföringen av denna fil tog då större delen av bandbredden på ARPANET. 1984 blev HOSTS.TXT så lång att det blev otympligt att skicka runt den
Hur det hela började (forts.) Man sökte ett annat sätt att hitta adresser givet ett datornamn Resultatet heter RFC882 och RFC883 och skrevs av Paul Mockapetris RFC882 och RFC883 har idag ersatts av RFC1034 och RFC1035, vilka nu är de standarder som används Allt sedan dess har DNS - The Domain Name System funnits och använts.
Viktiga begrepp: Domäner (underdomäner) Domän är en nod inklusive alla underliggande noder Domänträdet Hela trädet med noder. Alla noder som ligger under roten. Roten Den nod som ligger högst upp i trädet. Jämför med roten i UNIX-filsystem. Roten skrivs som tomma strängen. Noder T ex kth eller nada. FQDN Fully Qualified Domain Name, absolut namn inkl punkt på slutet. Framlängesuppslagning Leta efter information om ett IP-nummer om man vet ett domännamn Baklängesuppslagning Leta efter information om ett domännamn om man vet ett IP-nummer
Rekursiv uppslagning Be namntjänsten att leta efter svaret även om den inte vet svaret själv. Ickerekursiv uppslagning Om inte namntjänsten vet svaret, så svarar den bara så gott den kan, dvs med namn och adress till en annan namntjänst som är bättre att fråga. Cachning Sparar svaret på en fråga i en cache i ett visst antal tillåtna sekunder. Negativ Cachning Sparar även negativa svar, d v s att det inte fanns något svar på en viss fråga. Delegering Låta någon annan ta hand om ansvaret för en underliggande domän Zoner En zon är domänen minus de underdomäner som har blivit delegerade.
Primärtjänst och sekundärtjänst (master/slav) En master (primär tjänst) är den som har orginaldatabasen; en slav (sekundär/backup tjänst) kopierar information från en master när den märker att innehållet har ändrats. En master eller en slav kallas bemyndigad (auktoritativ) för en zon Vidarebefodrare (Forwarders) Namntjänst som är inställd på att fråga en annan namntjänst. Round Robin Om man har flera IP på samma A, rotera svarsordningen per fråga namntjänst (name server) En server som tillhandahåller en DNS tjänst och allt vad det innebär. (uppslagning på namn, IP-adress, var närmsta mail-server finns, etc.) rotnamnstjänst (root name server, root server) Tillhandahåller en DNS-rottjänst. En rottjänst innehåller endast hänvisningar till andra zoner.
Resolver/ resolver routines (klientens uppslagningsmekanism) Resolvern är den uppslagningsmekaninsm som applikationer använder sig av för att slå upp IP-adresser och annan DNS-relaterad information. T ex ett program på en dator, t ex en webbläsare eller en ftp klient använder dessa rutiner och får ett svar. Detaljerna hur resolverrutinerna arbetar göms för applikationen. named (name daemon) Tjänstedelen BIND Berkley Internet Name Domain En programvara för att sätta upp en DNS-tjänst.
Domännamnssyntax Översta noden (Rotnoden) är den tomma strängen Punkten är en avskiljare (och har ingenting att göra med IP-numret) Man traverserar trädet nerifrån när man skapar namn från vägen i trädet. Observera att detta skiljer sig från UNIX där man skapar namnen uppifrån! Alltså, nada.kth.se (inte se.kth.nada). För uppslagning traverseras dock trädet uppifrån. Maximal längd på varje delsträng (mellan punkterna) är 63 tecken, och maximal längd är 255 tecken. Tillåtna tecken är godtyckliga tecken Dock gäller a-z, 0-9 samt - för datornamn Det är ingen skillnad på små och stora bokstäver (Vi använder alltså små bokstäver när vi skriver)
Baklängesuppslagning arpa net se in-addr swip nordu sunet kth paf 130 237 mailbox nic nada 228 51
De posttyper som oftast används är: SOA ansvarig för domänen NS uppgift om namntjänst A uppgift om IP-adress PTR uppgift om namn (från IP-adress till namn) CNAME definiera ett alias m h a ett kanoniskt namn MX Postpost, uppgift om närmsta e-mail server SRV Uppgifter om olika tjänster
Posttyper: SOA Pekar ut vem som är ansvarig för domänen Dessutom kan man ange lite olika tider som har betydelse främst för de sekundära tjänster (slav server) som man har. En sekunär-tjänst har exakt samma information som en primär-tjänst (master server), och för att det ska vara samma information så måste man tala om i SOA-recorden hur ofta en slav ska kontrollera om informationen på mastern har ändrats. kth.se. IN SOA kth.se. hostmaster.kth.se. ( 1999010100 ;serial 7200 ;refresh 3600 ;retry 604800 ;expire 86400) ;min garantee TTL
Serial number Måste ökas om man ändrat i databasen Refresh Hur ofta en sekundärtjänst (slav server) ska kontrollera serienummret Retry Efter misslyckad kontroll, väntetid innan man frågar igen. Bara om primärtjänsten (master servern) inte svarar, gäller detta värde Expire Bäst-före-datum på informationen som sekundärtjänsten har Time to live Hur länge får svar cachas? (Bäst före datum)
NS Pekar ut alla namntjänster för en domän Man pekar alltså ut master och slav på samma sätt Alltså, för uppslagningar så är master och slav lika bemyndigade (auktoritativa) Två till Fyra namntjänster täcker de flesta behov (sikta på tre) Delegering sker genom att det finns ett NS-record för subdomäner (delegerade zoner) Om den auktoritativa servern ligger i en underordnad del, måste även ett s k klisterpost (glue record) läggas till med IP adress till den nya auktoritativa servern. kth.se. IN NS ns.kth.se. kth.se. IN NS nic.kth.se. kth.se. IN NS sunic.sunet.se. ;; delegera zonen nada.kth.se. nada.kth.se. IN NS ns.nada.kth.se. nada.kth.se. IN NS nic.swip.net. ;; glue record för ns.nada.kth.se. ns.nada.kth.se. IN A 130.237.222.71
A Anger mappning från namn till en IP-adress Olika namn kan peka på samma IP-adress! (Kärt barn har många namn) Samma namn kan peka på olika IP-adresser! (En server som har många Interface) piggelin.gb.sthlm.se. IN A 192.168.151.1
PTR Uppslagning av namn från en IP-adress (från IP-adress till namn) Domänen in-addr.arpa. innehåller samtliga IP-adresser som finns. Information om en dator finns både som A-record och som PTR-record. Ett IP-nummer kan ha många namn 1.151.168.192.in-addr.arpa. IN PTR piggelin.gb.sthlm.se.
CNAME Pekar ut alias för en maskin. (alias IN CNAME riktigt-namn) Man kan använda CNAME för att t ex ange logiska namn för tjänster som brev (mail), ftp, gopher, www, etc. Om man har ett CNAME så får man INTE ha någon annan typ av record med samma namn i datafältet. (Se exemplet nedan) Varför är det ibland vettigt att ha CNAME poster istället för multipla A-poster till samma IP-nr? www.acme.se. IN CNAME coffee.acme.se. ftp.acme.se. IN CNAME coffee.acme.se. acme.se. IN MX 10 ftp.acme.se. ftp.acme.se. IN A 192.168.12.1
MX Uppslagning av postkontorets namn (mail server) m h a brevdomänens namn. Postkontoret med lägst kostnad prioriteras i första hand. Inget postkontor skickar någonsin post till ett postkontor som ligger längre bort från målet än det egna postkontoret. På så sätt undviks mail-loopar. gb.sthlm.se. IN MX 10 mail0.gb.sthlm.se. gb.sthlm.se. IN MX 20 mail1.gb.sthlm.se. Posthantering: 1. Konfigurera upp egen posthantering 2. MX record i DNS 3. A record i DNS (Dock så vill man sällan ha mer än ett postkontor (mail server) per domän)
SRV Ett generiskt sätt att definiera var olika tjänster finns för en nod. Beskrives i RFC 2782, A DNS RR for specifying the location of services Formatet är: _Service._Proto.Name SRV Priority Weight Port Target Exempel för tjänsten foobar: _foobar._tcp.example.com. SRV 0 1 9 old-slow-box.example.com. SRV 0 3 9 new-fast-box.example.com.
Hur gör man då? Fallbeskrivning: se sthlm gb sia piggelin nogger storstrut igloo lill-per zaap storstrut trollis. se sthlm gb sia......
För att bli klient: Resolverkonfigurering! Resolverrutiner kallas de funktioner som används på en dator som frågar name-servern om olika saker Man måste alltså konfigurera resolvern på alla datorer som ska kunna ställa frågor mot DNS Tyvärr är konfigurationen olika på i stort sett alla system. Grundläggande resolverfunktioner: Två saker anger man normalt - vilka namnservrar man använder i en ordnad lista - vilken domän man tillhör, detta kan också vara en lista Listan av namn servrar betyder helt enkelt att man frågar en av dessa i taget tills man får svar. Listan av domäner skapar en s k sökväg för ett datornamn Sökväg innebär att man adderar de olika delarna till ett (inte) komplett datornamn (slutar inte på punkt)
Viktiga filer: /etc/resolv.conf innehåller IP-adresser till namn kan även innehålla andra sökvägar än default i /etc/resolv.conf: search gb.sthlm.se sia.sthlm.se nameserver 192.168.151.1 nameserver 192.168.34.8 Vilka domäner man ska söka i först Till vilka IP-nummer man ska ställa frågor eller: domain sthlm.se search gb.sthlm.se sia.sthlm.se nameserver 192.168.151.1 nameserver 192.168.34.8 Vilken domän jag tillhör (Om inget anges, tas domännamnet från host-namnet).
Att bli Namntjänst: BIND Programvara för UNIX som implementerar DNS Går att kompilera på de flesta UNIX-operativsystem Vi ska använda oss av BIND version 8 Finns att hämta med anonym ftp på : http://www.isc.org/ eller ftp://ftp.isc.org/isc/bind/src/ Viktiga filer: /usr/local/etc/named.conf Toppnivåfil som pekar ut alla andra En fil per zon (även baklängesuppslagningen räknas som en zon) Glöm inte att lägga till localhost och 127.0.0.0 Vanligt att lägga filerna under /usr/local/named/ Tips! Gör en katalog för master och en för slave samt en för default
Filstruktur för given fallbeskrivning: / etc usr resolv.conf named.conf etc local named master slave default db.localhost db.sthlm.se db.192.168.151 db.127.0.0 db.cache
/usr/local/etc/named.conf options { directory }; /usr/local/named ; zone. IN { type file }; hint; default/db.cache ; zone localhost IN { type master; file default/db.localhost ; }; zone 0.0.127.in-addr.arpa { type master; file default/db.127.0.0 ; };
zone sthlm.se IN { type master; file master/db.sthlm.se ; }; zone 151.168.192.in-addr.arpa IN { type master; file master/db.192.168.151 ; }; //kommentar #kommentar /* kommentar*/
/usr/local/named/master/db.sthlm.se (obs! I de här filerna är ; kommentartecken!) sthlm.se. IN SOA ns.sthlm.se. hostmaster.sthlm.se. ( 1999010100 ;serial 7200 ;refresh 3600 ;retry 604800 ;expire 86400) ;min TTL sthlm.se. IN NS ns.sthlm.se. sthlm.se. IN NS ns.gbg.se. ns.sthlm.se. IN A 192.168.151.1 piggelin.gb.sthlm.se. IN A 192.168.151.1 nogger.gb.sthlm.se. IN A 192.168.151.2 storstrut.gb.sthlm.se. IN A 192.168.151.3 iglo.gb.sthlm.se. IN A 192.168.151.4
;forts /etc/domain/master/db.sthlm.se lill-per.sia.sthlm.se. IN A 192.168.151.129 zaap.sia.sthlm.se. IN A 192.168.151.130 storstrut.sia.sthlm.se. IN A 192.168.151.131 trollis.sia.sthlm.se. IN A 192.168.151.132 gb.sthlm.se. gb.sthlm.se. sia.sthlm.se. sia.sthlm.se. IN MX 10 mail0.gb.sthlm.se. IN MX 20 mail1.gb.sthlm.se. IN MX 10 mail0.sia.sthlm.se. IN MX 20 mail1.sia.sthlm.se.
/usr/local/named/master/db.localhost ; om domän namnet är samma som ursprung kan @ användas istället @ IN SOA ns.sthlm.se. hostmaster.sthlm.se. ( 1999010100 ;serialnumber 7200 ;refresh 3600 ;retry 604800 ;expire 86400) ;min TTL localhost. IN NS ns.sthlm.se. localhost. IN A 127.0.0.1
/usr/local/named/master/db.192.168.151 @ IN SOA ns.sthlm.se. hostmaster.sthlm.se. ( 1999010100 ;serial 7200 ;refresh 3600 ;retry 604800 ;expire 86400) ;min TTL 151.168.192.in-addr.arpa. IN NS ns.sthlm.se. 151.168.192.in-addr.arpa. IN NS ns.sthlm.se. 1.151.168.192.in-addr.arpa. IN PTR piggelin.gb.sthlm.se. 2.151.168.192.in-addr.arpa. IN PTR nogger.gb.sthlm.se. 3.151.168.192.in-addr.arpa. IN PTR storstrut.gb.sthlm.se. 4.151.168.192.in-addr.arpa. IN PTR iglo.gb.sthlm.se. 129.151.168.192.in-addr.arpa. IN PTR lill-per.sia.sthlm.se. 130.151.168.192.in-addr.arpa. IN PTR zaap.sia.sthlm.se. 131.151.168.192.in-addr.arpa. IN PTR storstrut.sia.sthlm.se. 132.151.168.192.in-addr.arpa. IN PTR trollis.sia.sthlm.se.
/usr/local/named/master/db.127.0.0 @ IN SOA ns.sthlm.se. hostmaster.sthlm.se. ( 1999010100 ;serial 7200 ;refresh 3600 ;retry 604800 ;expire 86400) ;min TTL 0.0.127.in-addr.arpa. IN NS ns.sthlm.se. 1.0.0.127.in-addr.arpa. IN PTR localhost.
/usr/local/named/default/db.root ; <<>> DiG 8.1 <<>>. ns ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3 ;; QUERY SECTION: ;;., type = NS, class = IN ;; ANSWER SECTION:. 5w6d16h IN NS ns.adm.world.. 5w6d16h IN NS ns2.adm.world.. 5w6d16h IN NS ns3.adm.world. ;; ADDITIONAL SECTION: ns.adm.world. 1D IN A 192.168.1.1 ns2.adm.world. 1D IN A 192.168.1.1 ns3.adm.world. 1D IN A 192.168.1.1 ;; Total query time: 13 msec ;; FROM: kabul.city.af.world to SERVER: default -- 192.168.1.1 ;; WHEN: Sun Mar 7 12:31:04 1999 ;; MSG SIZE sent: 17 rcvd: 124
Parametrar i db-filerna $TTL $ORIGIN Sätt default TTL. Sätt default origin.
Observera punkten på slutet! tumregel nr 1: Allt i filen db.kth.se ska sluta på kth.se. tumregel nr 2: Allt som delegeras neråt i samma domän måste ha en klisterpost.
Delegera Om man t ex vill delegera bort sia, (så att de tar hand om sina egna glass-datorer) så att någon annan blir auktoritativ namntjänst, gör såhär: - stryk alla sia-poster i db.sthlm.se-filen - lägg till en NS-post i db.sthlm.se-filen: sia.sthlm.se. IN NS den.som.har.hand.om.det.
Bakåtdelegering Hur gör man om man vill delegera ut baklängesuppslagningen? - Går bara att delegera på jämna oktetter MEN! - Man kan luras.
arpa arpa in-addr in-addr 130 130 237 237 228 228 51 CNAME 0-100 51
I filen db.130.237.228 så lägger man: 51.228.237.130.in-addr.arpa.... för alla 0 till 100 adresser. IN CNAME 51.0-100.228.237.130.in-addr.arpa. samt glöm inte att delegera: 0-100.228.237.130.in-addr.arpa. IN NS ns.den.som.ska.ha.det Måste man ha en klisterpost?
Paketformat Ett paket på nätet som kommunicerar med databasen har ett bestämt format Detta paket innehållere ett par olika delar: Header Question Answer Authority Additional ID QR OPCODE AA TC RD RA RESERVED RCODE QDCOUNT ANCOUNT NSCOUNT ARCOUNT
Header En header finns i både frågor och i svar innehåller: id som unikt identifierar frågan flaggor som t ex om rekursion önskas eller inte svarskoder som t ex answer koder som t ex no error eller refused räknare som talar om hur många poster som finns i övriga fyra delar
ID QR OPCODE AA TC RD RA Reserved RCODE QCOUNT ANCOUNT NSCOUNT ARCOUNT Unikt id för meddelandet 0 för fråga 1 för svar Vad för typ av fråga? tex: 0 = QUERY 1 = IQUERY (inverse query) 2 = STATUS (fråga om status) 1 om Bemyndigat svar Truncation (svaret trunkerat för att det var för stort för ett paket.) Recursion Desired Recursion Available Response code, tex: 0 = No error 1 = Format error 2 = Server failure 3 = Name error 4 = Not implemented 5 = Refused #frågor #svar #ns-poster i authority-sektionen #additional records
Question Det finns alltid en och endast en fråga i varje paket innehåller: namn t ex www.kth.se typ t ex internetadress klass t ex internet Answer Det kan finnas mer än en post i ett svar En post består av: namn t ex www.kth.se typ t ex internetadress klass t ex internet data t ex 130.237.72.201 Authority Här finns information om ansvarsförhållanden mellan olika delar av databasen. Om svaret är en hänvisning så finns här information om detta
Additional När en databas svarar så kan den ibland gissa vad nästa fråga ska bli Om den råkar ha svar på denna så skickas detta svar med som additional information.