text: Debian [] ist ein gemeinschaftlich entwickeltes freies Betriebssystem. Debian GNU/Linux basiert auf den grundlegenden Systemwerkzeugen des GNU-Projektes sowie dem Linux-Kernel. Die aktuelle Version ist Debian 12 „Bookworm“. Debian bietet eine große Auswahl an Anwendungsprogrammen und Werkzeugen; derzeit sind es etwas mehr als 64.000 Programmpakete. Debian wurde im August 1993 von Ian Murdock ins Leben gerufen und wird seitdem aktiv weiterentwickelt. Heute hat das Projekt über 1000 offizielle Entwickler. Es ist eine der ältesten, einflussreichsten und am weitesten verbreiteten GNU/Linux-Distributionen. Viele weitere Linux-Distributionen basieren auf Debian. Das heute bekannteste Debian-GNU/Linux-Derivat ist Ubuntu, von dem wiederum das ebenfalls verbreitete Linux Mint abstammt. Projekt Debian-Entwickler kann jeder werden, der den sogenannten New-Member-Prozess erfolgreich durchläuft: Bewerber werden hinsichtlich ihrer Kenntnisse und Fähigkeiten geprüft, außerdem wird sichergestellt, dass sie mit der Philosophie des Projektes vertraut sind. Der Name des Betriebssystems leitet sich von den Vornamen des Debian-Gründers Ian Murdock und seiner damaligen Freundin und späteren Ehefrau Debra Lynn ab. Bereits wenige Monate nach der Gründung, im Mai 1994, entschied sich das Projekt zu einer Änderung des offiziellen Namens von Debian Linux zu Debian GNU/Linux, womit es der Auffassung der Free Software Foundation folgte, dass das häufig als Linux bezeichnete Betriebssystem eine Variante des GNU-Systems sei (zu den Hintergründen siehe GNU/Linux-Namensstreit). Da Debian in Version 6.0 (Squeeze) und 7 (Wheezy) in zwei Varianten – GNU/Linux und GNU/kFreeBSD – verfügbar ist, wird seitdem nur noch in Bezug auf diese der jeweilige Namenszusatz genannt; allgemein wird also nur noch von Debian gesprochen. Das System ist bekannt für seine Paketverwaltung dpkg und deren Frontend APT. Mit diesen ist es möglich, alte Versionen von Debian GNU/Linux durch aktuelle zu ersetzen oder neue Softwarepakete zu installieren. Sie sind ebenfalls dafür zuständig, alle von einem Programm benötigten Abhängigkeiten aufzulösen, also alle Programmpakete zu laden und zu installieren, welche die gewünschte Software benötigt. Geschichte 1993 bis 1998 Am 16. August 1993 wurde von Ian Murdock das „Debian Linux Release“ angekündigt. Er hatte versucht, SLS, das eine der ersten umfassenden Linux-Distributionen war, zu nutzen. Da er jedoch mit deren Qualität unzufrieden war, konzipierte er sein eigenes System, ließ sich aber von SLS inspirieren. Im selben Jahr veröffentlichte er auch das Debian-Manifest, eine Zusammenstellung seiner Sichtweise zu Debian. Im Vordergrund stand hier eine offene Entwicklung „im Geiste von Linux und GNU“. Bis 1995 veröffentlichte das Projekt die ersten Entwicklungsversionen mit den Versionsnummern 0.9x. In dieser Zeit wurde es auch von der Free Software Foundation gesponsert und zählte etwa 60 Entwickler. 1996 wurde letztlich die erste stabile Version 1.1 veröffentlicht. Weil ein CD-ROM-Verkäufer versehentlich eine Vorversion unter der Nummer 1.0 veröffentlicht hatte, kam es – um Verwirrung zu vermeiden – nie zu einer tatsächlichen Version 1.0. Im April 1996 wurde Murdock von Bruce Perens als Leiter des Projekts abgelöst. In den darauffolgenden Jahren wechselte diese Position einige Male. Am 17. Juni 1996 folgte mit Buzz (Version 1.1) das erste Release, welches einen Aliasnamen trug. Alle weiteren Veröffentlichungen wurden ebenfalls mit einem solchen versehen, wobei sich dieser immer nach einer Figur aus dem Film Toy Story bzw. seinen Fortsetzungen richtet. 1997 wurde nach vorheriger Diskussion der Debian-Gesellschaftsvertrag ratifiziert. Am 24. Juli 1998 wurde die Version 2.0 Hamm veröffentlicht, welche erstmals für mehrere Architekturen zur Verfügung stand. Das Projekt umfasste zu diesem Zeitpunkt 1500 Pakete und 400 Entwickler. 1999 bis 2004 Es folgten weitere 2.x-Veröffentlichungen mit neuen Portierungen zu anderen Architekturen sowie einer steigenden Zahl von Paketen. Besonders hervorzuheben ist die Entwicklung von APT. Auch entstand mit Debian GNU/Hurd die erste Portierung zu einem Nicht-Linux-Kernel. Im Jahr 2000 wurde der Testing-Zweig gegründet. In der nachfolgenden Zeit wurde die Debian-Website in 20 Sprachen übersetzt. Es kam zur Gründung der Unterprojekte Debian-Junior und Debian-Med, die sich an Kinder bzw. medizinische Forschung und Praxis richteten. Im gleichen Jahr fand auch erstmals die Entwicklerkonferenz DebConf statt, welche seitdem jährlich an unterschiedlichen Orten abgehalten wird. Die Version 3.0 Woody vom 19. Juli 2002 enthielt erstmals das K Desktop Environment, nachdem die Lizenzproblematik von Qt geklärt war. Das Projekt war auf 900 Entwickler und 8500 Binärpakete angewachsen. Die offizielle Distribution bestand aus 7 CDs. Seit 2005 Erst knappe drei Jahre später, am 6. Juni 2005, kam es zur Veröffentlichung von Version 3.1 Sarge. Der lange Zeitraum brachte dem Projekt einige Kritik ein, war aber vor allem in der Neuentwicklung eines Installers für elf verschiedene Architekturen begründet. Mit Ubuntu entstand zwischenzeitlich auch das heute bedeutendste Debian-Derivat. Sarge enthielt etwa 15.400 Pakete und benötigte damit 14 CDs. Es beteiligten sich etwa 1500 Entwickler an dieser Veröffentlichung. Neben der Masse an aktualisierten und neu hinzugekommenen Paketen ist vor allem das neu geschriebene Installationsprogramm hervorzuheben, das in 40 Sprachen übersetzt wurde. Erstmals wurde auch OpenOffice.org aufgenommen. 2006 wurde in Oaxtepec, Mexiko, die siebte DebConf abgehalten. Zudem wurde nach dem Namensstreit zwischen Debian und Mozilla seitens Debian das entsprechende Paket des Mozilla Firefox in Iceweasel, sowie das von Mozilla Thunderbird in Icedove umbenannt. Am 8. April 2007 wurde von etwa 1000 Entwicklern Version 4.0 Etch veröffentlicht. Diese enthielt rund 18.200 Binärpakete. Im Februar 2009 folgte 5.0 Lenny, und im Februar 2011 wurde Lenny oldstable und 6.0 Squeeze mit über 29.000 Softwarepaketen als stable veröffentlicht. Ab Version 6.0 „Squeeze“ war mit Debian GNU/kFreeBSD die erste offizielle Portierung auf einen anderen Betriebssystemkern – jenen des FreeBSD-Projektes – als Technologievorschau verfügbar. Am 4. Mai 2013 wurde mit Wheezy die Version 7 als „stable“ gesetzt. Diese enthielt erstmals LibreOffice. Für Version 7 „Wheezy“ wurde die Veröffentlichung von Debian GNU/Hurd, einer offiziellen Portierung auf den GNU Hurd, diskutiert. Dies wurde jedoch verworfen. Am 25. April 2015 folgte ihr Version 8, Codename Jessie, bei der das init-System vom bisher benutzten SysVinit auf das kontrovers diskutierte systemd umgestellt wurde. Auf die FreeBSD-Portierung wurde in Version 8 verzichtet. Die neunte Ausgabe von Debian, Codename Stretch, erschien am 17. Juni 2017. Augenfälligste Neuerung war die Rückkehr von Firefox und Thunderbird. Am 6. Juli 2019 wurde Debian 10 mit dem Codenamen Buster veröffentlicht. Es basiert auf dem Linux-Kernel 4.19. Wichtige Neuerungen sind das Mandatory Access Control (MAC) Framework AppArmor, das bei Neuinstallationen aktiviert ist, sowie das Container-Verwaltungswerkzeug Docker. In Debian 10 sind erstmals der Compiler für die Programmiersprache Rust und in Rust geschriebene Programme enthalten. Der Paketumfang wuchs gegenüber dem Vorgänger signifikant und liegt nun bei über 57.000 Paketen. Seit 2020 Debian 11 Bullseye erschien am 14. August 2021. Zu den Änderungen gehören die native Unterstützung für das Dateisystem ExFAT, treiberloses Drucken und die standardmäßige Passwort-Verschlüsselung mit yescrypt. Debian 12 Bookworm erschien am 10. Juni 2023. Die auffälligste Neuerung ist die Integration von unfreier (proprietärer) Firmware in die offiziellen Installationsabbilder. Grundlage dafür ist eine bis Anfang Oktober 2022 stattgefundene Abstimmung, bei der aus insgesamt sechs Varianten abgestimmt werden konnte, wie das Projekt zukünftig mit proprietärer Firmware umgeht. Die Abstimmung endete mit dem Ergebnis, zukünftig proprietäre Firmware in die offiziellen Abbilder zu integrieren. Dabei soll der Installations-Assistent prüfen, ob proprietäre Treiber notwendig sind und diese bei Bedarf automatisch laden. Dies ist die neue Standard-Einstellung, der Nutzer muss dies nicht gesondert aktivieren. Wer dagegen keine unfreie Firmware nutzen möchte, kann dieses neue Verhalten abschalten. Innerhalb von Debian wurde dies kontrovers diskutiert, da die GNU/Linux-Distribution sich für freie Software positioniert und bis dahin in den offiziellen Abbildern keine proprietäre Firmware auslieferte. Wer diese nutzen wollte, musste sie entweder händisch installieren oder inoffizielle Installationsmedien verwenden. Debian 12 ist die erste stabile Version, bei der diese Entscheidung umgesetzt wurde. Darüber hinaus erhält Debian 12 über 11.000 neue Pakete in den offiziellen Paketquellen. 6.000 Pakete wurden aus unterschiedlichen Gründen entfernt. Insgesamt bietet die Distribution mit insgesamt mehr als 64.000 Paketen ein umfangreicheres Softwareangebot als der Vorgänger. 67 % der bereits vorhandenen Pakete haben zudem eine Aktualisierung auf neuere Versionen erhalten. Die Version des Linux-Kernels springt von 5.10 auf 6.1. Organisation Das Debian-Projekt konstituiert sich durch die Debian-Verfassung. Sie regelt die demokratische Organisationsstruktur mit regelmäßigen Wahlen. Darüber hinaus verpflichtet sich das Projekt mit dem Gesellschaftsvertrag Debian Social Contract zu freier Software. Seit dem 26. April 2004 ist die Version 1.1 des Gesellschaftsvertrages gültig. Die eigentliche inhaltliche Änderung besagt, dass alle Komponenten des Debian-Systems (im Hauptzweig main) frei sein müssen, nicht mehr nur die Software. Die Debian-Richtlinien für freie Software beziehen sich also nicht mehr nur auf freie Software, sondern allgemein auf freie Werke. Da diese Auswirkungen einer als „editoriell“ bezeichneten Änderung für viele Entwickler überraschend war, wurde in einer zusätzlichen Abstimmung im Juli 2004 beschlossen, dass diese Änderung erst nach dem Release von Sarge im Juni 2005 wirksam wird. Aktueller Leiter des Debian-Projekts ist Jonathan Carter. Der Posten wird einmal im Jahr per Wahl neu vergeben. Alle Wahlen und Abstimmungen erfolgen elektronisch (mit Hilfe einer digitalen Signatur) nach der Schulze-Methode. Als eine Dachorganisation für Debian und weitere Freie-Software-Projekte wurde 1997 Software in the Public Interest gegründet. Debian-Gesellschaftsvertrag Der Debian-Gesellschaftsvertrag () ist eine vom Debian-Projekt beschlossene öffentliche Richtlinie, die Grundlagen regelt, wie die freie Software Debian hergestellt, verteilt und betreut wird. Der Gesellschaftsvertrag geht auf einen Vorschlag von Ean Schuessler zurück. Bruce Perens entwarf eine erste Version des Dokumentes, das dann mit anderen Debian-Entwicklern im Juni 1997 verfeinert wurde, bevor es als öffentliche Richtlinie akzeptiert wurde. Version 1.0 wurde am 5. Juli 1997 ratifiziert. Am 26. April 2004 wurde die überarbeitete Version 1.1 ratifiziert. Sie ersetzt seitdem ihren Vorgänger. Ein besonders bedeutender, auch über das Debian-Projekt hinaus genutzter Teil des Vertrages sind die Debian-Richtlinien für freie Software (DFSG). Die Gemeinschaft um die Etablierung des Begriffes Open Source in der Öffentlichkeit verwendete diese als Grundlage, um ihre Definition von Open Source zu verfassen. Bruce Perens verallgemeinerte die Richtlinien, indem er Debian aus dem Text strich, um The Open Source Definition (dt. Die Open Source Definition) zu schaffen. Sie wird seitdem von der Open Source Initiative (OSI) verwendet. Mit der Zeit haben sich hier allerdings einige Unterschiede ergeben. Die im Vertrag festgehaltene Verpflichtung zur Bereitstellung von freier Software wird vom Debian-Projekt sehr ernst genommen. Zentrale Diskussionen im Linux-Umfeld werden maßgeblich vom Projekt bestimmt, wie die konsequent freie Dokumentation der Programme (Diskussion über die GFDL) oder die Vermeidung von Markennamen, weil ein Hersteller darüber das Projekt beeinflussen kann. Eine Auswirkung dieser Politik war der Namensstreit zwischen Debian und Mozilla, der zu einer Umbenennung der Anwendung Firefox in Iceweasel innerhalb von Debian führte. Software-Sicherheit Softwareprobleme werden öffentlich behandelt, so auch sämtliche Sicherheitsprobleme. Aspekte der Sicherheit werden öffentlich auf der debian-security-announce-Mailingliste diskutiert. Debians Sicherheitsgutachten werden über eine öffentliche Mailingliste gesendet (sowohl innerhalb als auch außerhalb) und auf einem öffentlichen Server bekanntgegeben. Von dieser Verfahrensweise verspricht man sich ein schnelleres Auffinden von Sicherheitslücken und damit die Möglichkeit, diese eher beheben zu können. Die entgegengesetzte Herangehensweise des Security through obscurity wird dagegen als unpraktikabel angesehen. Die Tatsache, dass die Weiterentwicklung der Distribution öffentlich sichtbar unter Beteiligung einer Vielzahl von Personen geschieht, erfordert besondere Sicherheitsmaßnahmen. Beispielsweise werden Änderungen an Paketen grundsätzlich mit einem verifizierbaren Schlüssel digital signiert. Beim Anwender wird dann vor der Installation die Gültigkeit der Signatur überprüft. Diese Maßnahme soll es Dritten erschweren, schädliche Software in Debian-Pakete einzuschleusen. Die Paketbetreuer passen die Sicherheitsaspekte ihrer jeweiligen Software an die allgemeinen Grundsätze von Debian an. Daher sind Dienste nach der Installation oft „sicher“ voreingestellt, was von einem Benutzer als „Einschränkung“ empfunden werden kann. Dennoch versucht Debian, Sicherheitsaspekte und einfache Administration abzuwägen. Zum Beispiel werden Dienste wie ssh und ntp nicht inaktiv installiert, wie es bei den Distributionen der BSD-Familie üblich ist. Wenn ein Sicherheitsproblem in einem Debian-Paket entdeckt wurde, wird es zusammen mit einer Einschätzung der dadurch entstehenden Gefahr direkt veröffentlicht. Parallel wird so schnell wie möglich ein Sicherheitsupdate dieses Pakets vorbereitet und auf speziellen Servern veröffentlicht. Kritische Sicherheitslücken werden auf diese Weise häufig innerhalb von Stunden geschlossen. Die von Debian angepasste Implementierung des für die Schlüsselerstellung zuständigen Zufallsgenerators der OpenSSL-Bibliothek arbeitete von September 2006 bis 13. Mai 2008 mit einer erheblichen Sicherheitslücke. Die generierten geheimen Schlüssel konnten abgeschätzt und damit in kurzer Zeit (vor-)berechnet werden (1024- und 2048-Bit-Schlüssel in ungefähr zwei Stunden). Insbesondere OpenSSH und die sichere Kommunikation in Webbrowsern waren davon betroffen – GnuPG hingegen nicht. Das Sicherheitsrisiko besteht weiterhin für alle RSA-Schlüssel, die in diesem Zeitraum auf betroffenen Systemen erstellt wurden und seit der Aktualisierung der Bibliothek nicht neu erstellt wurden. Auch alle DSA-Schlüssel, die jemals von einem Rechner (Client) mit fehlerhaftem Zufallszahlengenerator verwendet wurden, sind seitdem unsicher, selbst wenn diese ursprünglich auf einem Rechner mit korrekt arbeitendem Zufallszahlengenerator erstellt wurden. Im Januar 2019 wurde in dem Paketmanagertool von Debian („apt“ bzw. „apt-get“) eine Sicherheitslücke entdeckt, die es einem Man-in-the-Middle-Angreifer ermöglichte, Code bei einem Update auszuführen. Der Entdecker dieser Sicherheitslücke plädierte, auch vor dem Hintergrund, dass dies nicht die einzige Sicherheitslücke mit diesen Auswirkungen in apt war, und solche Lücken immer passieren können, dafür, dass Debian in Zukunft standardmäßig HTTPS für Updates mit apt statt HTTP nutzt, da HTTPS die Integrität der gesamten Kommunikation mit dem Update-Server absichert. Dies wurde in der Vergangenheit mit dem Hinweis abgelehnt, dass apt selbst eine Verifizierung der Pakete vornimmt was soweit auch korrekt ist, allerdings würde es bei Sicherheitslücken wie dieser dennoch zu einem Sicherheitsgewinn kommen, da die Sicherheitslücke dann nicht mehr von allen Man-in-the-Middle-Angreifern, die in die Verbindung eingreifen können, ausnutzbar ist, sondern nur noch von den jeweils gewählten Debian-Update-Mirrors des Gerätes. Veröffentlichungszyklus Flussdiagramm des Lebenszyklus eines Paketes von Debian Von Debian werden zu jedem Zeitpunkt mehrere Varianten (Releases) parallel angeboten: (‚stabil‘), (‚Erprobung‘) und (‚instabil‘). Nach der Veröffentlichung jeder stable-Version wird die vorige stable-Version als (‚alt-stabil‘) für mindestens ein Jahr weitergeführt. Experimental experimental ist eine Vorstufe zu unstable. In experimental werden Änderungen ausprobiert, die umfangreiche Auswirkungen auf das gesamte System haben können. So wurde der Übergang des X Window Systems von XFree86 auf X.Org in experimental erprobt. experimental ist keine vollständige Sammlung von Paketen. Es enthält nur, was gerade einer besonderen Untersuchung bedarf. Unstable unstable ist der erste Anlaufpunkt für neue Versionen von Paketen und Programmen, bevor sie in testing integriert werden. Dort werden sie auf Fehler geprüft. unstable ist weniger für den produktiven Einsatz gedacht als für das Testen neuer Paketversionen. Wer unstable verwendet, muss damit rechnen, mit Programmfehlern konfrontiert zu werden, die aus mangelndem Zusammenspiel mit anderen Softwarekomponenten resultieren. Wurden innerhalb der Testzeit (meistens zehn, gelegentlich fünf, bei dringenden Paketen zwei oder sogar null Tage) keine schweren, für das Release entscheidenden Fehler („release-critical bugs“, „RC-Bugs“) gefunden und sprechen keine anderen Gründe wie das Zurückhalten einzelner Pakete durch das Release-Team oder nichterfüllte Abhängigkeiten dagegen, wird das Paket in testing aufgenommen. Testing testing ist der Kandidat für die nächste stable. Direkt nach der Veröffentlichung einer neuen stable sind testing und stable identisch. In testing werden nach und nach Aktualisierungen und neue Anwendungspakete eingebunden. testing entwickelt sich also ständig weiter. Dabei bleibt das System im Normalfall voll einsatzfähig. Die installierten Pakete können täglich auf Aktualisierungen geprüft und diese gegebenenfalls aufgespielt werden. Dieses Verfahren wird häufig für Arbeitsplatzrechner genutzt. Einige Monate vor der Veröffentlichung einer neuen stable-Version wird testing in Bezug auf neue Programme und Programmversionen eingefroren („freeze“). Änderungen beziehen sich dann in der Regel nur noch auf die Beseitigung von beim Test aufgetretenen Fehlern. Die Veröffentlichung eines neuen stable erfolgt erst dann, wenn alle als „schwer“ eingestuften Fehler behoben sind. Der aktuelle Stand und der zeitliche Verlauf der Anzahl dieser Fehler lässt sich in einer automatisch aktuell gehaltenen Webseite ablesen. Die ständigen Änderungen an testing bergen das Risiko von Installationsfehlern, die das laufende System beeinträchtigen können. Wie dieses Risiko im Vergleich zu den ebenfalls nicht fehlerfreien statischen Veröffentlichungen anderer Distributionen einzuschätzen ist, ist Gegenstand emotionaler Diskussionen. Stable stable ist die jeweils aktuelle offizielle Version. Debian veröffentlichte seit 2000 etwa alle zwei Jahre eine neue stable. Mit Ausnahme von Sicherheitsaktualisierungen wird an den in ihr enthaltenen Paketen nichts mehr verändert. stable gilt daher als geeigneter Kandidat für Server-Systeme, die lange Zeit zuverlässig laufen müssen. Vor der Veröffentlichung werden für einige Monate mit hoher Priorität die als schwerwiegend eingestuften Fehlfunktionen beseitigt. In dieser Zeit werden keine großen Versionssprünge in Paketen oder neue Pakete akzeptiert. Kurz vor einer Debian-Veröffentlichung repräsentiert stable in Bezug auf Software-Versionen daher den Stand von vor etwa einem halben Jahr. Oldstable oldstable ist der Vorgänger der jeweils aktuellen stable, solange Sicherheitsupdates zur Verfügung gestellt werden. Debian empfiehlt zwar, mit der jeweils aktuellen stable zu arbeiten, unterstützt oldstable aber noch mindestens ein weiteres Jahr mit Sicherheitsaktualisierungen. Ausgenommen davon sind Browser wie Mozilla Firefox oder Chromium, die nur für 6 Monate mit Sicherheitsupdates versorgt werden. Langzeitunterstützung (engl.: long-term support, kurz: LTS) Als im Frühjahr 2014 die reguläre Unterstützung der Version 6.x Squeeze endete, folgte erstmals Langzeitunterstützung, englisch long term support (LTS), für die meisten Pakete auf den Architekturen i386 und amd64 bis Februar 2016 durch das neu gegründete Projekt Debian Long Term Support (debian-lts). Dieses hat sich zum Ziel gesetzt, zukünftig alle Versionen für mindestens 5 Jahre mit Sicherheitsupdates zu versorgen. Seit Ende Mai 2018 und dem Ende der Unterstützung von Debian 7 Wheezy bietet das Unternehmen Freexian eine erweiterte Langzeitunterstützung, englisch Extended Long Term Support (ELTS), für ausgewählte Pakete an. Dieses kommerzielle Angebot soll mindestens 1 Jahr aktiv sein, es handelt sich dabei um kein offizielles Debianprojekt, Debians Infrastruktur ist nicht involviert. Zeitabstand zwischen den Releases Zeitweise lagen große Zeiträume zwischen den Debian-Veröffentlichungen. Darauf gab es verschiedene Reaktionen, etwa wurden Pakete verschiedener Veröffentlichungen gemischt. Dies wird jedoch unmöglich, wenn sich zentrale Teile des Systems zu stark unterscheiden. So gab es zwischen Sarge und Etch eine Änderung der glibc-ABI, die für die meisten Pakete eine Aktualisierung nötig machte. Für einige Aufgaben wie Spam- und Virenerkennung bot Debian zeitweise eine Paketquelle namens „volatile“ (unbeständig) an, die mit Squeeze durch eine neue Paket-Quelle „updates“ ersetzt wurde. Für einige Programme kann man sich auch mit sogenannten Backports behelfen. Das sind Pakete von neueren Programmversionen, die für eine alte Debian-Veröffentlichung kompiliert wurden. Dadurch werden nur die Programme aktualisiert, auf die die jeweiligen Backports ausgelegt sind. Eine weitere Alternative bieten Container-Umgebungen wie Flatpak. Codenamen und deren Herkunft Jede Version hat einen Codenamen, der von Charakteren des Films Toy Story oder seinen Fortsetzungen stammt. Derzeit ist „Bookworm“ (Debian 12) der Name des stable-Zweigs. Der Codename von unstable ist seit Dezember 2000 gleichbleibend „Sid“. Dies ist eine Anspielung auf den Jungen, der im Film Toy Story mehrfach Spielzeuge kaputtgemacht hat. Erstmals erhielt Debian mit Veröffentlichung der Version 1.1 (17. Juni 1996) einen Codenamen. Zu diesem Zeitpunkt hatte Bruce Perens die Leitung des Projekts von Ian Murdock übernommen. Perens arbeitete beim Filmstudio Pixar, das die Toy-Story-Filme produziert. Softwarekategorien Innerhalb eines Releases enthält die Abteilung main das eigentliche Debian-System. main besteht komplett aus freier Software und sonstigen Werken gemäß DFSG. Es ist möglich, allein mit Paketen aus main ein funktionstüchtiges System zu installieren. non-free enthält Software, die proprietär ist, und contrib beherbergt Software, die selbst frei ist, jedoch ohne Software aus non-free nicht lauffähig ist, wie früher Java-Programme, die die Java-Laufzeitumgebung von Sun Microsystems benötigten. contrib und non-free sind kein offizieller Teil von Debian, werden jedoch unter anderem durch Bereitstellung der für main üblichen Infrastruktur unterstützt. Unterstützte Architekturen Debian unterstützt eine Anzahl verschiedener Hardware-Architekturen. Dabei wird zwischen offiziellen Release-Architekturen und Ports unterschieden. Um als Release-Architektur offiziell unterstützt zu werden, muss eine Anzahl Bedingungen erfüllt sein. So ist ein ausreichend großes Team nötig, eine ausreichende Anzahl entsprechender Rechner muss dem Debian-Projekt zum Erstellen von Paketen zur Verfügung stehen, und fast alle Pakete müssen auf der Architektur gebaut werden können und die Software benutzbar sein. Jede Architektur wird zunächst als Port unterstützt und kann zu einer offiziell unterstützten Architektur aufgewertet werden. Umgekehrt kann eine offizielle Release-Architektur zum Port abgewertet werden, wenn die Anforderungen an Release-Architekturen nicht mehr erfüllt sind. Für Ports gibt es keine stable-Veröffentlichungen, sondern es existiert nur die unstable-Variante. Versionsgeschichte Verbreitung Laut einer Online-Umfrage von Heise online im Februar 2009 war Debian Linux zu dieser Zeit mit 47 % (Mehrfachnennung möglich) das am meisten verwendete freie Server-Betriebssystem in deutschen Unternehmen. Bei den freien Desktop-Betriebssystemen belegte Debian Linux mit einer Verbreitung von 29,9 % den zweiten Platz hinter Ubuntu (60,8 %), das auch von Debian abstammt – dicht gefolgt von openSUSE (28,8 %, Stand Februar 2009). Debian ist eine der häufigsten Linux-Distributionen auf Webservern. Debian wird neben Scientific Linux, Red Hat Enterprise Linux und Windows auf der Internationalen Raumstation (ISS) eingesetzt. Nutzung durch öffentliche Einrichtungen Die Regierung der spanischen Region Extremadura hat von 2002 bis 2011 die Debian-basierte Distribution GNU/LinEx entwickelt und in den Schulen und im öffentlichen Gesundheitssystem eingeführt. Anfang 2012 gab die Regionalverwaltung bekannt, dass LinEx eingestellt werde, kurz darauf kündigte sie an, dass nun 40.000 Arbeitsplätze der Verwaltung auf Debian umgestellt würden. Die Stadt München ist mit ihren Debian-basierten Betriebssystemen LiMux zwischen 2006 und 2013 auf freie Software umgestiegen, plant jedoch eine Rückkehr zu Windows-Systemen bis 2020. Das deutsche Bundesamt für Sicherheit in der Informationstechnik setzte ab 2008 unter anderem Debian auf Desktopsystemen ein. Auch Wien bot von 2004 bis 2009 mit Wienux der Stadtverwaltung eine Debian-basierte freie Alternative an. 2009 wurde eine angepasste Version von DebianEdu (auch bekannt als Skolelinux) in einer Pilotphase an elf Schulen im Land Rheinland-Pfalz getestet, nachdem das System bereits in Hamburg in etlichen Schulen eingeführt worden war. Kernel Das Debian-Projekt beabsichtigt, neben der Linux-Distribution Debian GNU/Linux mit Linux-Kernel auch Varianten des GNU-Systems mit anderen Kernen zu unterstützen. Mit Squeeze und Debian GNU/kFreeBSD wurde 2011 die erste Portierung auf den Kernel des FreeBSD-Betriebssystems veröffentlicht. Diese stand zunächst nur für x86-Architekturen (32-Bit: IA-32 bzw. „i386“, und 64-Bit: x64 bzw. „amd64“) zur Verfügung. Die Namensgebung Debian GNU/kFreeBSD sollte betonen, dass es sich lediglich um den Kernel von FreeBSD handelt, während die Systemwerkzeuge weiterhin denen des GNU-Projekts entsprachen, nicht den Varianten der BSD-Familie. Aus Anwendersicht blieb es daher bei einer größeren Ähnlichkeit mit anderen Linux-Distributionen als mit FreeBSD. Jessie enthielt den GNU/kFreeBSD-Port aufgrund anhaltender Probleme und enttäuschender Entwicklungsfortschritte jedoch nicht mehr. In Zukunft soll auch die Variante Debian GNU/Hurd mit dem Kernel GNU Hurd veröffentlicht werden. Konkrete Veröffentlichungspläne gibt es allerdings noch nicht. Eine Variante Debian GNU/NetBSD mit dem Kernel von NetBSD wurde 2002 aufgegeben. Debian Pure Blends Unter einem Debian Pure Blend (Debian-intern auch kurz Blend) versteht man eine interne Anpassung von Debian GNU/Linux, die einem speziellen Anwendungszweck dient. Blends bilden thematische Substrukturen innerhalb des unstrukturierten Paketpools von etwa 30.000 Binärpaketen von Debian und erlauben daher einen einfachen Zugriff auf die relevanten Pakete für spezifische Fachgebiete. Darüber hinaus steht hinter einem Blend auch ein für das Fachgebiet kompetentes Entwicklerteam, das als Ansprechpartner für bestimmte Fachgebiete dient und sich mit der Paketierung der zu diesem Fachgebiet gehörenden Software beschäftigt. Die stabilen Blends sind: Debian Accessibility Debian Astro DebiChem DebianEdu (früher: Skolelinux) Debian Games Debian GIS Debian Junior Debian Med Debian Multimedia Debian Science FreedomBox Hamradio Debian-Derivate Die große Auswahl an Paketen und das zuverlässige System der Paketverwaltung machen Debian attraktiv, um davon weitere eigenständige Distributionen abzuleiten. Rechtlich wird dies durch die für alle Komponenten geltende, weitgehende Freiheit gewährende Lizenz möglich. Daher gibt es eine große Anzahl von Distributionen, die hauptsächlich oder ausschließlich Pakete aus Debian verwenden. Einige weitverbreitete Distributionen nutzen Debian als Grundlage. Beispiele dafür sind Ubuntu, Knoppix und Linux Mint. Laut GNU/Linux Distribution Timeline gehen aus Debian und den daraus abgeleiteten Derivaten über 480 auf Debian basierende Distributionen hervor. (Stand Oktober 2012) Viele dieser Distributionen sind für einen speziellen Zweck, wie zum Beispiel den Einsatz als Server oder in der Schule, ausgerichtet. Trivia Nach einer vagen Schätzung des Debian-Entwicklers James Bromberger ist der Quellcode aller in Debian 7.0 enthaltenen Programme etwa 14 Milliarden Euro wert. Der Schätzung liegen Annahmen über das Jahresgehalt und die Programmierleistung eines durchschnittlichen Programmierers zugrunde. Debian wird mit dem m68k-Port benutzt, um alte Systeme wie Atari ST, Amiga oder Macintosh mit aktueller Linux-Software zu betreiben. Etwa 20 aktive Entwickler arbeiten an diesem Port, der von etwa 150–200 Nutzern weltweit verwendet wird. Literatur Eric Amberg: Linux-Server mit Debian 7 GNU/Linux: Das umfassende Praxis-Handbuch. mitp 2014, ISBN 978-3-8266-8200-1. Peter H. Ganten, Wulf Alex: Debian GNU/Linux – Grundlagen, Einrichtung und Betrieb. 3., überarb. Auflage. Springer 2007, ISBN 978-3-540-73338-6. Heike Jurzik: Debian GNU/Linux – Das umfassende Handbuch. 6., aktualisierte Auflage. Rheinwerk Computing 2015, ISBN 978-3-8362-3762-8. Michael Kofler: Linux 2013 – Debian, Fedora, openSUSE, Ubuntu. Addison-Wesley 2012, ISBN 978-3-8273-3208-0. Martin F. Krafft: Das Debian-System – Konzepte und Methoden. Open Source Press 2005, ISBN 3-937514-17-1. Rich Pollei: Debian 7: System Administration Best Practices. Packt Publishing 2013, ISBN 978-1-78328-311-8. Frank Ronneburg: Debian GNU/Linux 4 Anwenderhandbuch. Addison-Wesley 2008, ISBN 978-3-8273-2794-9. Weblinks Website des Projekts Debian Wiki Das Debian-Administrationshandbuch Einzelnachweise Linux-Distribution Gegründet 1993 Tor hidden service


