DNS. Måns Nilsson, KTHNOC/SUNET 16 september 2005

Transkript

1 DNS Måns Nilsson, KTHNOC/SUNET 16 september 2005

2 Innehåll 1 Historia och generell beskrivning 3 2 Organisation och politik runt domäner 20 3 Tekniken, hur sitter trädet ihop? 23 4 Data i DNS 29 5 Protokollet på tråden 45 6 Uppslagsprocessen 53 1

3 7 Drift av DNS-system 66 8 Nyheter i protokollet 70 9 Säkerhet 80 2

4 1 Historia och generell beskrivning Domain Name System Översätter från domännamn till IP-nummer Och tvärtom från nr till namn Även andra funktioner, som till exempel epostvägvisning Ett hierarkiskt system kan ses som ett träd. Men upp-och-ner! Roten är längst upp. 3

5 ... historia... I begynnelsen var ARPANET: NCP hade max 256 noder inga problem; vi tar och skickar ut en fil 2ggr per vecka! IPv4: 2 32 noder. Fortfarande samma fil! 1983 började det bli svårt att hinna leverera filen till alla som ville ha den. Dags att fundera ut nåt! 4

6 ... historia... Man började med att definiera hur ett namn på en dator ska se ut: RFC883. Detta uppdaterades i RFC Därefter tog man tag i att definiera den distribuerade databasens struktur. Det definieras i RFC DNS som det definieras i 1034 och 1035 gäller i allt väsentligt fortfarande. Nya saker är på ingång. Mer om dem senare! 5

7 Hur är det realiserat? DNS är uppbyggt som en distribuerad databas, den största och mest distribuerade databasen på Internet. DNS är ett protokoll som använder IP, både TCP och UDP. DNS hör hemma bland applikationerna, på nivå 7 i OSI-modellen. 6

8 Ett DNS-träd. (rot) net se ip6 arpa in addr Läsriktning nordu server nl surfnet www liu lysator sunet pilsnet kom yebisu 136 7

9 ... domännamn... Ett domännamns anatomi Avdelare FQDN yebisu.pilsnet.sunet.se. Nod cctld 8

10 Domänamn Domännamn läses underifrån: yebisu.pilsnet.sunet.se. Alltså från mest signifikanta delen. En punkt på slutet anger att domännamnet är komplett ett s.k. Fully Qualified Domain Name, förkortat FQDN. Punkterna har sällan med IP-adresser att göra! 9

11 Toppdomäner En toppdomän är den sträng som kommer sist i ett FQDN. En typisk toppdomän är landskodsdomänen, som består av de två bokstäver som definierar landet eller den friliggande provinsen i ISO Det finns dessutom ett antal generiska toppdomäner. Dessa sk GTLD er är bl a COM, ORG, NET, INT, ARPA, BIZ, MUSEUM, INFO, EDU (men inte EU än!) 10

12 GTLD = Generic Top Level Domain cctld = Country Code Top Level Domain... toppdomäner... Inställningen till den egna toppdomänen varierar Strikta länder: FI, FR, TM. Öppna länder: DK, NU, CC, SE Vissa GTLD er likaså öppna, andra slutna. En strukturdomän ARPA En del länder har tvingande underdomäner, som co.uk, org.al. 11

13 Delegering för att distribuera arbetet Ansvar delegeras uppifrån och ner: ICANN hanterar roten och delegerar SE till IIS som delegerar KTH till Kungliga Tekniska Högskolan som delegerar STACKEN till sin datorförening. Delegeringen är alltså ett överlämnande av ansvar. Den kan ske vid varje nod i trädet. En punkt betyder inte att man måste delegera! pilsnet.sunet.se och sunet.se är till exempel samma zon. 12

14 Delegeringsgränser IANA/ICANN. IIS KTH ITE KTHNOC se kth noc www 13

