Private Domain Name as a Service
In die Netze von Internetprovidern speisen die Kunden alles ein, was nicht lokal abgehandelt wird. Gebraucht gekaufte IoT-Geräte, internen Traffic, der am Firmen-VPN vorbei leaked, etc. pp. Ein Großteil davon geht an private IPv4 Adressen, die grundsätzlich nicht erreichbar sind. Ein Teil davon sind DNS Anfragen, Und die sollen beantwortet werden.
Seitdem ich den unzustellbaren Traffic einfange, möchte ich den Kundengeräten eine Antwort geben können, die sowohl ungefährlich als auch ausreichend ist. Hört dann das Gerät auf, weitere Pakete zu senden, kann das als Erfolg gelten. Noch besser ist es, wenn der Anwender erkennen kann, wo sein Fehler liegt.
DNS
Anfragen an Nameserver mit privaten IPs machen einen substantiellen Anteil des unzustellbaren Traffics aus. Die meisten Anfragen sind irgendwelche internen Namen wie Fritz-Repeater.fritz.box oder _ldap._tcp.dc._msdcs.WORKGROUP.WORKGROUP. Es würde also gar nichts bringen, in diesen Fällen die korrekte Antwort zu liefern, denn die gibt es nicht.
Um Schwierigkeiten mit anfälligen Funktionalitäten zu vermeiden wähle ich als DNS Server die Software nsd, ein rein authoritiver, sehr belastbarer Name-Server.
Die Konfig ist ziemlich einfach, denn der Server soll nur auf der lokalen IP 127.0.0.2 laufen:
server: ip-address: 127.0.0.2 zone: name: . zonefile: /etc/nsd/catch.zone allow-query: 127.0.0.0/8 NOKEY allow-query: 100.64.0.0/10 NOKEY
Zuständig ist er für die Root-Zone und damit für alles, was darunter liegt. Alles also. Und damit das keinen unkontrollierbaren Mißbrauch gibt, wird die Anfrage auf die IP Bereiche eingeschränkt, die auch in diesem Netz bedient werden. Zugriffe aus dem Rest des Internet werden abgelehnt, auch wenn diese eigentlich gar nicht ankommen können.
Die Zone muss nun alle sinnvoll auftretenden Recordtypen enthalten:
$ORIGIN . $TTL 600 ; automatic recovery after 10 minutes . SOA catch-private. noc.... ( 2026020301 ;Serial 7200 ;Refresh 3600 ;Retry 1209600 ;Expire 600 ;Negative response caching TTL ) NS catch-private. * A 127.0.0.1 AAAA ::1 NS your.dns.config.is.broken. MX 0 your.dns.config.is.broken. TXT "Please fix your DNS config" PTR your.dns.config.is.broken. SRV 0 0 443 your.dns.config.is.broken. SVCB 0 your.dns.config.is.broken. HTTPS 0 your.dns.config.is.broken.
Jede Art von Anfrage wird per Wildcard erfasst und mit den typischen Antworten bedacht:
- Verbinde Dich zu Dir selbst (localhost)
- Wenn Du etwas wissen musst, dann bekommst Du einen Hinweis auf Deine kaputte Konfiguration
- Der Hinweis verbindet sich zu Dir selbst.
Dank der DNAT Konfig scheinen dann die Antworten vom angefragten System zu stammen.
100.75.204.163.61225 > 10.2.0.1.53: 30905+ SRV? _ldap._tcp.dc._msdcs.fritz.box. (48) 10.2.0.1.53 > 100.75.204.163.61225: 30905*- 1/1/4 SRV your.dns.config.is.broken.:443 0 0 (227) 100.75.145.170.63061 > 10.0.0.243.53: 10330+ A? wpad.fritz.box. (32) 10.0.0.243.53 > 100.75.145.170.63061: 10330*- 1/1/2 A 127.0.0.1 (134) 100.75.145.170.62904 > 10.0.0.243.53: 37418+ A? wpad.fritz.box. (32) 10.0.0.243.53 > 100.75.145.170.62904: 37418*- 1/1/2 A 127.0.0.1 (134) 100.75.145.170.62904 > 10.0.0.243.53: 28489+ A? wpad.fritz.box. (32) 10.0.0.243.53 > 100.75.145.170.62904: 28489*- 1/1/2 A 127.0.0.1 (134) 100.75.145.170.63061 > 10.0.0.243.53: 48991+ A? wpad.fritz.box. (32) 10.0.0.243.53 > 100.75.145.170.63061: 48991*- 1/1/2 A 127.0.0.1 (134) 100.77.241.104.61466 > 192.168.1.1.53: 203+ A? www.3322.org. (30) 192.168.1.1.53 > 100.77.241.104.61466: 203*- 1/1/2 A 127.0.0.1 (132) 100.75.8.92.62066 > 10.238.2.2.53: 53864+ A? a.root-servers.net. (36) 10.238.2.2.53 > 100.75.8.92.62066: 53864*- 1/1/2 A 127.0.0.1 (138) 100.75.98.217.55031 > 192.168.19.2.53: 2898+ SRV? _ldap._tcp.dc._msdcs.WORKGROUP.WORKGROUP. (58) 192.168.19.2.53 > 100.75.98.217.55031: 2898*- 1/1/4 SRV your.dns.config.is.broken.:443 0 0 (237) 100.75.98.217.58566 > 192.168.19.2.53: 2899+ A? your.dns.config.is.broken. (43) 192.168.19.2.53 > 100.75.98.217.58566: 2899*- 1/1/2 A 127.0.0.1 (145) 100.75.98.217.58566 > 192.168.19.2.53: 2900+ AAAA? your.dns.config.is.broken. (43) 192.168.19.2.53 > 100.75.98.217.58566: 2900*- 1/1/2 AAAA ::1 (157) 100.75.155.21.63241 > 10.176.95.252.53: 18753+ AAAA? dns.msftncsi.com. (34) 10.176.95.252.53 > 100.75.155.21.63241: 18753*- 1/1/2 AAAA ::1 (148) 100.75.155.21.61397 > 10.176.95.252.53: 46222+ A? dns.msftncsi.com. (34) 10.176.95.252.53 > 100.75.155.21.61397: 46222*- 1/1/2 A 127.0.0.1 (136) 100.75.155.21.63241 > 10.176.95.252.53: 32607+ A? ipv6.msftconnecttest.com. (42) 10.176.95.252.53 > 100.75.155.21.63241: 32607*- 1/1/2 A 127.0.0.1 (144) 100.75.155.21.61397 > 10.176.95.252.53: 11911+ A? www.msftconnecttest.com. (41) 10.176.95.252.53 > 100.75.155.21.61397: 11911*- 1/1/2 A 127.0.0.1 (143) 100.75.155.21.62785 > 10.176.95.252.53: 61859+ A? www.msftconnecttest.com. (41) 100.75.155.21.64381 > 10.176.95.252.53: 61057+ A? ipv6.msftconnecttest.com. (42) 10.176.95.252.53 > 100.75.155.21.62785: 61859*- 1/1/2 A 127.0.0.1 (143) 10.176.95.252.53 > 100.75.155.21.64381: 61057*- 1/1/2 A 127.0.0.1 (144) 100.75.155.21.63241 > 10.176.95.252.53: 64996+ A? ipv6.msftconnecttest.com. (42) 10.176.95.252.53 > 100.75.155.21.63241: 64996*- 1/1/2 A 127.0.0.1 (144) 100.75.155.21.61397 > 10.176.95.252.53: 26122+ A? www.msftconnecttest.com. (41) 10.176.95.252.53 > 100.75.155.21.61397: 26122*- 1/1/2 A 127.0.0.1 (143)
Man sieht schön, wie
- Typische interne Namen (...fritz.box) nun aufgelöst werden können.
- Die Auflösung (_ldap...) akzeptiert wird und zu Folgeabfragen führt.
- Verschiedenste Verbindungstests beantwortet werden können, auch wenn dann lokal kein Webserver antwortet.
Was man nicht sieht, ist der dramatische Rückgang an DNS Anfragen, die sonst unbeantwortet blieben oder abgelehnt wurden. Das fehlkonfigurierte, anfragende System ist zumindest für einige Minuten ruhig gestellt.