(Zu) oft kommt es vor, dass sich Benutzer über lange Ladezeiten beim Zugang zu verschiedenen IT Diensten (Web, Citrix, Terminal Server ecc.) beschweren. Auch Cloud Services, wie Office 365 können betroffen sein. Doch die Ursache dafür liegt nicht zwingend beim Service selbst. Solche Einschränkungen können auch vorkommen wenn die Auflösung der DNS Adresse mehr Zeit benötigt als gewöhnlich. Um möglichen verlängerten Ladezeiten auf den Grund zu gehen, haben wir ein neues DNS Plugin für NetEye Real User Experience (RUE) entwickelt.
Der Client, welcher auf einen Dienst zugreifen möchte stellt seine Anfrage an den DNS Server. Enthält der DNS Server die Information bereits, gibt er sie zurück, andernfalls stellt er die Anfrage an einen anderen DNS Server.
Bevor ich näher auf das neue Plugin eingehe, widmen wir uns kurz der generellen DNS Funktionsweise: Um auf einen Dienst zugreifen zu können, muss die DNS Adresse in eine IP-Adresse umgewandelt werden. Dieser Vorgang erfolgt in mehreren Schritten – die einzelnen Schritte sind in der obenstehenden Grafik abgebildet.
Sobald die IP-Adresse identifiziert wurde, kann diese für eine bestimmte Zeit, im Cache des DNS Servers, gespeichert werden. Wird also die selbe Domäne erneut abgefragt, kann auf die Daten im Cache zugegriffen werden – die DNS Adresse muss nicht erneut aufgelöst werden. Ist die Time to Live (Lebensdauer im Cachespeicher) abgelaufen, muss die IP Adresse, im Fall einer erneuten Anfrage, wieder an den DNS Server gesendet und nach den oben beschriebenen Schritten aufgelöst werden.
Das neue DNS Plugin erhebt detaillierte Informationen im Rahmen der DNS-Auflösung die Antwortzeiten zu überwachen und den Grund für eventuelle Einschränkungen zu identifizieren.
Erfasst werden unter anderem:
Application Latency: Zeitspanne bis zum Erhalt einer Antwort
Response Code: Code des Ergebnisses (NOERROR, SERVFAIL, REFUSED, …)
Query Type: Art der abgefragten Information (A, AAAA, MX, …)
Query Text: Aufzulösender/zu aktualisierender Name
DNS query class: Internet / Nicht Internet
Answer: enthält die RRs welche auf die Query antworten
Rec TTL: Time to live (Lebenszeit im Cachespeicher) des DNS Eintrags
Authority: Enthält RRs welche andere autoritative Server beschreiben. (beispielsweise SOA RR für autoritative Daten in der Sektion “Answer”)
Additional: Enthält RRs welche für die Nutzung von RRs anderer Sektionen nützlich sein können
DNS OpCode: Art der Aktivität (Query, Update, Status, ..)
Erhobene Daten
Detaillierte Informationen
NetEye RUE sammelt und organisiert die oben genannten Daten und bietet Ihnen außerdem die Möglichkeit die Informationen grafisch darzustellen.
Grafische Darstellung
Fallbeispiel:
In diesem konkreten Beispiel sehen wir, dass der Dienst plus.google.com eine sehr niedrige Andwendungs-Latenz (~5 ms) vorweist. Die Antwort der sekundären DNS zur Auflösung des Hosts plus.google.com hat jedoch eine erhöhte Latenz (1,5 Sek.). In solch einem Fall beschwert sich der Benutzer über die lange Ladezeit. Die Einschränkung wird jedoch weder vom Dienst selbst, noch von der Internetverbindung verursacht. Die erhobenen Daten weißen nämlich auf eine Fehlkonfiguration oder eine Überlastung des DNS hin.
Hi everyone, I’m Luca, graduated in electrical engineering from the University of Bologna. I am employed by Würth Phoenix since its foundation. I worked mainly as enterprise architect and quality assurance engineer. Previously I was involved in systems measurement and embedded systems programming. I have gained experience on Unix (Solaris, HPUX), Windows, and C, C + +, Java. I personally contribute to the Open Source community as beta tester and developer. During my spare time I love piloting airplanes fly over the beautiful Alps. I practice many sports: tennis, broomball, skiing, alpine skiing, volleyball, soccer, mountain biking, middle distance, none have a sample but the competition excites me! I love hiking, tracking and traveling.
Author
Luca Di Stefano
Hi everyone, I’m Luca, graduated in electrical engineering from the University of Bologna. I am employed by Würth Phoenix since its foundation. I worked mainly as enterprise architect and quality assurance engineer. Previously I was involved in systems measurement and embedded systems programming. I have gained experience on Unix (Solaris, HPUX), Windows, and C, C + +, Java. I personally contribute to the Open Source community as beta tester and developer. During my spare time I love piloting airplanes fly over the beautiful Alps. I practice many sports: tennis, broomball, skiing, alpine skiing, volleyball, soccer, mountain biking, middle distance, none have a sample but the competition excites me! I love hiking, tracking and traveling.