15 Strukturdomänen ARPA med döttrar Hittills har vi framförallt berört domännamn som ser ut som om de kunde sitta på en dator, skrivas in efter epostadress eller i en vävbläddrares adressfönster. Men, det finns mer än så i DNS. Under ARPA samlar man numera inte försvarsforskning i USA utan infrastrukturdomäner: Advanced Research Projects Agency blev med ens Address and Routing Parameter Area Domain i och med RFC

16 ...ARPA... Under ARPA finner vi bla: IN-ADDR: Mappning av IPv4-adresser till namn. IP6: Mappning av IPv6-adresser till namn. (Låg tidigare under.int) E164: Mappning av E.164-telefonnummer till DNS-namn. 15

17 ... IN-ADDR.ARPA... IN-ADDR är viktigast (än så länge) och störst av zonerna under ARPA. Den innehåller mappningar från IP-adresser till domännamn: in-addr.arpa blir yebisu.pilsnet.sunet.se, dvs Fast de ser ut att vara baklänges! Varför? 16

18 Varför är IN-ADDR.ARPA så konstigt?... IN-ADDR.ARPA är ju baklänges... Av konsekvensskäl data i DNS skrivs alltid a i ordning från specifikt till allmänt: yebisu.pilsnet.sunet.se. Då måste förstås IP-adressen som normalt skrivs från allmänt till specifikt; dvs kastas om så den följer trädets struktur. Delegering sker vid punkterna i IP-adressen, dvs på oktettgräns. a Utom under.uk, en gång i tiden, men så kör de bil på fel sida också ;-) 17

19 Ett DNS-träd (igen). (rot) net se ip6 arpa in addr Läsriktning nordu server nl surfnet www liu lysator sunet pilsnet kom yebisu

20 IP6.ARPA För IPv6-reverskoppling finns en motsvarande struktur; där FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 mappas till A.B.C.D.E.F A.B.C.D.E.F.IP6.ARPA. Tidigare användes som sagt IP6.INT för IPv6-revers, men det är nu ändrat. 19

21 2 Organisation och politik runt domäner Från början enskilda personer som var personligt bekanta. Nu har domännamn som politisk och organisatorisk företeelse växt ur den kostymen. Många olika intressenter vill vara med och bestämma. Nationalstaterna håller på att vakna. (SOU 2002:60!) 20

22 Olika underavdelningar, tillsätter ICANNs styrelse Organisation internationellt Departement of Commerce ICANN Verisign, hanterar rot och gtld Olika länders registries Shared Registrars, kundkontakter för gtld registrering. 21

23 Organisation i Sverige Tillsätter styrelseledamöter. ISOC SE ICANN/ IANA Delar ut SE SOF IIS Administrativ innehavare Industri förbundet NIC SE NDR NÖD Registrerar domännamn, skapar zonfil. Förslag till regelverk. Överklaganden 22

24 3 Tekniken, hur sitter trädet ihop? Vi har hittills pratat om domäner. Nytt begrepp: ZON En domän är allt under en given punkt i trädet. En zon är allt under en given punkt i trädet minus det som delegerats vidare. För varje zon måste det finnas minst en namnserver utpekad från moderzonen. Det kan (och bör!) finnas fler. 23

25 ... tekniken... DNS-rymden realiseras alltså med hjälp av delegeringar från namnservers till namnservers; i moderzonen hänvisar man bort en bit av sin underliggande namnrymd. En namnserver har fått sig tilldelad en del av namnrymden. På så vis skapar man praktiskt uppdelningen i olika administrativa delar. 24

26 ... tekniken... Namnservern/rarna är alltså den kombination av hårdoch mjukvara som utgör en zons hemvist. Namnservern behöver inte vara dedikerad till en zon, utom för roten. (men det är av stabilitetsskäl, inte ett absolut krav, jfr RFC2870). 25

