Anycast DNS robust, latenzarm, skalierbar · 2016. 9. 28. · DNS-Anycast | Frank Brüggemann | 28.09.2016 Anycast – Wie funktioniert es Anycast 2 von 19 • Mehrere DNS-Server,

DNS-Anycast | Frank Brüggemann | 28.09.2016

Anycast DNS – robust, latenzarm, skalierbar

Und mehr…


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


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


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,…


Positionierung DNS-Server

Anbindung der DNS Server

(Anycast)

6 von 19


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


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


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




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




route-map anycastaddressesonly permit 10

match ipv6 address prefix-list anycastaddrs


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


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


Anycast – Queries ns1


Anycast – Queries ns2


Anycast – Latenz / Smokeping


Anycast – Latenz / Smokeping


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


Anycast

Fazit

• Voraussetzungen für Implementierung: Dynamisches Routing

• Positionierung der Server wichtig

• Ausreichend testen!

• Robust, latenzarm, skalierbar


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-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-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-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-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-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-Admin: Benutzeroberfläche

Startseite

10 von 19

• Übersicht der berechtigten Zonen

Statusanzeige

Keine Änderungen

Änderungen vorhanden

Für deploy markiert

und gesperrt

• Suchfunktion



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



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



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



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-Admin: Fazit

Zusammenfassung

• Mandantenfähige Lösung

• Entlastung des Hostmasters

• Strukturierung/Bereinigung des Datenbestandes

• Einbindung in Portallandschaft

• Automatisierte Dokumentation


Vielen Dank für Ihre Aufmerksamkeit

Mitwirkende:

Markus Dienstknecht, Flurin Noller

Tobias Thieron

Jens Hektor, Nils Neumann

Christoph Viethen

Documents

Anycast DNS robust, latenzarm, skalierbar · 2016. 9. 28. · DNS-Anycast | Frank Brüggemann | 28.09.2016 Anycast – Wie funktioniert es Anycast 2 von 19 • Mehrere DNS-Server,