Diskussion:Domain Name System/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Domain Name System/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Domain_Name_System/Archiv#Thema_1

Nicht-Eindeutigkeit?

'ein hierarchisches Datenbank(System) zur (eindeutigen) Benennung' wieso ist DNS zu einem Zeitpunkt nicht eindeutig? Das die DNS-Implementierung eine Datenbank ist, ist ja wohl irrelevant. --Walter (nicht signierter Beitrag von gw.phinware.de (Diskussion | Beiträge) 05:26, 21. Aug. 2002‎ (CEST))

"Quelloffen" vs. "open source"

Sollte man nicht quelloffen zu open source ändern? Ich denke das ist auch auf anderen Wikipedia seiten gang und gebe, ich denke der name open source ist mittlerweile eingedeutscht ;) (nicht signierter Beitrag von 212.130.239.102 (Diskussion) 11:43, 28. Sep. 2006‎ (CEST))

DNS, WINS und Active Directory

Im Artikel heißt es: "Unter Windows gibt es den Dienst WINS, der eine ähnliche Funktion zur Verfügung stellt, allerdings ein ganz anderes Protokoll verwendet. WINS wurde durch Active Directory abgelöst und gilt heute als veraltet."

Das ist so nicht richtig. Richtig ist, dass WINS eine Windows-Implementierung des NetBIOS-Nameservice ist (es gibt auch andere), die NetBIOS-Namen (nicht Host- oder DNS-Namen!) zu IP-Adressen auflöst. Nicht richtig ist, dass WINS durch Active Directory abgelöst wurde - AD ist ein Verzeichnisdienst und keine Namensauflösung. Ich schlage folgende Formulierung vor:

"Besonders in Windows-Netzwerken wurde und wird parallel zu DNS der ältere serverbasierte WINS-Dienst eingesetzt, der NetBIOS-Namen zu IP-Adressen auflöst und damit eine ähnliche Funktion erfüllt wie DNS. WINS nutzt allerdings ein anderes Protokoll sowie einen nicht gegliederten Namensraum. Mit der Einführung von Windows 2000 hat WINS an Bedeutung verloren, weil Windows alle Namensauflösungen zunächst über DNS zu erfüllen versucht und erst bei Fehlschlagen auf WINS zurückgreift. In der Praxis wird meist trotzdem ein WINS-Server eingesetzt, weil sich mit ihm Namensauflösungsprobleme vermeiden lassen, die vor allem durch ältere oder weniger sorgfältig entwickelte Anwendungsprogramme verursacht werden."

Nils Kaczenski (nicht signierter Beitrag von 217.110.85.2 (Diskussion) 16:06, 30. Mai 2007‎ (CEST))

Grafik der Protokollschichten

Die Grafik der Protokollschichten beinhlatet meines Erachtens einen Fehler. Das UDP Protokoll steht nicht gleichberechtigt neben TCP/IP sondern TCP/IP basiert auf dem UDP Protokoll. Die unsicheren Pakete des UDP Protokolls werden bei TCP/IP durch eine Rückantwort gesichert. (nicht signierter Beitrag von 80.152.153.170 (Diskussion) 10:08, 29. Aug. 2007‎ (CEST))

"Domain Name System" vs. "DNS"

Habe eine Anregung, der Artikel ist soweit nicht richtig, da Der Domain Name System kein Dienst ist sondern die Grundlage für den gleichnamigen Domain Name Service (auch DNS) bildet. Das heißt was hier in dem Artikel beschrieben wird ist der eigentliche Dienst, also der Domain Name Service. Andreas

-> Nein, Laut Cisco Systems Inc.: Internetworking Technologie Handbook ist das Akronym DNS gleichbedeutend mit Domain Name System. Ben (nicht signierter Beitrag von 77.134.82.123 (Diskussion | Beiträge) 18:31, 10. Mär. 2009 (CET))

---

"Nameserver": Hardware oder Software?

Ist ein "Nameserver" nicht eher eine Maschine, auf dem die Namerserver-Software läuft ?

Nein. Ein Nameserver kann Hardware sein, in diesem Fall ist der Nameserver aber ein Stück Software das für die Auflösung von Namen benötigt wird. -- jjanis 13:37, 18. Mai 2003 (CEST)

---

Rolle von DENIC?

Was das DENIC (siehe Weblinks) mit dem DNS zu tun hat ist mir nicht ganz klar ... Das DENIC ist die Vergabestelle für .DE Domains. Die beiden Links scheinen mir auch willkürlich gesetzt zu sein, und dienen meiner Ansicht nach nicht zur Vertiefung des Themas. -- jjanis 15:45, 16. Mai 2003 (CEST)

In der DENIC-FAQ stehen ein paar allgemeine Worte (in deutsch) zum Hintergrund von IP-Adressen und Domains, ohne allerdings auf die technischen Hintergruende einzugehen.

Der Artikel mit den Bindestrichen bezieht sich auf die kuenftige Codierung von internationalen Domainnamen. HaJo Gurt 16:47, 16. Mai 2003 (CEST)

