Ein Hidden Primary und dnsdist. Härtung von autoritativem DNS

Autoritatives DNS ist ein Verstärker für Angreifer und ein häufiges Ziel von Floods. Zwei Designentscheidungen leisten den größten Teil der Arbeit, es widerstandsfähig zu machen: Halten Sie den Primary verborgen, und setzen Sie einen Load Balancer, der DNS versteht, vor jeden öffentlichen Server. So geht es, mit den Regeln, die wir als Minimum betrachten.

Verbergen Sie den Primary

Der Server, auf dem Zonen bearbeitet werden, Schlüssel liegen und die Hauptkopie der Daten sitzt, sollte niemals dem Internet antworten. Stattdessen repliziert er über ein rein internes Netzwerk auf öffentliche Secondaries, und nur die Secondaries erscheinen in den NS-Einträgen.

Das bringt Ihnen drei Dinge. Der wertvollste Server ist weder Floods noch Exploits ausgesetzt. Öffentliche Server werden austauschbar: Wird einer angegriffen oder fällt aus, machen seine Partner weiter, und er lässt sich aus dem Primary neu aufbauen. Und Sie können die Secondaries über verschiedene Netzwerke, Standorte und Plattformen verteilen, sodass keine einzelne Fehlerdomäne die Domain lahmlegt.

Ob die Replikation klassisches AXFR und NOTIFY ist oder Datenbankreplikation unterhalb von PowerDNS: Die Eigenschaft, die es zu schützen gilt, ist dieselbe. Die Adresse des Primary darf niemals in einem öffentlichen NS- oder SOA-Eintrag erscheinen. Prüfen Sie es:

dig +short NS example.com
dig +short SOA example.com      # the MNAME field should not be your hidden primary

Warum ein generischer Load Balancer nicht ausreicht

Ein TCP- oder UDP-Load-Balancer kann Anfragen verteilen, aber er kann sie nicht lesen. Fast jede nützliche DNS-Abwehr hängt davon ab, die Anfrage zu verstehen: ihren Typ, die Zone, nach der sie fragt, ob sie ein UPDATE ist, wie viele Fehler eine Quelle erzeugt. dnsdist, aus dem PowerDNS-Projekt, sitzt vor dem Nameserver, hält den öffentlichen Port und trifft diese Entscheidungen, bevor die Anfrage das Backend erreicht. Der autoritative Server selbst lauscht dann nur noch auf localhost.

Die dnsdist-Regeln, die wir als Minimum betrachten

-- backend listens on localhost only
newServer({address="127.0.0.1:5300", name="auth"})
setLocal("0.0.0.0:53")
addLocal("[::]:53")

trusted = newNMG(); trusted:addMask("10.0.0.0/8")   -- your internal replication network
ourZones = newSuffixMatchNode(); ourZones:add("example.com.")

-- ANY queries are an amplification tool; refuse them
addAction(QTypeRule(DNSQType.ANY), RCodeAction(DNSRCode.REFUSED))

-- no dynamic updates or notifies from the internet
addAction(AndRule({OpcodeRule(DNSOpcode.Update), NotRule(NetmaskGroupRule(trusted))}),
          RCodeAction(DNSRCode.REFUSED))
addAction(AndRule({OpcodeRule(DNSOpcode.Notify), NotRule(NetmaskGroupRule(trusted))}),
          RCodeAction(DNSRCode.REFUSED))

-- only answer for zones we actually serve
addAction(NotRule(SuffixMatchNodeRule(ourZones)), RCodeAction(DNSRCode.REFUSED))

-- cap queries per source address
addAction(MaxQPSIPRule(50), DropAction())

-- automatic temporary blocks for sources generating floods of failures
local dbr = dynBlockRulesGroup()
dbr:setRCodeRate(DNSRCode.NXDOMAIN, 50, 10, "NXDOMAIN flood", 60)
dbr:setRCodeRate(DNSRCode.REFUSED, 50, 10, "REFUSED flood", 60)
function maintenance() dbr:apply() end

Was jede Regel Ihnen bringt:

