Moin, Uwe Koloska <[email protected]> (So 28 Aug 2016 13:14:37 CEST): > > Ja. Warum sollte man nicht die Rekusion komplett alleine machen, statt > > sich auf die Proxies zu verlassen. > > Weil Proxies unbestreitbare Vorteile haben und ein Proxy der für viele > arbeitet eine höhere Wahrscheinlichkeit hat, dass die Anfrage schon > aufgelöst wurde.
Welcher Vorteil ist das? Ich denke, wenn Du für Deine Infrastruktur einen DNS-Resolver (Bind/Unbound/Dnsmasq) am Laufen ist, ist das genug gecacht. Dnsmasq braucht halt einen weiteren Forwarder, die anderen nicht, sie lösen die unbekannten Probleme dann halt selbst rekursiv auf. Und m.E. nach schnell genug. Beim ersten Auftauchen einer unbekannten Frage und leerem Cache knapp 500ms. Bei einer anschließenden Anfrage einer anderen Domain unterhalb der selben TLD bin ich schon bei 230ms. Letzteres ist möglicherweise der häufigere Fall, da irgendwann ja die NS für die meist benutzen TLDs im Cache sind. Und bei Anfragen zu Namen innerhalb der selben 2nd Level Domain wird es vermutlich noch mal kürzer, da ja dann i.d.R. schon der zuständige NS aus dem Cache bekannt ist. Ich halte einen DNS-Resolver/Cache/Proxy je Infrastruktur durchaus für sinnvoll, aber sehe großen keinen Gewinn darin, diesen dann noch mal durch einen weiteren Proxy zu schicken. Da nicht alle Domains DNSSec verwenden, ist die Gefahr, dass ein Proxy Dir Antworten liefert, die Du nicht haben wolltest, nicht zu verachten. M.W. passiert sowas gerne bei der Telekom, die schicken Dich dann auf eine Landing-Page, die Deine Userexperience verbessern soll. (Oder wie auch immer das genannt wird …) Und gerade beim Fehlersuchen ist ein erfolgreiches ping auf foobar.froz.boz schon überraschend… (Ich muss fairerweise sagen, dass man dieses Feature in seinem T-Online-Account ausschalten kann.) Gegen böswillige Manipulation der Antworten hilft natürlich auch nicht, keinen Proxy zu verwenden, dafür ist DNS als Protokoll zu einfach. Da hilft nur DNSSec. Aber genau das scheint mein Speedport oder dessen Vorgesetzter nicht zu unterstützen (ich kann zwar einzelne DNSSec-relevante RRs abfragen, aber eine dig +dnssec liefert mitnichten die für eine eigene Validierung erforderlichen Informationen. > > (Warum betreibt Google öffentliche DNS-Resolver. Helfersyndrom, oder > > weil sie gerne wissen möchten, was die Welt so sucht?) > > Deswegen suche ich ja freie Resolver, die das nicht zum Datensammeln > machen. Ich denke, heute einen freien Resolver zu betreiben ist nicht leicht, da Du Vorkehrungen treffen müsstest, um nicht für eine DNS-Amplification-Attacke missbraucht zu werden. (Kurze Query mit falscher Absender-IP, deutlich längere Antwort an den gefakten Absender - ich denke, das tut dem schon weh, wenn es über viele offenen Resolvern zur selben Zeit gemacht wird.) Ich denke, genau deshalb verschicken einige Hoster auch Hinweis-Mails an Root-Server-Betreiber, wenn sie einen offenen Resolver laufen haben. > > Jeder Bind hat die Hint-Data dabei, die Liste der 13 Root-Server, und > > kann sich den Rest selbst zusammensuchen. > > Da bleibt also die alles entscheidende Frage: Rekursiv oder Forward? > > Hier hat mal jemand die Kombination dnsmasq + unbound mit den Google > Resolvern verglichen (Abschnitt "How it stacks up"): > > http://blog.alanporter.com/2014-03-09/dnsmasq-unbound Mir fällt in diesem Artikel schon eine gravierende Ungenauigkeit auf: BIND is a fully recursive DNS resolver. When you look up a name like “www.cnn.com”, it goes to “com” to ask who “cnn” is, and then it goes to “cnn.com” to ask who “www.cnn.com” is. Bind fragt die Root-Server nach A für www.cnn.com, bekommt einen Verweis auf die NS der .com-Zone, stellt denen dann die selbe Frage und wird an die NS der cnn.com-Zone verwiesen, dort stellt er wieder die selbe Frage und bekommt endlich seine Antwort. Insofern wäre ich skeptisch, was diesen Artikel angeht. Interesanntes Detail: Wenn ich meinem lokal laufenden Bind den DNS (vermutlich ein zurechtgestutzer dnsmasq auf dem Speedport) meines Plastik-Routers als „forwarders { … }; forward only;“ eintrage, kann ich Namen, die per DNSSec geschützt sind, nicht mehr auflösen (ausser mit dig +cd). (Oh, pikanterweise erklärt ein nmap mir gerade, daß das wie ein ISC Bind aussieht auf dem Speedport…, na, dann vermutlich eine Version ohne DNSSec-Unterstützung) > > Redest Du vom kasserver, also *Deiner* Domain. Der scheint mir aber EDNS > > zu können. > > Nein. Von _domainkey.archlinux.org -- wir hatten vor einiger Zeit schon > darüber diskutiert. Hm… das weiss ich nicht mehr. > Wo du jetzt aber die Unterschiede von TCP und UDP Paketen so > herausstellst, könnte es natürlich sein, dass ein anderer Nameserver, > der kein EDNS kann und dann aber korrekt auf UDP wechselt, die gleichen > Probleme hätte. Mal überlegen, ob ich das irgendwie überprüfen kann. Du kannst die Verwendung von EDNS verhindern: dig rrsig schlittermann.de @pu.schlittermann.de +noedns Dann sollte auffallen, dass die Antwort verkürzt ist und anschließend TCP verwendet wird. > Da kommen sofort diese Fragen auf: > * Wie könnte ich für diese Domain den authoritativen Nameserver > befragen? Also sage: Für diese (Sub-)Domain, frag den NS? > * Kann Bind/unbound das auch? Also eine Subdomain von einem anderen > Resolver (oder sogar dem NS) auflösen zu lassen? Stichwort sollte stub-Zone sein, oder eine forward-zone. Aber das hatten wir doch schon, habe ich vielleicht die Frage falsch verstanden? -- Heiko
signature.asc
Description: Digital signature
