<\/p>\n\n\n\n
Warum ich das erzähle?<\/h2>\n\n\n\n
Im nächsten Beitrag werden wir uns mit einem Produkt beschäftigen, das uns das Leben sehr viel einfacher machen kann und uns womöglich von den Werbeheinis und ich will-alles-von-dir-wissen Leute etwas befreien kann.
Aber schauen wir uns an, was DNS kann und wie es arbeitet.
<\/p>\n\n\n\n
Die Domain<\/h2>\n\n\n\n
mit der Einführung war auch bald eine Organisation der Namen vorgesehen. So wurden bald der Begriff TLD<\/a> und FQDN<\/a> geboren. Und damit wurde auch eine Aufteilung in<\/p>\n\n\n\n Jede Domain gehört einer Zone an, für diese Zone ist ein root<\/a> Server<\/a> zuständig, der die Anfragen entgegen nimmt und auch ausliefert. Ihr könnt euch vorstellen, dass diese Server<\/a> sehr bald unter Last waren. Nun, das war in den RFC<\/a> bereits damals vorgesehen und erwartet. Auch wurde im Abfrageprotokoll vorgesehen, das DNS-Anfragen sowohl TCP als auch im zustandslosen UDP<\/a> erfolgen dürfen. Ferner wurde ein hierarchisches Server<\/a>konzept vorgesehen und damit von den root<\/a>-Server<\/a> ausgehend beliebige weitere Knoten eingeführt. Wir haben es somit mit einer Baumstruktur zu tun.<\/p>\n\n\n\n Machen wir einen Blick auf die Infrastruktur. Derzeit sind 13 root<\/a>-Nameserver<\/a> online. Lan<\/a>ge Zeit reichten 10 aus. Das diese Server<\/a> kein PC von der Stange sind, dürfte jeden klar sein. Das sind solide aufgebaute HA-Cluster die bestimmte Ausfälle vertragen. Jeder der root<\/a>-server<\/a> arbeitet nur mit 33% Leistung. Somit können 8 Server<\/a>cluster total ausfallen und es würde zu keinem Leistungsengpass kommen. sind die nächsten Ebenen im Baum. Wir wissen aber nicht auf welcher Ebene sie sich befinden. Es kann uns auch egal sein, ob dieses Blatt ganz nahe am Boden ist oder hoch in der Spitze. ist Um die nicht unerheblichen Daten<\/a>mengen in den Griff zu bekommen bietet jeder Internet-Provider einen eigenen DNS-Server<\/a> an. Selbst Google betreibt unter der Adresse 8.8.8.8 einen eigenen DNS-Server<\/a>. Diese Server<\/a> sind gleichzeitig DNS-Cache<\/a> und natürlich Resolver.<\/p>\n\n\n\n Die unterste Ebene ist mein eigenes Gerät. Einen Resolver habe ich auf jeden Fall. <\/p>\n\n\n\n Nehmen wir an wir tippen im Browser www.linux<\/a>-bibel ein. Der Browser meint dann: aja da will einer in die Bibel schauen und schaut in der \/etc\/host<\/a>s nach der Linux<\/a>-Bibel nach. Nur dort ist keine Adresse vorgemerkt. Wenn ich das ganze ein zweites mal mache, dann ist in meiner \/etc\/host<\/a>s noch immer keine Linux<\/a>-Bibel eingetragen aber mein Router<\/a> als Resolver und DNS-Cache<\/a> kann sie beantworten. <\/p>\n\n\n\n Es gibt auf der Konsole<\/a> zwei nützliche Kommandos. Ein Altes und ein Neues. <\/p>\n\n\n\n nslookup für die Leute die mit Unix<\/a> angefangen haben (muss nach installiert werden) <\/p>\n\n\n\n Der Aufzählung soll helfen, uns in Zukunft diese Param<\/a>eter genauer zu betrachten. So das war die Schnelleinführung in den DNS. Ich hoffe, ich habe euch nicht gelan<\/a>gweilt. <\/p>\ndie Zonen<\/h2>\n\n\n\n
Die Infrastruktur <\/h2>\n\n\n\ndie root-Nameserver
<\/h3>\n\n\n\n
Ob dem wirklich so ist, wage ich zu bezweifeln, da es jede Menge vorgelagerter Systeme wie Leitungen, Router<\/a>, Firewall, Loadbalan<\/a>cer etc. gibt.
Wie auch immer, so ist die Ebene der root<\/a>-Nameserver<\/a> definiert und aufgebaut und bis heute gab es keinen merkbaren Ausfall.<\/p>\n\n\n\nDie Nameserver, Resolver und DNS-Cache. <\/h3>\n\n\n\n
Was passiert bei einer Domain-Abfrage?
<\/h2>\n\n\n\n
Unter Unix<\/a> gibt es die Datei<\/a> \/etc\/resolv.conf . Dort können wir z.B folgende Eintrag finden.<\/p>\n\n\n\n# \/etc\/resolv.conf\n# Generated by NetworkManager\nnameserver 192.168.24.2\n<\/code><\/pre>\n\n\n\n
Also wird der Request an diesen Adresse weitergeleitet. Das nächste Gerät hat ein ähnlichen Eintrag z.B. 8.8.8.8 und Google geht dann zum nächsten bis irgendwan<\/a>n als letzte Instanz ein root<\/a>-Server<\/a> antwortet.
Und dieser sagt dann die Linux<\/a>-Bibel ist als www.linux<\/a>-bibel.at unter der IP-Adresse<\/a> 5.132.191.10 zu erreichen.<\/p>\n\n\n\n
dig als neues modernes Kommando.<\/p>\n\n\n\ndig www.linux-bibel.at\n\n; <<>> DiG 9.20.11-4-Debian <<>> www.linux-bibel.at\n;; global options: +cmd\n;; Got answer:\n;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35954\n;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1\n\n;; OPT PSEUDOSECTION:\n; EDNS: version: 0, flags:; udp: 512\n;; QUESTION SECTION:\n;www.linux-bibel.at.\t\tIN\tA\n\n;; ANSWER SECTION:\nwww.linux-bibel.at.\t300\tIN\tA\t5.132.191.10\n\n;; Query time: 192 msec\n;; SERVER: 192.168.24.2#53(192.168.24.2) (UDP)\n;; WHEN: Wed Sep 17 16:46:56 CEST 2025\n;; MSG SIZE rcvd: 63<\/code><\/pre>\n\n\n\n
So genug in den Tiefen des Netzwerk<\/a>es. Ich hoffe, dass es nicht allzu viel war. Was speichert eigentlich ein DNS-Server<\/a> so. <\/p>\n\n\n\nDie Record-Typen<\/h2>\n\n\n\n
– SOA Resource Record wird für Gültigkeitsdauer, Seriennummer einer Zone verwendet.
– NS Record dient dazu die Delegation zwischen Server<\/a> zu regeln.
– A und das AAAA Record definieren einen Namen zu einer IPAdresse.
das A für Ipv4 das AAAA Record für IPv6. Das wäre ein Platz wo wir unsere www.linux<\/a>-bibel.at
finden würden.
-CName oder auch C Record ist ein Verweis eines Namens auf einen anderen. Ich könnte diesen Namen verwenden wenn ich meinen Server<\/a> unter einen zweiten Namen verwenden möchte.
-MX Record dient dazu einen Mail-Transfer-Agent zu definieren. SEV ist etwas ähnliches.
-PTR Record ist die umgedrehte Richtung IP zu einem Namen
-TXT Record Ein frei definierbarer Text. <\/p>\n\n\n\n
Wenn ihr jetzt das Wissen einsetzen und eine Lösung gegen Werbung wollt, dann lest https:\/\/linux-bibel.at\/index.php\/2023\/12\/23\/pi-hole-der-werbeblocker-fuer-das-netzwerk-unter-linux\/<\/a><\/p>\n\n\n\n
![\"Gef\u00e4llt](\"https:\/\/linux-bibel.at\/wp-content\/uploads\/2023\/12\/Daumen-Hoch.png\")
\r\n <\/a>\r\n ![\"Gef\u00e4llt](\"https:\/\/linux-bibel.at\/wp-content\/uploads\/2023\/12\/Daumen-Runter.png\")
\r\n <\/a>\r\n