27 ... tekniken Zontransfers... Data replikeras mellan olika servers utpekade för samma zon. ( zontransfer ) En av servrarna är utsedd till master. På mastern uppdaterar administratören data i zonerna. Slavarna har masterns IP-adress inställd (manuellt) och frågar med jämna mellanrum mastern om zonens serienummer. Om serienumret ändrats enligt ett visst mönster (RFC 1982) så begär slaven att få den nya zonen från mastern. Då slipper man underhålla data på mer än ett ställe. 26

28 ... tekniken Zontransfers... Andra system finns också: Dynamic Updates DNS-meddelanden med uppdateringar, lägger till eller tar bort en post. Database backends Hela systemet med zontransfer och inom-protokoll-data skrotas till förmån för ett nytt system som i princip gör alla servers till masters. Konvergensansvaret ligger då utanför DNS. Detta är tänkt att ge snabbare konvergens och förhoppningsvis mindre trafik. 27

29 ... tekniken Zontransfers... En annan metod att snabba upp är inkrementell zontransfer, där mastern (om slaven begär det) endast skickar innehålls- mellan ett angivet, gammalt, serienummer och sitt eget nyladdade. Ytterligare konvergens nås genom att implementera DNS Notify, (RFC 1996), under vilket mastern skickar uppdateringsmeddelanden till alla slavar, vilka om de stöder protokollet, omedelbart inleder serienummerkontroll och om så befinns nödvändigt, (eventuellt inkrementell) zontransfer. 28

30 4 Data i DNS Data i DNS är strukturerat efter namnet på den nod det associeras med. För en given nod kan det finnas flera olika dataposter, med vissa undantag för kombinationer som inte får förekomma. Även om vissa andra kombinationer är tillåtna så är de mycket ovanliga. Det finns flera parallella träd, sk klasser: INternet, CHAOS, och HESIOD. I praktiken används bara INternet, och det är skönsvärde i all programvara. 29

31 Nodnamn är begränsade enligt följande: Giltiga tecken i domännamn är A-z, 0-9 och bindestreck. a Skiftläge är ej signifikant men ska bevaras. Varje del i namnet är 0-63 tecken. Namnet får bestå av maximalt 63 delar. Totala längden får ej överstiga 255 tecken. a Och understreck i SRV-poster 30

32 ... data i DNS... Data för en nod kan innehålla: IP-adressen till noden: A Om noden ligger under [IN-ADDR IP6].ARPA kan man vilja ha värddatornamnet för den IP-adress noden representerar i en PTR Var post ska skickas som ska till noden: MX (för zoner (som också är noder)) Data om zonen: SOA Vilken namnserver som är ansvarig för zonen: NS Vilken dator man egentligen ska gå till: CNAME Vilken sorts dator en viss nod är: HINFO 31

33 Generell fritext om en nod: TXT Ny all-singing-dancing-service-post: SRV Det finns ytterligare några posttyper, men vi hoppar över några av dem och spar resten till sista föreläsningen. 32

34 Posttyper i detalj Poster hängs alltså upp på den nod de finns under. Normalt skriver man en post på en rad i klassiskt filformat, och gemensamt för alla poster är att de har uppdelningen: nodnamn TTL KLASS TYP RDATA där: TTL är bästföredatum KLASS är IN/CH/HS TYP är posttypen RDATA är nyttolasten. 33

35 ... Posttyper... A Adress A-posten är vår vanligaste art. Den pekar ut den IP-adress som gömmer sig bakom ett datornamn. paka.qaki.org. 600 IN A ; Nodnamn TTL Klass Typ RDATA Det finns också en AAAA ( quad-a ) för IPv6: localhost. 600 IN AAAA ::1 34

36 SOA Start Of Authority... Posttyper... SOA är den största av de vanliga posterna. Den innehålller administrativt data om zonen. Varje zon måste börja med en SOA-post. qaki.org. 600 IN SOA casper.besserwisser.org. qaryn.qaki.org. ( ; serial ; refresh (8 hours) ; retry (4 hours) ; expire (5 w 6 days 16 hours) 60 ) ; minimum (1 minute) På SOA hänger så att säga resten av zonen. 35

