Systemsicherheit 15: DNSSEC

Transkript

1 Systemsicherheit 15: DNSSEC Gliederung Einführung Domain Name System Domainnamen und die DNS-Hierarchie Delegation und Zonen Ressource Records (RR) DNS-Server und DNS-Resolver Auflösung von Domainnamen (und IP-Adressen) DNSSEC Neue RR-Datentypen Schlüssel und Signaturen Rückruf eines Schlüssels Probleme mit DNSSEC

2 Einführung DNS Kurze Geschichte des DNS Ursprung: hosts.txt des Arpanet einfaches Textfile mit Zuordnung Name IP-Adresse manuell aktualisiert vom Stanford Research Institute Verteilung per an alle Computer Netzwerklast: Proportional zu (Anzahl der Computer) : Geburt des Domain Name System als verteilte Datenbank Paul Mockapetris programmiert den ersten DNS-Server RFC 920 Berkeley Internet Name Domain (BIND) DNS für Unix Einführung DNS Was ist das DNS? Weltweit verteilte, redundant ausgelegte Datenbank Ordnet Domainnamen wie IP-Adressen zu (und umgekehrt) Speichert Informationen zum -Routing stellt Informationen für weitere Internet-Dienste bereit X.500-Verzeichnis für Rechner

3 Einführung DNS Domainnamen und die DNS-Namensraum DNS-Namensraum Struktur der Datenbank in Form eines Baumes Die Wurzel dieses Baumes hat das Label NULL oder. Jeder nachfolgende Knoten wird mit einem weiteren Label versehen, das auf dieser Ebene eindeutig sein muss Labels für die Top-Level-Domain (erste Ebene unterhalb der Wurzel) sind vorgegeben und reglementiert Ein Domainname ist ein absoluter Pfad in diesem Baum Eine Domain ist ein Teilbaum des DNS-Baumes, unterhalb des Knotens mit dem entsprechenden Domainnamen Einführung DNS COM EDU... DE FR... TEST VERISIGN RUB NETZ1 WWW CRL www NDS h14 crl.verisign.com h14.netz1.test

4 Einführung DNS Domainnamen und die DNS-Namensraum Beispiele: Die Domain ruhr-uni-bochum.de enthält alle Rechner der RUB. Die Domain rub.de enthält (leider nur) eine Teilmenge dieser Rechner. Beide Domains gehören zu der Zone, die vom Rechenzentrum verwaltet wird. Das Rechenzentrum betreibt dazu die autoritativen Nameserver für diese Zone, einen Primary DNS und mindestens einen Secondary DNS als Backup. Die Domain nds.rub.de wird vom Lehrstuhl NDS verwaltet. Gliederung Einführung Domain Name System Domainnamen und die DNS-Hierarchie Delegation und Zonen Ressource Records (RR) DNS-Server und DNS-Resolver Auflösung von Domainnamen (und IP-Adressen) DNSSEC Neue RR-Datentypen Schlüssel und Signaturen Rückruf eines Schlüssels Probleme mit DNSSEC

5 Einführung DNS Delegation und Zonen. COM EDU... de VERISIGN rub bund WWW CRL www nds www bsi crl.verisign.com Einführung DNS Delegation und Zonen Das Domain Name System ist eine so riesige Datenbank, dass sie nicht zentral administriert werden kann. Die Verantwortung muss daher aufgeteilt oder delegiert werden. Dazu wird der DNS-Namensraum in Zonen aufgeteilt. Zonen können Domains (d.h. komplette Teilbäume) oder Teile von Domains sein. Beispiel: Die Zone de delegiert die Verantwortung für die Domain rub.de an das Rechenzentrum der RUB, und dieses delegiert nds.rub.de weiter an NDS.

6 Gliederung Einführung Domain Name System Domainnamen und die DNS-Hierarchie Delegation und Zonen Ressource Records (RR) DNS-Server und DNS-Resolver Auflösung von Domainnamen (und IP-Adressen) DNSSEC Neue RR-Datentypen Schlüssel und Signaturen Rückruf eines Schlüssels Probleme mit DNSSEC Einführung DNS Ressource Records (RR) Die Information über eine Zone wird in einem Zonefile gespeichert Das Zonefile besteht aus einzelnen Ressource Records (RR) Das Zonefile wird in einem Rechner in der Nähe des point of delegation gespeichert Beispiel: Das Zonefile für rub.de kann z.b. in nameserver1.rub.de gespeichert sein. RRs haben eine feste Struktur

