anycast dns robust, latenzarm, skalierbar · 2016. 9. 28. · dns-anycast | frank brüggemann |...
TRANSCRIPT
DNS-Anycast | Frank Brüggemann | 28.09.2016
Anycast DNS – robust, latenzarm, skalierbar
Und mehr…
DNS-Anycast | Frank Brüggemann | 28.09.2016
Motivation
Status quo
2 von 19
• 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
DNS-Anycast | Frank Brüggemann | 28.09.2016
Verbesserungen
Teilprojekte
2 von 19
• 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
DNS-Anycast | Frank Brüggemann | 28.09.2016
Anycast – Wie funktioniert es
Anycast
2 von 19
• 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,…
DNS-Anycast | Frank Brüggemann | 28.09.2016
Positionierung DNS-Server
Anbindung der DNS Server
(Anycast)
6 von 19
DNS-Anycast | Frank Brüggemann | 28.09.2016
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 0.99.23.1, stabil auf NX-OS 6.2(14), CentOS 7
DNS-Anycast | Frank Brüggemann | 28.09.2016
Anycast
Zebra: #cat /etc/quagga/zebra.conf
interface em0
ipv6 nd suppress-ra
!
interface em1
description mgmt
ip address 134.130.5.210/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 134.130.4.1/32
ipv6 nd suppress-ra
interface lo:1
description INT2
ip address 134.130.5.1/32
ipv6 nd suppress-ra
interface lo:2
description EXT1
ip address 134.130.4.9/32
ipv6 nd suppress-ra
DNS-Anycast | Frank Brüggemann | 28.09.2016
Anycast
Quagga: OSPFv2, #cat /etc/quagga/ospfd.conf
interface lo
!
router ospf
ospf router-id 134.130.5.210
log-adjacency-changes
network 134.130.5.209/30 area 0.0.0.4
area 0.0.0.4 authentication message-digest
area 0.0.0.4 nssa
redistribute connected metric-type 1
distribute-list ANYCAST out connected
!
access-list ANYCAST permit 134.130.4.1/32
access-list ANYCAST permit 134.130.5.1/32
access-list ANYCAST permit 134.130.4.9/32
DNS-Anycast | Frank Brüggemann | 28.09.2016
Anycast
Quagga: OSPFv3, #cat /etc/quagga/ospf6d.conf
interface em1
ipv6 ospf6 instance-id 0
!
interface lo
!
!
router ospf6
router-id 134.130.5.210
redistribute connected route-map anycastaddressesonly
area 0.0.0.4 range 2a00:8a60:0:f012::/120
interface em1 area 0.0.0.4
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
DNS-Anycast | Frank Brüggemann | 28.09.2016
Anycast
Backbone: Nexus 7000 OSPF
…
router ospf 100
router-id 134.130.8.1
area 0.0.0.1 nssa default-information-originate
area 0.0.0.4 nssa
area 0.0.0.5 nssa
area 0.0.0.6 nssa
default-information originate always
router ospfv3 200
router-id 134.130.8.1
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 134.130.5.209/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 0.0.0.4
ipv6 router ospfv3 200 area 0.0.0.4
no shutdown
DNS-Anycast | Frank Brüggemann | 28.09.2016
Anycast
…
c6k-sw23#sh ip route ospf | begin 134.130.4.1/32
O E1 134.130.4.1/32
[110/61] via 137.226.38.113, 00:00:06, TenGigabitEthernet2/1
[110/61] via 137.226.38.105, 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
Routing Table eines OSPF-Routers im Backbone
DNS-Anycast | Frank Brüggemann | 28.09.2016
Anycast – Queries ns1
DNS-Anycast | Frank Brüggemann | 28.09.2016
Anycast – Queries ns2
DNS-Anycast | Frank Brüggemann | 28.09.2016
Anycast – Latenz / Smokeping
DNS-Anycast | Frank Brüggemann | 28.09.2016
Anycast – Latenz / Smokeping
DNS-Anycast | Frank Brüggemann | 28.09.2016
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
DNS-Anycast | Frank Brüggemann | 28.09.2016
Anycast
Fazit
• Voraussetzungen für Implementierung: Dynamisches Routing
• Positionierung der Server wichtig
• Ausreichend testen!
• Robust, latenzarm, skalierbar
DNS-Anycast | Frank Brüggemann | 28.09.2016
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
DNS-Anycast | Frank Brüggemann | 28.09.2016
DNS-Admin – Selfservice-Portal
Motivation & Ziele
4 von 19
• 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
DNS-Anycast | Frank Brüggemann | 28.09.2016
DNS-Admin
Deployment der Einträge
5 von 19
NOC Portal
Selfservice-Portal
DNS-Admin
KomDB NOC
Backend
MySQL Datenbank Bind Konfig wird generiert
Git
Git
DNS 1
DNS 2
DNS-Anycast | Frank Brüggemann | 28.09.2016
DNS-Admin
Portale
7 von 19
• Authentifizierung mit Shibboleth
• Autorisierung basierend auf Gruppenzugehörigkeit der Netzwerke-Datenbank
Datenbank
Netzwerke
Selfservice-Portal
DNS-Admin
NOC-Portal
Selfservice-Portal
DHCP-Admin
Selfservice-Portal
Radius-Admin
Selfservice-Portal
Interface-
Admin
Shibboleth
DNS-Anycast | Frank Brüggemann | 28.09.2016
DNS-Admin: Migration des Datenbestandes
Ablauf
8 von 19
• 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 300000 Records
• Unterstützung von zunächst 12 Record-Typen
• Prozess-Dauer ca. 5-10 Minuten
DNS-Anycast | Frank Brüggemann | 28.09.2016
DNS-Admin: Migration des Datenbestandes
Übersicht
9 von 19
halo Komdb (MySQL)
noc-backend (Datenverwaltung)
ns3 (Nameserver neu)
ns4 (Nameserver neu)
ns1 (Nameserver alt)
Git
Respository
Kopierscript Migrationsscript
Exportscript
* umbenannt zu ns1
* umbenannt zu ns2
DNS-Anycast | Frank Brüggemann | 28.09.2016
DNS-Admin: Benutzeroberfläche
Startseite
10 von 19
• Übersicht der berechtigten Zonen
Statusanzeige
Keine Änderungen
Änderungen vorhanden
Für deploy markiert
und gesperrt
• Suchfunktion
DNS-Anycast | Frank Brüggemann | 28.09.2016
DNS-Admin: Benutzeroberfläche
Zonen-Übersicht
12 von 19
• BIND Vorschau möglich
• Möglichkeit Zone zum Deploy
zu markieren
• Allgemeine Informationen
wie IP-Adressen
• Auflistung aller Records
• Zuletzt bearbeitete Records
gesondert dargestellt
DNS-Anycast | Frank Brüggemann | 28.09.2016
DNS-Admin: Benutzeroberfläche
Erstellen und Bearbeiten von Einträgen (1)
14 von 19
• 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
DNS-Anycast | Frank Brüggemann | 28.09.2016
DNS-Admin: Benutzeroberfläche
Erstellen und Bearbeiten von Einträgen (2)
15 von 19
• 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
DNS-Anycast | Frank Brüggemann | 28.09.2016
DNS-Admin: Benutzeroberfläche
Aktualisierung
16 von 19
• 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
DNS-Anycast | Frank Brüggemann | 28.09.2016
DNS-Admin: Fazit
Zusammenfassung
• Mandantenfähige Lösung
• Entlastung des Hostmasters
• Strukturierung/Bereinigung des Datenbestandes
• Einbindung in Portallandschaft
• Automatisierte Dokumentation
DNS-Anycast | Frank Brüggemann | 28.09.2016
Vielen Dank für Ihre Aufmerksamkeit
Mitwirkende:
Markus Dienstknecht, Flurin Noller
Tobias Thieron
Jens Hektor, Nils Neumann
Christoph Viethen