37 ... Posttyper... NS Name Server NS-posten pekar ut namnservers för en zon. Det måste finnas minst en NS-post i varje zon. qaki.org. 600 IN NS vovve.besserwisser.org. qaki.org. 600 IN NS casper.besserwisser.org. Noden är alltid en zon. (minst) RDATA är ett datornamn, som måste finnas som A-post någonstans i DNS. 36

38 ... Posttyper... MX Mail exchanger MX berättar till vilken dator e-post för en given nod ska skickas. qaki.org. 600 IN MX 10 snipan.besserwisser.org. qaki.org. 600 IN MX 20 casper.besserwisser.org. Noden kan vara zon eller dator. RDATA har två fält: Vikt, , anger preferens. Lägre är bättre. Host, anger namnet på datorn som tar emot post. 37

39 CNAME Canonical NAME... Posttyper... CNAME är ett aliassystem. Ett namn pekas till ett annat namn IN CNAME casper.besserwisser.org. CNAMEs leder ofta till förvirring. För att minska detta gäller regeln att ingen annan post får dela nod med ett CNAME. Har man således ett CNAME på en nod så får man inte ha något annat där. 38

40 ...CNAMEärkonstigt... Följande är illegalt: IN CNAME casper.besserwisser.org IN MX 10 snipan.besserwisser.org. Följande är däremot legalt: IN A IN MX 10 snipan.besserwisser.org. 39

41 PTR PoinTeR PTR-posten svarar för mappning av IP-adresser till namn. Den är lika för IPv4 och IPv6, och ser ut så här: in-addr.arpa. 600 IN PTR paka.qaki.org. ; IP-adressen omkastad TTL Klass Posttyp RDATA Motsvarande för IPv6 byter bara ut nodnamnet till: A.B.C.D.E.F A.B.C.D.E.F.IP6.ARPA. RDATA är alltså ett datornamn. Man kan ha flera om man vill; det är legalt. 40

42 SRV SeRVice SRV-posten är ett ovanligt djur. Den används för att i detalj beskriva var en viss tjänst finns, och hur man kontaktar den över IP. _kerberos._tcp.pdc.kth.se. 600 IN SRV jacksmelt.pdc.kth.se. _kerberos._udp.pdc.kth.se. 600 IN SRV jacksmelt.pdc.kth.se. ; tjänst protokoll nod TTL Klass Post Prio Vikt Port Datornamn. _kerberos Anger att detta är en SRV-nod och inte en dator, och att det är Kerberos vi har med att göra. _tcp Anger att tjänsten är nåbar över TCP. nod För vilken zon domän nod ger vi tjänst? TTL, Klass, Post: Standardbetydelser. 41

43 Prioritet Ordnar olika datorer i preferens, mindre är bättre Lik MX-posten. Vikt Ordnar olika datorer med samma prioritet. Mer är bättre (Tvärtom mot prioritet!) Port Vilken TCP UDP-port som tjänsten erbjuds på. Datornamn Den dator som erbjuder service. 42

44 TXT och HINFO Data för människor. TXT-posten kan innehålla fritext om en nod. HINFO beskriver OS och hårdvara. classic.pilsnet.sunet.se. 600 IN A classic.pilsnet.sunet.se. 600 IN HINFO "bongo-386" "Flightless bird" classic.pilsnet.sunet.se. 600 IN TXT "Mere af alting" TXT är en sträng på upp till 2 8 tecken. HINFO är två strängar, en för hårdvaruarkitektur och en för OS. Egentligen ska man följa en lista på godkända namn, men den är lätt föråldrad; Linux och Windows 2000 saknas, tex. SRV-drafts använder (felaktigt!) TXT. 43

