Meine Frage ist zum Beispiel.com, der autorisierende Nameserver wäre der COM-Server, oder?
Nein, lass dig
es:
# dig example.com SOA ;; ANSWER SECTION: example.com. 3600 IN SOA sns.dns.icann.org. noc.dns.icann.org. 2018080109 7200 3600 1209600 3600 ;; AUTHORITY SECTION: example.com. 86400 IN NS a.iana-servers.net. example.com. 86400 IN NS b.iana-servers.net.
Autorisierender Nameserver für example.com
ist:
a.iana-servers.net. b.iana-servers.net.
Das sind die Server, für die DNS-Einträge vorhanden sind example.com
Jetzt können wir sie direkt abfragen:
dig @a.iana-servers.net example.com A ;; ANSWER SECTION: example.com. 86400 IN A 93.184.216.34
Der DNS-Resolver zerlegt den vollqualifizierten Domänennamen (Fully Qualified Domain Name) von rechts nach links.
Erste Abfrage geht DNS - Server zu verankern zu fragen, wer in autoritativen DNS - Server ist TLD für .com
, dann Resolver - Abfrage bestimmte TLD für example.com
von diesen Servern.
# dnstracer -4 -r1 -s. example.com Tracing to example.com[a] via A.ROOT-SERVERS.NET, maximum of 1 retries A.ROOT-SERVERS.NET [.] (198.41.0.4) |\___ d.gtld-servers.net [com] (192.31.80.30) | |\___ b.iana-servers.net [example.com] (2001:0500:008d:0000:0000:0000:0000:0053) Not queried | |\___ b.iana-servers.net [example.com] (199.43.133.53) Got authoritative answer | |\___ a.iana-servers.net [example.com] (2001:0500:008f:0000:0000:0000:0000:0053) Not queried | \___ a.iana-servers.net [example.com] (199.43.135.53) Got authoritative answer
Versuchen wir jetzt eine andere Domain in der .com
TLD :
# dig google.com SOA ;; AUTHORITY SECTION: google.com. 345600 IN NS ns3.google.com. google.com. 345600 IN NS ns4.google.com. google.com. 345600 IN NS ns1.google.com. google.com. 345600 IN NS ns2.google.com.
Wir werden sehen, dass die autoritativen Nameserver für SLD google.com
jetzt anders sind.
da ist es der, der uns die Informationen gibt?
Nein, es ist eine Kette von autorisierenden DNS-Servern.
Root - DNS - Server nur Top - Level - Zonen hält auch bekannt als TLD, - wie .com
, .net
wenn Resolver verantwortlich autorisierenden DNS - Server bekam für TLD, Resolver - Abfrage bestimmte Zone für SLD (Second-Level - Domain, example
in unserem Fall), und wenn es autorisierenden DNS - Server gefunden Bei SLD wird der Server nach FQDN (Fully Qualified Domain Name) wie z. B. www.example.com abgefragt
Normalerweise verwenden Benutzer DNS-Server des Internetanbieters, die gelöschte DNS-Einträge im Cache speichern. Solche DNS-Server werden als Forwarding-DNS-Server bezeichnet. Wenn sich Datensätze im Cache befinden, antworten sie sofort an den Client, ohne dass alle Zwischenserver, die mit root beginnen, belästigt werden. Wenn solche Weiterleitungs-DNS-Server keine Einträge im Cache haben (oder der DNS-Eintrag abgelaufen ist), werden die Weiterleitungen erneut aufgelöst und das Ergebnis zwischengespeichert. Die DNS-Abfragen des Clients werden als rekursiv gesendet. Dies bedeutet, dass der Client vom DNS-Anbieter entweder einen Fehler oder einen aufgelösten Datensatz erhalten sollte. Der Client sollte die Kette der zwischengeschalteten DNS-Server nicht selbst abfragen, es ist die Aufgabe, den DNS-Server weiterzuleiten, der Clientanforderungen und zwischengespeicherte Ergebnisse bedient. Auf diese Weise reduzieren Weiterleitungen das Laden auf zwischengeschaltete DNS-Server und antworten so schnell wie möglich auf Clients, da die DNS-Server der Anbieter näher an den Clients sind.
(Übrigens, der öffentliche DNS-Server von Google ist auch eine Weiterleitung.)
DNS-Einträge haben den Parameter TTL (time to life), der in autorisierenden Servern nach Domaininhaber festgelegt ist. Wenn Sie also erwarten, dass Ihre IP-Adresse sich häufig ändert, können Sie TTL = 5 Minuten festlegen oder wenn Sie nicht möchten, dass sein DNS-Server vorhanden ist zu oft gestört, dann kann die TTL für einen Tag eingestellt werden.