7 Einführung DNS Beispiel $TTL example.com. IN SOA ns1.example.com. hostmaster.example.com. ( ; se = serial number ; ref = refresh = 2d 900 ; ret = update retry = 15m ; ex = expiry = 2w 3600 ; min = minimum = 1h ) IN NS ns1.example.com. IN NS ns2.example.com. ns2.example.com. IN A host2.example.com. IN A host2.example.com. IN A host4.example.com. IN A ns1.example.com. IN CNAME host2.example.com. Einführung DNS Ressource Records (RR) Start of Authority (SAO) Record mit Name der Zone, autoritativen Nameserver und -Adresse example.com. IN SOA ns1.example.com. hostmaster.example.com. ( ; se = serial number ; ref = refresh = 2d 900 ; ret = update = 15m ; ex = expiry = 2w 3600 ; min = minimum = 1h )

8 Einführung DNS Ressource Records (RR) Name Server (NS) Record example.com IN NS ns1.example.com. IN NS ns2.example.com. Einführung DNS Ressource Records (RR) Address (A) und CNAME Record ns2.example.com. IN A host2.example.com. IN A host2.example.com. IN A host4.example.com. IN A ns1.example.com. IN CNAME host2.example.com. Name Klasse Typ RData RRSet: Nur RData ist verschieden (Bspl. host2...)

9 Einführung DNS Ressource Records (RR) PTR Record in-addr.arpa. IN PTR alfred.example.ac.uk in-addr.arpa. IN PTR clara.example.ac.uk in-addr.arpa. IN PTR clara.example.ac.uk. Einführung DNS Ressource Records (RR) Aufbau: Domain_name: Name der Domain, für die dieses Record gilt. Dies ist der primäre Suchschlüssel für die Datenbank. Time_to_live: Angabe (in Sek.), wie stabil der Eintrag ist (TTL=86400: stabil, TTL=60: instabil, z.b. temporäre IP- Adressen) Class: fast immer IN für Internet, aber auch andere Werte sind möglich. Type: Typ des Records (siehe nächste Folie) Value: Der gesuchte Wert, oft die IP-Adresse.

10 Einführung DNS Typ des Records: SAO (Start of Authority): Parameter für diese Zone A (IP-Adresse): 32-Bit-Wert MX (Mail Exchange): Name des Hosts, der bereit ist. für diese Domain zu akzeptieren NS (Name Server): Nameserver für diese Domain CNAME (Canonical Name): Übersetzt einen Alias der Domain in den echten Namen PTR (Pointer): Alias für eine IP-Adresse HINFO (Host description): CPU und OS in ASCII TXT (Text): Uninterpretierter ASCII-Text Gliederung Einführung Domain Name System Domainnamen und die DNS-Hierarchie Delegation und Zonen Ressource Records (RR) DNS-Server und DNS-Resolver Auflösung von Domainnamen (und IP-Adressen) DNSSEC Neue RR-Datentypen Schlüssel und Signaturen Rückruf eines Schlüssels Probleme mit DNSSEC

11 7. DNS-Software Ein DNS-Client wird Resolver genannt. Systemaufruf an Resolver: getbyname(host) Unter Unix: /etc/resolv.conf enthält die lokale Domain und die DNS-Server für diese Domain. domain rpi.edu nslookup ist ein interaktiver Resolver zur direkten Kommunikation mit dem DNS-Server. Nachfolger von nslookup: dig. Meistverwendeter DNS-Server: BIND 7. DNS-Software nslookup ist auch unter Windows verfügbar

12 Gliederung Einführung Domain Name System Domainnamen und die DNS-Hierarchie Delegation und Zonen Ressource Records (RR) DNS-Server und DNS-Resolver Auflösung von Domainnamen (und IP-Adressen) DNSSEC Neue RR-Datentypen Schlüssel und Signaturen Rückruf eines Schlüssels Probleme mit DNSSEC Einführung DNS Auflösung von Domainnamen Rekursive Abfrage: Die Anfrage wird von Nameserver zu Nameserver weitergeleitet, bis der autoritive Server gefunde ist. Iterative Abfrage: Der Nameserver erhält auf seine Frage jeweils eine Liste mit Nameservern zurück, die er als nächste fragen soll. Client stellt rekursive Anfrage an Default-Nameserver, dieser kann sie rekursiv oder (besser) iterativ auflösen.

