Das Prinzip von DNSSEC hört sich einfach an, ist aber durchaus mit Problemen verbunden. Für Endanwender geht es damit los, dass gängige NAT-Router, etwa eine Fritzbox, in bestimmten Situationen nicht mehr richtig arbeiten – und zwar unabhängig davon, ob man DNSSEC nutzen möchte oder nicht.
<Update 30.09.2010 11:20:>
AVM hat im September 2010 für die Fritzbox-Modelle 7390, 7320, 7270 und 7240 ein Update herausgebracht, das DNSSEC unterstützt. Die Implementierung unterstützt DNS über TCP und „lange“ UDP-Pakete mit mehr als 512 Bytes. Sie wurde vom BSI als DNSSEC-kompatibel bestätigt. Für die Modelle 3270, 7170 und 7112 sind Aktualisierungen in Vorbereitung.</Update>
Damit DNSSEC funktioniert, muss ein Server zu jeder DNS-Antwort eine gültige Signatur liefern können. Das geschieht in Form eines RRSIG-Records. Diese RRSIG-Records haben eine gewisse Länge, meist 128 Byte, und etwas Protokoll-Overhead. Das Problem dabei ist, dass die meisten Consumer-Router nicht in der Lage sind, DNS über TCP abzuwickeln, was immer dann notwendig ist, wenn die Antwort 512 Byte überschreitet.
Normalerweise werden DNS-Antworten in einem UDP-Paket abgewickelt. Da die Queries und Antworten in der Regel recht kurz sind, wäre es ein großer Aufwand, dafür eine TCP-Verbindung auf- und wieder abzubauen. Der notwendige Datenverkehr für den Auf- und Abbau einer TCP-Verbindung würde die DNS-Nutzdaten meist überschreiten.
Grundsätzlich können IP-Pakete so lang sein, dass sie in ein Paket des darunterliegenden Transportprotokolls passen. Bei Ethernet sind das 1500 Byte. Diesen Wert bezeichnet man als Maximum Transmission Unit (MTU). Die MTU sinkt, wenn weitere Protokollebenen verwendet werden. Die deutschen DSL-Anbieter verwenden zur Authentifizierung PPPoE. Das bedeutet einen Protokolloverhead von 8 Byte. Die MTU sinkt somit auf 1492 Byte.
Jede Tunnelung, beispielsweise VPN-Verbindungen oder IPsec, sorgen für eine weitere Reduktion der MTU. Da verschiedene Tunnelmechanismen miteinander kombiniert werden können, kann die MTU weit unter 1500 Byte sinken. Um auf „Nummer sicher“ zu gehen, versenden DNS-Server maximal 512 Byte in einem UDP-Paket. So ist sichergestellt, dass das UDP-Paket auf jeden Fall durchkommt. Ab 513 Byte muss TCP verwendet werden.
Neueste Kommentare
2 Kommentare zu Denic führt DNSSEC ein: neue Technik mit kleinen Tücken
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.
Denic und DNSSEC
Vielen Dank für Ihren lesenwerten und gut recherchierten Artikel!
Was Denic in dieser Sache jedoch veranstaltet, ist unterirdisch! So wird auf http://www.denic.de/denic-im-dialog/pressemitteilungen/pressemitteilungen/2464.html im dritten Absatz vom „DNSSEC-Testbed für Deutschland“ gesprochen, und Denic als die deutsche Registry sollte für alle Deutschen und Computer zuständig sein, aber in der Resolver-Konfigurationsseite http://www.denic.de/domains/dnssec/status/resolver-konfiguration.html wird Windows – und damit ca. 90 % der Computerbenutzer – ausgeschlossen!
Einem kompetenten Umternehmen in Frankfurt’s Kaiserstraße sollte bekannt sein, dass Windows seit Vista und Server 2008 natürlich auch DNSEC unterstützen.
DNSSEC & LANCON
„Für DNSSEC ist DNS über TCP nicht zwingend erforderlich, solange alle Beteiligten
mit UDP-Paketen umgehen können, die größer als 512 Bytes sind… Dafür gibt es
EDNS (RFC 2671) über das dem Empfänger mitgeteilt wird, wie groß Die DNS-
Anfrage wirklich ist und wie viel Puffer er zur Verfügung stellen muß.
DNSSEC-fähige Server und Resolver *müssen* EDNS unterstützen – siehe auch
http://en.wikipedia.org/wiki/DNSSEC .
Daher ist es nicht nötig eine Auflösung über TCP zu unterstützen – und schon gar
nicht als Forwarder, der einfach nur Anfragen an den DNS-Server des Providers
weiterleitet… Nun gibt es da das Problem, daß viele Forwarder in Routern nicht
mit Anfragen umgehen können, die länger als 512 Bytes sind. Ich kann dazu nur
sagen, daß das LANCOM davon nicht betroffen ist – es forwarded Anfragen bis
zur Maximalgöße von 64K.“