source: wikipedia

text:
Die Begriffe DHTML, dynamisches HTML () oder auch DOM-Scripting bezeichnen bestimmte Webdesign-Methoden, bei denen während der Anzeige einer Webseite diese selbst, ausgelöst durch Benutzereingaben, verändert wird. Der Begriff „dynamisch“ bezieht sich dabei auf die Idee, dass diese Änderungen von Ereignissen bedingt werden, die auch mehrfach beim Anzeigen einer Seite auftreten können. Beispiele für dynamische Anzeigeeffekte sind: das Erscheinen („Aufklappen“) eines Menüs die Hervorhebung eines Textes die Möglichkeit, Objekte durch Drag & Drop auf dem Bildschirm zu verschieben Formularfelder automatisch in Abhängigkeit von anderen Feldern zu belegen Webseiten, die sich wie clientseitige Anwendungsprogramme bedienen lassen. Geschichte Die Skriptsprachen JavaScript im Netscape Navigator und JScript im Microsoft Internet Explorer ermöglichten schon Mitte der 1990er Jahre die ereignisbasierte Veränderung von Webseiten. Damals wurde der Begriff DHTML benutzt, um auf diese Fähigkeiten der damaligen Programmversionen hinzuweisen. Durch die Standardisierung des Document Object Model und das Platzen der damaligen Dotcom-Blase geriet der Begriff aus der Mode. Techniken Dynamisches HTML umfasst die folgenden Techniken: HTML zum Verfassen von Dokumenten eine clientseitige Skriptsprache, meistens JavaScript eine Schnittstelle zur Änderung und Erweiterung des HTML-Dokuments, heute wird vor allem das Document Object Model (DOM) verwendet XMLHttpRequest, um Daten zwischen dem Browser und einem entfernten HTTP-Server auszutauschen (siehe auch Ajax). Fetch API, um Daten zwischen dem Browser und einem entfernten HTTP-Server auszutauschen. ein Format zur Übertragung strukturierter Daten, etwa XML oder auch JSON Dabei müssen nicht unbedingt alle Techniken dieser Liste in einem Dokument verwendet werden (insbesondere die zur Datenübertragung nach dem ersten Laden nicht), um es als Anwendung von dynamischem HTML bezeichnen zu können. Beispiele Ein einfaches Beispiel eines dynamischen HTML Abschnitts, bei dem sich der dargestellte Text beim Anklicken verändert: ...
Klick mich
 ... Kritik und Nachteile Oft wird dynamisches HTML für effekt-orientierte Funktionen verwendet, bei denen der Nutzen nicht klar erkennbar ist und die eher stören. In der Anfangszeit konnte DHTML nur über Browser-spezifische sogenannte DHTML-Modelle realisiert werden, die nicht zueinander kompatibel waren. Daher führten einige DHTML-Seiten unter bestimmten Browsern zu Fehlern. Dieser Ruf hängt dynamischem HTML bis heute an. Daher wird heute auch der Begriff DOM Scripting verwendet, mit dem man standardkonformes DHTML von Browser-spezifischen Varianten abgrenzen möchte. Dynamisches HTML stellt teils hohe Anforderungen an die JavaScript-Fähigkeiten des Browsers, die nur von den neueren Browsergenerationen erfüllt werden. Wenn die Verwendung von JavaScript, z. B. aus Sicherheitsgründen, deaktiviert wird, kann dynamisches HTML nicht verwendet werden. Darüber hinaus kann sich die Zugänglichkeit für Anwender verschlechtern, die wegen körperlichen Einschränkungen auf alternative Eingabe- bzw. Ausgabemethoden zurückgreifen müssen (siehe Barrierefreies Internet). Es ist aber möglich, dynamisches HTML so zu verwenden, dass es nur bei Browsern verwendet wird, die damit auch umgehen können. Die übrigen Anwender können die Website dann verwenden, als ob diese gar kein dynamisches HTML einsetzen würde. Weblinks Tutorials für Anfänger und Schritt-für-Schritt-Anleitungen für konkrete Problemstellungen im SELFHTML-Wiki World Wide Web HTML