45 Hela zonen nihlen.org IN SOA vulcan.nihlen.org. per.nihlen.org. ( ; serial ; refresh 7200 ; retry ; expire 400 ; minimum ) nihlen.org IN MX 0 klingon.nihlen.org. nihlen.org IN NS jazz.tjernlund.net. nihlen.org IN NS vovve.besserwisser.org. nihlen.org IN NS vulcan.nihlen.org. borg.nihlen.org IN A hirogen.nihlen.org IN A klingon.nihlen.org IN A mail.nihlen.org IN CNAME klingon.nihlen.org. ns.nihlen.org IN A vulcan.nihlen.org IN A

46 5 Protokollet på tråden lite repetition här... Klient-Serversystem, frågor skickas och svar lämnas i utbyte. Det kan transporteras ovanpå såväl TCP som UDP, och använder i bägge fallen port 53. Varje frågetyp utom AXFR (som bara åker TCP) kan ställas över bägge protokollen. Det är illegalt att inte erbjuda tjänst på både TCP & UDP. 45

47 DNS-meddelanden i klassisk DNS är över UDP begränsade till 512 oktetter nyttolast, pga forntida problem med MTU 576 och UDP-fragmentering. Om ett svar på en UDP-fråga skulle överstiga 512 oktetter sätter servern en bit i meddelandehuvudet som anger detta. Klienten kan då välja att fråga om över TCP. Omfråga över TCP är resursmässigt dyrt server och klient måste hålla session och skicka fler paket. Därför vill man inte normalt sett skapa poster som skulle leda till svar över 512 oktetter. 46

48 Meddelandehuvudet 16 bitar QUERY ID QR Opcode AA TC RD RA Z RCODE QDCOUNT ANCOUNT NSCOUNT ARCOUNT 47

49 ID Ett 16-bitarsnummer, som identifierar frågan, sätts av frågaren och återfinns i svaret. QR En bit, 1 för svar, 0 för fråga. OPCODE Beskriver på 4 bitar frågans art: 0 Standardfråga. 1 Inverse Query Obsolet. 2 Statusfråga Reserverade. A Svar med auktoritet. Bara giltig i svarsmeddelanden, och om den är satt berättar den att servern som svarar är antingen master eller slav för zonen svaret hör hemma i. TC Trunkerat svar. Svaret är för långt för valt 48

50 transportsystem (typiskt UDP.) RD Rekursion önskas. Klienten ber servern utföra rekursion, och servern kopierar önskan i svaret. RA Rekursion tillgänglig. Om satt i svar så utför servern rekursion. Z Reserverad. Måste ursprungligen vara satt till 0 i alla meddelanden. Numera förbrukade. 49

51 RCODE Svarskod, 4 bitar vars värde säger: 0 Allt väl. 1 Syntaxfel. Servern förstod inte frågan. 2 Serverfel. Servern har ett problem som hindrar den att svara. Typiskt en slav som inte lyckats hämta zonen. 3 Namnet finns inte. Bara viktigt om AA är satt. 4 Ej implementerat. Servern stöder inte frågetypen. 5 Förvägrat svar. Servern vägrar svara av administrativa skäl. ACL av något slag Reserverade värden för framtida bruk. QDCOUNT 16bitarstal som anger antalet frågor i meddelandet. ANCOUNT 16bitarstal som anger antalet svar i 50

52 meddelandet. NSCOUNT 16bitarstal som anger antalet NS-poster i meddelandets tilläggsdatadel. ARCOUNT 16bitarstal som anger antalet dataposter i meddelandets tilläggsdatadel. 51

53 Därefter följer de tre nyttolastsegmenten: QUESTION: Innehåller frågan. Fylls på av klienten. Servern bibehåller frågedata i svaret. Frågan innehåller normalt: Nod som frågan gäller. Klass, IN/CHAOS/HESIOD QTYPE, ser ut som en posttyp (PTR/A/NS) men inte bara, det finns några till som AXFR och ANY ANSWER: Innehåller ett eller flera svar. ADDITIONAL: Innehåller bra-att-ha-data, typiskt NS-poster. 52