• Das Ablehnen von ANY entfernt die klassische Verstärkungsanfrage.
• Das Ablehnen von UPDATE und NOTIFY von außen schließt die Wege, über die Zoneninhalte oder die Replikation aus dem Internet beeinflusst werden könnten.
• Das Ablehnen von Zonen, die Sie nicht bedienen, bevor das Backend sie sieht, hält zufälligen Müll und Reflection-Probes vollständig vom Nameserver fern.
• Setzen Sie Ratenlimits pro Quelle anhand Ihres realen Datenverkehrs, großzügig genug für große Resolver.
• Dynamische Blocks auf Fehlerraten fangen Random-Subdomain-Angriffe ab, die Floods von NXDOMAIN-Antworten aus vielen Quellen erzeugen, ohne einen Resolver wegen einer schlechten Minute zu blockieren.

Ergänzen Sie Response Rate Limiting im Backend oder in dnsdist, damit selbst legitim wirkende Antworten nicht in eine Flood auf eine gefälschte Adresse verwandelt werden können.

DNSSEC ohne Schlüsselverschiebung

Wenn Ihre Secondaries die Zonen selbst signieren, braucht jeder einzelne die Schlüssel, und die Schlüsselverteilung ist der Punkt, an dem DNSSEC-Deployments schiefgehen. Wenn die Schlüssel in derselben Datenbank liegen, die auf die Secondaries repliziert, signiert jeder Server konstruktionsbedingt identisch. Wenn Sie eine signierte Domain zwischen Anbietern umziehen, gehen Sie in der richtigen Reihenfolge vor: Entfernen Sie den alten DS-Eintrag bei der Registry, warten Sie, bis die Caches abgelaufen sind, signieren Sie auf den neuen Servern, und veröffentlichen Sie dann den neuen DS. Die Validierung bricht nie.

Reverse DNS gehört zur Arbeit dazu

Behandeln Sie Reverse DNS als Regel: Jede Adresse, die einem Interface, einem Dienst oder einem Host zugewiesen wird, bekommt in derselben Änderung einen PTR, und jede Reverse-Zone wird an alle Ihre Nameserver delegiert. Prüfen Sie beide Richtungen und die Delegation vom Parent:

dig +short -x 192.0.2.25
dig +short host.example.com A
dig +short NS 2.0.192.in-addr.arpa

Forward- und Reverse-Namen sollten übereinstimmen, und das NS-Set der Reverse-Zone sollte dem entsprechen, was die regionale Registry hinterlegt hat.

Beobachten Sie die Antworten, nicht nur die Server

Ein Nameserver, der läuft, aber eine veraltete Zone ausliefert, ist schlimmer als einer, der nicht läuft, weil nichts Alarm schlägt. Überwachen Sie, was zählt: Vergleichen Sie das SOA-Serial jeder Zone über alle Server, vergleichen Sie die Anzahl der Einträge, beobachten Sie die Replikationsverzögerung, und alarmieren Sie, falls der Hidden Primary jemals in öffentlichen Daten auftaucht. Von einigen externen Beobachtungspunkten aus zu prüfen, dass jeder öffentliche Server autoritativ antwortet, schließt den Kreis.

Ihre Checkliste

• Ist Ihr Primary verborgen und aus NS und SOA abwesend?
• Stehen die öffentlichen Server hinter einem Front-End, das DNS versteht und ANY, externes UPDATE und NOTIFY sowie unbekannte Zonen ablehnt?
• Gibt es Limits pro Quelle und dynamische Blocks für Fehler-Floods?
• Signieren alle Server identisch, und ist Ihr Verfahren für den DS-Rollover schriftlich festgehalten?
• Hat jede zugewiesene Adresse einen passenden PTR?
• Alarmieren Sie bei abweichenden Serials zwischen Servern?

Wir betreiben unser autoritatives DNS auf PowerDNS genau so, und wir bauen dedizierte Cluster für Kunden, die ihr eigenes wollen. Wenn Sie eine Überprüfung Ihres DNS wünschen, helfen wir gern.

Mit einem Ingenieur sprechen

Related

Verwandt: Autoritatives DNS und Reverse DNS, betrieben als Infrastruktur · Autoritatives und rekursives DNS auf PowerDNS · IPv6, nativ und Dual-Stack