DNS Server mit Persönlichkeitschutz
Nachdem Google mit dem Public-DNS Dienst unter 8.8.8.8 zum Standard in allen Fragen der DNS-Problembehebung geworden ist, springen nun immer mehr Firmen auf. Aktuell treibt 9.9.9.9 die Sau durch Dorf. Dabei generiert diese Idee massive Probleme, wettbewerbsrechtlich und technisch.
Wettbewerb
Zunächst gibt es eine massive Beschränkung von leicht merkbaren IP-Adressen. Der IPv4 Adressraum läßt nur 220 Adressen der Form x.x.x.x zu.
Davon benutzen schon einige die IPs für DNS Dienste:
- 8.8.8.8 PTR google-public-dns-a.google.com.
- 9.9.9.9 PTR dns.quad9.net.
- 75.75.75.75 PTR cdns01.comcast.net.
- 79.79.79.79 PTR public-dns-a.as9105.net.
- 99.99.99.99 PTR dnsr4.sbcglobal.net.
- 108.108.108.108 PTR 108-108-108-108.pools.spcsdns.net.
- 114.114.114.114 PTR public1.114dns.com.
Einige benutzen die IPs für ihre eigenen Nameserver:
- 77.77.77.77 PTR ns3.hiweb.ir.
- 93.93.93.93 PTR ns.ngenix.net.
- 199.199.199.199 PTR NS1.Shane.co.
- 208.208.208.208 PTR ns1648.ztomy.com.
Andere haben eigene Ideen:
- 16.16.16.16 PTR ldtools.gre.hp.com.
- 23.23.23.23 PTR select.zone.
- 76.76.76.76 PTR lo0-rtc-svw.nco.riseb.net.
- 145.145.145.145 PTR Multicast-RendezvousPoint.surf.net.
- 192.192.192.192 PTR medmgmt-192.tajen.edu.tw.
Der Rest macht sich gar keine Gedanken und gibt die IPs an Kunden raus. 69 davon haben einen entsprechenden Reverse-DNS Eintrag.
Nehmen wir einfach mal an, es liese sich mit diesen Adressen ein DNS-Geschäft machen. Dann kommt die Frage auf, ob diese extrem knappe Ressource gerecht verteilt ist und zukünftige Marktteilnehmer mit ihren innovativen Idee auch die Chance auf Teilnahme bekommen können.
Die Antwort der zuständigen (nationalen) Wettbewerbsbehörde liegt auf der Hand: Natürlich nicht.
Damit bedürfen diese Adressen der Regulierung bzw. der Versteigerung wie bei Funkfrequenzen.
Eigenbedarf
Die offenkundigste Schlussfolgerung des Theaters um 9.9.9.9 ist, selbst weiter zu machen. Ich habe kurzerhand die IP 10.10.10.10 als DNS-Anycast konfiguriert und in Betrieb genommen.
$ dig AAAA lutz.donnerhacke.de @10.10.10.10 +dnssec +multiline ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 727 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 3, ADDITIONAL: 1 ;; ANSWER SECTION: lutz.donnerhacke.de. CNAME pro.donnerhacke.de. lutz.donnerhacke.de. RRSIG CNAME 5 3 57600 ... pro.donnerhacke.de. AAAA 2001:4bd8:1:1:209:6bff:fe49:79ea pro.donnerhacke.de. RRSIG AAAA 5 3 57600 ... ;; AUTHORITY SECTION: donnerhacke.de. NS avalon.iks-jena.de. donnerhacke.de. NS broceliande.iks-jena.de. donnerhacke.de. RRSIG NS 5 2 57600 ... ;; Query time: 11 msec ;; SERVER: 10.10.10.10#53(10.10.10.10) ;; WHEN: Fri Nov 17 21:04:34 CET 2017 ;; MSG SIZE rcvd: 672
Die Antwort kommt mit dem AD-Flag, das eine erfolgreich mit DNSSEC validierte Auskunft bekundet. Damit ist schon mal Sicherheit abgehakt.
Da 10.0.0.0/8 ein privater IP-Bereich ist, der nicht öffentlich erreicht werden kann, ist ausgeschlossen, dass der Kunde einen Nameserver irgendwo im Internet befragt. Stattdessen befragt er einen nächstgelegenen Server im Zuständigkeitsbereich seines ISP. Er hat damit die Gewährleistung, dass niemand die IP per Routingtricks im Internet entführt hat. In Konsequenz hat er damit sichergestellt ausschließlich mit seinem Vertragspartner zu kommunizieren und diesen haftbar machen zu können.
Die Verwendung eines lokalen Servers gestattet dem DNS Betreiber, auf die Weitergabe von Kundeninformationen zu verzichten. Ein angenehmer Nebeneffekt davon ist, dass alle Antworten für alle Anfragenden passen und somit effektiv gecached werden können. Zusammen mit der kurzen Laufzeit zwischen Server und Kunde kann so eine DNS Anfrage deutlich schneller beantwortet werden.
Da auf diese Weise die lokal günstig erreichbaren CDNs bevorzugt werden, wir das Surferlebnis insgesamt fluffiger. Regionale Datenquellen entlasten auch die Außenleitungen des ISP und erlauben so auch anderen Nutzern ein besseres Internet.
Was noch zu tun ist, ist der Hotline beizubringen, bei DNS Problemen nicht mehr auf die 8.8.8.8 zu verweisen, sondern stattdessen die 10.10.10.10 zu empfehlen. Das wird Zeit brauchen. Ebenso wird es dauern, bis die Techniker vor Ort nicht beim ersten Problem die DNS Einstellungen verändern, und wenn, dann auch die 10.10.10.10.
Es ist abzusehen, dass Kunden die 10er IPs auch intern verwenden. Für diese Kunden wird es dann die 100.100.100.100 geben. Ich bin ja nicht so.
Und wenn Du kein Kunde von uns bist? Dann tritt Deinen ISP, dass er auch einen solchen Service aufbaut! Es wäre Best Current Practice, diese IPs überall mit den o.g. Garantien erreichen zu können.
10.0.0.0/8 -> null0
172.16.0.0/12 -> null0
192.168.0.0/16 -> null0
So ist sicher gestellt, dass unbekannter RFC1918-Traffic eben nicht zum ISP geleitet wird.
Zumal ich eh meine, dass man bei IPv4 die direkte Kommunikation im Providernetz zwischen öffentlichen und RFC1918-Adressen vermeiden sollte. Führt bloß unnötig zu 'möglichen' Kollisionen der Adressen.
Da ich selbst ein 10.x.x.x/24 netz nutze ist der aufwand zur adaption nicht so gigantisch. Aber ok, mein ISP (o2) hat eigenes zeugs.
Überhaupt, wie lange is das her, das ein ISP/POP per default einen eigenen resolver anbot?
Ich habe _ECHT_ keinerlei ahnung da ich schon seit frühester zeit an (Compaq 486dx30 als ISDN router) immer eine eigene isc-dhcpd+bind(9) kombi am laufen habe ..... Und ja, der bind fragt natürlich selbst nach, zumindest gelegentlich. ;)
Gruß,
hacky
3 Kommentare