Das DNS ist nicht alleine für Domains da. Daher passt meiner Meinung nach ein Link auf eine Seite die Informationen über DE-Domains und IP Adressen gibt nicht besonders. Der Artikel mit den Bindestrichen ist eine Pressemeldung, daß solche Namen vorerst nicht mehr bei der DENIC registriert werden können. Dieser Artikel beschreibt die Punnycodes nicht. Daher denke ich, daß die beiden Links gestrichen werden sollten. Dieser Artikel behandelt das DNS und nicht Domains ... das ist ein bisschen was anderes. -- jjanis 13:37, 18. Mai 2003 (CEST)

---

Was hat das DENIC mit dem DNS zu tun? Im Artikel kommt die Philosophie des DNS zu kurz. Auch dass DNS vom MIT-Projekt ATHENA definiert wurde (das auch X11 und Kerberos hervorbrachte), wird nicht erwähnt. Die DNS-Philosophie ist die der Delegation von Domains (=Namensräumen). Die IANA ist für Toplevel-Domains zuständig. Sie kann diese selbst verwalten (z.B. .int) oder verteilen. .net wurde glaub ich an Verisign Inc. vergeben und DENIC hat eben .de. DENIC kann dann wieder Domains selbst verwalten oder weiter delegieren. Die Uni Ulm hat z. B. uni-ulm.de. Der Domainverantwortliche kann dann Teile selbst verwalten (z. B. rz.uni-ulm.de) oder weiter delegieren (z. B. mathematik.uni-ulm.de). Der Verantwortliche von mathematik.uni-ulm.de kann es dann ebenso machen bis zu jeder beliebigen Tiefe. DENIC (Deutsches Network Information Center) hat also z. Zt. die Kompetenz zur Verwaltung von .de-Domains und das Delegationsrecht. Durch diese Delegationen wird der Namensraum erst wartbar. Falls ein Verantwortlicher Murks macht, kann ihm das Recht entzogen werden. Dadurch funktioniert das Internet, wenn an oberster Stelle integre Personen sitzen, die genügend vertrauenswürdige Prsonen finden. Wenn das DENIC eine Domain vergibt, verlangt es, dass mindestens zwei Nameserver für die neue Domain zur Verfügung stehen. Dafür kann man selbst sorgen oder es seinem Provider überlassen. Damit garantiert das DENIC in gewisser Weise die Funktion des .de-Bereichs im Internet-DNS Service. Also was hat das DENIC mit dem DNS zu tun - sehr viel Hubi 19:54, 15. Okt 2003 (CEST)

Vielleicht sollte noch etwas zum Thema Dynamisches DNS und IPv6 stehen, fände ich ganz gut. Gerald

---

Habe folgendes im Internet gefunden: Anmerkung: In der Literatur finden Sie die Bezeichnungen Domain Name System und Domain Name Service. Im Grunde meinen beide einunddasselbe. Domain Name System bezeichnet genau genommen die Methode der Umsetzung von IP-Adressen in symbolische Namen. Die technische Umsetzung hingegegen, also alle Routinen zusammen genommen, die das System implementierten, formen einen Dienst - den Domain Name Service. Der Praktiker spricht also vom Service und der Theoretiker vom System.

Wäre es da nicht bessre beide Abkürzungen zu erwähnen? Smuker 10:18, 27. Jul 2004 (CEST)

DNS-Protokoll

Eine gute Zusammenfassung bzgl. der Protokollstruktur: DNS Packet Structure. (nicht signierter Beitrag von 92.230.185.51 (Diskussion | Beiträge) 15:55, 5. Feb. 2010 (CET))

Wer bezahlt die DNS-Server

Hallo, mal eine Frage, wer bezahlt eigentlich die Unterhaltskosten der DNS-Server? -- Wikinator (Diskussion)

Der Betreiber --Qbi 23:14, 17. Sep 2005 (CEST)

Wer ist der Betreiber und wieso macht er das überhaupt? -- Wikinator (Diskussion) 21:46, 20. Sep 2005 (CEST)

Betreiber kann mehr oder weniger jeder sein. So kannst auch du dich entscheiden einen derartigen Server aufzusetzen. Die Gründe hierfür sind vielfältig und man kann eine beliebig lange Liste aufschreiben. --Qbi 00:13, 21. Sep 2005 (CEST)

Na los, fang schon damit an, die Liste aufzuschreiben, nur zu! 84.59.128.56 19:43, 17. Apr. 2010 (CEST)

Häufig haben auch die Provider eigene DNS Server. (nicht signierter Beitrag von 213.39.222.85 (Diskussion | Beiträge) 05:26, 26. Jan. 2010 (CET))

Die root-DNS Server werden zum beispiel von der Regierung finanziert (US-Regierung, und davon das Militär. Das Internet ist ja eine Erfindung des Militärs.) (nicht signierter Beitrag von 77.134.82.123 (Diskussion | Beiträge) 18:31, 10. Mär. 2009 (CET))

---

link auf NDS entfernt -- zeigt auf das "Nassi-Shneiderman-Diagramm" was in dem zusammenhang total falsch ist.. :-) --Zwiskle 12:38, 2. Apr 2006 (CEST)

Zulässige Namen/Label

Ein kompletter Domainname eines Objektes besteht aus der Verkettung aller Labels. Label sind Zeichenketten (alphanumerisch, als einziges Sonderzeichen ist '-' erlaubt), die mindestens ein Zeichen und maximal 63 Zeichen lang sind.

