Diskussion:Domain Name System

'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

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 ;)

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)

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)

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

Letzter Kommentar: vor 18 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

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)Beantworten

Spamabwehr

Letzter Kommentar: vor 18 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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?!