Anycast DNS robust, latenzarm, skalierbar. Und mehr

Transkript

1 Anycast DNS robust, latenzarm, skalierbar Und mehr

2 Motivation Status quo Sun Solaris, alternde Hardware Zwei dedizierte Server, je zwei named-instanzen für Cache und Zonenserver, jeweils eigene Unicast IPv4-Adresse Keine eigentliche Redundanz Keine Wartungsfenster ohne zumindest teilweisen Dienstausfall Kein IPv6 Bearbeitung Datenbestand manuell durch Hostmaster (vi, git, scp i, ) Datenbestand uneinheitlich Keine Mandantenfähigkeit 2 von 19

3 Verbesserungen Teilprojekte Umstellung auf Linux, aktuelle Hardware, weiterhin dedizierte Server Redundanz und Wartungsfreundlichkeit erhöhen: anycast-setup Betrieb im Dual Stack: IPv4 und IPv6 Mandantenfähige datenbankgestützte Portallösung im Eigenentwicklung: DNS- Admin 2 von 19

4 Anycast Wie funktioniert es Anycast Mehrere DNS-Server, alle haben die gleiche Unicast IP-Adresse Auf dem DNS-Server läuft dynamisches Routing (OSPF, ) DNS-Server sind direkt am Backbone angebunden, auch dort dynamisches Routing DNS-Server annoncieren Ihre ÍP-Adresse als /32 Host-Route Metrik im Routing Table entscheidet zu welchem DNS-Server Anfragen geroutet werden Ausfall eines DNS-Servers: Annonciert die Route nicht mehr, OSPF rekonvergiert, Queries werden zu aktivem Server geroutet Anycast nur für Queries, nicht für Zonentransfer, Rekursion, 2 von 19

5 Positionierung DNS-Server Anbindung der DNS Server (Anycast) 6 von 19

6 Dynamisches Routing Konfiguration Server Routing auf Linux Servern: Zebra / Quagga Open Source Routing Software Suite Zebra Core Demon Quagga Clients implementieren die jeweiligen Routing-Protokolle OSPFv2 und OSPFv3 (Beta!) Version , stabil auf NX-OS 6.2(14), CentOS 7

7 Anycast Zebra: #cat /etc/quagga/zebra.conf interface em0 ipv6 nd suppress-ra! interface em1 description mgmt ip address /30 ipv6 nd suppress-ra ipv6 address 2a00:8a60:0:f012::2/120 interface em2 ipv6 nd suppress-ra interface lo! interface lo:0 description INT1 ip address /32 ipv6 nd suppress-ra interface lo:1 description INT2 ip address /32 ipv6 nd suppress-ra interface lo:2 description EXT1 ip address /32 ipv6 nd suppress-ra

8 Anycast Quagga: OSPFv2, #cat /etc/quagga/ospfd.conf interface lo! router ospf ospf router-id log-adjacency-changes network /30 area area authentication message-digest area nssa redistribute connected metric-type 1 distribute-list ANYCAST out connected! access-list ANYCAST permit /32 access-list ANYCAST permit /32 access-list ANYCAST permit /32

9 Anycast Quagga: OSPFv3, #cat /etc/quagga/ospf6d.conf interface em1 ipv6 ospf6 instance-id 0! interface lo!! router ospf6 router-id redistribute connected route-map anycastaddressesonly area range 2a00:8a60:0:f012::/120 interface em1 area ipv6 prefix-list anycastaddrs seq 10 permit 2a00:8a60:0:4::1/128 ipv6 prefix-list anycastaddrs seq 20 permit 2a00:8a60:0:4::9/128 ipv6 prefix-list anycastaddrs seq 30 permit 2a00:8a60:0:5::1/128 ipv6 prefix-list anycastaddrs seq 40 permit 2a00:8a60:0:5::9/128 route-map anycastaddressesonly permit 10 match ipv6 address prefix-list anycastaddrs

10 Anycast Backbone: Nexus 7000 OSPF router ospf 100 router-id area nssa default-information-originate area nssa area nssa area nssa default-information originate always router ospfv3 200 router-id log-adjacency-changes address-family ipv6 unicast redistribute direct route-map all-routes-v6 redistribute static route-map all-routes-v6 interface Ethernet10/9 description ns1 ip flow monitor rwth input ipv6 flow monitor rwth-v6 input ip address /30 ipv6 address 2a00:8a60:0:f012::1/120 ip ospf authentication message-digest ip ospf message-digest-key 1 md5 7. ip ospf priority 10 ip router ospf 100 area ipv6 router ospfv3 200 area no shutdown

11 Anycast Routing Table eines OSPF-Routers im Backbone c6k-sw23#sh ip route ospf begin /32 O E /32 [110/61] via , 00:00:06, TenGigabitEthernet2/1 [110/61] via , 00:00:06, TenGigabitEthernet1/1 - Equal cost paths, gleiche Metrik - Auswahl der präferierten Route folgt der Forwarding Logic (hier Cisco Express Forwarding, Defaults) - DNS-Anfragen sind immer kleine udp-pakete ( <512 Byte, stateless), 1 Anfrage = 1 Paket - Bei großen Antworten (z.b. viele CNAME-Einträge, DNSSEC, ): Truncation Bit wird gesetzt, Kommunikation schwenkt auf tcp, stateful, mehrere Pakete pro Transaktion - Potentiell problematisch bei per packet load balancing, hier nicht der Fall

12 Anycast Queries ns1