54 6 Uppslagsprocessen Hur hittar vi allt data vi har matat in? 53

55 När en applikation (tex telnet) får ett värdnamn som argument anropar den en funktion som på Unix heter gethostbyname(), vilken är insteget till DNS mfl namndatabaser (tex /etc/hosts). Som svar tillbaka får den en IP-adress. Vad händer bakom kulisserna? 54

56 ... Uppslagsprocessen... Det finns tre olika grundagenter i uppslagsprocessen: Resolvern Klientbibliotek i varje DNS-kapabel dator. Uppslagsservern Första anhalt, den som gör jobbet. Namnservern Här tillhandahålls data. 55

57 ... Uppslagsprocessen... Resolvern är den del som tar hand om systemanropet. Konfigureras att leta i filer, NIS, eller DNS. Formulerar fråga till uppslagsservern Tar emot svaret och presenterar det för applikationen. 56

58 ... Uppslagsprocessen... Uppslagsservern lyssnar på frågor från resolvern Den kan traversera DNS-trädet, och finna svar på frågorna. Den behöver inte veta något om det faktiska datat, mer än: 57

59 ... Uppslagsprocessen... För att kunna börja leta måste man ha en instegspunkt. Den består av en lista över de DNS-servers som håller root-zonen, dvs IN NS A.ROOT-SERVERS.NET IN NS B.ROOT-SERVERS.NET IN NS C.ROOT-SERVERS.NET IN NS D.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET IN A B.ROOT-SERVERS.NET IN A C.ROOT-SERVERS.NET IN A D.ROOT-SERVERS.NET IN A (Det finns egentligen 13 (vilket är så många man får in i ett UDP-meddelande), fast vi visar bara 4...) Den här listan stoppas in i uppslagsservern. 58

60 ... Uppslagsprocessen... Namnservern (eller rättare sagt alla utpekade namnservers på Internet) är platsen som uppslagsservern söker svaret hos. Uppslagsservern behöver alltså inte veta något förutom det data den själv är konfigurerad med. 59

61 ... Uppslagsprocessen... Processen som uppslagsservern utför, på begäran av resolvern, med hjälp av alla namnservers, kallas rekursion. Detta eftersom uppslagsservern, endast med hjälp av sin hintfil, rekurserar igenom strukturen av olika namnservers för att finna svaret. 60

62 ... Uppslagsprocessen... De där konstiga PTR-posterna då? När resolvern får ett gethostbyaddr()-anrop (= vi har IP-adressen, vi vill ha datornamnet ) istället, och frågan alltså är omvänd, då sker följande i resolverbiblioteket: 1. Tag oktetterna i IP-adressen och kasta om ordningen från till Klistra på in-addr.arpa på slutet. 3. Skicka en begäran om PTR-posten för det sålunda konstruerade namnet. 4. Få (förhoppningsvis) tillbaka svaret på övligt vis. 61

63 5. Reversera omkastningsproceduren och presentera datat. För IPv6 utförs samma omkastningsoperation, men man delar upp adressen på halv oktett (mellan varje hex-siffra) istället, vilket är en funktion av skrivsättet, plus att man förstås häktar på IP6.ARPA på slutet istället. Detta är alltså nödvändigt pga olika endian -konventioner mellan värddatornamn och IP-adresser. 62

64 Det kan se ut så här: Klienten. (rotnoden) Resolvservern org se lu besserwisser af 63

65 Glue records och delegering När en uppslagsserver rekurserar för att finna ett svar tar den sig vidare med hjälp av hänvisning till nya NS-poster vars RDATA den slår upp i DNS. Men om NS-postens RDATA ligger i den zon man just fått hänvisning till? Instant lockup! Nej, om så är fallet, så måste moderzonen extrakonfigureras med A-poster till namnservers i dotterzonen, så kallade Glue Records. 64