Damit wäre www.4u.de ein zulässiger Name. Wenn ich aber den RFC richtig lese, muss das erste Zeichen ein Buchstabe sein, oder? --Marc van Woerkom 01:52, 13. Apr 2006 (CEST)

Die RFC spricht nur von preferred Syntax und should. Namen wie www.4u.de sind nicht unzulässig und teilweise sogar im Gebrauch (z.B. www.2legs.de). Software wie telnet, die IP-Adressen und Hostnamen als Parameter erlauben, haben dann ein Problem, da 134.60.1.111 ja genaugenommen auch ein Domainname sein kann. Unter Unix/Linux wenden sie zunächst die Library-Funktion inet_addr, und falls die ok sagt, liegt eine IP-Adresse vor. Andernfalls wird das Domainnamesystem gefragt. Also gilt hier: alles was so ausschaut wie eine IP-Adresse ist eine, alles andere müsste eine Domain sein. --Hubi 10:33, 13. Apr 2006 (CEST)

Ich finde, der Text gehört unbedingt geändert. Daß DNS nur a-z 0-9 und - könnte, ist einfach nicht richtig. Die Einschränkung auf diesen Zeichensatz dient nur der Kompatibilität mit den alten hosts-Dateien und den auf deren Regeln beruhenden RFCs (mail) und Programmen. Das DNS selbst kann das volle 8Bit-Spektrum - mit Einschränkungen bei der Gleichsetzung von Klein- und Großbuchstaben. --At 00:29, 16. Nov 2006 (UTC)

Zahlenkolonnen vs. Worte

Kann man das wirklich pauschal für alle Menschen sagen, dass sich Worte besser einprägen lassen als Zahlen?

Ist es legitim, wenn wir an entsprechenden Stellen das Wort >>meisten<< einfügen? -- Tux-fg 15:45, 29.07.06 (CEST)

Das kann man mE pauschal so sagen, insbesondere wenn man viele davon unterscheiden muss. Ausnahmen sind möglicherweise Autisten oder anderweitig Hochbegabte, das sind absolute Ausnahmen, wenn überhaupt. Das Attribut meisten ist nicht gerechtfertigt. --Hubi 16:10, 29. Jul 2006 (CEST)

Zonentransfer bzw. Primary/Secondary Nameserver: tw. veraltet

Für jede Zone existiert mindestens ein autoritativer Server, der Primary Nameserver.

Die Synchronisation zwischen Primary und Secondary Nameservern erfolgt per Zonentransfer.

Das Konzept mit Primary und Secondary Nameserver wird oft so nicht umgesetzt. Speziell bei ISPs oder derlei werden die Zonendaten aus einer Datenbank generiert, die meist nicht selbst DNS-Server ist. Damit ist das Konzept des Primary Nameservers hinfällig, da der gedankliche Inhalt der primaeren Quelle in die Datenbank übersiedelt ist, die aber mit dem DNS nicht direkt etwas zu tun hat. Die autoritativen Nameserver holen sich die Zonen oder die einzelnen Responses direkt von der Datenbank, ohne dass einer davon primärer wäre, als die anderen. Damit gibt es auch keinen zone transfers mehr. Dort, wo es noch so etwas gibt, werden sie oft per rsync oder anderen Verfahren abgewickelt (siehe die Doku zu diversen Realtime Blacklists).

Für den zone transfer schlage ich etwa folgende Formulierung vor:

Zur Synchronisation zwischen primary und secondary nameserver ist im DNS der zone transfer spezifiziert, jedoch werden häufig andere Synchronistationsmethoden (z.B. rsync) verwendet oder die Nameserver beziehen ihre Informationen direkt aus einer Datenbank. --At 00:29, 16. Nov 2006 (UTC)

A-Recordlastigkeit - es fehlen MX, PTR, CNAME, AAAA, SRV, TXT

Ich habe das Gefühl, der Artikel vermittelt den Eindruck, bei DNS gehe es (fast) nur um die Auflösung von Hostnamen. Spricht irgendetwas dagegen, dem Reverse Lookup, dem Mailserver-Lookup mehr Gewicht zu verleihen? Ich schlage vor, wenigstens PTR und MX unter Aufbau der DNS-Datenbank zu erklären. AAAA ebenfalls, läßt sich sehr kurz fassen. TXT Records sollten wegen des Einsatzes in Blacklists erwähnt (und dort entsprechend referenziert) werden. Über die Wichtigkeit von SRV, NAPTR kann man imho streiten. Wenn es keine Einwände gibt, würde ich etwas dazu dichten. --At 10:31, 16. Nov 2006 (UTC)

Es wäre schön, wenn du eine Liste der möglichen Recordtypen aufführen und diese kurz erläutern würdest. Bisher werden die Typen zwar im Artikeltext verwendet, aber nicht erklärt. --87.78.150.47 11:18, 25. Nov. 2006 (CET)

Hab's doch noch gefunden. Was ich meinte ist so etwas wie Resource Record. --87.78.150.47 11:22, 25. Nov. 2006 (CET)

Spamabwehr

Das Thema kommt doppelt vor (einmal unter Aufbau der DSN-Datenbank und einmal unter DNS-Security) und sollte zusammengefaßt werden.--At 18:31, 16. Nov. 2006 (CET)

