Die Geschichte

DNS .. 3 Buchstaben und eine geniale Idee. Domain Name Service um den ausgeschrieben Begriff einmal zu verwenden, ist nichts anderes als die Umsetzung eines Namen in eine Nummer bzw umgekehrt (reverse lookup). Wenn man möchte das Telefonbuch des Internets.

Die Idee wurde von Paul Mockapetris 1982/1983 geboren und in 2 RFC (882 , 883 ) beschrieben. Ziel war es die damals üblichen /etc/hosts abzulösen. Vor 1982 wurden die hosts zentral gepflegt und an ALLE Systeme verteilt. Das geht bei 20 Systemen noch gut bei 1000den Rechnern sind immer ein paar die durch den Rost fallen. Im Laufe der Jahre wurden die beiden RFCs dann erweitert und liegen derzeit als RFC1034 und RFC1034 vor.

Warum ich das erzähle?

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.

Die Domain

mit der Einführung war auch bald eine Organisation der Namen vorgesehen. So wurden bald der Begriff TLD und FQDN geboren. Und damit wurde auch eine Aufteilung in

die Zonen

Jede Domain gehört einer Zone an, für diese Zone ist ein root Server zuständig, der die Anfragen entgegen nimmt und auch ausliefert. Ihr könnt euch vorstellen, dass diese Server sehr bald unter Last waren. Nun, das war in den RFC bereits damals vorgesehen und erwartet. Auch wurde im Abfrageprotokoll vorgesehen, das DNS-Anfragen sowohl TCP als auch im zustandslosen UDP erfolgen dürfen. Ferner wurde ein hierarchisches Serverkonzept vorgesehen und damit von den root-Server ausgehend beliebige weitere Knoten eingeführt. Wir haben es somit mit einer Baumstruktur zu tun.

Die Infrastruktur

die root-Nameserver

Machen wir einen Blick auf die Infrastruktur. Derzeit sind 13 root-Nameserver online. Lange Zeit reichten 10 aus. Das diese Server 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-server arbeitet nur mit 33% Leistung. Somit können 8 Servercluster total ausfallen und es würde zu keinem Leistungsengpass kommen.
Ob dem wirklich so ist, wage ich zu bezweifeln, da es jede Menge vorgelagerter Systeme wie Leitungen, Router, Firewall, Loadbalancer etc. gibt.
Wie auch immer, so ist die Ebene der root-Nameserver definiert und aufgebaut und bis heute gab es keinen merkbaren Ausfall.

Die Nameserver, Resolver und DNS-Cache.

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 Datenmengen in den Griff zu bekommen bietet jeder Internet-Provider einen eigenen DNS-Server an. Selbst Google betreibt unter der Adresse 8.8.8.8 einen eigenen DNS-Server. Diese Server sind gleichzeitig DNS-Cache und natürlich Resolver.

Die unterste Ebene ist mein eigenes Gerät. Einen Resolver habe ich auf jeden Fall.

Was passiert bei einer Domain-Abfrage?

Nehmen wir an wir tippen im Browser www.linux-bibel ein. Der Browser meint dann: aja da will einer in die Bibel schauen und schaut in der /etc/hosts nach der Linux-Bibel nach. Nur dort ist keine Adresse vorgemerkt.

Unter Unix gibt es die Datei /etc/resolv.conf . Dort können wir z.B folgende Eintrag finden.

# /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.24.2

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 irgendwann als letzte Instanz ein root-Server antwortet.
Und dieser sagt dann die Linux-Bibel ist als www.linux-bibel.at unter der IP-Adresse 5.132.191.10 zu erreichen.

Wenn ich das ganze ein zweites mal mache, dann ist in meiner /etc/hosts noch immer keine Linux-Bibel eingetragen aber mein Router als Resolver und DNS-Cache kann sie beantworten.

Es gibt auf der Konsole zwei nützliche Kommandos. Ein Altes und ein Neues.

nslookup für die Leute die mit Unix angefangen haben (muss nach installiert werden)
dig als neues modernes Kommando.

dig www.linux-bibel.at

; <<>> DiG 9.20.11-4-Debian <<>> www.linux-bibel.at
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35954
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.linux-bibel.at.		IN	A

;; ANSWER SECTION:
www.linux-bibel.at.	300	IN	A	5.132.191.10

;; Query time: 192 msec
;; SERVER: 192.168.24.2#53(192.168.24.2) (UDP)
;; WHEN: Wed Sep 17 16:46:56 CEST 2025
;; MSG SIZE  rcvd: 63

So genug in den Tiefen des Netzwerkes. Ich hoffe, dass es nicht allzu viel war. Was speichert eigentlich ein DNS-Server so.

Die Record-Typen

Der Aufzählung soll helfen, uns in Zukunft diese Parameter genauer zu betrachten.
– SOA Resource Record wird für Gültigkeitsdauer, Seriennummer einer Zone verwendet.
– NS Record dient dazu die Delegation zwischen Server 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-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 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.

So das war die Schnelleinführung in den DNS. Ich hoffe, ich habe euch nicht gelangweilt.

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/

3