Hauptnavigation:

Sie sind hier: Home > FAQs > Alle FAQs

Im Folgenden sind alle häufig gestellten Fragen (FAQs) aufgeführt, die derzeit vorhanden sind. Um die gewünschte Information zu finden, können Sie die Volltextsuche nutzen.

Volltextsuche
Um die Volltextsuche für alle vorhandenen FAQs zu nutzen, geben Sie in die unten stehende Box einen Suchbegriff ein. Wenn Sie mehrere Begriffe eingeben, wird jede Fundstelle angezeigt, die eines der Suchwörter enthält. Zur Verfeinerung der Suche können Sie die Suchbegriffe auch mit den logischen Verknüpfungen AND sowie NOT eingeben. Statt der Wörter AND bzw. NOT können Sie auch gezielt + und - voranstellen.

Volltextsuche: Es werden nur Wörter mit zwei oder mehr Zeichen akzeptiert. Maximal sind 200 Zeichen möglich. Leerzeichen werden zur Trennung von Worten verwendet, "" kann für die Suche nach ganzen Zeichenfolgen benutzt werden (keine Indexsuche). UND, ODER und NICHT sind Suchoperatoren, die den standardmäßigen Operator überschreiben.+/|/- entspricht UND, ODER und NICHT. Alle Suchwörter werden zu Kleinschreibung konvertiert.

Die Top Level Domains (TLDs) sind die höchste Hierarchiestufe im internationalen Domain Name System. Sie stehen bei einer Domain ganz rechts. Man unterscheidet zwischen allgemeinen oder generischen TLDs (gTLDs) wie beispielsweise .com, .net und .org und länderbezogenen TLDs (den ccTLDs für country code) wie .de (für Deutschland) oder .ch (für die Schweiz).

Einige der derzeit 15 gTLDs sind allgemein registrierbar; andere, wie z. B. .gov, .int, .aero oder .museum sind jedoch für bestimmte Benutzergruppen reserviert, in diesem Fall für die amerikanische Regierung , Internationale Organisationen, Unternehmen und Institutionen aus dem Bereich der Luftfahrt bzw. Museen. Die Koordination der gTLDs obliegt der internationalen Organisation ICANN.

Die einzelnen ccTLDs werden von so genannten Network Information Centers (NICs) verwaltet. Für Deutschland ist dies die DENIC eG. Eine Liste mit allen existierenden Endungen und den jeweiligen Registrierungsstellen findet man auf der Webseite der IANA.

Für User, die kein Javascript aktiviert haben, stellen wir die Domainabfrage auch als "Plain-HTML" zur Verfügung:

Zur Domainabfrage

Überschreitet die Anzahl der erlaubten Abfragen innerhalb des Zeitintervalls Z den zulässigen Maximalwert, so wird der Abfrager für das Zeitintervall Z und Z + 1 gesperrt. Statt der regulären Antwort bekommt er die entsprechende Fehlermeldung. Sendet der Abfrager im Zeitintervall Z + 1 erneut einen Auftrag, wird er automatisch auch für das Zeitintervall Z + 2 gesperrt. Dieser Mechanismus setzt sich solange fort, bis der Abfrager in einem gesperrten Zeitintervall keine Abfragen mehr sendet. Im eigenen Interesse sollten daher, nach Erhalt der Fehlermeldung, weitere Abfragen erst nach einer angemessenen Wartezeit erfolgen. Durch wiederholte Verletzung des Limits verlängert sich die Sperrung.

DENIC behält sich das Recht vor, die Anzahl der Zugriffe und das Zeitintervall lastabhängig zu variieren. Bei Überschreitung des Limits wird die Meldung „Connection refused; access control limit exceeded“ ausgegeben.

 

Erstes Beispiel - ACL liegt bei 2 Anfragen pro Minute

 

Zweites Beispiel  - mehrere Abfragen in der ersten Minute

 


Drittes Beispiel - eine weitere Abfrage in der Folgeminute

Domain Name Security Extensions (DNSSEC) sind eine Erweiterung des DNS (Domain Name System), die darauf abzielt, Sicherheitslücken im Internet - wie Cache-Poisoning, DNS-Umleitungen und DNS-Spoofing - zu schließen.