---

Dem Absatz:

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.

liegt wohl ein Mißverständnis zugrunde. Gemeint war offenbar, daß die Absenderdomain einen MX oder A-Record haben muß. Das ist notwendig und hinreichend, um zu verhindern, daß Spammer nichtexistente Domains als Absenderdomain verwenden. Da ein Spammer aber genausogut jede beliebige existierende Domain in seinen Spam schreiben kann, ist dieser Spamschutz weitgehend wirkungslos. Die Überprüfung ist vor allem aus einem anderen Grund hilfreich: Ein User, der sich beim Konfigurieren seines Mailklienten vertippt hat, sieht beim Versenden der Nachricht eine Fehlermeldung und kann den Fehler korrigieren; andernfalls würde die Nachricht zwar den Empfänger erreichen, dieser könnte aber nicht erfolgreich darauf antworten. Bei z.B. sendmail default seit mindestens V. 8.9, abzuwählen durch das FEATURE(accept_unresolvable_domains).

Zu erwarten, daß der Reverse Lookup des Mailexchangers einer Absenderdomain mit dieser übereinstimmt, würde MX-Records überflüssig machen und ist Unsinn. Zum Beispiel müßte dann gmx.at abgewiesen werden, weil der reverse lookup der MX-Records auf mx0.gmx.net und mx0.gmx.de lautet, also nicht übereinstimmt.--At 18:31, 16. Nov. 2006 (CET)

Du hast schon mal an AOL-Empfänger eine E-Mail verschickt, die dem Reverse Lookup standhält? Lehmi 02:27, 17. Nov. 2006 (CET)

Ich bin gerade über den gleichen Satz gestolpert und habe versucht, die Behauptung zu verifizieren.

Für den Fall web.de komme ich, wie die beiden Vorposter, auch zu unbefriedigenden Ergebnissen und möchte mich deren Bitte um Korrektur aus den o. a. Gründen anschließen.

--82.139.211.34 20:08, 21. Mär. 2009 (CET)

---

Bei Blacklisten werden nur domainnamenbasierte Blacklisten beschrieben. Diese sind aber (wegen der Fälscherei) beim Filtern weitgehend bedeutungslos (z.B. auf rfc-ignorant.org). Eher wird mail gefiltert, die von einem auf einer Schwarzen Liste vermerkten Rechner (der Test erfolgt ähnlich dem reverse lookup) versendet wurde (MAPS, SBL, SPAMCOP etc). Weiters gibt es URL-Blacklists (z.B: SURBL)--At 18:31, 16. Nov. 2006 (CET)

---

Query-ID ?? Transaction-ID? --> frei wählbare 16-Bit Zahl im DNS-Message Header. Sollten diese Begriffe nicht geklärt werden?

warum eigentlich aufgelöst und nicht "umgewandelt"

wäre es nicht verständlicher umgewandelt zu sagen das würden dann auch alle verstehen aufgelöst hört sich so fachlich an?!

Wir wollen doch fachlich sein, oder? ;-) Wandelst du einen Knoten in einem Seil um oder löst du ihn auf? Auch wenn der Vergleich ein bisschen wie Quasimodo (hinkend) rüberkommt, im allgemeinen wird "auflösen" verwendet. Man könnte auch "umwandeln" schreiben. Aber: "umwandeln" impliziert mMn nicht unbedingt das "in Ordnung bringen" sondern nur das "ändern" einer Tatsache, was ja eben auch nicht in Ordnung sein kann. Oi, jetzt habe ich mich selbst verwirrt. Egal, Beiträge bitte mit 4 gschwungenen Bindestrichen (~) unterschreiben. Igelkuesser 11:44, 22. Jun. 2007 (CEST)

Zu 'DNS und Lastverteilung'

'Im Idealfall wertet der Client die TTL aus; viele Browser oder Mailclients tun dies allerdings nicht.' Zumindest unter Windows ist das eigentlich nicht die Aufgabe des Clientprogrammes, sondern des Clientbetriebssystems. Und Windows wertet das aus, sodass eigentlich die meisten Programme das auch indirekt auswerten sollten, außer diejenigen natürlich, die das Rad neu erfunden haben. Hier wären aber Beispiele oder aber ein Link mit Beispielen angebracht. Lofote 15:21, 15. Nov. 2007 (CET)

irgendetwas fehlt bei den Beispielen

ich nutze gerade linux und habe weder "dig" noch "host" - was sollen das denn für beispiele sein? --217.84.56.101 10:45, 29. Apr. 2008 (CEST) Dann frag mal deinen Admin.. --77.185.159.70 10:38, 28. Nov. 2008 (CET)

Zum Thema Beispiele, könnte man das mal einheitlich machen, entweder (*).wikipedia.org durchgehend verwenden oder example.com(laut rfc) aber bitte nicht irgendwelche Webhoster wie ipxserver.de, Danke.

Software : UltraDNS

Ich bin für die Entfernung des Eintrags: a) es ist ein Service b) Verdacht auf Werbung --77.185.159.70 10:36, 28. Nov. 2008 (CET)

DNS ist doch eher zentral als dezentral

