Autodiscover für Exchange/Outlook ist gleichzeitig häßlich zu konfigurieren und schön, wenn es läuft. Der einfachste Weg ist es, wenn man im DNS für die Domains, die auf dem Exchange-Server liegen eine SRV-Eintrag hinterlegt. Da spart man sich zusätzlich SSL-Zertifikate, wenn man mehrere Domains auf einem Exchange-Server hat. Dazu muss für jede Domain-Endung, die als Absende-Adresse verwendet wird folgender Eintrag in die Zone:

_autodiscover._tcp.domain.com. IN SRV 0 0 443 exch-frontend.domain.com.

Weiterführend Informationen gibt es hier:

http://www.msxfaq.de/e2007/autodiscover.htm
http://www.lengoldenstein.com/2008/09/29/creating-an-outlook-2007sp1-autodiscover-dns-record-with-bind/
http://intinc.com/hosted-exchange/faq/a/change-dns-autodiscover.htm

Die Zeiten, in denen man ein komplettes Class A, B oder C-Netz zugeteilt bekam sind ja schon lange vorbei. Und jetzt, wo das Ende des IPv4-Adressraumes naht, muss man den Bedarf an IP-Adressen immer besser nachweisen. Seit geraumer Zeit also bekommt man Netze nach dem Schema 1.2.3.0/26 zugewiesen. Dieses Verfahren ist als CIDR (Classless Inter-Domain Routing) bekannt und mit einer der Gründe, warum die Routingtabellen in den zentralen Routern immer größer werden. Ein Problem bei diesem Verfahren ist auch das Reverse-DNS für die IP-Adressen eines solchen Netzes kleiner als /24. Mit der herkömmlichen Art und Weise kann man die umgekehrte DNS-Auflösung (welchen vollqualifizierten Domainnamen hat die IP-Adresse?) nicht an andere DNS-Server delegieren, weil eine Delegation von DNS-Zonen nur an „Punkt-Grenzen“ möglich ist. Der DNS-Eintrag für die IP 1.2.3.5 sieht zum Beispiel so aus: 5.3.2.1.in-addr.arpa.. Da kann man also eigentlich nur den kompletten Bereich von 0 bis 255 delegieren durch ein 3 IN NS reverse-ns.dnsserver.net. in der Zone 2.1.in-addr.arpa.. Hat man das Netz jetzt aber zum beispiel in mehrere /29-Netze aufgeteilt, muss man einen anderen Weg gehen, um den Adressbereich an unterschiedliche DNS-Server delegieren zu können. Hier zeigt das RFC 2317 einen Weg auf, der im Moment als „Best current practise“ eingestuft ist.
Weiterlesen... (548 words)

Google führt seit einiger Zeit bereits einen Testbetrieb seiner Dienste mit IPv6-Konntektivität durch. Leider ist dieser Dienst normalerweise nur erreichbar, wenn der eigene ISP natives IPv6 zur Verfügung stellt und seine Caching-Nameserver dafür von Google freigeschaltet wurden. Oder man muß Google über ipv6.google.com anwählen.

Wer aber direkte IPv6-Unterstützung von Google möchte, sprich bei Eingabe von www.google.de die Seite über IPv6 erreichen möchte, der kann das auch mit einer Anbindung über SIXXS tun. Die Caching-Nameserver von SIXXS sind dafür freigeschaltet. Sie heißen für Europa nscache.eu.sixxs.net.
Weiterlesen... (471 words)