text: Darwin steht für: Darwin (Familienname) – zu Namensträgern siehe dort Darwin (Familie), die Familie des Naturforschers Charles Darwin Darwin (Einheit), eine in der Evolutionsbiologie gebräuchliche Einheit Darwin (Betriebssystem), ein freies Unix-Betriebssystem von Apple Darwin (Weltraumteleskop), eingestelltes Projekt, das erdähnliche Planeten finden sollte Darwin (Programmierspiel), Computerspiel aus dem Jahr 1961 (1991) Darwin, Asteroid des Hauptgürtels Isla Darwin (Galápagos), Insel der Galápagosinseln Darwin ist der Name folgender Orte: Darwin (Northern Territory), Stadt im Norden Australiens Darwin (Río Negro), Ort in Argentinien Darwin (Falklandinseln), Ort auf den Falklandinseln in den Vereinigten Staaten: Darwin (Illinois) Darwin (Inyo County, Kalifornien) Darwin (Fresno County, Kalifornien) Darwin (Minnesota) Darwin (Nevada) Darwin (Ohio) Darwin (Oklahoma) Darwin (Virginia) Darwin Downs, Alabama Darwin Township (Illinois) Darwin Township (Minnesota) Berge: Cordillera Darwin, Gebirge in Chile Monte Darwin, Berg (2488 m) in Chile Darwin Mountains, Gebirge in der Antarktis Mount Darwin (Antarktika), Berg in der Antarktis Mount Darwin (Tasmanien), Berg (1031 m) im westlichen Tasmanien Darwin Peak, Berg im US-Bundesstaat Wyoming Krater: Darwin (Mondkrater) Darwin (Marskrater) Siehe auch: Darwin-Firnfeld Darwin-Gletscher Darwin-Medaille Darwin Award