13 Rekursive Abfrage NS für.com Authoritative NS für example.com Zone File Cache Response Name Server Query Name Server Res pon se Que ry User Query Response Resolver Query Response Name Server Default-NS PC Cache Cache Einführung DNS Rekursive Abfrage: Beispiel 1. Host fragt beim Default-Nameserver (muss konfiguriert werden) nach. 2. Dieser leitet die Anfrage an den de-nameserver weiter 3. de-ns fragt bei rub.de-ns nach 4. rub.de-ns fragt bei nds.rub.de-ns nach 5. Antwort von NS für nds.rub.de läuft über alle Nameserver zurück.

14 Iterative Abfrage Authoritative NS für example.com Zone File Name Server NS für.com Cache Name Server Response Query Que ry Ref erra l User Query Response Resolver Query Response Name Server Default-NS PC Cache Cache Einführung DNS Iterative Abfrage: Beispiel 1. Host fragt beim Default-Nameserver (muss konfiguriert werden) nach. 2. Dieser leitet die Anfrage an den de-nameserver weiter 3. de-ns liefert Adresse des rub.de-ns zurück 4. Default-NS fragt bei rub.de-ns nach 5. rub.de-ns liefert Adresse des nds.rub.de-ns zurück 6. Default-NS fragt bei nds.rub.de-ns nach 7. Antwort von NS für nds.rub.de wird über den Default-NS an den Client weitergegeben

15 Iterative Abfrage (aus Hinshelwood) Auflösung von Domainnamen: iterativ, ohne Caching Iterative Abfrage (aus Hinshelwood) Auflösung von Domainnamen: iterativ, mit Caching

16 DNS Query Domain Name System (query) Transaction ID: 0x0002 Flags: 0x0100 (Standard query) = Response: Message is a query = Opcode: Standard query (0) = Truncated: Message is not truncated = Recursion desired: Do query recursively = Z: reserved (0) = Non-authenticated data OK: Nonauthenticated data is unacceptable Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 0 Queries type A, class inet Name: Type: Host address Class: inet DNS Response (1) Domain Name System (response) Transaction ID: 0x0002 Flags: 0x8580 (Standard query response, No error) = Response: Message is a response = Opcode: Standard query (0) = Authoritative: Server is an authority for domain = Truncated: Message is not truncated = Recursion desired: Do query recursively = Recursion available: Server can do recursive queries = Z: reserved (0) = Answer authenticated: Answer/authority portion was not authenticated by the server = Reply code: No error (0) Questions: 1 Answer RRs: 2 Authority RRs: 3 Additional RRs: 3 Queries type A, class inet Name: Type: Host address Class: inet

17 DNS Response (2) Answers type CNAME, class inet, cname www1.rz.ruhr-uni-bochum.de Name: Type: Canonical name for an alias Class: inet Time to live: 1 day Data length: 26 Primary name: www1.rz.ruhr-uni-bochum.de www1.rz.ruhr-uni-bochum.de: type A, class inet, addr Name: www1.rz.ruhr-uni-bochum.de Type: Host address Class: inet Time to live: 1 day Data length: 4 Addr: DNS Response (3) Authoritative nameservers rz.ruhr-uni-bochum.de: type NS, class inet, ns ns1.rz.ruhr-uni-bochum.de Name: rz.ruhr-uni-bochum.de Type: Authoritative name server Class: inet Time to live: 1 day Data length: 6 Name server: ns1.rz.ruhr-uni-bochum.de rz.ruhr-uni-bochum.de: type NS, class inet, ns ns1.ruhr-uni-bochum.de Name: rz.ruhr-uni-bochum.de Type: Authoritative name server Class: inet Time to live: 1 day Data length: 6 Name server: ns1.ruhr-uni-bochum.de rz.ruhr-uni-bochum.de: type NS, class inet, ns ns2.ruhr-uni-bochum.de Name: rz.ruhr-uni-bochum.de Type: Authoritative name server Class: inet Time to live: 1 day Data length: 6 Name server: ns2.ruhr-uni-bochum.de

