Diskussion:Domain Name System/Archiv

message: 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)
thread_title:  "Domain Name System" vs. "DNS" 

message: 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)
thread_title:  "Nameserver": Hardware oder Software? 

message: 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)
thread_title:  DNS-Protokoll 

message: Hallo,
mal eine Frage, wer bezahlt eigentlich die Unterhaltskosten der DNS-Server? -- Wikinator (Diskussion)
:Der Betreiber --Qbi 23:14, 17. Sep 2005 (CEST)
replies: text: Wer ist der Betreiber und wieso macht er das überhaupt? -- Wikinator (Diskussion) 21:46, 20. Sep 2005 (CEST)
replies: text: 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)

text: 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)
thread_title:  Wer bezahlt die DNS-Server 

message: :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)
replies: text: 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)
thread_title:  Zulässige Namen/Label 

message: 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)
thread_title:  Zahlenkolonnen vs. Worte 

message: :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)
thread_title:  Zonentransfer bzw. Primary/Secondary Nameserver: tw. veraltet 

message: 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)
replies: text: 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)
replies: text: Hab's doch noch gefunden. Was ich meinte ist so etwas wie Resource Record. --87.78.150.47 11:22, 25. Nov. 2006 (CET)
thread_title:  A-Recordlastigkeit - es fehlen MX, PTR, CNAME, AAAA, SRV, TXT 

message: 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)
thread_title:  warum eigentlich aufgelöst und nicht "umgewandelt" 

message: '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)
thread_title:  Zu 'DNS und Lastverteilung' 

message: 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)
thread_title:  irgendetwas fehlt bei den Beispielen 

message: 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)
thread_title:  Software : UltraDNS 

message: 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)
thread_title:  DNS ist doch eher zentral als dezentral 

message: 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)
thread_title:  "Domain-Namensraum" -> Labels 

message: 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)
replies: text: Hinweis: Der letzte Absatz im Artikel VeriSign handelt von etwas relativ Ähnlichem. --YMS 01:45, 4. Feb. 2011 (CET)
thread_title:  DNS-Umbiegungen statt Fehlermeldungen bei Providern 

message: "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)
thread_title:  DNS und nicht allgemeine Namensauflösung 

message: 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)
thread_title:  dynamisches DNS 

message: 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)
thread_title:  Erweiterung des DNS / Spamabwehr 

message: '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)
thread_title:  8.1.5 Offener DNS-Server 

message: 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)
replies: text: 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)
thread_title:  Mängel 

message: 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)
thread_title:  RFCs für Beispiele 

message: 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)
replies: text: 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)
thread_title:  DNS und IT-Netzwerke ? 

message: 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)
replies: text: 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)
thread_title:  ICCP DP? 

message: * 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)
replies: text: 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)
thread_title:  Wertungen/NPOV 

message: 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)
replies: text: DNS --Matthäus Wander 00:58, 25. Aug. 2014 (CEST)
thread_title:  DNS-Begriffserklärung fehlt 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  DNS-Abfrage 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  DNS - Domain Name Service 

message: 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)
thread_title:  Gesicherte DNS Varianten 

message: 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)
replies: text: 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)
thread_title:  Es fehlen Informationen zum eigentlichen Protokoll 

message: 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)
replies: text: 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)
replies: text:  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)
replies: text: 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)
thread_title:  DNS over HTTPS ändert das DNS-System grundlegend.