Hoi Hilmar,

ich vermute das ist der korrekte Ansatz. Nur die Frage: wie. Wie gesagt, ich experimentiere grad damit herum.

Ich nutze aktuell bind 9.10.4.P2-1. Fehlt mir hier ggf. ein "Codeschnipsel" So etwas in der Art: wenn Du es nicht weißt, frag wen anders?

ich bei mir könnte jetzt direkt in der bind-config vermutlich etwas sagen wie: frag 192.168.0.254 (mein Router / DNS Server). Wie machen das andere?

Aber Du hast Recht, ich schau mal wie ich ihm das beibringen kann.

mit freundlichen Grüßen Martin

Am 21.08.2016 um 21:52 schrieb Preuße, Hilmar:

On 21.08.2016 21:46, Martin Schuchardt wrote:

Moin,

...

Daher folgende Frage:

ist es möglich, einem Linux-Client beizubringen, nur beim Auflösen einer (oder mehrerer Zonen) einen bestimmten DNS Server zu verwenden, ansonsten den Standard?

Zuerst die dumme Frage (da ich auch kaum Ahnung von DNS habe): Wäre es nicht einfacher Deinem DNS-Sever beizubringen, einen externen DNS-Server (also den von Deinem Provider) zu fragen, wenn er es selber nicht weiß. Ich behaupte mal frech, das ist gängige Praxis im Internet, weil nicht jeder Client x DNS-Server konfiguriert haben kann.

Hilmar

Martin Schuchardt kruemeltee@gmx.de (Mo 22 Aug 2016 21:51:50 CEST):

Hoi @all,

ja, das mit der .home war nicht so recht durchdacht, das gebe ich zu. Auch eine .local sollte vermieden werden, wenn man (wie ich gelesen habe) mit avahi arbeitet (ich nun nicht, aber der Teufel steckt im Detail).

Was aber das "delegieren" von Nameservereinträgen nur für eine bestimmte Zone anbetrifft, so heisst das Zauberwort: dnsmasq. Das Teil kann noch viel mehr, u.a. aber eben auch das abfragen eines bestimmten Nameservers für eine bestimmte Zone.

DNSMASQ hatte mal eine Zeitlang einen bösen Fehler: es setzte bei jeder Anfrage, die es aus dem Cache beantwortete, das AD Flag (authenticated data), mit anderen Worten, es suggerierte mir, die Daten wären (via DNSSec) validiert. Selbst bei Zonen, die gar kein DNSSec verwenden.

Ich weiss nicht, ob das inzwischen gefixt ist, es wurde damals als weniger wichtig angesehen. Seitdem sehe ich von der Nutzung von DNSMASQ ab, wo immer ich kann.

Heiko

Moin,

Martin Schuchardt kruemeltee@gmx.de (Do 25 Aug 2016 23:12:18 CEST):

Deine Meinung ist mir immer sehr wichtig. Die Einstellungsmöglichkeiten

… Danke. Das ehrt mich :)

beim DNSmasq sind der aktuellen Config nach zu urteilen recht umfangreich. Ich probiere auch noch viel mit dem Zeugs rum. Aber unter

In der Tat. But „real men use Bind“ :) (`unbound` ist auch noch ok :))

Archlinux ist die eingesetzte Version doch recht aktuell. Da ich mich mit DNSSEC jedoch noch in den Kinderschuhen befinde (aber ich bin schon dran mich in das Thema einzuarbeiten) geb ich gern nochmal Feedback diesbezüglich.

dig schlittermann.de @<dnsmasq server>

sollte grob so aussehen:

;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25942 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ** ... und dann natürlich die wirkliche Antwort. Und das schon bei der ersten Frage, dann macht er DNSsec.

Und bei

dig heise.de @<dnsmasq server>

sollte nie das |ad| dabei stehen. Denn die haben keine signierte Zone.

; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17431 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ------------------

Aber mein aktueller Stand, und das funktioniert sensationell: ich habe alle etwaigen Funktionen von DNSmasq deaktiviert, die einzige Aufgabe die das Teil aktuell hat ist: wenn Anfragen für Domain XY kommen, dies an einen bestimmten DNS Server zu senden.