18 DNS Response (4) Additional records ns1.rz.ruhr-uni-bochum.de: type A, class inet, addr Name: ns1.rz.ruhr-uni-bochum.de Type: Host address Class: inet Time to live: 1 day Data length: 4 Addr: ns1.ruhr-uni-bochum.de: type A, class inet, addr Name: ns1.ruhr-uni-bochum.de Type: Host address Class: inet Time to live: 1 day Data length: 4 Addr: ns2.ruhr-uni-bochum.de: type A, class inet, addr Name: ns2.ruhr-uni-bochum.de Type: Host address Class: inet Time to live: 1 day Data length: 4 Addr: Gliederung Einführung Domain Name System Domainnamen und die DNS-Hierarchie Delegation und Zonen Ressource Records (RR) DNS-Server und DNS-Resolver Auflösung von Domainnamen (und IP-Adressen) DNSSEC Neue RR-Datentypen Schlüssel und Signaturen Rückruf eines Schlüssels Probleme mit DNSSEC

19 DNNSEC: Beispiel Das Beispiel example.com. IN SOA ns1.example.com. hostmaster.example.com. ( ; se = serial number ; ref = refresh = 2d 900 ; ret = update retry = 15m ; ex = expiry = 2w 3600 ; min = minimum = 1h ) IN NS ns1.example.com. IN NS ns2.example.com. ns2.example.com. IN A host2.example.com. IN A host2.example.com. IN A host4.example.com. IN A ns1.example.com. IN CNAME host2.example.com. wird zu DNNSEC: Beispiel example.com IN SOA ns1.example.com. hostmaster.example.com. ( ; serial ; refresh (2 days) 900 ; retry (15 minutes) ; expire (2 weeks) 3600 ; minimum (1 hour) ) SOA SIG ( GiVY6piouHMs6GBeTKZXJCtH1zFmMn37gkSn hxdltmqnluh1bbxwugorm4nhsxkonlkejfpq vmn8japysksnwafr4ig5potucx3ut47ewkpe t/mybudolwkrxk38kclovnsteas/5pntbanu 1M5iFsVeqnCqZ5WGCA/hg3x+O/Q= ) ns1.example.com NS NS ns2.example.com SIG NS ( RdsrMFE3j2p1XMjLvotUxybVhGCNjrJ3eaR2 d+iccwsd2hfkchg6gdshm9/1pcpksyzqinf1 OMddD2RJycHxGQJosxHgK6vnzzetgPP05tAc hqdhpbfroinjdim3hy+m9d0qvrrxbuo+fuol FY+ppcTHnXbCBwguGD+MzSUbPls= ) ( KEY AQO+MbQ9Xt9neCUuOa9G6pfJWXe2Qq9HjkTl 57nl54ug2ZmKstUoW9nfytk7lbFuXlx7PyTq wkaqaylufh1arkyohvacpdxqr/p3dnmin29w TC+BV94cPGmmmyoJwYEcUuXlRy6ldJ9aedDW T4IcEvLmcBqiryt0aY/O2vyWOT+zXw== ) ; key id = host2.example.com. NS SOA SIG KEY NXT NXT SIG NXT ( defefl2lorju0ekwuybkenvit6trtk3i1tmw lfqcxcm13+6t17m8f6f/i+7wj1dewcfndsbe ZCeUwyUQs0KJduNqPlBzLS6nZO7ocCO6NAQV vcu14f18eoppgzriko8eetgx3fp33gcg6u6h brfnlg2rfkpooqyagcqf7bz2fm0= ) host2.example.com IN A IN A SIG A ( S3yTxBrgCOSjVeEAHeGSzPjyJALunjL51DkK z7wpkpswm1l+fl8+9zfmuubdfffj24zfuwbg NKQ6H0QLJA5u46MSdB0wgxpuAaTYZKzTJzpF uv1ehbx1recl1deonzwjygfoiizrtxuwbckm jekkeitcwlermvc7wqlllkemv+s= ) host4.example.com. A SIG NXT NXT SIG NXT ( A1sXJloJvtIJBVA+5mjMeJVaDXVep6ktiVs7 VEHmYKJYCAGENk3KOe2M5CGjxp6B2+JvRLIA L5jfu4hr9q4YHO8+7DO8NAwlUxCZNasfg5ma RG1q+j6URIWHUSw2bYvtqIAoQfJAQ9LP9Mkk Uo5zykb6/m/D0jjQXD/69IJIHHY= ) host4.example.com IN A SIG A ( HdxNpie2UuEWDE66080+lzYIJQ41zzapxnMc yavrt42sjwwp1yba8ua1wbpk4fx7wsw7tjwc Sg+yCM89WBhCIBc5zFQio5bXJ+Ua/+7uqa6l QDTE1LQkFp1nKB5KNmuQL8OvK5T03qeuJaOB QCHONDtw+nGkGi9G7cMCUb2g6QA= ) ns1.example.com. A SIG NXT NXT SIG NXT ( UH3qy4MlObeEIdzCt4Ekf2kBMAdq01RfRq66 2k5zrEoKl/s1VaX5UDXrmgG+Xtipqe9pXnQb z/0nvzqz8+l3nfgdqcxrfrp5wxaqvtvqg7pq VEKVlhPZ3DYBXEVs3Sur/dtfFbkCEWS6BAoB UByA1k+V11QqAMBU0Buc5UcPP70= ) CNAME host2.example.com. ns1.example.com IN SIG CNAME ( jf8ygmpvlfkq+hzhbdgnwd6ufzeql9xstjq8 yhslst2ygkkok3p8h9ra5umrvhtc6+hmp6mp 1M/dde7qOwSzurBcdHTRKz6JX5S+ODw5yWOi bqndg+cjif1rebrxui9domusaidgexv37zb/ K5ab5OvWzwezxMEI3xRTGzGhB8Y= ) ns2.example.com. CNAME SIG NXT NXT SIG NXT ( f8gjwfa5a1r3py7hfdjkdzu11rhdm+1tmp1x THTRuoXyasCEO0uRWMaR4Q/+ubU9EZtM/xrt /T77RjfNGb5rmM8OC/dzAMsp0cD/ZNnF0TOi Gl9Vep9am1vG4lXKkNDDsttY+rnTwFg6nPst y0dkfyy2hoas9ssr8+1jrlil+hs= ) ns2.example.com IN A SIG A ( C3e/g9FeemMJag1lIKIYSMXQjLFh/aVgms94 r4vam2k8t7cow/n/vxf6gztncna5ybvhj9go huqxezufs897djctfqdp61iwjlokguc28nea Aa7RcSpQw+1i3XWoP5petvMohfJYALfQ6NUY O5aGzqQTRpuAT4aqGy6OMRmaOr8= ) NXT example.com. A SIG NXT SIG NXT ( b4vob1/nptpp3xb6ngkhrpkyk53lkocou+ym FXt4ulVfFtt3i+TsSW8Iyl1zlouvQrWekKGm EZtlDfo0KlrzYleAKluBMCvizjeGzolgnUwT eqwqy7dxvig8ngo51bxh1lpha7shx9vmpiwx 4a8xzDPx0OPIbIEZkUopvHjMzDs= )

