Load Balancing, z.B. für Webserver lassen sich sehr leicht durch das erstellen von mehreren A RR's erreichen. Der Webbrowser nimmt dann zufällig eine der beiden Adressen.
hubermonsch.ch. 86400 IN A 157.161.114.120 hubermonsch.ch. 86400 IN A 157.161.114.140
Load Balancing für Email ist ebenfalls recht simpel, es kann über mehrere MX RR's mit der selben Priorität realisiert werden.
hotmail.com. 3600 IN MX 5 mx1.hotmail.com. hotmail.com. 3600 IN MX 5 mx2.hotmail.com. hotmail.com. 3600 IN MX 5 mx3.hotmail.com. hotmail.com. 3600 IN MX 5 mx4.hotmail.com.
; TTL dieses RR's hubermonsch.ch. 86400 IN A 157.161.114.120
Diese TTL gibt an, wie lange der RR in Sekunden gecacht werden darf. Dieses Caching geschieht durch Resolver. In diesem Falle darf der Resolver das Ergebnis seiner Anfrage einen Tag lang cachen, bevor er erneut Nachfragen muss. Wird diese Zone nun geändert, kann es schlimmstenfalls einen Tag dauern, bis Clients von Resolver xy wieder aktuelle Informationen haben. Doch ein herabsetzen der TTL erhöht den Traffic um einiges, weswegen hier meist ein Kompromiss geschlossen wird.
Die sogennanten DynDNS Dienste nutzen genau dies aus. Die TTL eines A RR's wird extrem herabgesetzt (60s), und schon hat man DynDNS.
Es existieren jedoch noch mehr TTL's, diese sind jedoch alle im SOA angegeben, und nur für die AXFR Transfer-Methode nötig (mit einer Ausnahme):
hubermonsch.ch. 86400 IN SOA ns1.v-1.ch. ; Primärer Nameserver
webmaster.v-1.ch. ; Adresse des Nameserver Admins
2002022716 ; Serial
10800 ; refresh
3600 ; retry
604800 ; expire
86400 ; minimum TTL
Natürlich müssen die Zonen, so denn mehrere authoritive Server für eine Domain zuständig sind, unter den Server synchronisiert werden. Für diese Synchronisation gibt es mehrere Methoden
AXFR ist die klassische Zonen-Transfer Methode. Sie wurde mit dem ersten DNS-Server (BIND) in Betrieb genommen, und erfreut sich unter BIND Benutzern immer noch grosser Beliebtheit, obwohl sie eigentlich die schlechteste aller zur Verfügung stehenden Methoden ist. AXFR wurde um ein paar Mechanismen erweitert, die seine Leistungsfähigkeit etwas steigern. Dies sind IXFR (Incremental), der die zu übertragende Datenmenge reduziert, und Notify, der die Zeit zwischen Zonen-Änderung und dem Zonentransfer enorm verkärzt.
LDAP ist eine etwas neuere Methode, um Zonendaten zu speichern. Sie wird z.B. vom M$ DNS Server benutzt, wenn die Zone im sogenannten 'Active-Directory integriert' Modus ist. LDAP hat den Vorteil, das eine Änderung der Zone, und deren Replikation leicht über LDAP geschehen kann. Dies schafft dann auch das Prinzip von Master und Slave ab.
Eine weitere generische Methode zur Datenreplikation unter *nix-Systemen ist die Verwendung von rsync über einen SSH Tunnel. Diese Methode wird z.B. von tinydns favorisiert, und ermöglicht eine hohe Geschwindigkeit beim Abgleich der Zone. Änderungen sind jedoch genauso wie bei AXFR nur auf dem Haupt-Server möglich. Im Gegensatz zu AXFR arbeitet rsync over ssh jedoch nach dem push-Verfahren, und ermöglicht so eine zeitnahe Synchronisation der Zone.
rsync over ssh hat gegenüber LDAP den Nachteil, das nur an einem Ort Änderungen möglich sind. Meistens stellt dies jedoch keine Einschränkung dar. rsync over ssh ist einiges simpler als ein authoritiver DNS-Server mit LDAP Anbindung, und aus diesem Grund auch im allgemeinen sicherer implementiert.