Im herkömmlichen DNS geht eine Anwendung davon aus, dass die Antwort auf eine DNS-Anfrage unversehrt ist und von der richtigen Quelle stammt. Dieses Vertrauen ist nicht immer berechtigt, denn in der Vergangenheit hat es vereinzelt Fälle gegeben, bei denen gezielt Fehlinformationen in DNS-Caches eingebracht wurde (sog. Cache-Poisoning). Dieser Angriff ist als potentielles Risiko bereits in den neunzigen Jahren erkannt und später in RFC 3833 dokumentiert worden. Die Internet Engineering Task Force (IETF) hat auf diese – zunächst theoretische – Bedrohung reagiert und schließlich im März 2005 die drei RFCs RFC4033RFC4034 und RFC4035 veröffentlicht. Diese Trilogie ist auch unter dem Namen "DNSSECbis" bekannt. Eine wichtige spätere Ergänzung ist das sog. NSEC3 (RFC 5155), mit dem die unerwünschte Aufzählung des Zoneninhaltes (etwa alle registrierten DE-Domains) verhindert werden kann.

Mittels Domain Name Security Extensions (DNSSEC) werden Daten anhand von kryptografisch gesicherten Signaturen geprüft, die über die zu schützenden Daten errechnet werden und zusammen mit den Daten an den Client übertragen werden. Die Prüfung der Daten erfolgt im Client oder in dem davor liegenden Resolver gegenüber den zur jeweiligen Zone passenden öffentlichen Schlüsseln. Diese Schlüssel können ebenfalls am einfachsten wiederum im Domain Name System (DNS) hinterlegt und abgerufen werden. Dabei ist kein Bruch des Sicherheitsmechanismus möglich, da auch der Transfer der Schlüssel mit Hilfe von DNSSEC abgesichert erfolgt und lediglich der für den Beginn der Kette notwendige Schlüssel (der Key der Root-Zone) im Client fest hinterlegt oder per Konfiguration eingepflegt wird.

Für Internetnutzer ist es wichtig, darauf vertrauen zu können, dass die angezeigten Informationen einer Webseite auch tatsächlich den Daten der Webseite entsprechen, die man eingegeben hat. Dazu ist es notwendig, den Pfad von der abgeschickten Anfrage einer Webseite bis zur erhaltenen Antwort abzusichern. Einen Beitrag dazu leisten die Domain Name Security Extensions (DNSSEC), die Quellenauthentisierung für das Domain Name System (DNS) bieten, das heißt, den Pfad zwischen DNS-Servern und validierenden DNS-Klienten sichern. Anhand der verwendeten Signatur lässt sich die Echtheit prüfen, d.h. ob die Daten aus der autoritativen Zone stammen. Gleichzeitig bietet die Integritätssicherung Schutz davor, dass die DNS-Daten auf dem Transportweg verfälscht werden.

Ob die ursprünglich eingepflegten Daten einer Website inhaltlich korrekt oder harmlos sind oder ob die aufgerufene Website eine Fälschung ist, die z.B. über einen in einer E-Mail enthaltenen Link erreicht wird (so genanntes Phishing), kann mit DNSSEC nicht erkannt werden. Auch Domain-Hijacking oder Eingriffe in Registrierungsprozesse lassen sich damit nicht feststellen.

Um von DNSSEC zu profitieren, benötigt man einen validierenden Resolver, der die durch DNSSEC gelieferte Zusatzinformation auswerten kann.

Sofern Sie selbst keinen validierenden Resolver betreiben, profitieren Sie daher nur, wenn Ihr Internet Service Provider dies für Sie tut. Beim Aufruf von z.B. Webseiten leitet das auf dem Rechner installierte Betriebssystem automatisch die DNS-Anfragen an die vom jeweiligen Internet Service Provider festgelegten DNS-Server. Damit findet die Überprüfung der signierten DNS-Daten auf dessen Server statt.

Wenn zu einem späteren Zeitpunkt DNSSEC weiter verbreitet ist, können Manipulationen erkannt und die gefälschten Daten unterdrückt werden.