20 DNSSEC: Vorgehensweise mit BIND Der Befehl dnssec-keygen -a RSA -b n ZONE -r /dev/urandom example.com liefert Kexample.com key (öffentlicher Schlüssel als KEY-RR) und Kexample.com private (privater Schlüssel) Einbinden des öffentlichen Schlüssels mit $include Kexample.com key Signieren des Zonefiles mit dnssec-signzone -r /dev/urandom -t example.com Kexample.com DNNSEC: Beispiel example.com IN SOA ns1.example.com. hostmaster.example.com. ( ; serial ; refresh (2 days) 900 ; retry (15 minutes) ; expire (2 weeks) 3600 ; minimum (1 hour) ) SIG SOA ( GiVY6piouHMs6GBeTKZXJCtH1zFmMn37gkSn hxdltmqnluh1bbxwugorm4nhsxkonlkejfpq vmn8japysksnwafr4ig5potucx3ut47ewkpe t/mybudolwkrxk38kclovnsteas/5pntbanu 1M5iFsVeqnCqZ5WGCA/hg3x+O/Q= ) NS ns1.example.com NS ns2.example.com SIG NS ( RdsrMFE3j2p1XMjLvotUxybVhGCNjrJ3eaR2 d+iccwsd2hfkchg6gdshm9/1pcpksyzqinf1 OMddD2RJycHxGQJosxHgK6vnzzetgPP05tAc hqdhpbfroinjdim3hy+m9d0qvrrxbuo+fuol FY+ppcTHnXbCBwguGD+MzSUbPls= ) KEY ( AQO+MbQ9Xt9neCUuOa9G6pfJWXe2Qq9HjkTl 57nl54ug2ZmKstUoW9nfytk7lbFuXlx7PyTq wkaqaylufh1arkyohvacpdxqr/p3dnmin29w TC+BV94cPGmmmyoJwYEcUuXlRy6ldJ9aedDW T4IcEvLmcBqiryt0aY/O2vyWOT+zXw== ) ; key id = NXT host2.example.com. NS SOA SIG KEY NXT SIG NXT ( defefl2lorju0ekwuybkenvit6trtk3i1tmw lfqcxcm13+6t17m8f6f/i+7wj1dewcfndsbe ZCeUwyUQs0KJduNqPlBzLS6nZO7ocCO6NAQV vcu14f18eoppgzriko8eetgx3fp33gcg6u6h brfnlg2rfkpooqyagcqf7bz2fm0= )