13 Anycast Queries ns2

14 Anycast Latenz / Smokeping

15 Anycast Latenz / Smokeping

16 Anycast Migrationspfad Übernahme der Bestands-IP-Adressen -> aus Nutzersicht keine Änderung Routen zu Bestandsservern haben niedrige Spezifizität (/28) Nach Annoncieren der Hostrouten durch Anycast-Server haben diese Priorität (/32) -> Queries erreichen jetzt die neuen Server Im Fehlerfalle: Hostrouten nicht mehr annoncieren, Routing konvergiert schnell wieder zu Bestandsrouten Läuft alles stabil -> alte Server in aller Ruhe außer Betrieb nehmen Umstellung auf neue Produktivsysteme für Clients nicht spürbar

17 Anycast Fazit Voraussetzungen für Implementierung: Dynamisches Routing Positionierung der Server wichtig Ausreichend testen! Robust, latenzarm, skalierbar

18 IP Adress Management DNS-Admin Portalbasierte Lösung zur Administration von DNS-Einträgen Ruby on Rails, Apache, MySQL, Eigenentwicklung Yet another portal für DHCP, IP Netzbereiche, Radius, Interface-Konfigurationen existieren bereits Portale Alternative zu IPAM Software Suites Erfordert Entwicklerkapazitäten, Release Management, Kontinuität

19 DNS-Admin Selfservice-Portal Motivation & Ziele Klassische Verwaltung System wird vom Hostmaster manuell verwaltet Änderungsanfragen über Tickets Keine automatische Validierung Keine automatische Versionskontrolle Selfservice-Portal Reduzierung von Konfigurationsfehlern - alle Portale basieren auf der Netzwerke-Datenbank Vereinfachte Administration - Validierung und Versionskontrolle Schnellere Verarbeitung von Änderungen 4 von 19

20 DNS-Admin Deployment der Einträge Selfservice-Portal DNS-Admin NOC Portal MySQL Datenbank KomDB Bind Konfig wird generiert NOC Backend Git Git DNS 1 DNS 2 5 von 19

21 DNS-Admin Portale Authentifizierung mit Shibboleth Autorisierung basierend auf Gruppenzugehörigkeit der Netzwerke-Datenbank Shibboleth Datenbank Netzwerke NOC-Portal Selfservice-Portal DNS-Admin Selfservice-Portal DHCP-Admin Selfservice-Portal Radius-Admin Selfservice-Portal Interface- Admin 7 von 19

22 DNS-Admin: Migration des Datenbestandes Ablauf Einlesen jeder Zone, Records parsen und auf Gültigkeit prüfen Ausfiltern von Altlasten und Konfigurationsfehlern Automatische Ergänzung von fehlenden Einträgen Prozess-Optimierung Tägliche Migration zur Herstellung eines Parallelsystems (Dauer 4 Monate) Ergebnis Nach Migration ca 1400 Zonen (genauere Einteilung für Rechtesystem) Vorher ca 300 Zonen mit insgesamt ca Records Unterstützung von zunächst 12 Record-Typen Prozess-Dauer ca Minuten 8 von 19

23 DNS-Admin: Migration des Datenbestandes Übersicht ns1 (Nameserver alt) Kopierscript halo Migrationsscript Komdb (MySQL) Exportscript ns3 (Nameserver neu) * umbenannt zu ns1 Git Respository noc-backend (Datenverwaltung) ns4 (Nameserver neu) * umbenannt zu ns2 9 von 19

24 DNS-Admin: Benutzeroberfläche Startseite Übersicht der berechtigten Zonen Statusanzeige Suchfunktion Keine Änderungen Änderungen vorhanden Für deploy markiert und gesperrt 10 von 19

25 DNS-Admin: Benutzeroberfläche Zonen-Übersicht BIND Vorschau möglich Möglichkeit Zone zum Deploy zu markieren Allgemeine Informationen wie IP-Adressen Auflistung aller Records Zuletzt bearbeitete Records gesondert dargestellt 12 von 19

26 DNS-Admin: Benutzeroberfläche Erstellen und Bearbeiten von Einträgen (1) Records, für die Berechtigungen vorliegen, dürfen bearbeitet und gelöscht werden A, AAAA, CNAME, HINFO Möglichkeit zur automatischen Erstellung von Reverserecords zu Addressrecords Automatische Validierung 14 von 19

27 DNS-Admin: Benutzeroberfläche Erstellen und Bearbeiten von Einträgen (2) Bestätigen durch Klick auf deploy Änderungen werden erst nach Bestätigung Live geschaltet (Aktualisierung alle 15 min) Zone wird bis zum Abschluss des Vorgangs für weitere Änderungen gesperrt 15 von 19

28 DNS-Admin: Benutzeroberfläche Aktualisierung Alle 15 Minuten (:00, :15, :30, :45) werden geänderte Daten abgerufen Zeitzyklus aufgrund der maximalen täglichen Seriennummer pro Zone (99) Überführen der Änderungen (Datenbank) in BIND-Syntax 16 von 19

29 DNS-Admin: Fazit Zusammenfassung Mandantenfähige Lösung Entlastung des Hostmasters Strukturierung/Bereinigung des Datenbestandes Einbindung in Portallandschaft Automatisierte Dokumentation

30 Vielen Dank für Ihre Aufmerksamkeit Mitwirkende: Markus Dienstknecht, Flurin Noller Tobias Thieron Jens Hektor, Nils Neumann Christoph Viethen