Systemsicherheit 15: DNSSEC

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

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 E-Mail an alle Computer Netzwerklast: Proportional zu (Anzahl der Computer) 2 1984: 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 www.nds.rub.de IP-Adressen zu (und umgekehrt) Speichert Informationen zum E-Mail-Routing stellt Informationen für weitere Internet-Dienste bereit X.500-Verzeichnis für Rechner

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 www.verisign.com crl.verisign.com www.rub.de h14.netz1.test

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

Einführung DNS Delegation und Zonen. COM EDU... de VERISIGN rub bund WWW CRL www nds www bsi www.verisign.com crl.verisign.com www.rub.de 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.

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

Einführung DNS Beispiel $TTL 172800 example.com. IN SOA ns1.example.com. hostmaster.example.com. ( 2003080800 ; se = serial number 172800 ; ref = refresh = 2d 900 ; ret = update retry = 15m 1209600 ; ex = expiry = 2w 3600 ; min = minimum = 1h ) IN NS ns1.example.com. IN NS ns2.example.com. ns2.example.com. IN A 192.0.1.1 host2.example.com. IN A 192.0.0.2 host2.example.com. IN A 192.0.0.3 host4.example.com. IN A 192.0.0.4 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 E-Mail-Adresse example.com. IN SOA ns1.example.com. hostmaster.example.com. ( 2003080800 ; se = serial number 172800 ; ref = refresh = 2d 900 ; ret = update = 15m 1209600 ; ex = expiry = 2w 3600 ; min = minimum = 1h )

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 192.0.1.1 host2.example.com. IN A 192.0.0.2 host2.example.com. IN A 192.0.0.3 host4.example.com. IN A 192.0.0.4 ns1.example.com. IN CNAME host2.example.com. Name Klasse Typ RData RRSet: Nur RData ist verschieden (Bspl. host2...)

Einführung DNS Ressource Records (RR) PTR Record 2.0.0.192.in-addr.arpa. IN PTR alfred.example.ac.uk. 4.0.0.192.in-addr.arpa. IN PTR clara.example.ac.uk. 5.0.0.192.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.

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. E-Mail 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

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 128.113.1.5 128.113.1.3 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

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.

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 www.nds.rub.de 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.

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 www.nds.rub.de 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

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

DNS Query Domain Name System (query) Transaction ID: 0x0002 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 OK: Nonauthenticated data is unacceptable Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 0 Queries www.rub.de: type A, class inet Name: www.rub.de Type: Host address Class: inet DNS Response (1) Domain Name System (response) Transaction ID: 0x0002 Flags: 0x8580 (Standard query response, No error) 1............ = Response: Message is a response.000 0......... = Opcode: Standard query (0)....1........ = Authoritative: Server is 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......... 0000 = Reply code: No error (0) Questions: 1 Answer RRs: 2 Authority RRs: 3 Additional RRs: 3 Queries www.rub.de: type A, class inet Name: www.rub.de Type: Host address Class: inet

DNS Response (2) Answers www.rub.de: type CNAME, class inet, cname www1.rz.ruhr-uni-bochum.de Name: www.rub.de 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 134.147.64.11 Name: www1.rz.ruhr-uni-bochum.de Type: Host address Class: inet Time to live: 1 day Data length: 4 Addr: 134.147.64.11 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

DNS Response (4) Additional records ns1.rz.ruhr-uni-bochum.de: type A, class inet, addr 134.147.128.3 Name: ns1.rz.ruhr-uni-bochum.de Type: Host address Class: inet Time to live: 1 day Data length: 4 Addr: 134.147.128.3 ns1.ruhr-uni-bochum.de: type A, class inet, addr 134.147.32.40 Name: ns1.ruhr-uni-bochum.de Type: Host address Class: inet Time to live: 1 day Data length: 4 Addr: 134.147.32.40 ns2.ruhr-uni-bochum.de: type A, class inet, addr 134.147.222.4 Name: ns2.ruhr-uni-bochum.de Type: Host address Class: inet Time to live: 1 day Data length: 4 Addr: 134.147.222.4 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

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

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

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

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

DNNSEC: SIG-RR 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ type covered algorithm labels +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ original TTL +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signature expiration +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signature inception +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ key tag +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name + / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ / / / signature / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DNNSEC: SIG-RR host4.example.com. 172800 IN A 192.0.0.4 172800 SIG A 1 3 172800 20050617121623 ( HdxNpie2UuEWDE66080+lzYIJQ41zzapxnMc yavrt42sjwwp1yba8ua1wbpk4fx7wsw7tjwc Sg+yCM89WBhCIBc5zFQio5bXJ+Ua/+7uqa6l QDTE1LQkFp1nKB5KNmuQL8OvK5T03qeuJaOB QCHONDtw+nGkGi9G7cMCUb2g6QA= ) Dieser Teil ist auf der vorhergehenden Folie beschrieben.

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 172800 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 1.1.1970 angegeben, in der ASCII-Darstellung des Zonenfiles wird dagegen das besser lesbare Format JJJJMMTThhmmss verwendet.

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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ flags protocol algorithm +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / public key / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 172800 KEY 256 3 1 ( AQO+MbQ9Xt9neCUuOa9G6pfJWXe2Qq9HjkTl 57nl54ug2ZmKstUoW9nfytk7lbFuXlx7PyTq wkaqaylufh1arkyohvacpdxqr/p3dnmin29w TC+BV94cPGmmmyoJwYEcUuXlRy6ldJ9aedDW T4IcEvLmcBqiryt0aY/O2vyWOT+zXw== ) ; key id = 16307

DNNSEC: KEY-RR Anwendungsgebiet ist im protocol-feld angegeben: DNSSEC (3), TLS (1), E-Mail (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 E-Mail-Adresse. DNNSEC: NXT-RR 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ next domain name / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ type bit map / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259200 NXT ns.example.net. NS SOA MX SIG KEY NXT

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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Key Tag Algorithm Digest Type +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Digest / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 www.example.com

DNNSEC: Verifikation eines Eintrags 1. Er fragt den Rootserver nach www.example.com. 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 www.example.com. 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.

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 www.example.com. 8. Der example.com-nameserver kennt diesen Namen und sendet die IP-Adresse von www.example.com (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.

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