21 DNNSEC: Beispiel host2.example.com IN A IN A SIG A ( S3yTxBrgCOSjVeEAHeGSzPjyJALunjL51DkK z7wpkpswm1l+fl8+9zfmuubdfffj24zfuwbg NKQ6H0QLJA5u46MSdB0wgxpuAaTYZKzTJzpF uv1ehbx1recl1deonzwjygfoiizrtxuwbckm jekkeitcwlermvc7wqlllkemv+s= ) NXT host4.example.com. A SIG NXT SIG NXT ( A1sXJloJvtIJBVA+5mjMeJVaDXVep6ktiVs7 VEHmYKJYCAGENk3KOe2M5CGjxp6B2+JvRLIA L5jfu4hr9q4YHO8+7DO8NAwlUxCZNasfg5ma RG1q+j6URIWHUSw2bYvtqIAoQfJAQ9LP9Mkk Uo5zykb6/m/D0jjQXD/69IJIHHY= ) DNNSEC: Beispiel host4.example.com IN A SIG A ( HdxNpie2UuEWDE66080+lzYIJQ41zzapxnMc yavrt42sjwwp1yba8ua1wbpk4fx7wsw7tjwc Sg+yCM89WBhCIBc5zFQio5bXJ+Ua/+7uqa6l QDTE1LQkFp1nKB5KNmuQL8OvK5T03qeuJaOB QCHONDtw+nGkGi9G7cMCUb2g6QA= ) NXT ns1.example.com. A SIG NXT SIG NXT ( UH3qy4MlObeEIdzCt4Ekf2kBMAdq01RfRq66 2k5zrEoKl/s1VaX5UDXrmgG+Xtipqe9pXnQb z/0nvzqz8+l3nfgdqcxrfrp5wxaqvtvqg7pq VEKVlhPZ3DYBXEVs3Sur/dtfFbkCEWS6BAoB UByA1k+V11QqAMBU0Buc5UcPP70= )

22 DNNSEC: Beispiel ns1.example.com IN CNAME host2.example.com SIG CNAME ( jf8ygmpvlfkq+hzhbdgnwd6ufzeql9xstjq8 yhslst2ygkkok3p8h9ra5umrvhtc6+hmp6mp 1M/dde7qOwSzurBcdHTRKz6JX5S+ODw5yWOi bqndg+cjif1rebrxui9domusaidgexv37zb/ K5ab5OvWzwezxMEI3xRTGzGhB8Y= ) NXT ns2.example.com. CNAME SIG NXT SIG NXT ( f8gjwfa5a1r3py7hfdjkdzu11rhdm+1tmp1x THTRuoXyasCEO0uRWMaR4Q/+ubU9EZtM/xrt /T77RjfNGb5rmM8OC/dzAMsp0cD/ZNnF0TOi Gl9Vep9am1vG4lXKkNDDsttY+rnTwFg6nPst y0dkfyy2hoas9ssr8+1jrlil+hs= ) DNNSEC: Beispiel ns2.example.com IN A SIG A ( C3e/g9FeemMJag1lIKIYSMXQjLFh/aVgms94 r4vam2k8t7cow/n/vxf6gztncna5ybvhj9go huqxezufs897djctfqdp61iwjlokguc28nea Aa7RcSpQw+1i3XWoP5petvMohfJYALfQ6NUY O5aGzqQTRpuAT4aqGy6OMRmaOr8= ) NXT example.com. A SIG NXT SIG NXT ( b4vob1/nptpp3xb6ngkhrpkyk53lkocou+ym FXt4ulVfFtt3i+TsSW8Iyl1zlouvQrWekKGm EZtlDfo0KlrzYleAKluBMCvizjeGzolgnUwT eqwqy7dxvig8ngo51bxh1lpha7shx9vmpiwx 4a8xzDPx0OPIbIEZkUopvHjMzDs= )

