Iterative DNS Abfrage! & zugehörige DNS Delegationskette

[WarDynasty]

Hey,
ich müsste die Arbeitsweise eines iterativen DNS-Resolvers erklären und hab nun einiges zusammen geschrieben:

1. Arbeitsweise eines iterativen DNS-Resolvers:
Bei einem Webseitenaufruf (Google), schickt der DNS-Resolver eine Anfrage zum DNS-Server, welcher in meinem Fall die IP 195.34.133.21 hat. Ein DNS-Server wird üblicherweise vom Provider zur Verfügung gestellt.

Der DNS-Server 195.34.133.21 erhält die Anfrage und überprüft zunächst ob sich die IP Adresse der Webseite bereits in dessen Cache befindet, was der Fall sein kann, wenn die Webseite zuvor schon einmal aufgerufen wurde. (Stimmt das )
Enthält der DNS-Server keinen IP-Eintrag der Webseite, dann antwortet er mit einem Verweis zum nächstliegenden root server. Nun kann der DNS-Resolver eine Anfrage an den root server direkt schicken. Der root server stellt dann eine Auswahl von Servern zur Verfügung, welche für die entsprechende .at gTLD verantwortlich sind.
(gTLD = generic top-level domain). Der DNS-Server 195.34.133.21 entscheidet sich für eine .at gTLD und sendet an diese wiederum eine Anfrage. Als Antwort erhalten wir eine Liste von IP Adressen der DNS-Server, welche für die Domain www.google.at verantwortlich sind.

Der lokale DNS Server sendet dann eine Anfrage denn autoritativen DNS-Server welcher mit der IP Adresse für www.google.at antwortet.

Stimmt das so einigermaßen? ^^

Und wie sieht eigentlich die zugehörige DNS Delegationskette aus? Bin mir nicht sicher, was damit gemeint ist.
lg

 

[TCM]

Was ist für dich ein "DNS-Resolver"? Was ist dann der "lokale DNS-Server" im letzten Satz?

Der Resolver eines Betriebssystems kann nichts weiter als einen(!) DNS-Server rekursiv befragen. Das bedeutet, dass bei der Abfrage das recursion desired flag gesetzt ist. Das sieht so aus:

$ dig www.google.at

; <<>> DiG 9.5.0-P2 <<>> www.google.at
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50429
;; [COLOR="#FF0000"]flags[/COLOR]: qr [COLOR="#FF0000"]rd[/COLOR] ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;www.google.at.                 IN      A

;; ANSWER SECTION:
www.google.at.          274     IN      A       173.194.44.88
www.google.at.          274     IN      A       173.194.44.87
www.google.at.          274     IN      A       173.194.44.95

;; AUTHORITY SECTION:
google.at.              10774   IN      NS      ns4.google.com.
google.at.              10774   IN      NS      ns3.google.com.
google.at.              10774   IN      NS      ns2.google.com.
google.at.              10774   IN      NS      ns1.google.com.

;; ADDITIONAL SECTION:
ns1.google.com.         155592  IN      A       216.239.32.10
ns2.google.com.         345454  IN      A       216.239.34.10
ns3.google.com.         155592  IN      A       216.239.36.10
ns4.google.com.         155592  IN      A       216.239.38.10

;; Query time: 2 msec
;; SERVER: [...]
;; WHEN: Sat Apr 12 17:12:18 2014
;; MSG SIZE  rcvd: 225

Alles, was du an lookups zu den Root-Servern (es sind mehrere) beschreibst, wird von dem DNS-Server durchgeführt, der vom Resolver gefragt wird. Jeder rekursiv "befragbare" DNS-Server hat eine Liste der Root-Server lokal bei sich vorliegen. Einen dieser Root-Server fragt er nach den zuständigen Servern für die .at TLD. Einen davon wiederum nach den zuständigen Servern für google.at und davon wiederum einen nach www.google.at.

Ein kompletter lookup sieht z.B. so aus:

$ dig www.google.at +trace

