6. Domain Name System (DNS)

1. 6. Domain Name System (DNS) • P. Mockapetris. DOMAIN NAMES - CONCEPTS AND FACILITIES. RFC 1034. 1987. • P. Mockapetris. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. RFC 1035. 1987. • Abbildung von Systemnamen (hostname) auf IP-Adressen und umgekehrt: • conan.informatik.uni-mannheim.de  134.155.96.10 • 134.155.96.48  pi4.informatik.uni-mannheim.de • verwendet alternativ TCP oder UDP

2. DNS Name Space

3. DNS Name Space • jeder Knoten (Node) hat einen Bezeichner (Label), der höchstens 63 Buchstaben lang ist • die Wurzel des DNS name space ist ein Knoten mit einem leeren Bezeichner • Groß-/Kleinschreibung wird nicht berücksichtigt • einen absolute domain name / fully qualified domain name (FQDN) erhält man, wenn man von einem Blatt des DNS name space zur Wurzel geht und dabei alle Bezeichner notiert; die Bezeichner werden mit einem „.“ voneinander getrennt

4. DNS Top-Level Domains • die DNS top-level domains finden sich direkt unterhalb des DNS name space Wurzelknotens • sie werden in 3 Klassen eingeteilt: • arpa - spezielle domain zur Abbildung von Adressen auf DNS Namen • (noch) sieben generic domains: com, edu, gov, int, mil, net, org • country / geographical domains: de, us, at, au, ...

5. DNS Zones • DNS ist ein verteiltes System - kein System kennt alle DNS Einträge • die top-level domains werden zentral verwaltet, die Verwaltung der darunter liegenden Teilbäume wird delegiert • eine Zone ist ein Teilbaum des DNS name space, der unabhängig von anderen Teilbäumen administriert wird, die nicht vollständig in dieser Zone liegen • eine Zone kann wiederum in mehrere Zonen unterteilt werden

6. DNS Zones • in jeder Zone gibt es: • einen primary name server, hier wird die Abbildung von den DNS Namen auf IP Adressen eingetragen, die in der Zone liegen • mehrere secondary name server, die als backup dienen und die ihre Informationen vom primary name server beziehen

7. DNS Prinzipielles Vorgehen • ein client beauftragt einen der ihm bekannten name server mit der Adressabbildung • ist diese Abbildung bekannt, antwortet der name server sofort • wenn die Abbildung nicht bekannt ist, muß der name server einen anderen name server kontaktieren, der die Abbildung kennt • aber: nicht jeder name server kennt jeden anderen name server!

8. DNS Prinzipielles Vorgehen • es gibt sogenannte root server im Internet: • diese kennen alle name server, die für die top-level domains verantwortlich sind • eine liste gibt es von ftp.rs.internic.net unter domain/root.zone • der root server kann die Anfrage an entsprechende name-server weiterleiten, die dann ihrerseits die Anfrage weiterleiten können • dies terminiert, wenn der name-server gefunden wurde, der für die eigentliche Abbildung verantwortlich ist (authoritative) • damit dieser Vorgang nicht wiederholt werden muss, werden Einträge vom name server in einem Cache gehalten

9. DNS Prinzipielles Vorgehen • die Weiterleitung von name server zu name server kann rekursiv oder iterativ erfolgen: • rekursiv: der kontaktierte name server fragt seinerseits nach und gibt dann das Ergebnis der Anfrage an den anfragenden name server zurück • iterativ: der kontaktierte name server gibt nur die Adresse des name servers zurück, der für die weitere Adressabbildung kontaktiert werden sollte • die root server unterstützen meist nur den iterativen Modus, die anderen name server verwenden meist den rekursiven Modus

10. 0 15 31 7 DNS Paketformat IP + UDP or TCP header identification flags number of questions number of answer RRs number of authority RRs number of additional RRs questions (variable number of questions) answers (variable number of resource records) authority (variable number of resource records) additional information (variable number of resource records)

11. DNS Paketformat • identification: ermöglicht es dem Sender, einer Anfrage die Antwort auf diese Anfrage von anderen Antworten zu unterscheiden (wie bei Ping!) • number of ... : Anzahl der Einträge in den jeweiligen Feldern variabler Länge • questions: ein oder mehr DNS Question Einträge (Anfrage nach Adressabbildung) • answers, authority, additional information: ein oder mehr resource record Einträge (Antwort auf eine Anfrage)

12. DNS Paketformat • flags: • query/response (1bit): 0=query, 1=response • opcode (4 bits): 0=standard query, 1=inverse query, 2=server status requests, ... • authoritative answer (1 bit): 1= Antwort stammt von einem authoritative name server • truncated (1 bit): 1=UDP Paket wurde auf 512 Byte Abgeschnitten (Paket war zu lang, TCP sollte benutzt werden!) • recursion desired (1 bit): 1=Rekursion über die name-server wird vom name-server durchgeführt, 0=der name-server liefert nur Informationen über den nächsten name-server zurück, der dann vom client selbständig kontaktiert werden muß • recursion available (1 bit): 1=der name server unterstützt rekursive Anfragen • return code (4 bits): 0=no error, 3=name error - DNS name wurde nicht gefunden, ...

13. 0 15 31 7 DNS Question name (variable length) type class