23 DNNSEC: SIG-RR type covered algorithm labels original TTL signature expiration signature inception key tag signer's name + / / / / / signature / / / DNNSEC: SIG-RR host4.example.com IN A SIG A ( HdxNpie2UuEWDE66080+lzYIJQ41zzapxnMc yavrt42sjwwp1yba8ua1wbpk4fx7wsw7tjwc Sg+yCM89WBhCIBc5zFQio5bXJ+Ua/+7uqa6l QDTE1LQkFp1nKB5KNmuQL8OvK5T03qeuJaOB QCHONDtw+nGkGi9G7cMCUb2g6QA= ) Dieser Teil ist auf der vorhergehenden Folie beschrieben.

24 DNNSEC: SIG-RR Was wird signiert? type covered ist der Typ des Ressource Records (bzw. RRSets), der durch diese Signatur authentifiziert wird (in unserem Beispiel A ). Mit welchen Algorithmen wurde signiert? Für das Feld algorithm sind in RFC 2535 vier verschiedene Werte definiert (in unserem Beispiel 1 für MD5/RSA). Auf welcher Ebene des DNS-Baumes wurde signiert? Die ganze Zahl in label gibt an, aus wie vielen durch Punkt getrennten Teilen der Name des signierten Eintrags im Zonefile besteht. (Für die Signatur des Adresseintrags von host4.example.com muss hier somit die Zahl 3 stehen). DNNSEC: SIG-RR Wie lange darf die Signatur maximal gecached werden? Der eigentliche TTL-Wert einer Signatur (Zahl vor dem SIG in unserem Beispiel in Bild 8.10), der mit dem TTL-Wert des geschützten RRSet identisch sein muss, ist nicht gegen Manipulationen geschützt. Beim Caching wird dieser Wert ständig erniedrigt. Die original TTL wird daher im SIG RR aufgenommen und mit signiert. Wie lange ist die Signatur gültig? Hier wird im Wire format Beginn und Ende der Gültigkeitsdauer der Signatur in Anzahl der Sekunden seit dem angegeben, in der ASCII-Darstellung des Zonenfiles wird dagegen das besser lesbare Format JJJJMMTThhmmss verwendet.

25 DNNSEC: SIG-RR Welcher öffentliche Schlüssel zur Verifikation herangezogen werden muss, ist aus dem key tag-wert ersichtlich. (Der key tag unseres Beispielschlüssels ist die Zahl 16307, die auch in den Dateinamen der Public Key- Datei vorkommt.) Wer hat signiert? Hier wird natürlich der Domainname des Eigentümers des öffentlichen Schlüssels angegeben. (Im Beispiel example.com.) Natürlich muss auch die eigentliche Signatur angegeben werden, deren genaue Struktur von dem gewählten Algorithmus abhängt. (Base64-codiert Hdx... 6QA=.) DNNSEC: KEY-RR flags protocol algorithm / / public key / / / KEY ( AQO+MbQ9Xt9neCUuOa9G6pfJWXe2Qq9HjkTl 57nl54ug2ZmKstUoW9nfytk7lbFuXlx7PyTq wkaqaylufh1arkyohvacpdxqr/p3dnmin29w TC+BV94cPGmmmyoJwYEcUuXlRy6ldJ9aedDW T4IcEvLmcBqiryt0aY/O2vyWOT+zXw== ) ; key id = 16307

26 DNNSEC: KEY-RR Anwendungsgebiet ist im protocol-feld angegeben: DNSSEC (3), TLS (1), (2), und IPSEC (4). algorithm-eintrag definiert Typ des public key: 1 für RSA/MD5 [RFC 2537], 2 für Diffie-Hellman [RFC 2539], 3 für DSA [RFC 2536], und 4 für einen Algorithmus auf Basis elliptischer Kurven. flags-feldes: Besonderheiten des Domain Name Systems spielen eine Rolle. Bspl: SOA RR aus unserer Beispieldatei enthält hostmaster.example.com. Das flags-feld definiert diesen Eintrag eindeutig als -Adresse. DNNSEC: NXT-RR next domain name / type bit map / NXT ns.example.net. NS SOA MX SIG KEY NXT