; <<>> DiG 9.5.0-P2 <<>> www.google.at +trace
;; global options:  printcmd
.                       204610  IN      NS      [COLOR="#40E0D0"]b.root-servers.net.[/COLOR]
.                       204610  IN      NS      [COLOR="#40E0D0"]d.root-servers.net.[/COLOR]
.                       204610  IN      NS      [COLOR="#40E0D0"]e.root-servers.net.[/COLOR]
.                       204610  IN      NS      [COLOR="#40E0D0"]l.root-servers.net.[/COLOR]
.                       204610  IN      NS      [COLOR="#40E0D0"]j.root-servers.net.[/COLOR]
.                       204610  IN      NS      [COLOR="#40E0D0"]i.root-servers.net.[/COLOR]
.                       204610  IN      NS      [COLOR="#40E0D0"]h.root-servers.net.[/COLOR]
.                       204610  IN      NS      [COLOR="#40E0D0"]f.root-servers.net.[/COLOR]
.                       204610  IN      NS      [COLOR="#40E0D0"]g.root-servers.net.[/COLOR]
.                       204610  IN      NS      [COLOR="#40E0D0"]m.root-servers.net.[/COLOR]
.                       204610  IN      NS      [COLOR="#40E0D0"]k.root-servers.net.[/COLOR]
.                       204610  IN      NS      [COLOR="#40E0D0"]a.root-servers.net.[/COLOR]
.                       204610  IN      NS      [COLOR="#40E0D0"]c.root-servers.net.[/COLOR]
;; Received 228 bytes from [...] in 2 ms

at.                     172800  IN      NS      [COLOR="#EE82EE"]d.ns.at.[/COLOR]
at.                     172800  IN      NS      [COLOR="#EE82EE"]j.ns.at.[/COLOR]
at.                     172800  IN      NS      [COLOR="#EE82EE"]n.ns.at.[/COLOR]
at.                     172800  IN      NS      [COLOR="#EE82EE"]r.ns.at.[/COLOR]
at.                     172800  IN      NS      [COLOR="#EE82EE"]u.ns.at.[/COLOR]
at.                     172800  IN      NS      [COLOR="#EE82EE"]ns1.univie.ac.at.[/COLOR]
at.                     172800  IN      NS      [COLOR="#EE82EE"]ns2.univie.ac.at.[/COLOR]
at.                     172800  IN      NS      [COLOR="#EE82EE"]ns9.univie.ac.at.[/COLOR]
;; Received 474 bytes from 2001:500:3::42#53([COLOR="#40E0D0"]l.root-servers.net[/COLOR]) in 47 ms

google.at.              10800   IN      NS      [COLOR="#FFA500"]ns1.google.com.[/COLOR]
google.at.              10800   IN      NS      [COLOR="#FFA500"]ns2.google.com.[/COLOR]
google.at.              10800   IN      NS      [COLOR="#FFA500"]ns3.google.com.[/COLOR]
google.at.              10800   IN      NS      [COLOR="#FFA500"]ns4.google.com.[/COLOR]
;; Received 113 bytes from 2001:628:2030:4301::2#53([COLOR="#EE82EE"]ns1.univie.ac.at[/COLOR]) in 75 ms

www.google.at.          300     IN      A       173.194.44.87
www.google.at.          300     IN      A       173.194.44.95
www.google.at.          300     IN      A       173.194.44.88
;; Received 79 bytes from 216.239.34.10#53([COLOR="#FFA500"]ns2.google.com[/COLOR]) in 63 ms

 

[WarDynasty]

was ein Resolver ist, habe ich auf wiki nachgelesen: Domain Name System
und die vorgehensweise die du beschreibst ist wie du sagst rekursiv. es gibt jedoch auch eine iterative anfrage, wobei der dns server nur einen verweis zum root server liefert.

 

[TCM]

Hier hast du es doch: Dateins-abfrage.svg

Der System-Resolver ist rekursiv, der gefragte DNS-Server ist der iterative Resolver. Der System-Resolver fragt nie irgendwelche anderen Server als die eingestellten.

Was bei dem Wikipedia-Artiekl zu Verwirrung führt, ist dass in einem Kontext 2x Resolver genannt wird, der jeweils was anderes bezeichnet. Aufklärung liefert dann nur der Satz "Übliche Resolver von Clients arbeiten ausschließlich rekursiv, sie werden dann auch als Stub-Resolver bezeichnet. Nameserver besitzen in der Regel eigene Resolver. Diese arbeiten gewöhnlich iterativ."

 

[WarDynasty]

na gut, das habe ich dann wohl falsch verstanden .S danke. weißt du vllt. was mit der delegationskette gemeint ist?

 

[TCM]

Ich denke mal, damit ist gemeint, dass die Root-Server die TLD-Server kennen, die die Domain-Server kennen, die die Hostnamen/Subdomains kennen.

 

[WarDynasty]

hm alles klar. Ich habe also einfach zuviel geschrieben. Eigentlich macht der iterative DNS-Resolver nichts weiter als Anfragen zu versenden/weiterzuleiten?! und erhält Verweise auf andere Server die er dann wieder anfragt, bis er die antwort hat. Habe ich das nun richtig verstanden? :P