14. DNS Question • name: der DNS Name, der abgebildet werden soll, im Format [<label length><label>]*, wobei der letzte Eintrag eine label length von 0 hat (Wurzel Knoten).Beispiel 3www12uni-mannheim2de0 • type: welchen Typ soll die Antwort haben? Beispiele: 1=IP Adresse (A Type), 12=Hostname (pointer query Type), ... • class: um welche Protokollfamilie geht es? 1=IP

15. 0 15 31 7 DNS Resource Record domain name (variable length) type class time-to-live resource data resource data length

16. DNS Resource Record • name, type, class: wie bei DNS question • time-to-live: Anzahl an Sekunden, die die Antwort vom Empfänger gecached werden darf (meist 2 Tage) • resource data length: Länge des resource data Feldes (4 für IP) • resource data: Ergebnis der Abbildung (bei IP eine IP Adresse)

17. DNS Beispiel für Client/Server Interaktion • Anfrage: • questions: • name: 3ftp2uu3net0 • type: A • class: IN • alle anderen Felder sind leer • Antwort: • questions: leer • answers (ein resource record): • name: 3ftp2uu3net0 • type: A • class: IN • ttl: 345600 • resource data: 192.48.96.9

18. DNS Beispiel für Client/Server Interaktion • Antwort (Fortsetzung): • authority (2 resource records): • name: 2uu3net0 • type: NS (Name Server Type) • class: IN • resource data: 2ns2uu3net0 • 2. Eintrag analog! • additional information (2 resource records) • name: 2ns2uu3net0 • type: A • class: IN • resource data: 137.39.1.3 • 2. Eintrag analog!

19. DNS Demo • wir untersuchen einen telnet Aufruf mit tcpdump • unter /etc/resolv.conf finden wir die Einstellungen für den Rechner: • namesever • domain - dieser String (z.B. informatik.uni-mannheim.de) wird an nicht vollständige Domain Namen angehängt (z.B. conon), um diese zu vervollständigen • mit host können wir auf DNS von der Kommandozeile aus zugreifen (-v gibt detaillierte Infos): • host -v ftp.uu.net

20. DNS Pointer Query • ein DNS Pointer Query wird von einem client verwendet, um zu einer IP Adresse den DNS Namen eines Systems zu erhalten • hierzu wird der in-addr.arpa Unterbaum des DNS name space benötigt • die Verantwortung für eine Zone beinhaltet automatisch auch die Verantwortung für den entsprechenden Unterbaum des in-addr.arpa Bereiches • z.B. uni-mannheim.de und 155.134.in-addr.arpa gehören zur Zone, für die die Universität Mannheim verantwortlich ist!

21. DNS Pointer Query Beispiel • wir verwenden • host 134.155.48.96 • und tcpdump, um ein Pointer Query in Aktion zu sehen

22. DNS CNAME Resource Record • manche DNS Einträge sind „virtuell“ und werden nicht direkt auf eine IP Adresse abgebildet, sondern verweisen auf einen anderen DNS Namen • z.B. www.uni-heidelberg.de wird auf:www-uni.urz.uni-heidelberg.de abgebildet • dies ermöglicht es, daß der Eintrag unabhängig von einer IP Adresse bleibt • DNS unterstützt dies mit dem CNAME Resource Record, eine Antwort enthält dann im answers Teil zwei Einträge: die Abbildung auf den eigentlichen DNS Namen (CNAME resource record) und die Adresse (A resource record) dieses DNS Namens

23. DNS CNAME Beispiel • host www.uni-heidelberg.de

24. DNS Caching • um die Belastung des Netzes zu minimieren, werden Einträge in den DNS Servern gecached • jeder Eintrag hat eine ttl (wird als Antwort einer Anfrage mitgeschickt) • wenn die ttl auf 0 sinkt, wird der Eintrag im Cache gelöscht • die clients haben keinen cache (lohnt nicht, da ein client eine einzelne Anwendung ist, die i.d.R. nur eine kurze Laufzeit hat)

25. DNS Implementierung • server: named unter UNIX • client (Java): • InetAddress addr = InetAddress.getByName(String) • InetAddress[] addrs = InetAddress.getAllByName(String) • addr.getAddress() • addr.getName()

26. TCP vs. UDP • DNS funktioniert über TCP oder UDP • i.d.R. wird UDP verwendet, bei Paketverlust erfolgt Übertragungswiederholung nach timeout • TCP wird verwendet: • wenn DNS Pakete größer als 512 bytes sind und daher abgeschnitten werden (truncated option bit gesetzt) • beim initialisieren von secondary name server durch die Übertragung aller Informationen vom primary name server

27. DNS Zusammenfassendes Beispiel - rlogin • rlogin erlaubt das Einloggen von einem rlogin client auf einen entfernten Rechner (rlogin server), dabei muß kein Paßwort angegeben werden, wenn der Rechner, von dem aus man sich einloggt, in einer Liste von vertrauenswürdigen Rechnern eingetragen ist (.rhosts). • diese Liste beinhaltet DNS Namen • um festzustellen, ob der Verbindungswunsch von einem vertrauenswürdiger Rechner kommt, wird ein pointer query durchgeführt • um sich vor Mißbrauch zu schützen, wird danach eine normale DNS Anfrage durchgeführt: eine der zurückgegebenen Adressen muß dann mit der IP Adresse des rlogin clients übereinstimmen

28. PTR? PTR? PTR A? NS A TCP A? A A A? PTR? PTR A? A? NS A DNS Zusammenfassendes Beispiel - rlogin root name server server‘s name server rlogin server root name server client‘s name server rlogin client