Genau das können Bind oder Unbound auch :). Aber die können kein DHCP. Und ja, DNSMASQ kann viel.

Meinen aktuellen Tests nach zu urteilen macht damit DNSmasq genau das, was ich von ihm will: nur im Falle von Auflösungen von Domains XY wendet er sich an meinen DNS Server, alles andere wird "regulär" an meinen normalen DNS Server weiter geleitet.

Was meinst Du mit „regulärer DNSServer“? Den Deines Providers? Oder einen weiteren Server in Deiner Infrastruktur?

Grüße aus der Neustadt,

Uwe Koloska uwe@koloro.de (Do 25 Aug 2016 23:38:25 CEST):

Am 25.08.2016 um 23:22 schrieb Heiko Schlittermann:

...

In der Tat. But „real men use Bind“ :) (`unbound` ist auch noch ok :))

Und wie lösen die "Real Men" mit Bind oder unbound die folgenden Probleme:

• Nameserver des Providers liefert fehlerhafte DKIM-Signaturen, dnsmasq

fragt in diesem Fall einfach einen beliebigen anderen DNS-Server

Real Men fragen nicht den Nameserver des Providers. (Und, DNS liefert keine DKIM-Signaturen, oder verstehe ich etwas falsch?)

• DNS Anfragen für eine bestimmte Domain (z.B. bei einer VPN-Verbindung)

sollen an den zuständigen Nameserver gehen

Du kannst zonenweise Forwarder einrichten.

...

dig schlittermann.de @<dnsmasq server>

sollte grob so aussehen:

;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25942 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

Habe ich das jetzt richtig verstanden, dass dort nur 'ad' stehen darf, wenn dnsmasq für DNSSEC konfiguriert ist? Das habe ich nämlich (noch) nicht gemacht und bekomme diese Flags:

Dort sollte nur 'ad' stehen, wenn der Resolver, den Du fragst (in Deinem Fall dnsmasq) sich von der Korrektheit der Daten überzeugt hat (sprich: die DNSSec-Signaturen geprüft hat und die Trustchain passt) - natürlich nur bei Domains, die die Verwendung von DNSSec durch einen DS Record in der (signierten) Parent-Domain signalisieren. Im Falle einer fehlerhaften Signatur sollte es keine Antwort geben (Bind: SERVFAIL, glaube ich).

…

...

...

die das Teil aktuell hat ist: wenn Anfragen für Domain XY kommen, dies an einen bestimmten DNS Server zu senden.

Genau das können Bind oder Unbound auch :).

Wann ham die das denn gelernt? Ich dachte, die (wobei ich unbound einfach mal in den Bind-Topf schmeiße) können nur zwischen Autorität (Ich bin selbst zuständig) und Forwarding (für alles andere) unterscheiden.

Ich meine, das geht schon immer.

zone "foobar.de" { type forward; forwarders { 1.1.1.1; 2.2.2.2; }; };