text:
Das Document Object Model (DOM, engl. für Dokumenten-Objekt-Modell) ist eine Spezifikation einer Programmierschnittstelle, welche HTML- oder XML-Dokumente als eine Baumstruktur darstellt, in der jeder Knoten ein Objekt ist, welches einen Teil des Dokumentes repräsentiert, z. B. einen Absatz, eine Überschrift, ein Video oder etwa eine Tabellenzelle. Die Schnittstelle ist plattform- und programmiersprachenunabhängig und erlaubt damit standardisiert, die Struktur und das Layout eines Dokumentes zu verändern. Im Webbrowser bildet dies einen wichtigen Baustein für dynamische Webseiten. Das DOM wird vom World Wide Web Consortium definiert. Eine Implementierung, die der DOM-Spezifikation genügt, besteht im Sinne der objektorientierten Programmierung aus einem Satz von Klassen zusammen mit deren Methoden und Attributen. Benennung Bei der Bezeichnung „Document Object Model“ handelt es sich eigentlich um eine Fehlbenennung, da DOM nicht als Modell, sondern als Schnittstelle (Interface) für den Datenzugriff definiert ist und vom W3C auch so bezeichnet wird. Die Bezeichnung als Modell betont hingegen das der Schnittstelle zugrundeliegende, wohldefinierte Objektmodell, dessen Gültigkeit Voraussetzung für die Gültigkeit der darauf aufgebauten Schnittstelle ist. Auf einer höheren Abstraktionsebene ist auch eine Schnittstelle ein Modell, nämlich für die Art und Weise, auf Objekte oder Daten zuzugreifen. Geschichte DOM ist ursprünglich unter dem Einfluss von mindestens zwei Entwicklungen entstanden, die die Computerwelt in der jüngsten Vergangenheit maßgeblich prägten. Beiden liegt die Notwendigkeit zugrunde, auf die strukturierten Daten in HTML- und XML-Dokumenten einfach und einheitlich zugreifen zu können. Mitte der 1990er Jahre, als das World Wide Web an Popularität zunahm, wurde die Skriptsprache JavaScript erfunden und gängige Webbrowser enthielten seitdem Interpreter, die solche Scripte ausführen. JavaScript definierte rudimentäre Möglichkeiten zum Zugriff auf das HTML-Dokument und zur Ereignisbehandlung. Später erfanden verschiedene Browserhersteller unterschiedliche Modelle für dynamisches HTML (DHTML), die eine umfassendere Änderung der Struktur und des Aussehens des Dokuments ermöglichten, während das Dokument im Browser angezeigt wird. Diese Unterschiede machten allerdings die Arbeit für Webentwickler, welche dynamisches HTML nutzen wollten, zu einer äußerst mühsamen Angelegenheit, da sie oft praktisch gezwungen waren, für jeden zu unterstützenden Browser eine eigene Version zu schreiben. Die ersten DOM-Standards des W3C sind daher Versuche, die verschiedenen proprietären JavaScript- und DHTML-Techniken, die während der Zeit der Browserkriege entstanden, zusammenzuführen, zu standardisieren und letztlich abzulösen. Dies ist so weit gelungen, dass DOM heutzutage eine zentrale Bedeutung bei der JavaScript-Programmierung einnimmt. Gleichzeitig entstand XML als allgemeines Austauschformat zur menschenlesbaren Darstellung von strukturierten Daten, das an den Erfolg von HTML anknüpfte. Zur Verarbeitung von XML-Dokumenten war eine verständliche, leistungsfähige und programmiersprachenübergreifende Schnittstelle nötig. DOM bietet eine solche und definiert darüber hinaus zusätzliche Schnittstellen für einen komfortablen Umgang mit XML-Dokumenten. Grundlagen anhand eines Beispiels Folgender HTML-Code definiert eine Tabelle mit dem Element table und verschiedenen Unterelementen:

 Vorname	 Name

 Donald	 Duck

 So sieht es im Browser aus: Das DOM repräsentiert das table-Element und dessen Unterelemente in der folgenden Baumstruktur: An diesem Beispiel lässt sich der prinzipielle Aufbau des Objektmodells diskutieren: Dokumente werden logisch wie ein Stammbaum dargestellt. Knoten (nodes) stehen über „Verwandtschaftsbeziehungen“ zueinander in Verbindung. Arten von Beziehungen Die vorliegende Struktur wird im Objektmodell durch die folgenden Beziehungen charakterisiert: Der Wurzelknoten (root) table hat als Kinder (children) die Elementknoten thead und tbody. Der table-Elementknoten ist umgekehrt ein Elternteil (parent) von thead und tbody. Knoten mit gemeinsamem Elternteil (zum Beispiel die beiden th-Elementknoten) werden Geschwister (siblings) genannt. Ausgehend von einem beliebigen Knoten ist jeder andere Knoten über diese Verwandtschaftsbeziehungen erreichbar. Arten von Knoten Die wichtigsten Knotentypen in DOM sind: Ein Dokumentknoten stellt die gesamte Baumstruktur dar. Ein Dokumentfragmentknoten stellt einen Teil der Baumstruktur dar. Ein Elementknoten entspricht exakt einem Element in HTML oder XML. Ein Attributknoten entspricht exakt einem Attribut in HTML oder XML. Ein Textknoten stellt den Textinhalt eines Elements dar. Attributknoten sind eine besondere Knotenart, denn sie kommen nicht als Knoten in der Baumstruktur vor, die vor allem durch Elementknoten gebildet wird. Attributknoten sind demnach keine „Kinder“ von Elementknoten, sondern Eigenschaften von ihnen. Verarbeitung eines Dokuments Im ersten Schritt wird ein bestehendes Dokument durch das Programm eingelesen und ein Dokument-Objekt erzeugt. Anhand dieses Objekts kann mittels der Methoden des API auf die Inhalte, Struktur und Darstellung zugegriffen werden. Insbesondere erlaubt DOM die Navigation zwischen den einzelnen Knoten eines Dokuments, das Erzeugen, Verschieben und Löschen von Knoten sowie das Auslesen, Ändern und Löschen von Textinhalten. Am Ende der Verarbeitung kann aus dem Dokument-Objekt durch so genannte Serialisierung ein neues XML- oder HTML-Dokument generiert werden. Standardisierung DOM ist seit 1998 ein Standard des W3C und wurde seitdem mehrfach aktualisiert und erweitert. Es existieren mehrere Versionen (Levels) jeweils mit verschiedenen Modulen: DOM Level 0 Dieses Level wurde nie formal spezifiziert. Level 0 bezeichnet die mittels JavaScript nutzbaren Techniken zum Zugriff auf HTML-Dokumente. Diese wurden von Webbrowsern wie Internet Explorer und Netscape Navigator vor der Standardisierung von DOM eingeführt. DOM Level 1 Veröffentlicht Ende 1998. DOM Core (DOM-Kern) definiert das Bewegen im DOM-Baum, die Manipulation der Knoten, inklusive des Einfügens neuer Elemente und des Setzens von Attributen. DOM HTML ist die Erweiterung zum Zugriff auf HTML-Dokumente. Es standardisiert und vervollständigt die bereits verbreitete Praxis, die auf den JavaScript-Spezifikationen von Netscape bzw. Microsoft JScript basiert. DOM Level 2 Veröffentlicht Ende 2000. DOM Core: u. a. Erweiterung um XML-Namensraum-Unterstützung DOM HTML: u. a. Ausweitung auf XHTML-Dokumente, Anpassung an DOM 2 Core DOM Style und DOM CSS ermöglichen das dynamische Auslesen, Hinzufügen und Ändern der Formatierung bzw. des Layouts des Dokuments über Stylesheets, insbesondere Cascading Style Sheets (CSS). DOM Views erlaubt den Zugriff auf Informationen konkreter Wiedergabearten des Dokuments (zum Beispiel der grafischen Darstellung im Webbrowser). Das wird vor allem zusammen mit DOM CSS benutzt, um die tatsächlichen CSS-Eigenschaftswerte von gewissen Elementen in Erfahrung zu bringen (z. B. „Welche Hintergrundfarbe hat diese Überschrift?“). DOM Events standardisiert die Verarbeitung von Ereignissen im Dokument, zum Beispiel Benutzeraktionen. Wird vor allem im Zusammenhang mit JavaScript bei der Darstellung von HTML-Dokumenten in Webbrowsern verwendet. Angelehnt an die Modelle der Ereignis-Behandlung des Netscape Navigators und des Internet Explorers für HTML-Dokumente. DOM Traversal und DOM Range: Durchlaufen des Knotenbaums anhand von bestimmten Auswahlkriterien, Arbeiten mit Bereichen im Dokument, die bestimmte Elemente und Textknoten umfassen DOM Level 3 Veröffentlicht April 2004. DOM 3 Core: umfassende Erweiterung, u. a. verbesserte Ausnahmebehandlung und Umgang mit Zeichenkodierungen DOM 3 Load and Save ermöglicht die Serialisierung von Dokumenten oder Dokumentteilen sowie das Parsen von XML-Dokumenten in Zeichenketten in Dokument-Objekte. Zudem können XML-Dokumente über HTTP versendet und abgerufen werden, wie es mit der bekannteren XMLHttpRequest-Technik möglich ist. DOM 3 XPath erlaubt das Auswählen von Knoten anhand von XPath-Ausdrücken. DOM 3 Events erweitert DOM 2 Events u. a. um Tastatur-Ereignisse. DOM 3 Validation erlaubt das Prüfen, ob nach einer dynamischen Änderung (Hinzufügen oder Entfernen von Knoten) das DOM-Dokument valide bleibt. DOM 3 Views and Formatting erlaubt es, dynamisch auf den Inhalt, Struktur und Style zuzugreifen und diese zu ändern. DOM 3 Abstract Schemas Siehe auch Simple API for XML (SAX) Xerces, JDOM, dom4j Weblinks Website beim W3C (englisch) W3C-Übersetzung zu Testsuiten (deutsch) Mario Jeckle: Skript zur Vorlesung XML: DOM DOM Einführung bei data2type (deutsch) DOM-Referenz bei data2type (deutsch) Folienvortrag Sammlung von Links zu Fachartikeln (englisch) Praktisches Anwendungsbeispiel DOM mit PHP – Erstellung eines validen RSS-Feed mit DOM und PHP Einzelnachweise Beschreibungssprache JavaScript-Programmierschnittstelle XML


