Das DNS (Domain Name System) übersetzt im Internet Namen in IP-Adressen (und vice versa). Da praktisch kein relevantes Service ohne die Unterstützung des DNS auskommt, ist es ein wichtiges Service. Während beim Zugriff auf Webseiten Notlösungen mit gespeicherten IP-Adressen oft funktionieren, ist insbesondere das Versenden und Empfangen von E-Mails (siehe Bild 3) ohne funktionierendes DNS unmöglich.
Bisherige Konfiguration
Es gibt vor allem zwei Punkte, die das Nameservice der TU Wien in der Rückschau nicht optimal erscheinen lassen:
- Die Konfiguration der Clients wurde fast lückenlos in der publizierten Reihenfolge durchgeführt, sodass sich eine eklatante Ungleichverteilung (Bild 1) der Zugriffe auf die Server tunamea und tunameb einstellte. Auf tunameb sind größtenteils nur Zugriffe von caching1 Nameservern , die von verschiedenen Instituten an der TU betrieben werden, feststellbar.
- Da fast alle Rechner tunamea als ersten Nameserver eingestellt haben, war bei einer Störung oder Wartung dieses Servers praktisch immer die gesamte TU dadurch betroffen, dass der zweite Nameserver erst befragt wird, wenn der erste nicht innerhalb einer gewissen Zeit (je nach Betriebssystem des Clients verschieden) antwortet.
Die Werte sind jeweils Mittelwerte über eine Stunde. Die blaue Linie stellt die Gesamtzahl der Anfragen, die grüne die Anzahl der Anfragen, die positiv beantwortet wurden, dar. Diese Durchschnittswerte können auch von einem einzigen System übertroffen werden, wenn die darauf installierte Software fehlerhaft ist oder der Rechner massiv zum Versenden von Spam-Mails missbraucht wird.
Neue Konfiguration
Ende Oktober 2007 wurden neue DNS-Server mit den Adressen 128.130.4.3 und 128.131.4.3 in Betrieb genommen. Die neue Konfiguration hat folgende Vorteile gegenüber der alten:
- Jeder der beiden Nameserver wird gleichzeitig auf zwei Rechnern betrieben, die über den Campus verteilt sind. Im Normalbetrieb wird von einem Client-Rechner der in der Netztopologie nächste Server abgefragt, bei Ausfall eines der beiden physischen Server gehen alle Abfragen nach einer kurzen Umschaltzeit zum verbleibenden Server.
- Für die Reihenfolge der Nameserver in den Client-Einstellungen wurde eine Empfehlung herausgegeben, sodass beide Nameserver-Gruppen einigermaßen gleichmäßig ausgelastet werden.
Technische Details
Ausgehend von verschiedenen Dokumenten im Netz über Anycast Routing bei verschiedenen Nameserver-Implementierungen wurden eigene Versuche durchgeführt und die Verteilung der Server und die Adressen festgelegt.
Jeder der Server ist mit dem Routing-Protokoll OSPF Teilnehmer am verteilten Routing des Backbone und gibt bekannt, ob bei ihm die zugeordnete virtuelle Nameserver-Adresse aktiv ist oder nicht. Alle Router berechnen die Wege, über die eine bestimmte Adresse – in diesem Fall die virtuelle Nameserver-Adresse – erreicht werden kann, von denen dann normalerweise der kürzeste verwendet wird (Open Shortest Path First).
Durch die räumliche Verteilung der physischen Server wird von verschiedenen Punkten im TUNET jeweils ein bestimmter Server überwiegend (aber nicht immer) verwendet.
Erste Erfahrungen
Durch Kontaktieren der Administratoren der aktivsten Server wurden innerhalb von drei Wochen ca. 50 % der Nameserver-Abfragen auf die neuen Server verschoben. Die Maximalanzahl der Clients ist ca. 900, vor der Umstellung verwendeten ca. 700 tunamea und 200 tunameb.
Nach drei Wochen verwendeten jeweils ca. 50 Rechner die neuen Nameserver, die Client-Anzahl von Ex-tunamea und -tunameb sank jeweils um ca. 100.
Wenn es gelingt, die verbliebenen Server mit vielen Nameserverabfragen (und die fehlkonfigurierten Arbeitsplatzrechner) bald auf die neuen Nameserver umzulegen, können die Benutzer, deren Rechner noch nicht auf die neuen Nameserver umgestellt ist, eine bessere Performance der alten Nameserver erwarten als bisher.
Für die verbleibenden Clients wird die Performance dadurch wesentlich verbessert, dass regelmäßig ein Neustart der Server durchgeführt wird.
Empfehlungen für die Konfiguration von Nameserver-Clients
Konfiguration von Nameserver-Clients Die bisherige fixe Konfiguration – erster DNS Server 128.130.2.3, zweiter DNS Server 128.130.3.131 – gilt nicht mehr. Statt dessen wird folgende Vorgangsweise empfohlen:
Diese Einstellungen sollten bis spätestens Ende 2008 auf allen Rechnern im TUNET vorgenommen werden. |
Literatur
[1] Blair Rampling, David Dalan, DNS for Dummies: www.dummies.com/WileyCDA/DummiesArticle/id-1701.html
[2] Kevin Miller, Deploying IP Anycast: www.net.cmu.edu/pres/anycast/
[3] Kim Hawtin, Configuring Anycast DNS: www.linuxsa.org.au/meetings/2006-07/anycast-dns.pdf
[4] Bill Woodcock, Best Practices in IPv4 Anycast Routing: www.pch.net/resources/papers/ipv4-anycast/ipv4-anycast.ppt
| TXT? 2.39.89.75.sa-trusted.bondedsender.org. NXDomain TXT? 2.39.89.75.list.dsbl.org. NXDomain TXT? 2.39.89.75.bl.spamcop.net. NXDomain NS? softroq.com. NS ns2.affa-soft.com. MX? alltel.net. MX mx01.alltel.net. A? softroq.com.multi.surbl.org. A 127.0.0.70 A? ns2.affa-soft.com. ServFail A? ns1.affa-soft.com. ServFail A? alltel.net.rhsbl.ahbl.org. NXDomain A? alltel.net.fulldom.rfc-ignorant.org. NXDomain A? alltel.net.blackhole.securitysage.com. ServFail A? alltel.net. A www2.windstream.net A? 2.39.89.75.sbl-xbl.spamhaus.org. NXDomain A? 2.39.89.75.sa-accredit.habeas.com. NXDomain A? 2.39.89.75.iadb.isipp.com. NXDomain A? 2.39.89.75.dnsbl.sorbs.net. NXDomain A? 2.39.89.75.combined.njabl.org. NXDomain A? 2.39.89.75.combined-HIB.dnsiplists.completewhois.com. ServFail |
Bild 3: Nameserver-Abfragen, die durch den Empfang einer E-Mail ausgelöst werden
1 Ein caching Nameserver nimmt Nameserver-Anfragen entgegen und beantwortet sie sofort, wenn die Antwort bereits in seinem cache Speicher vorhanden ist. Ist sie das nicht, reicht er die Anfrage an seine Forwarder weiter und speichert dann das Ergebnis für eine definierte Zeit, für den Fall, dass die gleiche Anfrage noch einmal hereinkommt. Die TUNET Nameserver sind für tuwien-Namen und -Adressen autoritativ (d. h. sie müssen für eine Antwort keine anderen Nameserver befragen) und lösen externe Namen und Adressen durch Rekursion auf, deren Ergebnis sie in ihrem eigenen Cache speichern [1].
2 Eine IP-Adresse ist eine 32 Bit Zahl, die der besseren Lesbarkeit wegen in 4 dezimal notierten Oktets (=Bytes) geschrieben wird. Die Notierung a.b.c.d/n umfasst einen Bereich von allen Adressen, bei denen die ersten n Bits konstant bleiben und die restlichen Bits alle möglichen Werte annehmen. 128.130.0.0/16 umfasst also einen Bereich von 128.130.0.0 bis 128.130.255.255.