Jeder Domaininhaber hat die Möglichkeit, seine Domain durch eine DNSSEC-Signierung zu schützen. Durch die Signierung ist für den Nutzer der Webseite erkennbar, ob die übertragenen Daten tatsächlich den ursprünglich eingepflegten Daten entsprechen.

Die Signierung einer Domain kann über den Internet Service Provider erfolgen oder durch den Domaininhaber selbst. Im Falle der Signierung durch den Provider – Voraussetzung ist, er unterstützt DNSSEC – ist dieser für die Schlüsselerzeugung, Signierung der Zonendaten, Neusignierung vor Ablauf der Signaturgültigkeit sowie den gelegentlich notwendigen Schlüsselwechsel zuständig.

Erfolgt die Signierung durch den Domaininhaber, weil er gleichzeitig die dafür notwendigen Nameserver betreibt, erhält der Provider den öffentlichen Schlüssel des Inhabers, um ihn an die passende Registrierungsstelle (hier: DENIC) weiterzugeben. Bei dieser Variante kennt nur der Domaininhaber den privaten Schlüssel.

Neben dem 2048bit "Key Signing Key" kommt ein 1024bit "Zone Signing Key" zum Einsatz, der nach jeweils fünf Wochen mit dem sog. Pre-Publish-Verfahren gewechselt wird. Beide Schlüssel erzeugen Signaturen nach dem standardisierten RSA/SHA256-Verfahren, in Übereinstimmung mit RFC5702. Die KSK-Signaturen haben eine 3-wöchige Gültigkeit, die ZSK-Signaturen wiederum nur eine 1-wöchige. Die Signierung der .de-Zone erfolgt mit Opt-Out unter Verwendung von NSEC3-Records nach RFC5155.

"nsentry"-Domains werden, da die entsprechenden Records direkt in der .de-Zone vorliegen und dort autoritativ sind, automatisch von DNSSEC erfasst und mit entsprechenden, von der DENIC erzeugten Signaturen versehen.

Setzen Sie sich bitte direkt mit Ihrem Domain-Provider in Verbindung um herauszufinden, ob er DNSSEC unterstützt.

Wenn Sie selbst einen validierenden Resolver betreiben, sind Sie selbst grundsätzlich in der Lage, Signaturen für DNSSEC-Domains zu validieren. Die Details dazu sind Resolver-spezifisch.

Alternativ setzt Ihr Internet Service Provider einen validierenden Resolver ein. In diesem Falle wird dieser Resolver als gefälscht erkannte Daten unterdrücken können und gar nicht erst an Sie weiterleiten. Da ein validierender Resolver auch Daten von nicht-signierten Domains weiterleitet, ist für den Nutzer nicht erkennbar, ob die Daten von einer signierten oder einer nicht-signierten Domain stammen.  

Gibt ein DENIC-Mitglied die Verwaltung einer Domain auf und gibt die Domain in den TRANSIT, wird DENIC eventuell vorhandenes Schlüsselmaterial aus der Registrierungsdatenbank entfernen. Ohne verwaltendes Mitglied können Änderungen zu den Domaindaten, inkl. Änderungen des Schlüsselmaterials, nicht an DENIC übertragen werden. Damit sind die Voraussetzungen für eine Schlüsselverwaltung nicht mehr gegeben. Zur Vermeidung von Validierungsfehlern wird der DS-Record gestrichen, und die Zone ist damit als unsigniert markiert.

Unser Service DENICdirect bietet aktuell nicht die Möglichkeit, Schlüsselmaterial für Domains mit Nameserver-Einträgen zu hinterlegen. Domains mit "nsentry"-Einträgen werden, da die entsprechenden Records direkt in der .de-Zone vorliegen und dort autoritativ sind, automatisch von DNSSEC erfasst und mit entsprechenden, von DENIC erzeugten Signaturen versehen.

Weitere Informationen finden Sie unter http://www.denic.de/hintergrund/nameservice/nameserver-und-nsentry-eintraege.html.

<< erste < vorherige 21-40 41-60 61-80 81-100 101-120 121-140 141-154 nächste > letzte >>