text: Das Domain Name System, deutsch Domain-Namen-System, (DNS) ist ein hierarchisch unterteiltes Bezeichnungssystem in einem meist IP-basierten Netz zur Beantwortung von Anfragen zu Domain-Namen (Namensauflösung). Das DNS funktioniert ähnlich wie eine Telefonauskunft. Der Benutzer kennt die Domain (den für Menschen merkbaren Namen eines Rechners im Internet) – zum Beispiel example.org. Diese sendet er als Anfrage in das Internet. Die Domain wird dann dort vom DNS in die zugehörige IP-Adresse (die „Anschlussnummer“ im Internet) umgewandelt – zum Beispiel eine IPv4-Adresse der Form 192.0.2.42 oder eine IPv6-Adresse wie 2001:db8:85a3:8d3:1319:8a2e:370:7347 – und führt so zum richtigen Rechner. Überblick Das DNS ist ein weltweit auf Tausenden von Servern verteilter hierarchischer Verzeichnisdienst, der den Namensraum des Internets verwaltet. Dieser Namensraum ist in sogenannte 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 () 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 Zahlenketten. 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 mehr an Bedeutung, denn dann werden einem Namen jeweils IPv4- und IPv6-Adressen zugeordnet. So löst sich beispielsweise der Name www.kame.net in die IPv4-Adresse 203.178.141.194 und die IPv6-Adresse 2001:200:dff:fff1:216:3eff:feb1:44d7 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 () realisiert werden. Mit dem DNS ist auch eine umgekehrte Auflösung von IP-Adressen in Namen () 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 RFC 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 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: dezentrale Verwaltung, hierarchische Strukturierung des Namensraums in Baumform, Eindeutigkeit der Namen, Erweiterbarkeit. Domain-Namensraum Der Domain-Namensraum hat eine baumförmige Struktur. Die Blätter und Knoten des Baumes werden als Labels ( für Aufschrift) bezeichnet. Ein kompletter Domainname eines Objektes besteht aus der Verkettung aller Labels eines Pfades. Labels sind Zeichenketten, die jeweils mindestens ein Byte und maximal 63 Bytes lang sind.RFC 2181 Einzelne Labels werden durch Punkte voneinander getrennt. Ein Domainname wird mit einem Punkt abgeschlossen (der letzte Punkt wird meist weggelassen, gehört rein formal aber zu einem vollständigen Domainnamen dazu). Somit lautet ein korrekter, vollständiger Domainname (auch genannt) zum Beispiel www.example.com. und darf inklusive aller Punkte maximal 255 Bytes 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 (englisch ). Die erste Ebene (beispielsweise com.) wird als Top-Level-Domain (TLD) bezeichnet, die zweite (beispielsweise example.com.) als Second-Level-Domains, usw. Zone Die Daten des Domain Name Systems sind über eine Vielzahl von Nameservern weltweit verteilt, die durch Verweise untereinander lose gekoppelt sind. Die Verweise werden Delegierungen () genannt und folgen der hierarchischen Struktur des Domain-Baums. Durch die Delegierungen wird der Domain-Namensraum in überschneidungsfreie Bereiche unterteilt, die Zonen genannt werden. Ein oder mehrere autoritative Nameserver sind für die Auslieferung der Daten einer Zone zuständig. So sind beispielsweise die Root-Nameserver für die Beantwortung von Anfragen an die Wurzel-Zone zuständig und die Nameserver von Verisign für die Zone der Top-Level-Domain .com. Eine Zone besteht aus einer Liste von Resource Records. Der BIND-Nameserver sowie dazu kompatible Nameserver-Software speichert die Resource Records in einer Zonendatei. Resource Record Ein Resource Record ist ein Datensatz im Domain Name System. Er besteht aus fünf Datenfeldern. Beispiel: www.example.com. 86400 IN A 93.184.216.34 Name Der Domainname, unter dem der Resource Record abgelegt ist (beispielsweise www.example.com.). Time to Live Maximale Zeit, für die dieser Record in einem DNS-Cache zwischengespeichert werden kann (beispielsweise 86400 Sekunden = 1 Tag). Klasse Fast ausschließlich „IN“ für Internet. Typ Datentyp der Nutzdaten (beispielsweise A Resource Record: eine IPv4-Adresse). Daten Die eigentlichen Nutzdaten (beispielsweise 93.184.216.34). Der Abruf eines Resource Records erfolgt unter Angabe von Domainname, Klasse und Typ. Da als Klasse nahezu ausschließlich „IN“ verwendet wird, sind in der Praxis lediglich der Domainname und Record-Typ relevant. Es sind mehrere Dutzend Record-Typen spezifiziert, die unterschiedlichen Anwendungszwecken dienen. Im Laufe der Zeit wurden neue Typen definiert, mit denen Erweiterungen des DNS realisiert wurden. Zu den am häufigsten verwendeten gehören die folgenden Record-Typen: Mit dem SOA Resource Record werden Parameter der Zone, wie z. B. Gültigkeitsdauer oder Seriennummer, festgelegt. Mit dem NS Resource Record werden die Verknüpfungen (Delegierungen) der Server untereinander realisiert. Mit folgenden Record-Typen werden die eigentlichen Daten definiert: Ein A Resource Record weist einem Namen eine IPv4-Adresse zu. Ein AAAA Resource Record weist einem Namen eine IPv6-Adresse zu. Ein CNAME Resource Record verweist von einem Namen auf einen anderen Namen. Ein MX Resource Record weist einem Namen einen Mail Transfer Agent zum E-Mail-Empfang zu. Einem ähnlichen Zweck dient der SRV Resource Record, der jedoch durch die Angabe eines Dienstebezeichners flexibel für verschiedene Anwendungen verwendet werden kann, während der MX Resource Record auf einen bestimmten Anwendungszweck festgelegt ist. Ein PTR Resource Record weist einer IPv4- oder einer IPv6-Adresse einen Namen zu (Reverse DNS). Ein TXT Resource Record weist einem Namen einen frei definierbaren Text zu. Dies wird für verschiedene Anwendungszwecke verwendet, beispielsweise zur E-Mail-Authentifizierung mit Sender Policy Framework oder DomainKeys Identified Mail. Komponenten Nameserver Ein Nameserver ist ein Server, der Namensauflösung anbietet. Namensauflösung ist das Verfahren, das es ermöglicht, Namen von Rechnern bzw. Diensten in eine vom Computer bearbeitbare Adresse aufzulösen (z. B. www.wikipedia.org in 91.198.174.192). Die meisten Nameserver sind Teil des Domain Systems, das auch im Internet benutzt wird. Nameserver sind zum einen Programme, die auf Basis einer DNS-Datenbank Anfragen zum Domain-Namensraum beantworten. Im Sprachgebrauch werden allerdings auch die Rechner, auf denen diese Programme zum Einsatz kommen, 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 bedeuten, dass der Nameserver in dieser Zeit falsche Informationen liefert, 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-Nameserver Falls kein Weiterleitungsserver konfiguriert wurde oder dieser nicht antwortet, werden die Root-Nameserver 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 ausschließlich iterative Anfragen. Sie wären sonst mit der Anzahl der Anfragen schlicht überlastet. Anders konzipierte Namensauflösungen durch Server, wie der NetWare Name Service oder der Windows Internet Naming Service, sind meistens auf Local Area Networks beschränkt und werden zunehmend von der Internetprotokollfamilie verdrängt. Resolver Ein Resolver ist eine Software-Komponente, die per DNS-Protokoll Informationen von einem Nameserver abruft. Die Anwendung, zum Beispiel ein Webbrowser, fordert per Programmierschnittstelle vom Resolver die Auflösung eines Domainnamens an. Der Resolver führt entweder eine rekursive oder iterative Namensauflösung durch und gibt die Antwort an die Anwendung zurück. 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 eine positive oder negative Antwort erhält. Der Nameserver, der die rekursive Anfrage bearbeitet, verwendet selbst einen eigenen Resolver zur Abfrage anderer Nameserver. Ein Nameserver, der rekursive Namensauflösung anbietet, wird als rekursiver Nameserver oder teilweise auch als rekursiver Resolver bezeichnet. Im iterativen Modus bekommt der Resolver entweder den gewünschten Resource Record oder einen Verweis auf weitere Nameserver, die er selbst als nächstes fragt. Der Resolver hangelt sich so von Nameserver zu Nameserver, bis er von dem autoritativen Nameserver eine verbindliche Antwort erhält. Während beim rekursiven Modus dem angefragten Nameserver die vollständige Auflösung überlassen wird, muss beim iterativen Modus der Resolver selbst durch wiederholte (iterative) Anfragen die Auflösung übernehmen. Jedes Betriebssystem mit TCP/IP-Netzwerkfunktionalität enthält einen Resolver. Üblicherweise handelt es sich dabei um einen simplen Resolver, der ausschließlich rekursive Anfragen an einen konfigurierbaren Nameserver stellen kann. Ein solcher Resolver wird als Stub-Resolver (von : Stumpf oder Stummel) bezeichnet. Bekannte Kommandozeilen-Programme zur Namensauflösung sind nslookup, host und dig. Protokoll DNS-Anfragen werden normalerweise per UDP Port 53 zum Namensserver gesendet. Der DNS-Standard fordert aber auch die Unterstützung von TCP für Fragen, deren Antworten zu groß für UDP-Übertragungen sind. Ursprünglich betrug die maximal zulässige Länge einer DNS-Nachricht über UDP 512 Bytes. Mit Extended DNS (EDNS) wurde diese Größenbeschränkung aufgehoben und kann variabel zwischen Client und Server gewählt werden. Beim DNS Flag Day 2020, einer Informationsinitiative von DNS-Software- und DNS-Service-Anbietern, wurde eine standardmäßige Maximallänge von 1232 Bytes empfohlen. Die maximal mögliche Nachrichtenlänge wird durch die Maximum Transmission Unit begrenzt. Der Einsatz von IP-Fragmentierung ist zwar möglich, wird aber nicht empfohlen. Überlange Antworten werden abgeschnitten übertragen, sodass sie die maximal mögliche Nachrichtenlänge des Antwortenden nicht übersteigen, und mit dem Header-Flag Truncated (TC) als solches markiert. Der Anfragende kann daraufhin die Anfrage über TCP wiederholen. Bei TCP beträgt die maximale Nachrichtenlänge 65.535 Bytes. Die Verwendung von persistenten Verbindungen und Pipelining ist möglich. Zonentransfers werden stets über TCP durchgeführt, wobei die Nachrichtenlängenbeschränkung dafür nicht relevant ist. Auflösung eines DNS-Requests 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 6724 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. Der Rechner X sucht in seiner Hosts-Datei, ob die IP-Adresse für „de.wikipedia.org“ dort hinterlegt ist. Falls dem nicht so ist, fragt er beim DNS-Server nach. Dieser ist entweder fest eingetragen oder wurde per DHCP bzw. DHCPv6 automatisch zugewiesen und hat die Form nameserver 192.0.2.23 oder nameserver 2001:db8::23:cafe:affe:42. Hat der DNS-Server von Rechner X eine IP-Adresse für den angefragten Namen zwischengespeichert, antwortet er damit und die Anfrage kommt zum Ende (siehe letzter Punkt). Andernfalls fragt er einen der 13 Root-Nameserver nach „de.wikipedia.org.“. Der Root-Nameserver findet heraus, dass die Auflösung dieses Namens in der „org.“-Zone weitergeht und sendet die Namen und die IP-Adressen der „org.“-Nameserver (NS Resource Records und deren AAAA bzw. A Resource Records) zum DNS-Server von Rechner X. Nun fragt der DNS-Server von Rechner X einen der Nameserver für „org.“-Domains nach „de.wikipedia.org.“. Der „org.“-Nameserver sendet ihm die Namen der Nameserver (und deren IP-Adressen, sofern sie zur selben Top-Level-Domain gehören) für die Zone „wikipedia.org.“. Anschließend fragt der DNS-Server von Rechner X einen „wikipedia.org.“-Nameserver wie die IP-Adresse des Namens „de.wikipedia.org.“ ist. Mit dieser Adresse wird an den DNS-Server von Rechner X geantwortet und der ... ... sendet sie an den Rechner X, welcher nun zum Beispiel seine HTTP-Anfragen an die IP-Adresse von „de.wikipedia.org.“ senden kann. Beispiel Namensauflösung 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.90 J.ROOT-SERVERS.NET. 10421 IN A 192.58.128.30 J.ROOT-SERVERS.NET. 1289 IN AAAA 2001:503:c27::2:30 G.ROOT-SERVERS.NET. 10940 IN A 192.112.36.4 K.ROOT-SERVERS.NET. 4208 IN A 193.0.14.129 K.ROOT-SERVERS.NET. 7277 IN AAAA 2001:7fd::1 C.ROOT-SERVERS.NET. 6126 IN A 192.33.4.12 M.ROOT-SERVERS.NET. 3274 IN A 202.12.27.33 M.ROOT-SERVERS.NET. 7183 IN AAAA 2001:dc3::35 I.ROOT-SERVERS.NET. 9788 IN A 192.36.148.17 H.ROOT-SERVERS.NET. 10421 IN A 128.63.2.53 H.ROOT-SERVERS.NET. 13739 IN AAAA 2001:500:1::803f:235 E.ROOT-SERVERS.NET. 11125 IN A 192.203.230.10 F.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, welcher auf die Root-Nameserver verweist, die alle weiter via IPv4 befragt werden können, einige zusätzlich auch mittels IPv6. Die Root-Nameserver verwalten die Wurzel-Zone (Zone, die die Nameserver für .org, .de, .com und andere Top Level Domains enthält) der Namensauflösung, dargestellt durch einen Punkt. Die IP-Adressen der Root-Nameserver ändern sich sehr selten und müssen allen Nameservern bekannt sein, sofern sie das Internet betreffende Anfragen beantworten. (Diese IP-Adressen können beispielsweise in einer als „Root Hints“ bezeichneten Textdatei mitgeliefert werden.) 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.53 C.DE.NET. 172800 IN A 208.48.81.43 F.NIC.de. 172800 IN A 81.91.164.5 F.NIC.de. 172800 IN AAAA 2001:608:6:6::10 L.DE.NET. 172800 IN A 89.213.253.189 S.DE.NET. 172800 IN A 195.243.137.26 Z.NIC.de. 172800 IN A 194.246.96.1 Z.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 den 13 genannten Root-Nameservern wurde zufällig „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.14 ns.heise.de. 86400 IN A 193.99.145.37 ns.plusline.de. 86400 IN A 212.19.48.14 ns.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 Aus den sechs genannten Nameservern wurde zufällig „F.NIC.de.“ ausgewählt, um Näheres über „www.heise.de.“ zu erfahren. Er beantwortet die Anfrage mit fünf möglichen Delegierungen. 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.85 heise.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.37 ns.pop-hannover.de. 10800 IN A 193.98.1.200 ns2.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 Aus den fünf genannten Nameservern wurde zufällig „ns.pop-hannover.de.“ herangezogen, um die Frage nach „www.heise.de.“ zu beantworten. Die Antwort lautet 193.99.144.85. Damit ist die Anfrage am Ziel angelangt. Es werden auch wieder dieselben Nameserver als verantwortlich für „heise.de.“ genannt, ohne also auf andere Nameserver zu verweisen. Beispiel Reverse Lookup 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. (Dieser Name ist lang, da die implizit enthaltenen Nullen nun wieder explizit genannt werden müssen.) 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.4 A.ROOT-SERVERS.NET. 2470 IN AAAA 2001:503:ba3e::2:30 C.ROOT-SERVERS.NET. 387 IN A 192.33.4.12 D.ROOT-SERVERS.NET. 2747 IN A 128.8.10.90 E.ROOT-SERVERS.NET. 7183 IN A 192.203.230.10 F.ROOT-SERVERS.NET. 14225 IN AAAA 2001:500:2f::f H.ROOT-SERVERS.NET. 7950 IN A 128.63.2.53 H.ROOT-SERVERS.NET. 13245 IN AAAA 2001:500:1::803f:235 I.ROOT-SERVERS.NET. 6172 IN A 192.36.148.17 J.ROOT-SERVERS.NET. 7168 IN A 192.58.128.30 J.ROOT-SERVERS.NET. 13860 IN AAAA 2001:503:c27::2:30 K.ROOT-SERVERS.NET. 3541 IN A 193.0.14.129 K.ROOT-SERVERS.NET. 9369 IN AAAA 2001:7fd::1 L.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. Erweiterungen 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. Dynamisches DNS Die manuelle Änderung von DNS-Einträgen ist mit Aufwand verbunden. Durch DNS-Caching kann es zudem mehrere Stunden oder sogar Tage dauern, bis sich eine Änderung im Netz verbreitet hat. Dynamisches DNS ermöglicht die automatisierte Aktualisierung von DNS-Einträgen. In Kombination mit der Verwendung eines niedrigen Time-to-Live-Werts können Resource Records mit geringem Aufwand und geringer Zeitverzögerung aktualisiert werden. Ein typischer Einsatzzweck ist die automatische Aktualisierung von A oder AAAA Resource Records bei der Verwendung von dynamischen IP-Adressen. Dynamisches DNS kann ein Sicherheitsrisiko darstellen, falls die Schnittstelle zur Aktualisierung von DNS-Einträgen nicht gegen unautorisierte Zugriffe abgesichert ist. Bei einer REST API kann die Absicherung durch den Einsatz von HTTPS und einer Authentifizierung des Clients erfolgen. Bei DNS-Update kann die Absicherung per TSIG erfolgen. Internationalisierung Bisher waren die Labels auf alphanumerische Zeichen und das Zeichen ‚-‘ eingeschränkt. Möglich, aber nicht standardkonform, ist bei Subdomains zudem ‚_‘. Dieser begrenzte Zeichenvorrat 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 ü sowie ß) oder Zeichen aus komplett anderen Schriftsystemen (zum Beispiel Chinesisch) ursprünglich nicht in Domainnamen möglich. Ein mittlerweile etablierter Ansatz zur Vergrößerung des Zeichenvorrats ist die 2003 in RFC 3490 eingeführte und 2010 mit RFC 5890 aktualisierte Internationalisierung von Domainnamen (IDNA). Um das neue System mit dem bisherigen kompatibel zu halten, werden die erweiterten Zeichensätze mit den bislang zulässigen Zeichen kodiert. Die erweiterten Zeichensätze werden dabei zunächst normalisiert, um unter anderem Großbuchstaben auf Kleinbuchstaben abzubilden, und anschließend per Punycode auf einen ASCII-kompatiblen String abgebildet. IDNA erfordert eine Anpassung der Netzwerkanwendungen (zum Beispiel Webbrowser), 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 anderen Top-Level-Domains, insbesondere im asiatischen Raum, ist die Verwendung von internationalisierten Domainnamen möglich. Extended DNS 1999 beschrieb Paul Vixie im RFC 2671 einige kleinere, abwärtskompatible Erweiterungen am Domain Name System, die als Extended DNS Version 0 bezeichnet werden. Durch Einsatz eines Pseudo-Records als Header-Erweiterung kann der Anfragende zusätzliche Optionen setzen. Insbesondere kann er übermitteln, dass er UDP-Antworten größer als 512 Bytes entgegennehmen kann. DNSSEC-fähige Server und Resolver müssen EDNS beherrschen. Verwaltung von Telefonnummern 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. RFID-Unterstützung Mit der RFID können auf speziellen RFID-Etiketten abgelegte IDs – sogenannte 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 Name Service ONS wandelt dazu den EPC in einen DNS-Namen um und erfragt per Standard-DNS einen oder mehrere Naming Authority Pointer NAPTR. Spam-Abwehr Zur Filterung von Spam-Mails überprüfen viele Mailserver den DNS-Eintrag des sendenden Mailservers routinemäßig mit Hilfe des Reverse DNS Lookup. Dieser muss nicht nur auch vorwärts wieder korrekt auflösen und auf die IP-Adresse des sendenden Systems zeigen (Forward-confirmed reverse DNS), sondern muss auch dem im SMTP-Protokoll genannten HELO-Hostnamen des sendenden Systems entsprechen. Mittels Sender Policy Framework wird versucht, den Versand von gefälschten Absendern durch Dritte möglichst zu unterbinden. Zu jeder Mail-Domain wird dabei über einen speziellen SPF Resource Record explizit aufgelistet, von welchen Servern und IP-Netzen mit E-Mails dieser Domain zu rechnen ist. SPF steht jedoch wegen zahlreicher technischer Schwierigkeiten, beispielsweise bei Weiterleitungen, in der Kritik. Auch der Anti-Spam-Mechanismus DKIM greift auf Einträge im DNS zurück, indem sendende Mailserver in DNS-TXT-Records ihren Public-Key veröffentlichen, mit dem die Signatur ihrer ausgehenden E-Mails verifiziert werden kann. Sonstiges 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 im lokalen Netz 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. DNS-Serververbund 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. Beispielsweise 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 empfohlenerweise 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. Sicherheit 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. Angriffsformen 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. DDoS-Angriff auf Nameserver Bei einem Distributed-Denial-of-Service-Angriff 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 zurzeit 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. Um eine große Anzahl DNS-Anfragen zu erzeugen, werden bei solchen Angriffen Botnetze eingesetzt. Ein DDoS-Angriff kann unbeabsichtigt einen DNS-Server betreffen und zum Ausfall bringen, wenn der Domainname des Angriffsziels wiederholt aufgelöst wird ohne zwischengespeichert zu werden. Der Effekt auf DNS-Server wird verhindert, wenn das DDoS-Schadprogramm DNS-Caching verwendet. DNS-Amplification-Angriff Die DNS Amplification Attack ist ein Denial-of-Service-Angriff, bei der nicht der DNS-Server selbst das eigentliche Angriffsziel ist, sondern ein Dritter. Ausgenutzt wird, dass ein DNS-Server in manchen Fällen auf kurze Anfragen sehr lange Antworten zurücksendet. Durch eine gefälschte Absenderadresse werden diese an die IP-Adresse des Opfers gesendet. Ein Angreifer kann damit den von ihm ausgehenden Datenstrom substanziell verstärken und so den Internet-Zugang seines Angriffsziels stören. DNS-Spoofing Beim DNS-Spoofing handelt es sich um eine Angriffsklasse von Maskierungsangriffen, die das Ziel haben eine falsche Identität vorzugeben. Dafür wird die DNS-Antwort an einen Client verändert um ihn auf einen anderen, meist vom Angreifer kontrollierten Dienst fehlzuleiten. Cache Poisoning Cache Poisoning bezeichnet ein Angriffsszenario, welches in die Angriffsklasse des DNS-Spoofing fällt. Dabei werden einem anfragenden Client zusätzlich zu der korrekten Antwort, manipulierte Daten übermittelt, die dieser in seinen Cache übernimmt und später, möglicherweise ungeprüft, verwendet. Offener DNS-Server 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. Beispielsweise bewirkt die Option allow-recursion {127.0.0.1; 172.16.1.4;};, 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. Ein offener DNS-Server kann auch eine Falle sein, wenn er gefälschte IP-Adressen zurückgibt, siehe Pharming. Sicherheitserweiterungen Mehr als zehn Jahre nach der ursprünglichen Spezifikation wurde DNS um Security-Funktionen ergänzt. Folgende Verfahren sind verfügbar: TSIG Bei TSIG (Transaction Signatures) handelt es sich um ein einfaches, auf symmetrischen Schlüsseln beruhendes Verfahren, mit dem der Datenverkehr zwischen DNS-Servern und Updates von Clients gesichert werden kann. DNSSEC Bei DNSSEC (Domain Name System Security Extensions) wird von einem asymmetrischen Kryptosystem Gebrauch gemacht. Neben der Server-Server-Kommunikation kann auch die Client-Server-Kommunikation gesichert werden. Dies soll die Manipulation der Antworten erschweren. DNS over TLS (DoT) Bei DNS over TLS sollen sowohl DDoS-Angriffe, die Manipulation der Antworten als auch das Ausspähen der gesendeten Daten verhindert werden. Dazu werden die DNS-Abfragen per Transport Layer Security (TLS) abgesichert. DNS over HTTPS (DoH) DNS over HTTPS ändert das DNS-System grundlegend. Anfragen finden hier auf Anwendungsebene statt. Anwendungen wie beispielsweise der Webbrowser fragen direkt beim DNS-Server an, anstatt die Anfrage an das Betriebssystem weiterzuleiten. Dadurch sehen DNS-Anfragen aus wie normaler Internetverkehr und können somit nicht gezielt abgefangen bzw. blockiert werden. Cloudflare und Google bieten öffentliche DoH-Webserver an. Mozilla Firefox unterstützt DoH seit Version 60 als experimentelle Funktion. Mozilla stellt in Zusammenarbeit mit Cloudflare einen DoH-Server bereit, der strenge Privatsphäre-Anforderungen erfüllen muss. DNS over QUIC (DoQ) DNS over QUIC soll die Vorteile von DoT und DoH kombinieren. DoQ soll gute Privatsphäre und Sicherheit bieten, eine geringe Latenz aufweisen und nicht blockierbar sein. RFC 9250 der Internet Engineering Task Force beschreibt DoQ. Domain-Registrierung 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 (Registries, z. B. Verisign oder Afilias) 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. In den allermeisten Fällen können Domains bei den Registries nur über Zwischenhändler, sogenannte Registrare wie Godaddy oder 1&1 Internet SE registriert werden, die mit den Registries entsprechende Verträge abgeschlossen haben. Bonjour bzw. Zeroconf Apple hat bei der Entwicklung von macOS 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) Implementierungen verfügbar. Zusammen mit einer Reihe von anderen Techniken fasst Apple DNS-SD und mDNS unter dem Namen „Zeroconf“ zusammen, als Bestandteil von OS X auch als „Rendezvous“ bzw. „Bonjour“. Die meisten Linux-Distributionen unterstützen diese Erweiterung z. B. mit der avahi-Implementierung von Zeroconf. Zensur und alternative DNS Standardmäßig wird der DNS-Servern durch den Mobilfunkanbieter ausgewählt, oder durch die Anwendung die gerade genutzt wird. Mozilla Firefox verwendet bspw. Cloudflare um DNS-Anfragen aufzulösen. Innerhalb eines Netzwerkes, oder lokal auf einem Gerät, kann jedoch nach eigener Präferenz ein DNS-Server eingestellt werden. Unzensierte DNS-Server Seit der Debatte um das Zugangserschwerungsgesetz (2008) und Zensur im Internet im Allgemeinen gibt es eine Reihe von alternativen DNS-Anbietern, die Domains nach eigener Aussage nicht zensieren. Beispiele sind Organisationen wie Digitalcourage, Freifunk München oder Digitale Gesellschaft. Auch von Privatpersonen werden alternative DNS-Server bereitgestellt. Der alternative DNS-Server des Chaos Computer Club wird, aufgrund von fehlenden Sicherheitsaspekten, kritisiert. Dienste mit Filterlisten Es kann unterschiedliche Gründe geben einen DNS-Server zu nutzen, der mit Schwarzen Listen arbeitet, also bestimmte Anfragen an Webseiten nicht auflöst. So können gezielt Werbetreibende blockiert werden (siehe auch: Werbeblocker), auch gibt es Anbieter die versprechen die Cybersicherheit oder die Privatsphäre zu verbessern. Das Blockieren von nicht jugendfreien Inhalten ist ein weiterer Einsatzzweck. Technisch betrachtet handelt es sich bei der Verwendung von Filterlisten um eine Zensur von Inhalten. Die Grenzen zur Meinungszensur sind jedoch unscharf und werden subjektiv empfunden. Einige Anbieter führen Blocklisten über Fake-News-Websiten, die Kriterien nach denen die Einordnung erfolgt sind hierbei teilweise nicht offengelegt. Große Anbieter, die blockierende DNS-Server betreiben sind unter anderen: Quad9, Mullvad und Adguard. Die EU kündigte 2022 an, einen eigenen DNS-Server etablieren zu wollen (DNS4EU), dieser soll ebenfalls mit Filterlisten arbeiten und Netzsperren umsetzen. Namecoin Namecoin ist der erste Fork von Bitcoin aus dem Jahr 2011 und findet Anwendung als Kryptowährung sowie als Key-Value Store für Domainnamen und Identitäten. Als alternatives verteiltes Domain Name System (DNS) außerhalb des ICANN-Namensraumes werden Transaktionen zum Registrieren, Aktualisieren und Übertragen von Domains auf der Blockchain aufgezeichnet. Zur Auflösung der .bit Adressen werden ein Browserplugin oder ein lokaler Namecoin DNS-Server benötigt. Ebenso wie Bitcoin ist Namecoin ein dezentrales Peer-to-Peer-System, das keiner Zensur unterliegt. Die Software ist Open Source und wird auf GitHub gehostet. Einem Bericht von Trend Micro zufolge wurden .bit-Domains seit 2013 vermehrt auch von Cyberkriminellen genutzt. Vornehmlich aus diesem Grund hat das OpenNIC-Projekt im Sommer 2019 seine DNS-Auflösung von .bit Domains eingestellt. Nameserversoftware Auswahl bekannter Software für Namensauflösung. BIND (Berkeley Internet Name Domain) ist die meistgebrauchte Nameserversoftware und gilt als Referenzimplementierung der meisten RFCs zu DNS. Die erste Version von BIND war die erste öffentlich verfügbare Nameserver-Implementierung. CoreDNS ist ein in Go geschriebener DNS-Server der Cloud Native Computing Foundation. Bei djbdns hat der Autor Daniel J. Bernstein eine Prämie für das Finden von Sicherheitsproblemen ausgeschrieben. Djbdns wird von Bernstein nicht mehr weiterentwickelt, weil er es als fertig ansieht. Dnsmasq ist ein Nameserver und DHCP-Server mit eingeschränkter Funktionalität. Es werden die Namen aus dem lokalen Netz entsprechend /etc/hosts aufgelöst. Dnsmasq verfügt über keinen vollständigen Resolver: unbekannte Namensanfragen werden weitergeleitet und im Cache gespeichert. Knot DNS ist ein autoritativer Nameserver, der von CZ.NIC entwickelt wird, dem Betreiber von .cz. Microsoft Windows DNS ist eine der wenigen kommerziellen Nameserver-Implementierungen als Teil der Produktreihe Microsoft Windows Server. Der Nameserver unterstützt dynamische Updates, Zonentransfers und Notification. Zonendaten können in den aktuellen Versionen im Active Directory oder in Zonendateien gespeichert und repliziert werden. Name Server Daemon ist ein autoritativer Nameserver, der zum Einsatz als Top-Level-Domain- und Root-Nameserver entwickelt wurde. NSD kompiliert Antworten statisch vor, um die Server-Performance zu optimieren. Dynamische Zoneninhalte oder Round Robin werden nicht unterstützt. PowerDNS ist ein Nameserver, der Zonen aus SQL-Datenbanken, LDAP-Verzeichnissen und anderen Backends lesen kann. PowerDNS begann als kommerzielle Implementierung und ist seit 2002 unter der GPL lizenziert. Unbound ist ein DNS-Resolver, der DNSSEC-Validierung und Caching unterstützt. Unbound kann als Softwarebibliothek in Anwendungen eingebunden werden. Weblinks RFCs Multicast DNS Funktionsweise und Verwaltung des DNS als Poster Beiträge des Chaos Computer Clubs Zensur durch DNS-Server: DNS Howto Podcast zum Thema DNS: Chaosradio Express 099 – Domain Name System Julia Evans: Life of a DNS query. Wizard Zines (DNS-Abfrage als Comic) Einzelnachweise Internet-Anwendungsprotokoll Internetstandard