Oder auch stub-Zones (https://lists.isc.org/pipermail/bind-users/2011-March/083244.html)

Uwe Koloska uwe@koloro.de (Sa 27 Aug 2016 17:55:27 CEST):

Am 26.08.2016 um 22:38 schrieb Heiko Schlittermann:

...

Real Men fragen nicht den Nameserver des Providers.

…

Wen denn dann, wenn es nicht Google oder der gar nicht so offene OpenDNS

…

• schnell sind
• keine Datenschutzbedenken auslösen
• keine Antworten verändern oder unterdrücken

Oder machen "Real Men" ihre rekursive Auflösung immer selbst?

Ja. Warum sollte man nicht die Rekusion komplett alleine machen, statt sich auf die Proxies zu verlassen. (Warum betreibt Google öffentliche DNS-Resolver. Helfersyndrom, oder weil sie gerne wissen möchten, was die Welt so sucht?)

Jeder Bind hat die Hint-Data dabei, die Liste der 13 Root-Server, und kann sich den Rest selbst zusammensuchen.

...

(Und, DNS liefert keine DKIM-Signaturen, oder verstehe ich etwas falsch?)

OK, falsches Wort: Ich meinte DKIM Domainkeys. Die liefert der DNS-Server meines Providers nicht aus, weil der TXT-Record zu groß ist und der Server kein EDNS kann (oder das falsch konfiguriert ist).

Redest Du vom kasserver, also *Deiner* Domain. Der scheint mir aber EDNS zu können.

Und selbst ohne DNS sollte ein großer Datensatz kein Problem sein, dafür gibt es ein Fallback auf TCP. Oft ist nicht der Server, sondern der Client falsch konfiguriert (z.B. TCP Port 53 wird nicht raus gelassen, und die Antworten dann nicht rein), oder eine Firewall (bisher eigentlich immer beim Client) denkt, dass UDP Pakete von einem Port 53 nicht mehr als 512 Byte haben dürfen.

...

...

Thema Forward für einzelne Domains:

Ich meine, das geht schon immer. zone "foobar.de" { type forward; forwarders { 1.1.1.1; 2.2.2.2; }; }; Oder auch stub-Zones (https://lists.isc.org/pipermail/bind-users/2011-March/083244.html)

Cool. Wieder was gelernt. Danke!

Gerne :)

Moin,

Uwe Koloska uwe@koloro.de (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?

Uwe Koloska ml@koloro.de (Di 30 Aug 2016 23:56:12 CEST): …

Vorteil von dnsmasq wäre die einfache Integration von DHCP und PXE/TFTP und da würde der Bind/Unbound dann den Part des externen Proxys übernehmen.

Ja, das ist wahr. DHCP&DNS&PXE geht mit dnsmasq wirklich recht schnell und simpel.

Mit dnsmasq brauchst du auf jeden Fall einen Proxy, die Frage ist nur, ob der bei dir oder irgendwo in den Weiten des Netzes steht. Und wenn dnsmasq Vorteile hätte, nähme ich auch in Kauf, zusätzlich einen Proxy zu brauchen.

Ja, den würde ich dann ggf auf 127.0.0.1 laufen lassen und dafür eine Vollversion :) eines Nameservers (eben Bind9 oder Unbound) verwenden.

...

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.

Das funktioniert und die per UDP eintreffenden Antworten sehen vollständig aus (sind aber auch nicht so groß wie der Domainkey von archlinux).

Na, genau mit dem o.g. Bespiel sollte es eigentlich auf TCP umschalten, weil die Antwort die 512 Byte überschreitet und EDNS ausdrücklich unterdrückt wird (das EDNS wäre dann in der Lage, eine größe Paketgröße zu vereinbaren)

Funfakt: Mittlerweile liefert auch der KabelDeutschland (aka Vodafone) NS den vollständigen Eintrag aus.

Vielleicht haben die ja repariert. Oder mehrere Resolver und morgen geht es wieder nicht :)

...

...

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?

Ein richtiger Resolver fragt letztlich immer den für die entsprechende Domain authoritativen Server. Diese Information holt er sich aber über das Abklappern der Kette, bei der Root-Zone beginnend und Zwischenergebnisse cachend, zusammen. Wenn Du den Weg abkürzen willst (oder musst, weil vielleicht die Domain nicht in der Parent-Zone registriert ist), dann kannst Du ja per forward/stub Zone direkt zu den verantwortlichen NS delegieren.

Die erste ist so gemeint: Wenn ich einen Proxy benutze, wie kann ich dann eine einzelne Domain über ihren eigenen NS auflösen? AFAIK kann ich ja nur einen expliziten Nameserver (genauer dessen IP) angeben. Ich möchte jetzt aber einfach sagen: Diese Domain bitte rekursiv auflösen, alles andere an den (externen) Proxy.

Ja, das hängt von dem verwendeten Resolver (Proxy-Client) ab. DNSMASQ kann das, die Resolver-Lib kann es nicht, ob lwres das kann, weiss ich jetzt nicht. Wenn der Client des Proxys ein Bind/Unbound ist, dann geht das (hatten wir ja :))

Bei der zweiten Frage habe ich wahrscheinlich an diese sehr kompliziert aussehende Antwort gedacht:

http://stackoverflow.com/questions/15338232/how-to-forward-a-subzone

Ah, ok.