66 Programvara debugprogram. nslookup: Använd inte nslookup! Det är alldeles för optimistiskt och hurtigt. Det kommer dessutom att försvinna från BIND-distributionen. host: Betydligt bättre som snabbverktyg. dig: DNS-teknikerns Hiltihammare. Berättar precis hur saker hänger ihop. 65

67 7 Drift av DNS-system Det behöver inte finnas kopplingar mellan A & PTR! Det är endast och allena en administrativ sak. Delegeringen är ett ansvar, inte en rättighet. Det är alltid efter den överliggande domänens principer man tilldelas delegering. Därför är det viktigt att man ser till att DNS-systemet sköts. Som tur är så är DNS ett mycket stryktåligt system. Det kan fungera, och bra! med så mycket som 25-30% fel (fnvp fel). 66

68 Men det är inte bra nog. Det måste bli bättre! Varför det då? Det gick ju bra sa du! Många företag finns publikt sett bara på Internet. Internetkommunikationen är även för vanliga företag allt mer central. Mer och mer data tenderar att publiceras i DNS. Kritiskt data. (W2K Active Directory!) Finns du inte i DNS så syns du inte. 67

69 ... Drift... Bra DNS beror på många olika saker. Entropi är nödvändigt! Flera av allt är lätt och bra: Flera olika OS Flera olika AS Flera olika elbolag (Kista!) Flera olika ställen (WTC!) Flera olika programvaror vore bra men är svårt. Bättring är på väg. Exempel: Microsofts försvinnande 68

70 Hantering av data För att DNS ska fungera måste man så klart stoppa in data. Det finns lite olika metoder: vi. Vanligast. Fungerar ofta bra. Antingen på zonfil eller magisk fil. Tillverkarens GUI. För till exempel Microsoft men även mer specialiserade produkter som QIP. Kostar ofta mycket, kan ha begränsningar. Dynamisk DNS. För hand eller per automatik vid DHCP. Praktiskt men potentiellt farligt. 69

71 8 Nyheter i protokollet DNS har måst utvecklas ganska drastiskt de senaste åren, men man kan inte göra avkall på kravet på bakåtkompatibilitet, eller åtminstone frihet från påverkan på de som inte kan, vill, eller vet att de borde uppgradera. Några av de saker som tillkommit har vi redan nämnt, som IXFR och Notify. Några återstår och kommer här. 70

72 EDNS0 EDNS0 (ung. extension of DNS, v. 0, se RFC 2671) är ett system för att låta ett klient-serverpar, inom ramarna för vanlig DNS förhandla fram en gemensam uppsättning av utökade finesser som de kan använda för att ta sig förbi flaskhalsar i standarden. En begränsning som EDNS0 kan få bort är storlek på UDP-meddelanden. En annan är att man kan signalera beredvillighet att acceptera DNSSEC-data. (DNSSEC OK, RFC 3225) 71

73 RFC 2317 klasslös reversdelegering Eftersom IP-routing numera görs utan fixering vid de gamla klasserna av IP-adresser uppstår snart behovet att bryta klassgränserna även i DNS. Under IN-ADDR.ARPA är minsta odelbara delegering 256 adresser. Under IP6.ARPA är den 16 adresser. Hur göra? 72

74 Man gör en ny dotterzon, här för /27:... Hur göra? in-addr.arpa. NS vovve.besserwisser.org. För att resolvern ska hitta: in-addr.arpa. CNAME in-addr.arpa. ;...osv till in-addr.arpa. CNAME in-addr.arpa. I den nya zonen: in-addr.arpa. PTR network.besserwisser.org. För IPv6 är problemet i princip irrelevant eftersom minsta allokering är en /64. 73