Ich würde DNS als eine "zentrale Verwaltung" betrachten. Die DNS-Einträge werden zentral auf Servern verwaltet. Natürlich sind es mehrer/viele Server, aber in großen Strukturen sind natürlich immer mehr Server zuständig. Dezentral wäre aus meiner Sicht die NetBIOS-Namensvergabe, da Sie auf den einzelnen Clients geschieht.

-> nein, die DNS-Server-Topologie ist dezentral. dezentral wird in der Fachliteratur auch immer genutzt, wenn eine Serverfarm eine Funktion ausführt. Es geht dabei darum, ob es ein! Server ist oder mehrere Computer. Diese Computer können zwar eine! Funktion ausführen sind aber dezentral. Verteiltes (dezentrales) High Performance Computing erfüllt auch eine Aufgabe/Funktion mit mehreren Hosts, heißt aber trotzdem nicht zentral. Siehe Beispielsweise dezentrales Netzwerkmanagement, etc. (nicht signierter Beitrag von 77.134.82.123 (Diskussion | Beiträge) 18:31, 10. Mär. 2009 (CET))

"Domain-Namensraum" -> Labels

Im Moment steht ja "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“)." drin - das kann ja nicht mehr auf dem neusten Stand sein, oder? Schließlich gibt es mittlerweile auch Adressen mit Sonderzeichen drin. Kann jemand mit Fachwissen da vielleicht das mal ändern bzw. kurz anmerken, wie die Sonderzeichen entsprechend der RFC aufgelöst werden?-- Mor‣gil 21:16, 28. Mär. 2009 (CET)

DNS-Umbiegungen statt Fehlermeldungen bei Providern

Bei immer mehr Providern scheint die Unsitte umzugehen, bei nicht existierenden DNS-Namen statt einer Fehlermeldung eine Adresse im eigenen Netz anzugeben, damit – falls ein Webbrowser die DNS-Anfrage ausgelöst hat – dieser dann auf einer Seite vom Provider landet, statt eine Fehlermeldung anzuzeigen.

Problematisch hierbei ist, dass eben Internet nicht nur "Websurfen" ist. Hat man sich bei einer e-Mail in der Empfängeradresse vertippt, landet die Mail nun stillschweigend beim Provider, oder der Nutzer erhält die verwirrende Fehlermeldung, dass der Mailserver nicht erreichbar sei. Bei anderen Diensten können die Schäden noch viel gravierender sein.

Kann jemand nichtmal dazu was schreiben? --RokerHRO 01:28, 4. Feb. 2011 (CET)

Hinweis: Der letzte Absatz im Artikel VeriSign handelt von etwas relativ Ähnlichem. --YMS 01:45, 4. Feb. 2011 (CET)

DNS und nicht allgemeine Namensauflösung

"Resolver sind einfach aufgebaute Software-Module, die auf dem Rechner eines DNS-Teilnehmers installiert sind und die Informationen von Nameservern abrufen können. " können aber auch komplexe Software-Module sein, die alles Mögliche über verschiedene Wege auflösen können, findet man z.B. bei PCs und Servern.

"Aufbau der DNS-Datenbank" sieht sehr "bind"-spezifisch aus.

