Eine eigene Webseite erstellen
Eine Website (englische Aussprache: [ˈwɛbsaɪt]; vom englischen „site“ für Ort, Platz, Stelle und vom lateinischen „Situs“ für Lage oder Stellung) – im deutschen Sprachgebrauch selten auch Webauftritt, Webpräsenz, Webangebot oder kurz Webseite[1] genannt – ist ein virtueller Platz im World Wide Web, an dem sich meist mehrere Webdokumente (Dateien) und andere Ressourcen befinden. Diese sind üblicherweise durch eine einheitliche Navigation (durch Hypertext-Verfahren) zusammengefasst und verknüpft.
So ist etwa die Wikipedia als Gesamtes eine Website, die im Internet auf einem oder mehreren Host-Rechnern (Servern) gespeichert ist, während das, was im Browser angezeigt wird, speziell als ein einzelnes Dokument betrachtet wird. Die Website der deutschen Wikipedia umfasst derzeit über eine Million Webseiten.
Inhaltsverzeichnis |
|
Dieser Artikel oder Abschnitt bedarf einer
Überarbeitung. Näheres ist auf der Diskussionseite, unter "Zu den Begriffen", angegeben. Hilf mit,
ihn zu verbessern, und entferne
anschließend diese Markierung. |
Die deutsche Bezeichnung ist vom englischen Begriff website oder web site (englisch site, der Platz, die Stelle‘) abgeleitet. Website und Webseite (Webpage, deutsch als Übersetzung zu englisch page, ursprünglich ‚Seite (eines Buches‘) sind heute im Deutschen falsche Freunde und werden leicht verwechselt.
Die Webseite ist in der Regel[2] eine HTML-Datei, die Website eine Ressource, die unter einer URL angesprochen werden kann. Homepage ist ursprünglich die Frontpage (Startseite) einer Website. Dagegen bezeichnet das Wort Webspace (englisch space ‚der Platz, der Raum‘) die Kombination aus Adresse und Datenspeicherressource, die ein Internetprovider einem Kunden zur Verfügung stellt, damit er dort seine Website einrichten kann oder ein anderes Internetangebot, etwa ein Online-E-Mail-Konto, nutzen kann.
In den Frühzeiten des Internets waren eigene Webserver teuer, und die meisten Benutzer hatten keine eigene Domain, sondern waren unter einer Webseite erreichbar, die tief in der Domain angesiedelt war (anfangs meist die Domains von Universitäten oder größeren Firmen) – deshalb waren damals die Ausdrücke ‚Website‘ („eigener Platz im Internet“) und ‚Webpage‘ („eine HTML-Seite im Internet“) synonym. Als gehobenere Form galt, auch Unterseiten erstellen zu können – die ursprüngliche Webseite wurde so zur Einstiegsseite (Front- oder Homepage).
Aus dem umgangssprachlichen Ausdruck „eine eigene Homepage haben“ für komplexer aufgebaute Webauftritte wird ‚Homepage‘ gelegentlich als Website verstanden. Daher wird der Ausdruck ‚Webseite‘ im deutschen Sprachraum gelegentlich synonym an Stelle des Anglizismus ‚Website‘ verwendet, was der intuitiven Sprachbildung folgt. Eine ‚Website‘ ist jedoch etwas anderes als eine Webseite (page).
Nur im Fachdiskurs durchgesetzt hat sich bisher der Begriff ‚Webpräsenz‘, eine sprachlich präzisere Neubildung.
Die Mehrzahl von Website lautet Websites. Meistens wird Website – ebenfalls in Anlehnung an ‚Seite‘ – dem weiblichen Geschlecht zugeordnet („die Website“).
Die erste Webseite, die sozusagen online ging, wurde am 13. November 1990 von dem am CERN beschäftigten Wissenschaftler Tim Berners-Lee geschaffen und veröffentlicht. Am 30. April 1993 kündigte das CERN an, dass das World Wide Web für jedermann frei zugänglich sein werde.
Eine Website besteht im einfachsten Fall zumindest aus einer HTML-Datei, die
in einem Verzeichnis
im Pfad
einer Domain
liegt. Im Allgemeinen ist sie heute aber aus zahlreichen HTML-Dateien aufgebaut,
die auch in einer verschachtelten Ordnerstruktur untergebracht werden können.
Außerdem ist zu beachten, dass eine HTML-Datei selbst meist aus einer Datei mit
der Endung .htm(l), und
einem gleichnamigen Ordner besteht, in dem die nicht HTML-konformen Elemente
(Bilder, Medien, usw.) untergebracht sind; dazu gehören Dateien über die CSS-Klassentypisierungen und diverse
Skriptdateien (JavaScript)).
So stellt es sich zumindest dar, wenn die angezeigte Seite vom Browser auf der Festplatte des Besuchers abgespeichert wird; intern kann sie synthetisch vollständig durch Skriptsprachen und Datenbankinhalte erzeugt sein, so dass die Existenz einer echten Datei lediglich vorgetäuscht wird (teilweise deshalb, weil man sich davon bessere Positionen bei Suchmaschinen verspricht). CSS und JavaScript-Dateien werden typischerweise für eine Website zentral vorgegeben und bei Massenhostern sogar vom Provider für den ganzen Webspace vorgegeben.
Homepage bezeichnet die Seite eines Web-Auftrittes, die als zentraler Dreh- und Angelpunkt angelegt ist. Die Startseite (auch Eintritt-, Index-Seite) ist die erste aufgerufene Seite einer Website, also ein Tor (daraus die Bildung Webportal und Portalseite). Dies kann die Homepage oder eine Intro-Seite sein.
In den meisten Fällen ist die Homepage auch die Startseite einer Website. In besonderen Fällen ist ihr jedoch eine Intro-Seite vorgeschaltet. Dies in der Regel deshalb, weil anschließend eine Frame-Lösung gezeigt wird, deren Erfassung durch Suchmaschinen oft nicht optimal ist. Das Intro soll dann über die für den Besucher unsichtbaren, für Suchmaschinen bestimmten Inhalte und Stichworte die nötigen Informationen liefern, sofern die Folgeseiten für diese "unsichtbar" bleiben. Daher erscheint das Intro oft extrem spartanisch und sagt für den Besucher nichts aus; es wird oft als lästig und als Hindernis empfunden. Dem versucht man vielfach mit Flash-Animationen zu begegnen, die jedoch von vielen Besuchern ebenfalls als Zumutung und Zeitverschwendung betrachtet werden. Als Reaktion darauf wird meist ein Link zum Überspringen angeboten.
Websites werden vorwiegend in der plattformunabhängigen Auszeichnungssprache HTML oder XHTML geschrieben, um zu gewährleisten, dass sie von möglichst allen Browsern dargestellt werden können. Des Öfteren wird die Website mit CSS gestaltet, denn diese ermöglichen eine einfache Gestaltung von Inhalten, die mit HTML oder XHTML strukturiert wurden. Bei aufwendigeren Websites erfolgt die Programmierung meist unter Verwendung serverseitiger Skript- (PHP, Perl, Python, Ruby, VBScript) oder Programmiersprachen (Java), die unter anderem auch die Verwendung von Datenbanksystemen (MySQL, PostgreSQL, Oracle) erlauben. Oft kommen auch clientseitige Skriptsprachen wie JavaScript zum Einsatz, die normalerweise mehr für die Benutzerinteraktion als für die vollständige Erstellung einer Website verwendet werden. Serverseitige Skripte oder Programme erzeugen als Ausgabe vorzugsweise HTML-Text, der dann vom Browser des Benutzers gerendert wird. Die Website wird auf einem Webserver abgelegt, der häufig in einem Rechenzentrum von einem so genannten Webhoster betrieben und an den Inhaber der Website vermietet wird.
Weiter als der Begriff der Webpräsenz ist der Begriff Internetpräsenz zu verstehen, da hierin neben Web-Anwendungen auch Dienste (Daemons) wie FTP oder E-Mail enthalten sein können.
Die Entwicklung von Websites wird als Webdesign oder Webauthoring bezeichnet.
Praktische Hinweise
Die
Forschung in diesem Bereich ist noch sehr jung, praktische Hinweise für das
Webdesign lassen sich aus den gegenwärtigen Studien bisher nur begrenzt
ableiten. Der Brite Alistair Sutcliffe schlägt einige praktische Regeln für ein
ästhetisches Webdesign vor:[16]
Die visuelle Wahrnehmung von Webauftritten im Internet ist grundsätzlich abhängig von den allgemeinen Gesetzmäßigkeiten der visuellen Kommunikation. Der Prozess der Informationsaufnahme durch den Benutzer/Besucher wird wesentlich durch die grafische Gestaltung der Website gesteuert. Der Unterschied zu Printmedien besteht sowohl in technischen Begrenzungen als auch in der erweiterten Funktionalität des World Wide Web.
Neben dem professionellen Transport von Information und Corporate Identity geht es bei der Gestaltung von Websites um die Benutzerfreundlichkeit (Usability). Navigation und Aufbau der Websites sollen möglichst vielen Menschen entgegen kommen. Hier erfahren viele behinderte Menschen Nachteile, da sie Websites benötigen, die barrierefrei gestaltet sind. Die praktische Umsetzung einer weitgreifenden Benutzerfreundlichkeit schränkt entweder die gestalterischen Möglichkeiten ein oder erfordert höheren Aufwand in Technik und Gestaltung.
Werden in einem Hypertext zu viele Wahlmöglichkeiten durch Links gegeben, kann dies außerdem zu einer Konfusion beim Nutzer, dem so genannten Lost in Hyperspace führen.
Zur Benutzerfreundlichkeit kommt die Forderung der Zugänglichkeit (Accessibility), z.B. durch Vermeidung von Techniken, die Informationen nur mit einem bestimmten Webbrowser erreichbar machen, oder durch das Schaffen von (Text-)Alternativen zu multimedialen Inhalten. Flash und andere Browser-Erweiterungen müssen deswegen nicht grundsätzlich vermieden werden, es sollte jedoch sichergestellt sein, dass der Inhalt ohne diese Techniken voll abrufbar bleibt.
Ein wichtiger Aspekt beim Webdesign ist eine korrekte Textauszeichnung und Kenntnisse in Webtypografie. Aufgrund der zur Zeit noch wesentlich schlechteren Auflösungen von Bildschirmen gegenüber Printmedien werden oft spezielle, auf die Anzeige am Bildschirm optimierte Schriften eingesetzt.
Während Webseiten für die Browser-Generationen 4 (Netscape 4 und Internet Explorer 4) noch sehr unterschiedlich geschrieben wurden und Browserweichen erforderlich waren, kann der Webentwickler in den aktuellen Versionen (Mozilla Firefox, Internet Explorer, Opera, Konqueror, usw.) eine mehr oder weniger weitgehende Unterstützung der Standards des W3C erwarten.
Programmcode zur Steuerung und zur äußerlichen Erscheinung der Website lässt sich entweder durch serverseitige Skriptsprachen wie PHP, Python, Perl, ASPNet, ColdFusion oder JSP (Java Server Pages) ausführen oder durch weitgehend clientseitige Erweiterungen wie Flash, Silverlight, Java oder JavaScript. Es besteht die Möglichkeit, client- und serverseitige Technologien zu kombinieren, beispielsweise PHP und Flash, um die Vorteile beider nutzen zu können. Dabei sollte darauf geachtet werden mit clientseitigen Erweiterungen sparsam umzugehen, da oft die notwendigen Plugins beim Benutzer nicht vorhanden sind oder JavaScript aus Sicherheitsgründen abgeschaltet wurde.
Auch im Webdesign gibt es immer wieder Tendenzen zu speziellen Technologien zu beobachten, oder auch Trends die von den Webdesignern verstärkt verfolgt werden. Dabei finden sowohl proprietäre als auch quelloffene und freie Technologien überzeugte Anhänger. In den letzten Jahren werden jedoch verstärkt wieder quelloffene und freie Technologien, die sowohl vom W3C als auch von der WHATWG überwacht und freigegeben werden, verfolgt und verstärkt implementiert.[1][2]
Trends sind jedoch nicht nur bei den verwendeten Technologien zu finden, auch im Bereich der Art und Weise wie Websites und die dazu passenden Logos aussehen sind klare Vorlieben auszumachen. Dabei spielt das beliebte Kunstwort Web 2.0 bis dato eine gewichtige Rolle.[3][4][5]
Webdesign und Printlayout unterscheiden sich in Gestaltung oder Präsentation einer Publikation.
Ein großer Unterschied zu den Printmedien ist die herangezogene Maßeinheit. Während im Printbereich mit absoluten Einheiten (z. B. metrischen Einheiten) und einer bekannten definierten Größe des Mediums gearbeitet wird, ist beim Webdesign die Größe und Beschaffenheit des Ausgabemediums nicht bekannt. Jedoch gibt es im Web absolute und relative Maßeinheiten, des Weiteren sogar Mischungen dieser.[6] Weit verbreitet ist die Verwendung der pseudoabsoluten Maßeinheit Pixel. Pseudoabsolut, da ein Pixel je nach Ausgabegerät eine variierende Größe aufweist. Von vielen Webdesignern wird oft gefordert, dass ausschließlich relative Angaben Verwendung finden dürfen, da man nie wisse welche Ausgabegeräte zum Einsatz kommen. In der Praxis erweisen sich hierbei jedoch diverse Probleme, wie die teilweise variierende und manchmal nicht nachvollziehbare Interpretation von relativen Angaben der unterschiedlichen Browser (z. B. die Interpretation der Angabe thin bei Rahmen durch den Internet Explorer bis Version 8).
„Hardliner empfehlen immer wieder, man solle ausschließlich relative Angaben verwenden […] Für die Praxis empfiehlt sich kein völliger Verzicht auf absolute Angaben, jedoch ein behutsamer Umgang damit.“
– Stefan Münz: Webseiten professionell erstellen, Seite 125, Kapitel 4.6.4 Maßangaben in CSS
Als weiteres Problem erweist sich die Farbdarstellung, das Erscheinungsbild von Farbabbildungen – die Farbtreue – ist sowohl vom Monitor-Gamma als auch dem verwendeten Farbraum abhängig. Zudem weisen die verschiedenen Panel-Arten der heute gebräuchlichen TFT-Monitore stark variierende Farbqualitäten auf. Gute Monitore liegen meist in hohen Preisklassen und sind deshalb nicht sehr weit verbreitet, ein Umstand der bei CRT-Monitoren noch nicht so stark zum tragen kam.
Wechseln zu: Navigation, Suche
|
Domain Name System
(DNS) |
|||||||||||||||||||||||||||||||||||||
|
Familie: |
|||||||||||||||||||||||||||||||||||||
|
Einsatzgebiet: |
|||||||||||||||||||||||||||||||||||||
|
Ports: |
53/UDP, 53/TCP |
||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||
|
Standards: |
RFC 1034 (1987) RFC 1035 (1987) |
||||||||||||||||||||||||||||||||||||
Das Domain Name System (DNS) ist einer der wichtigsten Dienste im Internet. Seine Hauptaufgabe ist die Beantwortung von Anfragen zur Namensauflösung.
In Analogie zu einer Telefonauskunft soll das DNS bei Anfrage mit einem Hostnamen (dem für Menschen merkbaren Namen eines Rechners im Internet) – zum Beispiel www.example.org – als Antwort die zugehörige IP-Adresse (die „Anschlussnummer“ im Internet) – zum Beispiel eine IPv4-Adresse der Form 192.0.2.42 oder eine IPv6-Adresse wie 2001:db8:85a3:8d3:1319:8a2e:370:7347 – nennen.
Das DNS ist ein weltweit auf tausende von Servern verteilter hierarchischer Verzeichnisdienst, der den Namensraum des Internets verwaltet. Dieser Namensraum ist in so genannte Zonen unterteilt, für die jeweils unabhängige Administratoren zuständig sind. Für lokale Anforderungen – etwa innerhalb eines Firmennetzes – ist es auch möglich, ein vom Internet unabhängiges DNS zu betreiben.
Hauptsächlich wird das DNS zur Umsetzung von Domainnamen in IP-Adressen („forward lookup“) benutzt. Dies ist vergleichbar mit einem Telefonbuch, das die Namen der Teilnehmer in ihre Telefonnummer auflöst. Das DNS bietet somit eine Vereinfachung, weil Menschen sich Namen weitaus besser merken können als Zahlenkolonnen. So kann man sich einen Domainnamen wie example.org in der Regel leichter merken als die dazugehörende IP-Adresse 192.0.32.10. Dieser Punkt gewinnt im Zuge der Einführung von IPv6 noch an Bedeutung, denn dann werden einem Namen jeweils IPv4- und IPv6-Adressen zugeordnet, so löst der Name www.kame.net in die IPv4-Adresse 203.178.141.194 und die IPv6-Adresse 2001:200:0:8002:203:47ff:fea5:3085 auf.
Ein weiterer Vorteil ist, dass IP-Adressen – etwa von Web-Servern – relativ risikolos geändert werden können. Da Internetteilnehmer nur den (unveränderten) DNS-Namen ansprechen, bleiben ihnen Änderungen der untergeordneten IP-Ebene weitestgehend verborgen. Da einem Namen auch mehrere IP-Adressen zugeordnet werden können, kann sogar eine einfache Lastverteilung per DNS (Load Balancing) realisiert werden.
Mit dem DNS ist auch eine umgekehrte Auflösung von IP-Adressen in Namen („reverse lookup“) möglich. In Analogie zum Telefonbuch entspricht dies einer Suche nach dem Namen eines Teilnehmers zu einer bekannten Rufnummer, was innerhalb der Telekommunikationsbranche unter dem Namen Inverssuche bekannt ist.
Das DNS wurde 1983 von Paul Mockapetris entworfen und in RFC 882 und 883 beschrieben. Beide wurden inzwischen von RFC 1034 und RFC 1035 abgelöst und durch zahlreiche weitere Standards ergänzt. Ursprüngliche Aufgabe war es, die lokalen hosts-Dateien abzulösen, die bis dahin für die Namensauflösung zuständig waren und die der enorm zunehmenden Zahl von Neueinträgen nicht mehr gewachsen waren. Aufgrund der erwiesenermaßen hohen Zuverlässigkeit und Flexibilität wurden nach und nach weitere Datenbestände in das DNS integriert und so den Internetnutzern zur Verfügung gestellt (siehe unten: Erweiterung des DNS).
DNS zeichnet sich aus durch:
schematische Darstellung der DNS-Hierarchie
Der Domain-Namensraum hat eine baumförmige Struktur. Die Blätter und Knoten des Baumes werden als Labels
bezeichnet. Ein kompletter Domainname eines Objektes besteht aus der Verkettung aller Labels
eines Pfades. Label sind Zeichenketten (alphanumerisch, als einziges Sonderzeichen
ist '-' erlaubt), die mindestens ein Zeichen und maximal 63 Zeichen lang sind,
mit einem Buchstaben beginnen müssen und nicht mit '-' enden dürfen (RFC 1035, Abschnitt „2.3.1.
Preferred name syntax“). Die einzelnen Labels werden durch Punkte voneinander
getrennt. Ein Domainname wird mit einem Punkt abgeschlossen (der hinterste
Punkt wird normalerweise weggelassen, gehört rein formal aber zu einem
vollständigen Domainnamen dazu). Ein korrekter, vollständiger Domainname (auch Fully Qualified
Domain-Name (FQDN) genannt) lautet etwa: www.example.com.
Ein Domainname darf inklusive aller Punkte maximal 255 Zeichen lang sein.
Ein Domainname wird immer von rechts nach links delegiert und aufgelöst, das heißt je weiter rechts ein Label steht, umso höher steht es im Baum. Der Punkt am rechten Ende eines Domainnamens trennt das Label für die erste Hierarchieebene von der Wurzel (engl. root). Diese erste Ebene wird auch als Top-Level-Domain (TLD) bezeichnet. Die DNS-Objekte einer Domäne (zum Beispiel die Rechnernamen) werden als Satz von Resource Records meist in einer Zonendatei gehalten, die auf einem oder mehreren autoritativen Nameservern vorhanden ist. Anstelle von Zonendatei wird meist der etwas allgemeinere Ausdruck Zone verwendet.
→ Hauptartikel: Nameserver
Nameserver sind zum einen Programme, die Anfragen zum Domain-Namensraum beantworten, im Sprachgebrauch werden allerdings auch die Rechner, auf denen diese Programme laufen, als Nameserver bezeichnet. Man unterscheidet zwischen autoritativen und nicht-autoritativen Nameservern.
Ein autoritativer Nameserver ist verantwortlich für eine Zone. Seine Informationen über diese Zone werden deshalb als gesichert angesehen. Für jede Zone existiert mindestens ein autoritativer Server, der Primary Nameserver. Dieser wird im SOA Resource Record einer Zonendatei aufgeführt. Aus Redundanz- und Lastverteilungsgründen werden autoritative Nameserver fast immer als Server-Cluster realisiert, wobei die Zonendaten identisch auf einem oder mehreren Secondary Nameservern liegen. Die Synchronisation zwischen Primary und Secondary Nameservern erfolgt per Zonentransfer.
Ein nicht-autoritativer Nameserver bezieht seine Informationen über eine Zone von anderen Nameservern sozusagen aus zweiter oder dritter Hand. Seine Informationen werden als nicht gesichert angesehen. Da sich DNS-Daten normalerweise nur sehr selten ändern, speichern nicht-autoritative Nameserver die einmal von einem Resolver angefragten Informationen im lokalen RAM ab, damit diese bei einer erneuten Anfrage schneller vorliegen. Diese Technik wird als Caching bezeichnet. Jeder dieser Einträge besitzt ein eigenes Verfallsdatum (TTL time to live), nach dessen Ablauf der Eintrag aus dem Cache gelöscht wird. Die TTL wird dabei durch einen autoritativen Nameserver für diesen Eintrag festgelegt und wird nach der Änderungswahrscheinlichkeit des Eintrages bestimmt (sich häufig ändernde DNS-Daten erhalten eine niedrige TTL). Das kann unter Umständen aber auch bedeuten, dass der Nameserver in dieser Zeit falsche Informationen liefern kann, wenn sich die Daten zwischenzeitlich geändert haben.
Ein Spezialfall ist der Caching Only Nameserver. In diesem Fall ist der Nameserver für keine Zone verantwortlich und muss alle eintreffenden Anfragen über weitere Nameserver (Forwarder) auflösen. Dafür stehen verschiedene Strategien zur Verfügung:
Zusammenarbeit der einzelnen Nameserver
Damit ein nicht-autoritativer Nameserver Informationen über andere Teile des Namensraumes finden kann, bedient er sich folgender Strategien:
Delegierung
Teile des Namensraumes einer Domain werden oft an Subdomains mit dann eigens zuständigen Nameservern ausgelagert. Ein Nameserver einer Domäne kennt die zuständigen Nameserver für diese Subdomains aus seiner Zonendatei und delegiert Anfragen zu diesem untergeordneten Namensraum an einen dieser Nameserver.
Weiterleitung (forwarding)
Falls der angefragte Namensraum außerhalb der eigenen Domäne liegt, wird die Anfrage an einen fest konfigurierten Nameserver weitergeleitet.
Auflösung über die Root-Server
Falls kein Weiterleitungsserver konfiguriert wurde oder dieser nicht antwortet, werden die Root-Server befragt. Dazu werden in Form einer statischen Datei die Namen und IP-Adressen der Root-Server hinterlegt. Es gibt 13 Root-Server (Server A bis M). Die Root-Server beantworten Anfragen ausschließlich iterativ (der Server antwortet mit einem Verweis auf andere Nameserver), da diese sonst mit der Anzahl der Anfragen überlastet wären.
schematische Darstellung der rekursiven und iterativen DNS-Abfrage
Resolver sind einfach aufgebaute Software-Module, die auf dem Rechner eines DNS-Teilnehmers installiert sind und die Informationen von Nameservern abrufen können. Sie bilden die Schnittstelle zwischen Anwendung und Nameserver. Der Resolver übernimmt die Anfrage einer Anwendung, ergänzt sie, falls notwendig, zu einem FQDN und übermittelt sie an einen normalerweise fest zugeordneten Nameserver. Ein Resolver arbeitet entweder rekursiv oder iterativ.
Im rekursiven Modus schickt der Resolver eine rekursive Anfrage an den ihm zugeordneten Nameserver. Hat dieser die gewünschte Information nicht im eigenen Datenbestand, so kontaktiert der Nameserver weitere Server, und zwar solange bis er entweder eine positive Antwort oder bis er von einem autoritativen Server eine negative Antwort erhält. Rekursiv arbeitende Resolver überlassen also die Arbeit zur vollständigen Auflösung ihrem Nameserver.
Bei einer iterativen Anfrage bekommt der Resolver entweder den gewünschten Resource Record oder einen Verweis auf weitere Nameserver, die er als nächstes fragt. Der Resolver hangelt sich so von Nameserver zu Nameserver, bis er von einem eine verbindliche Antwort erhält.
Die so gewonnene Antwort übergibt der Resolver an das Programm, das die Daten angefordert hat, beispielsweise an den Webbrowser. Übliche Resolver von Clients arbeiten ausschließlich rekursiv, sie werden dann auch als Stub-Resolver bezeichnet. Nameserver besitzen in der Regel eigene Resolver. Diese arbeiten gewöhnlich iterativ.
Bekannte Programme zur Überprüfung der Namensauflösung sind nslookup, host und dig. Weitere Informationen zur iterativen/rekursiven Namensauflösung finden sich unter rekursive und iterative Namensauflösung.
DNS-Anfragen werden normalerweise per UDP Port 53 zum Namensserver gesendet. Der DNS-Standard erlaubt aber auch TCP. Falls kein Extended DNS verwendet wird (EDNS), beträgt die maximal zulässige Länge des DNS-UDP-Pakets 512 Bytes. Überlange Antworten werden daher abgeschnitten übertragen. Durch Setzen des Truncated-Flags wird der anfragende Client über diesen Sachverhalt informiert. Er muss dann entscheiden, ob ihm die Antwort reicht oder nicht. Gegebenenfalls wird er die Anfrage per TCP Port 53 wiederholen.
Zonentransfers werden stets über Port 53 TCP durchgeführt. Die Auslösung von Zonentransfer erfolgt aber gewöhnlich per UDP.
Das Domain Name System kann als verteilte Datenbank mit baumförmiger Struktur aufgefasst werden. Beim Internet-DNS liegen die Daten auf einer Vielzahl von weltweit verstreuten Servern, die untereinander über Verweise – in der DNS-Terminologie Delegierungen genannt – verknüpft sind.
In jedem beteiligten Nameserver existieren eine oder mehrere Dateien – die so genannten Zonendateien – die alle relevanten Daten enthalten. Bei diesen Dateien handelt es sich um Listen von Resource Records. Von großer Bedeutung sind sieben Record-Typen:
Im Laufe der Zeit wurden neue Typen definiert, mit denen Erweiterungen des DNS realisiert wurden. Dieser Prozess ist noch nicht abgeschlossen. Eine umfassende Liste findet sich unter Resource Record.
Beispiele:
Folgender NS Resource Record in der Zonendatei der Domain „org.“ definiert: Die Zonendatei für die Domain „wikipedia.org.“ befindet sich auf dem Server „ns0.wikimedia.org.“. Der Punkt am Ende ist wichtig, da dieser klarstellt, dass kein relativer Name gemeint ist, also hinter „org“ nichts mehr zu ergänzen ist. „IN“ meint, dass der Eintrag die Klasse „Internet“ besitzt und die Zahl davor bedeutet die Time To Live (TTL) in Sekunden, sie besagt, wie lange diese Information in einem Cache zwischengespeichert werden könnte, bevor sie neu erfragt werden sollte. Bei dynamischen IP-Adressen liegt diese Zahl meistens zwischen 20 und 300 Sekunden.
wikipedia 86400 IN NS ns0.wikimedia.org.
Folgender CNAME Resource Record in der Zonendatei der Domain „wikipedia.org.“ definiert: Der Name „de.wikipedia.org.“ verweist auf den Namen „rr.wikimedia.org.“.
de 3600 IN CNAME rr.wikimedia.org.
Folgende Resource Records in der Zonendatei der Domain „wikimedia.org.“ definieren: Der Name „rr.wikimedia.org.“ verweist auf den Namen „rr.esams.wikimedia.org.“ und diesem wiederum ist die IPv4-Adresse 91.198.174.2 zugewiesen.
rr 600 IN CNAME rr.esams
rr.esams 3600 IN A 91.198.174.2
Letztlich müssen also alle Rechner, die sich mit „de.wikipedia.org.“ verbinden möchten, IPv4-Pakete an die IP-Adresse 91.198.174.2 senden.
Angenommen, ein Rechner X will eine Verbindung zu „de.wikipedia.org.“ (Rechner Y) aufbauen. Dazu braucht er dessen IP-Adresse. In den folgenden Schritten wird beschrieben, wie dies ablaufen könnte. Falls der Rechner X IPv6-fähig ist, läuft der Vorgang zunächst für IPv6 (Abfrage von AAAA Resource Record) und sofort danach für IPv4 (Abfrage von A Resource Record) ab. Dabei kann eine Anfrage nach einer IPv6-Adresse mittels IPv4-Übertragung an einen IPv4-DNS-Server gerichtet werden. Falls am Ende eine IPv6- und eine IPv4-Adresse für Rechner Y ermittelt werden, wird in der Regel laut der Default Policy Table in RFC 3484 die Kommunikation zwischen X und Y über IPv6 bevorzugt, es sei denn im Betriebssystem oder in den benutzten Anwendungen, wie zum Beispiel dem Webbrowser, wurde dieses Verhalten anders eingestellt.
Im folgenden, kommentierten Beispiel wird zum Namen „www.heise.de.“ die IPv4-Adresse mit Hilfe des Resolver-Tools dig bestimmt. „+trace“ bedeutet, dass die einzelnen Antworten auf iterative Anfragen an die Nameserver-Hierarchie angegeben werden, „+additional“ sorgt dafür, dass zusätzlich dargestellt wird, dass die Nameserver für Delegierungen nicht nur NS Resource Records verwalten, sondern teilweise auch deren IP-Adressen in Form von A oder AAAA Resource Records kennen und mit ausliefern, „-t A“ schließlich verlangt nach dem A Resource Record, also der IPv4-Adresse. Es zeigt sich, dass nacheinander vier Nameserver befragt werden müssen, um zur Antwort zu gelangen:
$ dig +trace +additional -t A www.heise.de.; <<>> DiG 9.5.1-P3 <<>> +trace +additional -t A www.heise.de.;; global options: printcmd. 6086 IN NS B.ROOT-SERVERS.NET.. 6086 IN NS D.ROOT-SERVERS.NET.. 6086 IN NS J.ROOT-SERVERS.NET.. 6086 IN NS G.ROOT-SERVERS.NET.. 6086 IN NS K.ROOT-SERVERS.NET.. 6086 IN NS C.ROOT-SERVERS.NET.. 6086 IN NS M.ROOT-SERVERS.NET.. 6086 IN NS I.ROOT-SERVERS.NET.. 6086 IN NS H.ROOT-SERVERS.NET.. 6086 IN NS E.ROOT-SERVERS.NET.. 6086 IN NS F.ROOT-SERVERS.NET.. 6086 IN NS A.ROOT-SERVERS.NET.. 6086 IN NS L.ROOT-SERVERS.NET.D.ROOT-SERVERS.NET. 6644 IN A 128.8.10.90J.ROOT-SERVERS.NET. 10421 IN A 192.58.128.30J.ROOT-SERVERS.NET. 1289 IN AAAA 2001:503:c27::2:30G.ROOT-SERVERS.NET. 10940 IN A 192.112.36.4K.ROOT-SERVERS.NET. 4208 IN A 193.0.14.129K.ROOT-SERVERS.NET. 7277 IN AAAA 2001:7fd::1C.ROOT-SERVERS.NET. 6126 IN A 192.33.4.12M.ROOT-SERVERS.NET. 3274 IN A 202.12.27.33M.ROOT-SERVERS.NET. 7183 IN AAAA 2001:dc3::35I.ROOT-SERVERS.NET. 9788 IN A 192.36.148.17H.ROOT-SERVERS.NET. 10421 IN A 128.63.2.53H.ROOT-SERVERS.NET. 13739 IN AAAA 2001:500:1::803f:235E.ROOT-SERVERS.NET. 11125 IN A 192.203.230.10F.ROOT-SERVERS.NET. 9973 IN A 192.5.5.241;; Received 500 bytes from 192.168.2.1#53(192.168.2.1) in 50 ms
192.168.2.1 (siehe letzte Zeile) ist der eingetragene Nameserver des abfragenden Rechners und der verweist auf die Root-Nameserver, welche alle weiter via IPv4 befragt werden können, einige könnten auch mittels IPv6 befragt werden. Die Root-Nameserver verwalten die Wurzel der Namensauflösung, dargestellt durch einen Punkt, deren IP-Adressen ändern sich sehr selten und müssen allen Nameservern bekannt sein, sofern sie das Internet betreffende Anfragen beantworten.
de. 172800 IN NS F.NIC.de.
de. 172800 IN NS L.DE.NET.
de. 172800 IN NS S.DE.NET.
de. 172800 IN NS Z.NIC.de.
de. 172800 IN NS A.NIC.de.
de. 172800 IN NS C.DE.NET.
A.NIC.de. 172800 IN A 194.0.0.53C.DE.NET. 172800 IN A 208.48.81.43F.NIC.de. 172800 IN A 81.91.164.5F.NIC.de. 172800 IN AAAA 2001:608:6:6::10
L.DE.NET. 172800 IN A 89.213.253.189S.DE.NET. 172800 IN A 195.243.137.26Z.NIC.de. 172800 IN A 194.246.96.1Z.NIC.de. 172800 IN AAAA 2001:628:453:4905::53
;; Received 288 bytes from 192.36.148.17#53(I.ROOT-SERVERS.NET) in 58 ms
Aus allen genannten Root-Nameservern wurde „I.ROOT-SERVERS.NET.“ ausgewählt, um ihm die Frage nach „www.heise.de.“ zu stellen, er antwortete mit sechs Nameservern zur Auswahl, die für die Zone „de.“ verantwortlich sind. Auch hier ist bei zwei Servern die Abfrage mittels IPv6 möglich.
heise.de. 86400 IN NS ns.plusline.de.
heise.de. 86400 IN NS ns.heise.de.
heise.de. 86400 IN NS ns2.pop-hannover.net.
heise.de. 86400 IN NS ns.pop-hannover.de.
heise.de. 86400 IN NS ns.s.plusline.de.
ns.s.plusline.de. 86400 IN A 212.19.40.14ns.heise.de. 86400 IN A 193.99.145.37ns.plusline.de. 86400 IN A 212.19.48.14ns.pop-hannover.de. 86400 IN A 193.98.1.200;; Received 220 bytes from 81.91.164.5#53(F.NIC.de) in 52 ms
Nun wurde „F.NIC.de.“ befragt, um Näheres über „www.heise.de.“ zu erfahren. Er beantwortete die Frage unter anderem mit einer Delegierung auf den Server „ns.heise.de.“. Diese Information würde ohne den dazugehörigen A Resource Record, auf 193.99.145.37 zeigend, auf demselben Server nichts helfen, denn der Name liegt in der Zone „heise.de.“, die er selbst verwaltet. Man spricht bei dieser Art von Information auch von Glue Records (von engl. glue, kleben). Sollte der Server „ns2.pop-hannover.net.“ für den nächsten Schritt ausgewählt werden, so wäre in einer gesonderten Namensauflösung zunächst dessen IP-Adresse zu bestimmen, da diese hier nicht mitgesendet wurde.
www.heise.de. 86400 IN A 193.99.144.85heise.de. 86400 IN NS ns.pop-hannover.de.
heise.de. 86400 IN NS ns.plusline.de.
heise.de. 86400 IN NS ns2.pop-hannover.net.
heise.de. 86400 IN NS ns.s.plusline.de.
heise.de. 86400 IN NS ns.heise.de.
ns.heise.de. 86400 IN A 193.99.145.37ns.pop-hannover.de. 10800 IN A 193.98.1.200ns2.pop-hannover.net. 86400 IN A 62.48.67.66;; Received 220 bytes from 193.98.1.200#53(ns.pop-hannover.de) in 4457 ms
Der Server „ns.pop-hannover.de.“ wird schließlich herangezogen, um die Frage nach „www.heise.de.“ zu beantworten, die Antwort lautet 193.99.144.85. Es werden auch wieder dieselben Nameserver als verantwortlich für „heise.de.“ genannt, ohne also auf andere Nameserver zu verweisen.
Für den Reverse Lookup, also das Auffinden eines Namens zu einer IP-Adresse, wandelt man die IP-Adresse zunächst formal in einen Namen um, für den man dann das DNS nach einem PTR Resource Record befragt. Da die Hierarchie bei IP-Adressen von links nach rechts spezieller wird (siehe Subnetz), beim DNS aber von rechts nach links, dreht man beim ersten Schritt die Reihenfolge der Zahlen um und aus der IPv4-Adresse 193.99.144.85 wird z. B. der Name „85.144.99.193.in-addr.arpa.“ sowie aus der IPv6-Adresse 2a02:2e0:3fe:100::6 der Name „6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.e.f.3.0.0.e.2.0.2.0.a.2.ip6.arpa.“ erzeugt.
Der PTR Resource Record für die so umgeformte IPv4-Adresse lässt sich analog zum vorigen Beispiel bestimmen:
$ dig +trace +additional -t PTR 85.144.99.193.in-addr.arpa.; <<>> DiG 9.5.1-P3 <<>> +trace +additional -t ptr 85.144.99.193.in-addr.arpa.;; global options: printcmd. 2643 IN NS M.ROOT-SERVERS.NET.. 2643 IN NS A.ROOT-SERVERS.NET.. 2643 IN NS B.ROOT-SERVERS.NET.. 2643 IN NS C.ROOT-SERVERS.NET.. 2643 IN NS D.ROOT-SERVERS.NET.. 2643 IN NS E.ROOT-SERVERS.NET.. 2643 IN NS F.ROOT-SERVERS.NET.. 2643 IN NS G.ROOT-SERVERS.NET.. 2643 IN NS H.ROOT-SERVERS.NET.. 2643 IN NS I.ROOT-SERVERS.NET.. 2643 IN NS J.ROOT-SERVERS.NET.. 2643 IN NS K.ROOT-SERVERS.NET.. 2643 IN NS L.ROOT-SERVERS.NET.A.ROOT-SERVERS.NET. 10978 IN A 198.41.0.4A.ROOT-SERVERS.NET. 2470 IN AAAA 2001:503:ba3e::2:30C.ROOT-SERVERS.NET. 387 IN A 192.33.4.12D.ROOT-SERVERS.NET. 2747 IN A 128.8.10.90E.ROOT-SERVERS.NET. 7183 IN A 192.203.230.10F.ROOT-SERVERS.NET. 14225 IN AAAA 2001:500:2f::fH.ROOT-SERVERS.NET. 7950 IN A 128.63.2.53H.ROOT-SERVERS.NET. 13245 IN AAAA 2001:500:1::803f:235I.ROOT-SERVERS.NET. 6172 IN A 192.36.148.17J.ROOT-SERVERS.NET. 7168 IN A 192.58.128.30J.ROOT-SERVERS.NET. 13860 IN AAAA 2001:503:c27::2:30K.ROOT-SERVERS.NET. 3541 IN A 193.0.14.129K.ROOT-SERVERS.NET. 9369 IN AAAA 2001:7fd::1L.ROOT-SERVERS.NET. 3523 IN A 199.7.83.42;; Received 512 bytes from 192.168.2.1#53(192.168.2.1) in 50 ms 193.in-addr.arpa. 86400 IN NS ns3.nic.fr.
193.in-addr.arpa. 86400 IN NS sec1.apnic.net.193.in-addr.arpa. 86400 IN NS sec3.apnic.net.
193.in-addr.arpa. 86400 IN NS sunic.sunet.se.193.in-addr.arpa. 86400 IN NS ns-pri.ripe.net.193.in-addr.arpa. 86400 IN NS sns-pb.isc.org.193.in-addr.arpa. 86400 IN NS tinnie.arin.net.;; Received 239 bytes from 199.7.83.42#53(L.ROOT-SERVERS.NET) in 170 ms 99.193.in-addr.arpa. 172800 IN NS auth50.ns.de.uu.net.99.193.in-addr.arpa. 172800 IN NS ns.ripe.net.99.193.in-addr.arpa. 172800 IN NS auth00.ns.de.uu.net.;; Received 120 bytes from 202.12.28.140#53(sec3.apnic.net) in 339 ms 144.99.193.in-addr.arpa. 86400 IN NS ns.heise.de.144.99.193.in-addr.arpa. 86400 IN NS ns.s.plusline.de.144.99.193.in-addr.arpa. 86400 IN NS ns.plusline.de.;; Received 114 bytes from 194.128.171.99#53(auth50.ns.de.uu.net) in 2456 ms 85.144.99.193.in-addr.arpa. 86400 IN PTR www.heise.de.144.99.193.in-addr.arpa. 86400 IN NS ns.heise.de.144.99.193.in-addr.arpa. 86400 IN NS ns.s.plusline.de.144.99.193.in-addr.arpa. 86400 IN NS ns.plusline.de.ns.heise.de. 86400 IN A 193.99.145.37;; Received 148 bytes from 193.99.145.37#53(ns.heise.de) in 4482 ms
Die Antwort lautet also „www.heise.de.“. Es ist jedoch weder notwendig, dass jeder IP-Adresse ein Name zugeordnet ist, noch müssen Hin- und Rückauflösung einander entsprechen. Die Auflösung beginnt wieder mit dem Verweis auf die Root-Nameserver und die Delegierungen finden offensichtlich an den durch Punkte markierten Grenzen zwischen den Zahlen statt. Man sieht in dem Beispiel jedoch auch, dass nicht an jedem Punkt in einem Namen delegiert werden muss.
Da sich das DNS als zuverlässig und flexibel erwiesen hat, wurden im Laufe der Jahre mehrere größere Erweiterungen eingeführt. Ein Ende dieses Trends ist nicht absehbar.
Im klassischen DNS ist es aufwendig, einem Namen eine neue IP-Adresse zuzuordnen. Das zugehörige Zonenfile muss (meist manuell) geändert und der Nameserver neu geladen werden. Zeitliche Verzögerungen bis hin zu mehreren Tagen sind üblich. Mit Dynamischem DNS sind Änderungen durch Senden eines entsprechenden DNS-Requests ohne Zeitverzug möglich.
Das Dynamische DNS gilt als Sicherheitsrisiko, da ohne spezielle Vorkehrungen jedermann DNS-Einträge löschen oder verändern kann. In Zusammenhang mit DHCP ist Dynamisches DNS nahezu zwingend erforderlich, da einem User häufig neue IP-Adressen zugewiesen werden. Der DHCP-Server sendet dazu bei jeder Adressänderung eine entsprechende Mitteilung an den Nameserver.
Bisher waren die Label – wie beschrieben – auf alphanumerische Zeichen und das Zeichen ‚-‘ eingeschränkt. Dies hängt vor allem damit zusammen, dass das DNS (wie auch das Internet ursprünglich) in den USA entwickelt wurde. Damit waren in vielen Ländern gebräuchliche Schriftzeichen (im deutschen Sprachraum zum Beispiel die Umlaute ä, ö, ü und ß) oder Zeichen aus komplett anderen Schriftsystemen (zum Beispiel Chinesisch) ursprünglich nicht DNS-fähig.
Ein mittlerweile etablierter Ansatz zur Vergrößerung des Zeichenvorrats ist die 2003 in RFC 3490 beschriebene Internationalisierung von Domain-Namen IDNA. Um das neue System mit dem bisherigen kompatibel zu halten, werden die erweiterten Zeichensätze mit zulässigen Zeichen kodiert, also auf derzeit gültige Namen abgebildet. Die erweiterten Zeichensätze werden dabei zunächst gemäß dem Nameprep-Algorithmus (RFC 3491) normalisiert und anschließend per Punycode (RFC 3492) auf den für DNS verwendbaren Zeichensatz abgebildet. IDNA erfordert eine Anpassung der Netzwerkanwendungen (z. B. Web-Browser), die Nameserver-Infrastruktur (Server, Resolver) braucht jedoch nicht verändert zu werden. Im deutschsprachigen Raum können seit März 2004 deutsche, liechtensteinische, österreichische und schweizerische Domains (.de, .li, .at und .ch) mit Umlauten registriert und verwendet werden. Auch bei einigen anderen Top-Level-Domains, insbesondere im asiatischen Raum, ist die Verwendung von IDNA möglich.
1999 beschrieb Paul Vixie im RFC 2671 einige kleinere, abwärtskompatible Erweiterungen am Domain Name System, die als EDNS Version 0 bezeichnet werden. Durch Verwendung von bis dahin reservierten, aber ungenutzten Header-Codes, kann der Anfragende festlegen, dass er UDP-Antworten größer als 512 Bytes entgegennehmen kann. Außerdem wurde es möglich andere Label-Typen zu nutzen. DNSSEC-fähige Server und Resolver müssen EDNS beherrschen.
Eine weitere aktuelle Erweiterung des DNS stellt ENUM (RFC 2916) dar. Diese Anwendung ermöglicht die Adressierung von Internet-Diensten über Telefonnummern, also das „Anwählen“ von per Internet erreichbaren Geräten mit dem aus dem Telefonnetz bekannten Nummerierungsschema. Aus dem breiten Spektrum der Einsatzmöglichkeiten bietet sich insbesondere die Verwendung für Voice over IP Services an.
Mit der Radio Frequency Identification können auf speziellen RFID-Etiketten abgelegte IDs – so genannte elektronische Produktcodes oder EPCs – berührungslos gelesen werden. Das DNS kann dazu verwendet werden, zu einer ID den Server zu ermitteln, der Daten über das zugehörige Objekt enthält. Der Object Naming Service ONS wandelt dazu den EPC in einen DNS-Namen um und erfragt per Standard-DNS einen oder mehrere Naming Authority Pointer NAPTR.
Zur Filterung von Spam-Mails überprüfen viele Mailserver routinemäßig mit Hilfe des DNS die Absenderadressen eingehender Mails. Als erster Schritt wird dabei der MX Record ermittelt. Aus der so erhaltenen IP-Adresse wird per reverse Lookup ein Name erfragt. Dieser muss mit dem ursprünglichen Absendernamen identisch sein, sonst wird die Mail verworfen. Ein Spammer ist dann nicht mehr in der Lage, beliebige Absenderadressen zu erfinden, sondern muss auf registrierte DNS zurückgreifen.
Mittels Sender Policy Framework kann wesentlich wirkungsvoller verifiziert werden, dass ein Absendername gültig ist. Zu jeder Mail-Domain wird dabei über einen speziellen SPF Resource Record explizit aufgelistet, wer aus dieser Domain heraus Mails versenden darf (im Idealfall nur ein einziger Server).
Neben den IP-Adressen können DNS-Namen auch ISDN-Nummern, X.25-Adressen, ATM-Adressen, öffentliche Schlüssel, Text-Zeilen usw. zugeordnet werden. In der Praxis sind derartige Anwendungsfälle aber die Ausnahme.
DNS ist nicht auf das Internet beschränkt. Es ist ohne weiteres möglich und mit der Definition verträglich, für die Auflösung lokaler Namen eigene Zonen im Nameserver einzurichten und dort die entsprechenden Adressen einzutragen. Der einmalige Aufwand zur Installation lohnt sich auch bei relativ kleinen Netzen, da dann alle Adressen im Netz zentral verwaltet werden können.
Bei größeren Firmen oder Organisationen ist häufig ein aus lokalem und Internet-DNS bestehendes Mischsystem (Split-DNS) anzutreffen. Die internen Nutzer greifen auf das lokale und die externen auf das Internet-DNS zu. In der Praxis können dadurch sehr komplizierte Konstellationen entstehen.
Der DNS-Server BIND kann auch mit DHCP zusammenarbeiten und damit für jeden Client im Netz eine Namensauflösung ermöglichen.
Unter Windows gibt es noch einen anderen Dienst zur Namensauflösung – WINS, der eine ähnliche Funktion zur Verfügung stellt, allerdings ein anderes Protokoll verwendet.
Es ist möglich, mehrere DNS-Server zu verbinden. Die als Master bezeichneten Server sind für eine oder mehrere Domains verantwortlich. Die Slaves aktualisieren nach einer Änderung selbst die Daten, der Master verteilt diese Daten nicht automatisiert. Die Abholung der Daten wird über einen Zonentransfer realisiert. Z.B. kann eine Firma mit mehreren Standorten an einem Platz einen Master für ihr internes DNS betreiben, der die Server in den Außenstellen versorgt. Der Zonentransfer geht bei BIND über TCP (per Default Port 53) und erfordert normalerweise, durch seine Konfiguration, Authentifizierung. Die Slaves aktualisieren sich, wenn sich die Seriennummer für eine Zonendatei ändert oder sie eine entsprechende Nachricht vom Master erhalten. Die Freigabe für den Transferport sollte man per Firewall an die IP-Adresse des Masters binden. Bei anderen Softwarepaketen werden die Daten unter Umständen auf anderen Wegen abgeglichen, beispielsweise durch LDAP-Replikation, rsync, oder noch andere Mechanismen.
Das DNS ist ein zentraler Bestandteil einer vernetzten IT-Infrastruktur. Eine Störung kann erhebliche Kosten nach sich ziehen und eine Verfälschung von DNS-Daten Ausgangspunkt von Angriffen sein. Mehr als zehn Jahre nach der ursprünglichen Spezifikation wurde DNS um Security-Funktionen ergänzt. Folgende Verfahren sind verfügbar:
Hauptziel von DNS-Angriffen ist es, durch Manipulation DNS-Teilnehmer auf falsche Webseiten zu lenken, um anschließend Passwörter, PINs, Kreditkartennummern usw. zu erhalten. In seltenen Fällen wird versucht, den Internet-DNS durch Denial-of-Service-Attacken komplett auszuschalten und so das Internet lahmzulegen. Außerdem kann das DNS dazu verwendet werden, gezielte Angriffe auf Einzelpersonen oder Unternehmen zu intensivieren.
Bei einer Distributed-Denial-of-Service-Attacke werden Nameserver durch einen hohen Datenstrom von DNS-Anfragen überlastet, so dass legitime Anfragen nicht mehr beantwortet werden können. Gegen DDOS-Angriffe auf Nameserver gibt es zur Zeit keine Abwehrmöglichkeit. Als vorbeugende Maßnahme kann lediglich versucht werden, die Nameserver entsprechend zu dimensionieren bzw. ein verteiltes Netz mit möglichst vielen Servern zu installieren. Solch eine Attacke ist jedoch aufwändig, denn man muss mindestens eine so leistungsschnelle Leitung besitzen wie der Server selbst, was also schwer realisierbar ist. Botnetze und dergleichen werden bei solchen Attacken häufig eingesetzt.
Der DNS Amplification Attack ist ein Denial-of-Service-Angriff, bei dem nicht der DNS selbst das eigentliche Angriffsziel ist, sondern ein unbeteiligter Dritter. Ausgenutzt wird, dass DNS-Server in manchen Fällen auf kurze Anfragen sehr lange Antworten zurücksenden. Diese werden auf die IP-Adresse des Opfers gelenkt. Ein Angreifer kann damit den von ihm ausgehenden Datenstrom substantiell verstärken und so den Internet-Zugang seines Angriffziels stören.
Beim DNS-Spoofing wird einem anfragenden Client eine Antwort mit einer falschen IP-Adresse untergeschoben, so dass dieser auf eine falsche Web-Seite gelenkt wird.
Beim Cache Poisoning werden einem anfragenden Client zusätzlich zur korrekten Antwort manipulierte Daten übermittelt, die dieser in seinen Cache übernimmt und später, möglicherweise ungeprüft, verwendet.
Wer einen autoritativen DNS-Server für seine eigenen Domains betreibt, muss
natürlich für Anfragen von beliebigen IP-Adressen offen sein. Um zu verhindern,
dass Internetteilnehmer diesen Server als allgemeinen Nameserver verwenden
(z. B. für Angriffe auf Root-Server), erlaubt BIND es, die Antworten auf
die eigenen Domains einzuschränken. Z. B. bewirkt die Option allow-recursion {127.0.0.1; 172.16.1.4;};
es, dass rekursive Anfragen, d. h. Anfragen auf andere Domains,
ausschließlich für den lokalen Host (localhost) sowie 172.16.1.4 beantwortet
werden. Alle anderen IP-Adressen bekommen nur auf Anfragen auf eigene Domains
eine Antwort.
Eine zusätzliche Sicherheitsmaßnahme ist es, für Input von außen nur UDP zuzulassen. ICCP DP kann zusätzlich zugelassen werden. Dies variiert jedoch je nach Proxy-Eigenschaften.
Ein offener DNS-Server kann auch eine Falle sein, wenn er gefälschte IP-Adressen zurückgibt, siehe Pharming.
Bei Schwarzen Listen (auch 'RBL'; Abkürzung für engl. Realtime Blackhole Lists) z. B. gegen Spammer, wird DNS angewendet, um abzufragen, ob ein Domainname oder eine IP-Adresse gelistet ist: Der Client schickt eine DNS-Anfrage an den Rbl-Server. Dieser antwortet mit '127.0.0.1', wenn die Adresse nicht gelistet ist, sonst mit '127.0.0.x', x>1. Der Wert von 'x' kann noch zusätzliche Informationen über die gelistete Adresse enthalten. Da der Bereich 127.0.0.0/8 für Localhost reserviert ist, sind Missdeutungen nicht möglich.
Um DNS-Namen im Internet bekannt machen zu können, muss der Besitzer die Domain, die diesen Namen enthält, registrieren. Durch eine Registrierung wird sichergestellt, dass bestimmte formale Regeln eingehalten werden und dass Domain-Namen weltweit eindeutig sind. Domain-Registrierungen werden von Organisationen (Registrars) vorgenommen, die dazu von der IANA bzw. ICANN autorisiert wurden. Registrierungen sind (von wenigen Ausnahmen abgesehen) gebührenpflichtig. Für Domains unter .de ist die DENIC zuständig.
Detaillierte Informationen finden sich unter Domain-Registrierung.
Apple hat bei der Entwicklung von Mac OS X mehrere Erweiterungen am DNS vorgenommen, welche die umfassende Selbstkonfiguration von Diensten in LANs ermöglichen soll. Zum einen wurde Multicast DNS („mDNS“) eingeführt, das die Namensauflösungen in einem LAN ohne einen dedizierten Namensserver erlaubt. Zusätzlich wurde noch DNS-SD (für „DNS Service Discovery“) eingeführt, die die Suche („Browsing“) nach Netzwerkdiensten in das DNS beziehungsweise mDNS ermöglicht. mDNS und DNS-SD sind bisher keine offiziellen RFCs des IETF, sind aber trotzdem bereits in verschiedenen (auch freien) Implementationen verfügbar. Zusammen mit einer Reihe von anderen Techniken fasst Apple DNS-SD und mDNS unter dem Namen „Zeroconf“ zusammen, als Bestandteil von Mac OS X auch als „Rendezvous“ bzw. „Bonjour“.
Auswahl bekannter Software für Namensauflösung.
Wechseln zu: Navigation, Suche
|
HTTP (Hypertext
Transfer Protocol) |
|||||||||||||||||||||||||||||||||||||
|
Familie: |
|||||||||||||||||||||||||||||||||||||
|
Einsatzgebiet: |
Datenübertragung, |
||||||||||||||||||||||||||||||||||||
|
Port: |
80/TCP |
||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||
|
Standards: |
RFC 1945 (HTTP/1.0, 1996) RFC 2616 (HTTP/1.1, 1999) |
||||||||||||||||||||||||||||||||||||
Das Hypertext Transfer Protocol (HTTP, dt. Hypertext-Übertragungsprotokoll) ist ein Protokoll zur Übertragung von Daten über ein Netzwerk. Es wird hauptsächlich eingesetzt, um Webseiten aus dem World Wide Web (WWW) in einen Webbrowser zu laden.
HTTP gehört der sogenannten Anwendungsschicht etablierter Netzwerkmodelle an. Die Anwendungsschicht wird von den Anwendungsprogrammen angesprochen, im Fall von HTTP ist das meist ein Webbrowser. Im ISO/OSI-Schichtenmodell entspricht die Anwendungsschicht den Schichten 5–7.
HTTP ist ein zustandsloses Protokoll. Ein zuverlässiges Mitführen von Sitzungsdaten kann erst auf der Anwendungsschicht durch eine Sitzung über eine Session-ID implementiert werden.
Durch Erweiterung seiner Anfragemethoden, Header-Informationen und Statuscodes ist HTTP nicht auf Hypertext beschränkt, sondern wird zunehmend zum Austausch beliebiger Daten verwendet. Zur Kommunikation ist HTTP auf ein zuverlässiges Transportprotokoll angewiesen. Dafür wird in nahezu allen Fällen TCP verwendet.
Das Protokoll wurde 1989 von Roy Fielding, Tim Berners-Lee und anderen am CERN zusammen mit URL und HTML entwickelt, womit die Grundlage des World Wide Web geschaffen wurde.
Inhaltsverzeichnis |
Die Kommunikationseinheiten in HTTP zwischen Client und Server werden als Nachrichten bezeichnet, von denen es zwei unterschiedliche Arten gibt: die Anfrage (engl. Request) vom Client an den Server und die Antwort (engl. Response) als Reaktion darauf vom Server zum Client.
Jede Nachricht besteht dabei aus zwei Teilen, dem Nachrichtenkopf (engl. Message Header, kurz: Header oder auch HTTP-Header genannt) und dem Nachrichtenkörper (engl. Message Body, kurz: Body). Der Nachrichtenkopf enthält Informationen über den Nachrichtenkörper wie etwa verwendete Kodierungen oder den Inhaltstyp, damit dieser vom Empfänger korrekt interpretiert werden kann. Der Nachrichtenkörper enthält schließlich die Nutzdaten.
Wenn auf einer Webseite der Link zur URL http://www.example.net/infotext.html aktiviert wird, so wird an den Computer mit dem Hostnamen www.example.net die Anfrage gerichtet, die Ressource /infotext.html zurückzusenden.
Der Name www.example.net wird dabei zuerst über das DNS-Protokoll in eine IP-Adresse
umgesetzt. Zur Übertragung wird über TCP auf den Standard-Port
80 des HTTP-Servers eine HTTP-GET-Anforderung gesendet.
Anfrage:
GET /infotext.html HTTP/1.1
Host: www.example.net
Enthält der Link Zeichen, die in der Anfrage nicht erlaubt sind, werden diese %-kodiert. Zusätzliche Informationen wie Angaben über den Browser, zur gewünschten Sprache etc. können über den Header (Kopfzeilen) in jeder HTTP-Kommunikation übertragen werden. Sobald der Header mit einer Leerzeile abgeschlossen wird, sendet der Computer, der einen Web-Server (an Port 80) betreibt, seinerseits eine HTTP-Antwort zurück. Diese besteht aus den Header-Informationen des Servers, einer Leerzeile und dem tatsächlichen Inhalt der Nachricht, also dem Dateiinhalt der infotext.html-Datei. Übertragen werden normalerweise Dateien in Seitenbeschreibungssprachen wie (X)HTML und alle ihre Ergänzungen, zum Beispiel Bilder, Stylesheets (CSS), Skripte (JavaScript) usw., die meistens von einem Browser in einer lesbaren Darstellung miteinander verbunden werden. Prinzipiell kann jede Datei in jedem beliebigen Format übertragen werden, wobei die „Datei“ auch dynamisch generiert werden kann und nicht auf dem Server als physische Datei vorhanden zu sein braucht (z. B. bei Anwendung von CGI, SSI, JSP, PHP und ASP.NET).
Antwort:
HTTP/1.1 200 OK
Server: Apache/1.3.29 (Unix) PHP/4.3.4
Content-Length: (Größe von infotext.html in Byte)
Content-Language: de (nach RFC 3282 sowie RFC 1766)
Content-Type: text/html
Connection: close (Inhalt von infotext.html)
Der Server sendet eine Fehlermeldung zurück, wenn die Information aus irgendeinem Grund nicht gesendet werden kann. Der genaue Ablauf dieses Vorgangs (Anfrage und Antwort) ist in der HTTP-Spezifikation festgelegt.
Derzeit werden zwei Protokollversionen, HTTP/1.0 und HTTP/1.1, verwendet. Bei HTTP/1.0 wird vor jeder Anfrage eine neue TCP-Verbindung aufgebaut und nach Übertragung der Antwort standardmäßig vom Server wieder geschlossen. Sind in ein HTML-Dokument beispielsweise zehn Bilder eingebettet, so werden insgesamt elf TCP-Verbindungen benötigt, um die Seite auf einem grafikfähigen Browser aufzubauen. Bei HTTP/1.1 kann ein Client durch einen zusätzlichen Headereintrag (Keep-Alive) den Wunsch äußern, keinen Verbindungsabbau durchzuführen, um die Verbindung erneut nutzen zu können (persistent connection). Die Unterstützung auf Serverseite ist jedoch optional und kann in Verbindung mit Proxies Probleme bereiten. Mittels HTTP-Pipelining können in der Version 1.1 mehrere Anfragen und Antworten pro TCP-Verbindung gesendet werden. Für das HTML-Dokument mit zehn Bildern wird so nur eine TCP-Verbindung benötigt. Da die Geschwindigkeit von TCP-Verbindungen zu Beginn durch Verwendung des Slow-Start-Algorithmus recht gering ist, wird so die Ladezeit für die gesamte Seite signifikant verkürzt. Zusätzlich können bei HTTP/1.1 abgebrochene Übertragungen fortgesetzt werden.
Bei HTTP gehen Informationen aus früheren Anforderungen verloren (zustandsloses Protokoll). Über Cookies in den Header-Informationen können aber Anwendungen realisiert werden, die Statusinformationen (Benutzereinträge, Warenkörbe) zuordnen können. Dadurch werden Anwendungen möglich, die Status- bzw. Sitzungseigenschaften erfordern. Auch eine Benutzerauthentifizierung ist möglich. Normalerweise kann die Information, die über HTTP übertragen wird, auf allen Rechnern und Routern gelesen werden, die im Netzwerk durchlaufen werden. Über HTTPS kann die Übertragung aber verschlüsselt erfolgen.
Eine Möglichkeit zum Einsatz von HTTP/1.1 in Chats ist die Verwendung des MIME-Typs multipart/replace, bei dem der Browser nach Sendung eines Boundary-Codes und einem neuerlichen Content-Length-Headerfeld sowie eines neuen Content-Type-Headerfeldes den Inhalt des Browserfensters neu aufbaut.
Mit HTTP/1.1 ist es neben dem Abholen von Daten auch möglich, Daten zum Server zu übertragen. Mit Hilfe der PUT-Methode können so Webdesigner ihre Seiten direkt über den Webserver per WebDAV publizieren, und mit der DELETE-Methode ist es ihnen möglich, Daten vom Server zu löschen. Außerdem bietet HTTP/1.1 eine TRACE-Methode, mit der der Weg zum Webserver verfolgt und überprüft werden kann, ob die Daten korrekt dorthin übertragen werden. Damit ergibt sich die Möglichkeit, den Weg zum Webserver über die verschiedenen Proxies hinweg zu ermitteln, ein traceroute auf Anwendungsebene.
GET
ist die gebräuchlichste Methode. Mit ihr wird eine Ressource (z. B. eine Datei) unter Angabe eines URI vom Server angefordert. Als Argumente in dem URI können also auch Inhalte zum Server übertragen werden. Die Länge des URIs ist je nach eingesetztem Server begrenzt und sollte aus Gründen der Abwärtskompatibilität nicht länger als 255 Bytes sein.
POST
schickt unbegrenzte, je nach physikalischer Ausstattung des eingesetzten Servers, Mengen an Daten zur weiteren Verarbeitung zum Server, diese werden als Inhalt der Nachricht übertragen und können beispielsweise aus Name-Wert-Paaren bestehen, die aus einem HTML-Formular stammen. Es können so neue Ressourcen auf dem Server entstehen oder bestehende modifiziert werden. POST-Daten werden im Allgemeinen nicht von Caches zwischengespeichert. Zusätzlich können bei dieser Art der Übermittlung auch Daten wie in der GET-Methode an den URI gehängt werden.
HEAD
weist den Server an, die gleichen HTTP-Header wie bei GET, nicht jedoch den eigentlichen Dokumentinhalt (Body) zu senden. So kann zum Beispiel schnell die Gültigkeit einer Datei im Browsercache geprüft werden.
PUT
dient dazu eine Ressource (z. B. eine Datei) unter Angabe des Ziel-URIs auf einen Webserver hochzuladen.
DELETE
löscht die angegebene Ressource auf dem Server. Heute ist das, ebenso wie PUT, kaum implementiert bzw. in der Standardkonfiguration von Webservern abgeschaltet, beides erlangt jedoch mit RESTful Web Services und der HTTP-Erweiterung WebDAV neue Bedeutung.
TRACE
liefert die Anfrage so zurück, wie der Server sie empfangen hat. So kann überprüft werden, ob und wie die Anfrage auf dem Weg zum Server verändert worden ist – sinnvoll für das Debugging von Verbindungen.
OPTIONS
liefert eine Liste der vom Server unterstützen Methoden und Features.
CONNECT
wird von Proxyservern implementiert, die in der Lage sind, SSL-Tunnel zur Verfügung zu stellen.
RESTful Web Services verwenden die unterschiedlichen Request-Methoden zur Realisierung von Web-Services. Insbesondere werden dafür die HTTP-Request-Methoden GET, POST, PUT und DELETE verwendet.
WebDAV fügt folgende Methoden zu HTTP hinzu: PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK
Häufig will der Nutzer einer Website spezielle Informationen senden. Dazu stellt HTTP prinzipiell zwei Möglichkeiten zur Verfügung:
Die zu übertragenden Daten müssen ggf. URL-kodiert werden, d. h. reservierte Zeichen müssen mit „%<Hex-Wert>“ und Leerzeichen mit „+“ dargestellt werden.
Hier werden die Parameter-Wertepaare durch das Zeichen ? in der URL eingeleitet. Oft wird diese Vorgehensweise gewählt, um eine Liste von Parametern zu übertragen, die die Gegenstelle bei der Bearbeitung einer Anfrage berücksichtigen soll. Häufig besteht diese Liste aus mit dem Zeichen & getrennten Wertepaaren, die je aus einem Parameternamen, dem Zeichen = und dem Wert des Parameters bestehen. Seltener wird das Zeichen ; zur Trennung von Einträgen der Liste benutzt.[1]
Ein Beispiel: Auf der Startseite von Wikipedia wird in das Eingabefeld der Suche „Katzen“ eingegeben und auf die Schaltfläche „Artikel“ geklickt. Der Browser sendet folgende oder ähnliche Anfrage an den Server:
GET /wiki/Spezial:Search?search=Katzen&go=Artikel HTTP/1.1
Host: de.wikipedia.org
…
Dem Wikipedia-Server werden zwei Wertepaare übergeben:
|
Argument |
Wert |
|
search |
Katzen |
|
go |
Artikel |
Diese Wertepaare werden in der Form
Argument1=Wert1&Argument2=Wert2
mit vorangestelltem ? an
die geforderte Seite angehängt.
Dadurch „weiß“ der Server, dass der Nutzer den Artikel Katzen betrachten will. Der Server verarbeitet die Anfrage, sendet aber keine Datei, sondern leitet den Browser mit einem Location-Header zur richtigen Seite weiter, etwa mit:
HTTP/1.0 302 Moved TemporarilyDate: Fri, 13 Jan 2006 15:12:44 GMTLocation: http://de.wikipedia.org/wiki/Katzen…
Der Browser befolgt diese Anweisung und sendet aufgrund der neuen Informationen eine neue Anfrage, etwa:
GET /wiki/Katzen HTTP/1.1
Host: de.wikipedia.org
…
Und der Server antwortet und gibt den Artikel Katzen aus, etwa:
HTTP/1.0 200 OKDate: Fri, 13 Jan 2006 15:12:48 GMTLast-Modified: Tue, 10 Jan 2006 11:18:20 GMTContent-Language: deContent-Type: text/html; charset=utf-8 Die Katzen (Felidae) sind eine Familie aus der Ordnung der Raubtiere (Carnivora)
innerhalb der Überfamilie der Katzenartigen (Feloidea).
…
Der Datenteil ist meist länger, hier soll nur das Protokoll betrachtet werden.
Da sich die Daten nicht in der URL befinden, können per POST große Datenmengen, z. B. Bilder, übertragen werden.
Im folgenden Beispiel wird wieder der Artikel Katzen angefordert,
doch diesmal verwendet der Browser aufgrund eines modifizierten HTML-Codes (method="POST") eine
POST-Anfrage. Die Variablen stehen dabei nicht in der URL, sondern gesondert im
Body-Teil, etwa:
POST /wiki/Spezial:Search HTTP/1.1
Host: de.wikipedia.org
Content-Type: application/x-www-form-urlencoded
Content-Length: 24