• 27.02.2013
• Support
• keine Kommentare

• .atAnycastDDoSDNShttp.netInternetIPv6

Warum Anycast?

Beim Stöbern in alten RFC fällt heutzutage auf, dass das Internet in weiten Teilen offenbar unter der Annahme konstruiert wurde, dass die Netzteilnehmer alle gutwillig und an der technischen Unversehrtheit jedes anderen Teilnehmers interessiert sind. Kaum jemand scheint ernsthaft darüber nachgedacht zu haben, was sich für Probleme daraus ergeben können, wenn Nachrichten auf verschiedenen Ebenen ihrer Struktur nicht nur mitgelesen, verfälscht und umgeleitet, sondern sogar zur Waffe umfunktioniert werden. Dies betrifft Nachrichten in jeder Form, seien es E-Mails, HTTP-Requests oder speziell DNS-Abfragen, deren Integrität für die richtige Zustellung der anderen Nachrichten erforderlich ist, und die (UDP) klein, schnell und unsicher wie Postkarten versendet und beantwortet werden.

Mittlerweile ist das Netz bekanntlich in der Wirklichkeit angekommen und die gezielte Störung anderer Netzteilnehmer ist längst als kriminelles Geschäftsmodell etabliert. Die Botnetze werden immer größer, die Angriffe heftiger und ausgefeilter. Das BSI erwähnte bereits Ende 2012 Angriffe in einer Größenordnung von 150 Gbit/s.

Es ist daher höchste Zeit, neue Wege zu beschreiten um den gewachsenen Herausforderungen wirksam begegnen zu können. Das in der Forschungs- und Entwicklungsabteilung der österreichischen Domain-Registry nic.at realisierte Anycast-Netz RCodeZero hat beste Referenzen, so wird es z.B. bereits erfolgreich bei der Konnektierung der TLDs .at und .hu eingesetzt und ist darauf eingerichtet, die extrem hohen Verfügbarkeitsanforderungen der ICANN bei der Konnektierung neuer gTLDs zu erfüllen. Der Dienst ist mit derzeit 9 weltweit verteilten Standorten, an denen jeweils mit Lastverteilung auf 2 unabhängigen Servern eine halbe Million Anfragen pro Sekunde sauber verabeitet werden können, hervorragend aufgestellt, und ein weiterer Ausbau der Standorte ist geplant.

Wie können Sie Anycast nutzen?

Ganz einfach, Sie tragen in Ihre Zone ein oder zwei sekundäre Anycast-Namerver ein und benutzen einen primären Nameserver der http.net (egal ob Standard-, Alias- oder virtueller Nameserver) . Alles Weitere geht automatisch und ist im Normalfall innerhalb von ein bis zwei Minuten nach Auftragseingang erledigt.

Eine mögliche Standardkonfiguration für Ihre Zonen wäre z.B. folgende:

primary:   ns.routing.net
namesrv:   ns.routing.net 213.160.64.64
namesrv:   ns8.routing.net 213.160.65.251
nserver:   ns9.routing.net 83.133.190.51
namesrv:   sec1.routing.net 192.174.68.100
zonettl:   86400

Damit haben Sie den Hauptteil des Traffics auf drei Nameserver der http.net an zwei Standorten in Deutschland verteilt und zusätzlich Ihre Zone im weltweiten Anycast-Netz eingetragen.

Sie können unsere Standardhostnamen für den Anycast-Dienst verwenden oder sich eigene Aliase anlegen. Der Hostname ist beliebig, er muss nur auf die dedizierten Anycast-Adressen (IPv4 und IPv6) geroutet sein. Weitere Einzelheiten zum Eintragen Ihrer Zonen finden Sie im Newsletter und im Partnerweb, und natürlich steht Ihnen unser Support wie immer gern mit Rat und Tat zur Seite.

Fair Traffic!

Während Sie diesen Satz lesen, wird die Zone routing.net über jeden der fünf zuständigen Nameserver ungefähr 30 mal abgefragt. Genauer gesagt, liegen wir derzeit bei rund 8 Abfragen pro Sekunde auf jedem Server für diese Zone. Diese Zone hat ein vergleichsweise extrem hohes Abfragevolumen, weil einige Namen innerhalb dieser Zone bei einer fünfstelligen Zahl von Domains als Nameserver eingetragen sind, und die Domain daher ständig in Ausflösungsprozesse einbezogen ist: ein Resolver, der die Adresse von name.de ermitteln möchte, indem er z.B. ns1.routing.net fragt, benötigt dafür zuerst die Adresse von ns1.routing.net.

Zum Glück haben die Resolver einen Cache, um die Häufigkeit der Abfragen zu reduzieren. Jede Zone hat eine Lebensdauer (TTL / Time-To-Live) im Resolver-Cache, die erhebliche Auswirrkungen auf das Abfragevolumen haben kann. Für routing.net haben wir jetzt eine hohe TTL von 432000 (5 Tage) eingestellt. Ein noch höherer Wert macht dann nicht mehr allzu viel Unterschied, während ein niedriger Wert sehr schnell das Abfragevolumen vervielfachen kann. Eine TTL von 300 (5 Minuten) oder weniger kann schnell ein Volumen von 50 Abfragen pro Sekunde erzeugen.

Gerade Nameserver-Domains werden besonders häufig abgefragt, aber gerade bei Nameservern ändert man auch besonders selten die IP-Adresse. Deshalb empfehlen wir für solche Domains eine TTL von mehreren Tagen und bei allen anderen Domains eine Standard-TTL von mindestens 86400 (24 Stunden).

zonettl:   86400

Wenn Sie eine Änderung an einem bestehenden Resource Record planen, wie z.B. die Änderung einer IP-Adresse im Verlauf eines Server-Umzugs oder den Schwenk auf einen anderen Mailserver, können Sie 24 Stunden vorher die TTL vorübergehend auf 300 herabsetzen. (Noch kleinere Werte bringen keine nennenswerte Beschleunigung mehr bei der Propagation.) Spätestens nach Ablauf der vorherigen TTL hat sich dann unter allen Resolvern herumgesprochen, dass hier Änderungen zu erwarten sind und die Daten immer wieder erneut abzufragen sind.

Das Hinzufügen einer neuen Subdomain zu einer Zone erfordert i.A. keine Herabsetzung der TTL, denn eine Name, der schon lange nicht oder noch nie existiert hat, wird nur in unwahrscheinlichen Fällen im Negativ-Cache sein, so dass die Resolver den Namen ohnehin direkt abfragen und er schnell propagiert ist.

Übrigens haben wir auch unseren DNS-Synchronisierungsdienst vollständig überarbeitet und optimiert, so dass Änderungen schneller auf die Nameserver übertragen werden und alle bestehenden Resource Records zu jeder Zeit während eines Updates abgefragt werden können, um ungewollte Negativ-Caching-Effekte zu vermeiden.