"Auflösung eines DNS-Requests" schreibt "beschrieben, wie dies ablaufen könnte". Kann aber auch ganz anders ablaufen.Der Teil sollte weg, inbesondere punkt 1: "Der Rechner X sucht in seiner Hosts-Datei", entweder weg (geht hier um DNS, nicht um allgemeine Namensauflösung, die neben hosts (was in resolv.conf übrigens "files" heißt) auch NIS, LDAP oder sonstwas benutzen kann, oder klar als Beispiel nennen, aber das tut dann nichts zur Sache.

Weiterhin kann man noch viel mehr als nur Hostnamen auflösen (selbst DNS).

Steffen 15:22, 10. Nov. 2011 (CET)

dynamisches DNS

in "Dynamisches DNS":

"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. "

Das ist doch schlicht falsch. Natürlich kann man es aufwändig und manuell machen, aber das kann man nicht als Regel auslegen. Die ISP, die ich kenne, ändern manuell keine Zonefiles sondern verwenden dazu Benutzerschnittstellen und Werkzeuge. Sind Verzögerungen durch Caching gemeint? Dauer ist konfigurierbar und gilt i.d.R. nicht für neue Namen. Von RRs, die man ändern möchte, kann man die TTL vorher reduzieren, alte TTL warten und kann danach mit schneller Verteilung rechnen (z.B. eine Minute). Eine Minute Verzögerung habe ich oft auch bei dynamischen DNS.

"In Zusammenhang mit DHCP ist Dynamisches DNS nahezu zwingend erforderlich, da einem User häufig neue IP-Adressen zugewiesen werden." ist einfach nur falsch. Ich kenne viele Netze, wo DHCP ohne dynamisches DNS verwendet wird. Man kann IPs fest zu Ethernet-MAC-Adressen zu ordnen oder kleinen Geräten keinen DNS-Namen geben

"Das Dynamische DNS gilt als Sicherheitsrisiko, da ohne spezielle Vorkehrungen jedermann DNS-Einträge löschen oder verändern kann." Konfigurationen jeder Art, die nicht von "speziellen Vorkehrungen" geschützt sind, sind ein Sicherheitsrisiko. Auch ein DNS Root Server mit leerem root-passwort. Tut also nichts zur Sache, am besten raus.

Kann man den gesamten Abschnitt nicht ersetzen gegen: "Mit Dynamischem DNS sind schnelle Änderungen durch Senden eines entsprechenden DNS-Requests möglich."

Steffen 15:22, 10. Nov. 2011 (CET)

Erweiterung des DNS / Spamabwehr

Zu welchem Namen wird hier der MX-Record ermittelt? Soweit mir bekannt ist, wird lediglich der A-Record des im HELO genannten Servers ermittelt, und mit der IP des anfragenden Systems verglichen. Anschließend wird überprüft, ob der PTR zu dieser IP dem im HELO genannten Namen entspricht. Alles Andere ergibt keinen Sinn, da die sendenden Server in der selbst keine MX-Einträge besitzen. Diese werden meist nur auf der Basis-Domain definiert, und können dann auf völlig andere Server zeigen, welche die eingehenden Mails verarbeiten.

Beispiel: Ein Webhoster hat 5 Webserver. Von diesen Servern werden über Scripte versendete Mails verschickt. Jeder dieser Server hat eine Subdomain beim Hoster, diese enhalten jedoch keine MX-Records. Eingehende Mails an den Hoster werden mit Hilfe eines MX auf einen dedizierten Mailserver geleitet.

--Bachsau 14:48, 16. Nov. 2011 (CET)

8.1.5 Offener DNS-Server

'Eine zusätzliche Sicherheitsmaßnahme ist es, für Input von außen nur UDP zuzulassen.' Warum soll das sicherer sein? -> Bitte Begründung angeben bzw. als Quelle verlinken. Lofote 11:21, 28. Sep. 2007 (CEST)

Wofür steht "ICCP DP"? Bitte Erklärung / Quelle angeben bzw. verlinken. (nicht signierter Beitrag von 91.4.159.41 (Diskussion) 18:17, 17. Jan. 2012 (CET))

Mängel

Trotz inhatlicher Richtigkeit ist dieser Artikel zu großen Teilen zu unverständlich geschrieben. Ein unerfahrener Leser würde besonders im hinteren Teil des Artikels kein Wort mehr verstehen. Bitte ändern!

Außerdem würde ich auch gerne erfahren, wie denn nun die realen, physischen DNS-Server aussehen und wo die stehen - also nicht nur was sie machen. Danke! --Alleskoenner ✉ 13:21, 1. Mai 2012 (CEST)

Kannst du die unverständlichen Teile etwas konkreter benennen? DNS-Server oder Nameserver sind Softwarekomponenten, die auf Hosts ausgeführt werden. Hosts sind physische Computer, die Nameserver, Webserver, Mailserver oder sonstige Server beherbergen und ausführen. Hosts stehen in Rechenzentren, Serverräumen oder zu Hause. Wie ein DNS-Server (oder genauer gesagt: sein Host) aussieht, ist damit sehr unterschiedlich: Computercluster, Desktop-Computer, Heimrouter, ... --Matthäus Wander 16:56, 1. Mai 2012 (CEST)

RFCs für Beispiele

Die Beispiele für Domains und IP-Adressen sollten anhand folgender RFCs gewählt werden:

• RFC 2606: Reserved Top Level DNS Names
• RFC 3849: IPv6 Address Prefix Reserved for Documentation
• RFC 5737: IPv4 Address Blocks Reserved for Documentation

--Fomafix (Diskussion) 23:13, 27. Jun. 2012 (CEST)

DNS und IT-Netzwerke ?

Es gibt nicht nur das Internet als "IT-Netzwerk". Soweit ich weiß, ist DNS lediglich im TCP/IP-Protokoll definiert. Daher habe ich in der Einleitung den Link auf IT-Netzwerk entfernt und durch Internet Protocol (TCP/IP) ersetzt.

ATLANTIS (Diskussion) 20:54, 9. Dez. 2012 (CET)

Ich wollte es gerade zurücksetzen, aber ein Kollege hatte das schon erledigt. IT-Netzwerk beinhaltet Internet und lokale Netze, ist also die allgemeinere und richtige Aussage.--Lex parsimoniae (Diskussion) 21:09, 9. Dez. 2012 (CET)

ICCP DP?

In Domain_Name_System#Offener_DNS-Server wird auf "ICCP DP" verwiesen. Dieser Ausdruck ist weder erläutert noch liefert eine Suche nach diesem Ausdruck irgendwelche Informationen. Kann man ihn löschen? (Dies wurde bereits vor über einem Jahr bemerkt, es scheint aber nichts geschehen zu sein.) --MarcelToo (Diskussion) 15:40, 15. Mai 2013 (CEST)

Soeben entfernt, ist wohl Quatsch. Auch der Hinweis, von außen nur UDP zuzulassen, ist Unfug: der Angriff ist nur über UDP möglich. --Matthäus Wander (Diskussion) 20:52, 15. Mai 2013 (CEST)

Wertungen/NPOV

• ist ein Nameserver, bei dem die Entwickler besonderen Wert auf Sicherheit legen - sagt wer? Die Entwickler? Der TÜV? Und sagen die es nur, oder ist es wirklich so? Welche Sicherheit genau? Getestet wie und von wem? Mit welchem Ergebnis?
• aber extrem sicher und stabil Wie extrem genau? Im Vergleich wozu? Beurteilt wer nach welchen Maßstäben und in wessen Auftrag?

So wie es dasteht, sind es beliebige Behauptungen, die eher aus einem Werbeprospekt stammen.

A propos Werbeprospekt:

• UltraDNS ist ein kommerzieller managed DNS Service von NeuStar Ultra Services. Diese Firma bietet auch ein DNSshield an, das DNS in einer Alliance mit verschiedenen ISPs absichert und ist damit spezialisiert auf DNS großer Webseiten. Auch ein Teil der Root-Level-DNS ist hier gesichert. Das Internet Systems Consortium (ISC) sichert den F-Root Server hier ab.

Mal abgesehen dass das der Beschreibung nach keine DNS-Software ist, sondern ein Hoster (der einzige? Wenn nein, warum gerade dieser?): Das hier klingt ja auch eher nach der Firmenhomepage als nach einem WP-Eintrag.

Bitte objektiver sein und/oder belegen, es war sicher keine böse Absicht, aber so gehört es hier nicht her. Danke! --Bierfaß (Diskussion) 02:19, 22. Mai 2013 (CEST)

Habe die Liste überarbeitet und den NPOV-Baustein entfernt. Bei ein paar Einträgen war ich mir nicht sicher, ob diese nennenswert verbreitet sind. Im Zweifel: Artikel zum Thema schreiben und hier verlinken. --Matthäus Wander (Diskussion) 20:26, 14. Jul. 2013 (CEST)

Darstellung der DNS-Hierarchie

Das Schema zur DNS-Hierarchie weißt eine verwirrende Inkonsistenz auf. Wenn ich den Artikel richtig verstanden habe, dann ist die erste Hierarchieebene des Fully Qualified Domain Names ein leerer String − einfach Nichts. Und dieses Nichts wird, wie bei allen anderen Labels auch, durch einen Punkt vom nachfolgenden Label, in diesem Fall der TLD getrennt. Das Schema erweckt nun den Anschein, als sei dieser Punkt, der ja nur zur Trennung dient, selber das erste Label. Ich finde, dass das geändert werden sollte. Außerdem könnten man überlegen, ob man die trennenden Punkte irgendwie in das Schema mit einbaut um es anschaulicher zu gestalten. (nicht signierter Beitrag von Renegar (Diskussion | Beiträge) 22:55, 22. Mär. 2007‎ (CET))

Domainnamensraum

Ich dachte, ein Domainnamen dürfte nur 63 Zeichen lang sein, wobei nur ein FQDN 255 Zeichen lang sein darf. - Ben (nicht signierter Beitrag von 91.47.138.24 (Diskussion) 13:02, 11. Feb. 2008‎ (CET))

DNS Server Angeben

Hallo ihr Wikijaner. Ihr hattet hier früher mal IP Adressen zu einem Offenen DNS Netzwerk. Ich habe letztens dringend IPs von offenen DNS Servern gebraucht und ewig nichts aktuelles gefunden. Habe jetzt das hier gefunden : http://www.opendns.com/ Könnt ja den Link auf der DNS Seite anbringen, das würde Leuten helfen die nicht eine Erklärung zu DNS suchen, sondern einen Server an sich. Gruß. (nicht signierter Beitrag von 91.40.54.195 (Diskussion) 14:06, 27. Nov. 2008‎ (CET))

DNS-Begriffserklärung fehlt

Nicht Computer-/Netz-affine Menschen denken bei DNS zuerst an Desoxyribonukleinsäure. Die vielen durchs Fernsehen geläufige DNA ist die Abkürzung der englischen deoxyribonucleic acid. Also sollte imho eine Begriffserklärung oder wenigstens ein Weiterleitungshinweis erstellt werden. --87.146.62.50 00:07, 25. Aug. 2014 (CEST)

DNS --Matthäus Wander 00:58, 25. Aug. 2014 (CEST)

DNS-Abfrage

Fehlt in der DNS Abfrage nicht der Schritt, in dem geprüft wird ob der Client selbst den angefragten Hostnamen hat? Noch bevor es an die Hosts-Datei geht? Und bevor die Anfrage an den DNS geht, wird doch auch der lokale DNS-Cache genutzt. --Pfmd86 (Diskussion) (10:40, 27. Jun. 2014 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Kommt auf den Resolver an, nicht jeder verwendet einen Cache (glibc z. B. nur mit Verwendung des nscd, sonst nicht). --Matthäus Wander 15:36, 27. Jun. 2014 (CEST)

Dann sollte das aber auch so in dem Artikel stehen. So wie es jetzt ist, fehlt der Cache im Ablauf völlig und das ist schlicht falsch. Windows benutzt übrigens IMMER einen Cache. (nicht signierter Beitrag von 80.147.52.105 (Diskussion) 10:05, 24. Nov. 2014 (CET))

DNS - Domain Name Service

DNS bedeutet nicht "Domain Name System" sondern "Domain Name Service". Es ist ein Dienst eines Servers und kein eigenes System. Arcania202 13:56, 13. Mai 2016 (CEST))

Die Benennung Domain Name System ist den referenzierten RFCs entnommen. Hast Du einen offiziellen Beleg für die Benennung Domain Name Service --Fomafix (Diskussion) 14:10, 13. Mai 2016 (CEST)

Laut RFC stimmt das. Die IANA sagt jedoch Domain Name Service (siehe Link: https://www.iana.org/domains). Grundsätzlich ist es ja ein Service der auf einem Server installiert wird und kein eigenes System. --Arcania202 (Diskussion) 10:58, 20. Mai 2016 (CEST)

Die IANA spricht an dieser Stelle allgemein von Domain Name Services. Überall, wo es um das DNS-Protokoll geht (wo wie auch hier in dem Artikel), spricht auch die IANA von Domain Name System (bspw. hier). --net (Diskussion) 17:50, 20. Mai 2016 (CEST)

Gesicherte DNS Varianten

Neben der im Artikel angegebenen gesicherten DNS Variante DNSsec fehlt die Angabe folgender gesicherter Varianten:

• DNS-over-TLS (DOT)
• DNS-over-DTLS
• DNS-over-HTTP[s] (DOH)
• DNSCrypt
• DNS-over-HTTPS (proxied)
• DNS-over-QUIC
• DNSCurve
• Quelle:
• https://blog.cloudflare.com/dns-over-tls-for-openwrt/
• https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+-+The+Solutions --185.183.104.138 01:56, 1. Jul. 2018 (CEST)

Es fehlen Informationen zum eigentlichen Protokoll

Wenn ich selber eine Anfrage an einen Nameserver stellen möchte, bspw. mit einem selbstgeschriebenen Programm, dann schreibe ich in mein C-Quelltext sicherlich nicht dig www.example.com, sondern mache vermutlich irgendeine Socket-Verbindung auf und erhalte eine wohldefinierte binäre Antwort und nicht die schön formatierten ASCII-Tabellen, die dig liefert. Dem Artikel fehlen ein paar grundlegende Informationen, wie das eigentliche DNS-Protokoll denn nun wirklich aussieht. Der Artikel dreht sich momentan nur darum, wie man "im (IT-)Alltag" mit DNS arbeitet, aber nicht, was es wirklich ist - der Abschnitt Domain_Name_System#Protokoll ist viel zu rudimentär gehalten, er binhaltet lediglich die Portnummer als echte Information, sollte aber eher ein Byte-Schema des Requests bzw. des Responses enthalten (vgl. IP-Paket). Die ganzen high-level tools wie dig stellen das ja nur schön dar und bieten ein gewisses User Interface. Man erklärt die grundlegende Funktionsweise relationaler Datenbanksysteme ja auch nicht, indem man Screenshots der MySQL Workbench zeigt und dazu sagt "das geht irgendwie über Port 3306". --2003:D1:13E5:D100:B1FC:3D15:DA4E:3B10 13:49, 2. Jul. 2018 (CEST)

Der Artikel verweist auf RFC 1034 und RFC 1035. Dort findest du alle Informationen die du brauchst. --FriedhelmW (Diskussion) 14:49, 2. Jul. 2018 (CEST)

DNS over HTTPS ändert das DNS-System grundlegend.

Folgendes mag' ich zu bezweifeln: DNS over HTTPS ändert das DNS-System grundlegend. Anfragen finden hier auf Anwendungsebene statt. Beim traditionellen DNS ist das DNS-Protokoll Payload eines UDP- oder TCP-Pakets, also auch da bereits in der Anwendungsebene. Dies passt auch zur Darstellung im Artikel User Datagram Protocol, dass DNS auf der Anwendungsebene listet. Zudem ist es keine grundlegende Änderung, gemäss aktuellem Draft wird ja lediglich was vorher als UDP-Payload übertragen wurde neu in HTTPS übertragen. Keine Änderung an der Semantik.

--BlackEyeGalaxy (Diskussion) 17:16, 3. Aug. 2018 (CEST)

TCP oder UDP sind doch nicht in der Anwendungsebene? Ansonsten: Lies die Original-Quelle. Ist ja eine angegeben. Dort steht das alles so drin. --TheRandomIP (Diskussion) 18:29, 3. Aug. 2018 (CEST)

TCP/UDP sind nicht in der Anwendungsebene, korrekt, sondern (wie im von dir verlinkten Artikel geschrieben) Layer 4 bzw. Transport. Hier geht es aber um DNS - die Queries/Replies werden als Payload in einem UDP/TCP Paket übertragen. Somit sind sie einen Layer höher. Listet auch die englische Wikipedia en:Internet_protocol_suite in der "Internet protocol suite" Tabelle so. --BlackEyeGalaxy (Diskussion) 15:34, 6. Aug. 2018 (CEST)

Neu ist, dass DNS als nächst tiefere Schicht HTTPS nutzt, das auf der Anwendungsebene ist. Früher wurde TCP/UDP genutzt, das ist auf System- bzw. Transportebene. Das kann man evtl. noch konkretisieren, aber darum geht es im Kern. Das heißt jetzt kann sich z.B. der Browser ganz alleine um DNS-Anfragen kümmern, und leitet die Anfrage nicht an das Betriebssystem weiter, wodurch DNS plötzlich ganz neue Möglichkeiten bekommt (gebündelte Anfragen, siehe den Artikel in der c't). --TheRandomIP (Diskussion) 19:39, 6. Aug. 2018 (CEST)