27 DNNSEC: NXT-RR Problem: Alle Antworten müssen in DNSSEC digital signiert sein. Für existierende RRs kann diese Signatur vorberechnet werden Bei nicht existierenden Servernamen müsste sie on the fly berechnet werden. Dies ist zu rechenaufwändig. Lösung: Das NXT-RR spezifiziert den lexikographisch nächsten RR, zu dem dann eine vorberechnete Signatur vorliegt Zonefile wird nach Namen geordnet: Labels des Namens von rechts nach links, auf jeder Ebene lexikographisch. Ordnung ist zyklisch: Der letzte NXT-RR verweist wieder auf SOA-RR DNNSEC: DS-RR Key Tag Algorithm Digest Type / / / Digest / / /

28 DNNSEC: DS-RR Problem: Wo soll der Public Key einer Zone gespeichert sein? In der Zone selbst? So nicht vertrauenswürdig. In der übergeordneten Zone? Wie kommt er da hin? Lösung: Das Delegation Signer-RR (DS) Tag und Hashwert des Public Key werden in der übergeordneten Zone gespeichert. DNNSEC: DS-RR -Zonefile DS für.com Vergleich.com -Zonefile KEY für.com DS für example.com Vergleich example.com-zonef. KEY für example.com A für

29 DNNSEC: Verifikation eines Eintrags 1. Er fragt den Rootserver nach 2. Der Rootserver kennt diesen Namen nicht, er weiß aber, welche Nameserver für die Domäne.com zuständig sind. Wir erhalten in einer Referral genannten Nachricht die Namen der Nameserver (unsigniert, da Änderungen dieser Namen von der.com-domäne verwaltet werden) die IP-Adressen der Nameserver (unsigniert, s.o.) und den DS-RR für.com, einschließlich des SIG -RR dazu. 3. Der Resolver verifiziert das SIG-RR zum DS-RR mit Hilfe des vorkonfigurierten Schlüssels für die Root-Zone, und macht nur weiter, falls diese Verifikation positiv ist. DNNSEC: Verifikation eines Eintrags 4. Der Resolver fragt bei einem der.com-nameserver nach 5. Der.com-Nameserver kennt diesen Namen nicht, er weiß aber, welche Nameserver für die Domäne example.com zuständig sind. Wir erhalten in der Referral-Nachricht die Namen der Nameserver (unsigniert), die IP-Adressen der Nameserver (unsigniert), den KEY -RR für die Zone.com, einschließlich des zugehörigen SIG-RR und den DS-RR für example.com, einschließlich des SIG-RR dazu.

30 DNNSEC: Verifikation eines Eintrags 6. Der Resolver verifiziert diese Antwort, indem er den Hashwert des KEY-RR für die.com-zone mit dem in Schritt 2 erhaltenen DS-RR vergleicht, und den SIG-RR zum DS-RR mit dem öffentlichen Schlüssel der.com-zone verifiziert. 7. Der Resolver fragt bei einem der example.com- Nameserver nach 8. Der example.com-nameserver kennt diesen Namen und sendet die IP-Adresse von (A-RR), zusammen mit dem SIG-RR dafür, und den KEY-RR für die Zone.com, einschließlich des zugehörigen SIG-RR. DNNSEC: Verifikation eines Eintrags 9. Der Resolver verifiziert diese Antwort, indem er den Hashwert des KEY-RR für die example.com-zone mit dem in Schritt 5 erhaltenen DS-RR vergleicht, und den SIG-RR zum A-RR mit dem öffentlichen Schlüssel der example.com-zone verifiziert.

31 Implementierungen sponsored by The Foundation for Internet Infrastructure in Sweden. - operated by CAIRN (Collaborative Advanced Interagency Research Network), a DARPAsponsored network for collaborative research. - sponsored by NLnet Labs. Quellen DNSSEC: The Protocol, Deployment, and a Bit of Development by Miek Gieben, NLnet Labs. Internet Protocol Journal v7 no2, June David Hinshelwood: DNS, DNSSEC and the Future. SANS Reading Room Jürgen Pfleger: DNSSEC Resolver Algorithm. Diplomarbeit / Master Thesis FH Wiener Neustadt, 4/2003.