75 Dynamisk DNS, RFC 2136 On-line-redigering. Använder DNS-meddelanden. Inkrementerar SOA. Säkras ofta med TSIG. Behöver helst IXFR. Active Directory flitig användare. 74

76 Räksmörgås eller Internationalized Domain Names En försvinnande del av jordens befolkning klarar att uttrycka alla sina ord med US-ASCII. Vi andra fer trdla runt i svrjan och begränsa oss. IDN, som beskrivs i RFC 3490, 3491, 3492 är ett sätt att lösa detta. 75

77 ...IDN... Kraven är hårda: Protokollet på tråden kan inte förändras. Även om protokollet är 8-bit-rent så är inte all programvara det. Hela Unicode måste in. Men man kan inte ha två olika glyfer som ser lika ut för ögat men har olika bitmönster i någon kodning. 76

78 Hur löser man det här? Jo, man valde IDNA, IDN in Applications. Protokollet och dataformatet på tråden är orört. Istället tar man en trestegsraket:...idn... Reducera alla grafonymer (med lika utseende) till ett definerat tecken. Detta kallas nameprep, Name Preparation. (3491) Koda dem med Punycode, ett system för att klämma in Unicode-tecken i ASCII. (3492) Lämna till applikationerna att upptäcka de kodade namnen och tolka dem. (3490) 77

79 ...IDN... Så här kan det se ut: räksmörgås blir zq--rksmrgs-5wao1o vilket alltså går bra att köra i alla vanliga system. Lite trist att läsa men det fungerar. Sedan är det alltså upp till vävbläddraren att skriva om det till räksmörgås igen. 78

80 Telefoner i DNS E.164.ARPA I och med att telefoni och Internet konvergerar till höger och vänster behövs system för att kunna anropa Internet-addresserade personer eller datorer från telefoner, och vice versa. Under E164.ARPA stoppar man in telefonnummer så att man kan hänga till exempel hänvisningsdata på dem: blir e164.arpa. Det här bygger bland annat KTH s och SU s IP-telefoniutveckling på. 79

81 9 Säkerhet Säkerhet kan definieras på en rad olika sätt i en DNS-kontext. 1. Skydd mot ändring av data. 2. Skydd för värddatorn. 3. Skydd för känsligt data. 80

82 ... säkerhet?... Vilka lösningar finns för dessa problem? 1. DNSSEC. Mer därom senare. I vissa fall hjälper TSIG. 2. Korrekt systemadministration, nya versioner, försiktig konfiguration. 3. Stoppa inte in datat i DNS. Blockerade zontransfers är inte ett sätt att skydda data, det är något man gör av prestandaskäl! 81

83 TSIG Transaction SIGnatures TSIG är ett sätt att sätta sitt sigill på en datatransaktion som utförs över DNS-meddelanden. RFC 2845 Secret Key Transaction Authentication for DNS (TSIG) Ingen kryptering bara äkthet! Värd till värd, ingen PKI. Skalar inte! Används för: 1. Klientfrågor. 2. Dynamiska uppdateringar 3. Zontransfers. 82

84 TSIG på bild master.server.se. slav.server.se 236 All trafik här signeras om klockorna och nycklarna stämmer. 236 server slave.server.se { keys { 236 }; }; server master.server.se { keys { 236 }; }; 83

85 ... TSIG... TSIG hjälper oss att garantera att de DNS-meddelanden vi utväxlar mellan datorer organisatoriskt nära oss inte förvanskas. Det är inte en ersättning för DNSSEC! Nära oss kan alltså vara: Till klienter. Mellan slav och master. Från DHCP-server (eller klient) till DNS-server vid bruk av dynamisk DNS-uppdatering. 84

86 Men, det löser ju inte allt! Nej, och det är därför vi har rullat ut DNSSEC. Igår. Om DNSSEC mer om tiden tillåter.. 85

87 Slut Frågor? Funderingar? Måns Nilsson, 86