Hi.

ich bastel grad bissi mit nem DNS Server auf Basis eines debian mit bind9. 'Mein' DNS löst aktuell alle bekannten Hosts über FQDN (also Hostnamen.MeineDomain) vorwärts wie rückwärts sauber auf. ping auf hostnamen klappt, nslookup auf hostnamen klappt. dig auf hostnamen klappt erst mit dreingabe von '+search'. Normale Antwortzeiten bewegen sich hier um die 2-4ms.

Soweit so gut dachte ich mir und wunderte mich, als ich bei einem 'dig' auf einen internen hostnamen, in dem mir ein Tipfehler unterlaufen war (beispielsweise 'drukcer' anstatt 'drucker'), nun eine Antwortzeit von über 20ms zeigte
Über einen tcpdump war dann auch ersichtlich, dass die Anfrage nicht lokal mit NXDOMAIN beantwortet wurde, sondern an den externen DNS durchgereicht wurde.
Schaut so aus, dass Auflösungsversuche von unbekannten hostnamen an den Resolver des ISP gereicht werden, der ja nu ganz sicher nichts damit anzufangen weiß. Meine Erwartungshaltung wäre eigentlich, dass einzelne Hostnamen nur lokal aufgelöst werden sollten und eher garnicht an den externen DNS durchgereicht werden; hierfür seh ich meinen DNS als "authoritär" an.


Jemand ne spontane Idee, ob das so soll? Oder steht doch eher noch ein wenig Gegrabe in meiner Config an?

Danke und nen schee Wochenende!

Das ist normal. Alles was nicht lokal aufgelöst werden kann wird durchgereicht. Wie sonst soll die Entscheidung getroffen werden?

Danke für die Rückmeldung! Das hab ich irgendwie befürchtet.
Hätte es gut gefunden, wenn quasi für alle Hostnamen, die entweder gar keinen oder eben meinen (privaten) Domain-Anteil für die Anfrage mitbringen, die Auflösung gezielt auf dem lokalen DNS (inkl. dem NXDOMAIN bei Bedarf) erfolgt, während alle FQDN mit einem anderem Domain-Teil an den vorgelagerten Resolver gehen können und ich dann ggf den NXDOMAIN von dort bekomme.
Merci =)

ich würde vermuten, dass man deinem DNS/bind per Konfiguration sagen kann, dass Auflösungen mit deiner internen Domäne nicht weitergereicht werden, sondern dass Fehler gleich weitergereicht werden.
Also dass er die Suche nach drukcer.meinnetz.corp nicht weiterreichen soll, weil er DER DNS für die Domäne meinnetz.corp ist und das externe DNS das erst recht nicht auflösen können - diese können es nicht besser wissen als er.
Aber ist eine Vermutung die ich nicht mit praktischer Erfahrung belegen kann - aber es würde mich wundern - da kämen sicher tausende sinnloser Anfragen and die externen DNS aus internen Netzen - was bei Firmennetzen kein Spaß ist (weil man die Anfragen an externe DNS Server mitlesen kann).

genau diese Stellschraube hatte ich auch erhofft. =)
Ist ja nur ne Kleinigkeit, weil letztlich nur Tipfehler nach "draußen" gehen, während die bekannten Hosts ja lokale Auflösung erfahren. Ich grabe weiter.. Danke!

Nein. Nicht ganz jedenfalls.

Wenn der Vertipper im Domainteil (also hinter dem ersten Punkt) des FQDN ist, muß der Resolver versuchen, den Namen rekursiv aufzulösen. Dann hast Du recht.

Ist er im Hostnamen und ist der Nameserver für die korrekt geschriebene Zone autoritativ, muß bei korrekter Konfiguration ein NXDOMAIN zurückgegeben werden (oder ein NXRRSET, falls es nur das angeforderte RR nicht gibt).

Um die Frage wirklich beantworten zu können, müßte man die Konfiguration (mindestens named.conf) des BIND9 kennen, ebenso wie die Anfrage und ggf. die Antwort.

Hi Peter,

Deine Worte machen mir Hoffnung =) Denke, dann find ich auch den Schalter, den es braucht, dass der interne DNS einfache Hostnamen ohne Domainanteil auch ordentlich mit NXDOMAIN quittiert, wenn ma nen Tippfehler drin sein sollte.
Auf das dig für besagten "drukcer.MeineDomain" gibt mein DNS ganz ordentlich den NXDOMAIN zurück, ohne den externen DNS anzusprechen.

"dig drukcer" verlässt allerdings das lokale Netz, obwohl 'dig drucker' wieder sauber ausschließlich intern behandelt wird.

Die named.conf schaut so aus:


Die named.conf.local:


die named.conf.options :



Viielen Dank für Eure Gedanken und Input!

20ms ist aber auch wirklich eine lange Zeit um auf die Fehlermeldung zu warten und das Kommando zu korrigieren

Irgendwie seh ich das Problem nicht

Sollten wirklich Anfragen fuer interne authorative Zonen nach draussen gehen, im Falle das nur ein Fehler im Hostnamen gegeben ist, dann ist da ein Problem.

Ich verwende generell ein dual DNS Setup, das bedeutet alle internen Systeme haben einen Domainteil der nur fuer meinem internen DNS authorativ ist.
Mein interner DNS (der DNS der sich von innen betrachtet vor der DMZ befindet), loest nur die internen Anfragen auf, externe Anfragen (alle Domains die nicht mir sind bzw. auch eigene die nicht meiner internen Subdomain angehoeren) kann nur mein externer DMZ Server (der sich innerhalb der DMZ befindet) aufloesen bzw. die Anfrage zur Aufloesung an die uebergeordneten Nameserver weitergeben.

Alle Rechner im internen Netzwerk kennen den externen DNS Server nicht und koennen selbst auch keine extenen DNS Server ansprechen (Kommunikation ist ueber die erste Firewall von innen in Richtung DMZ geblockt), Domains ueber den externen DNS Server (in der DMZ) kann nur der Proxyserver aufloesen, da nur dieser mit Rechnern in der DMZ "sprechen" kann.

Lies dir bitte noch mal genau den Text von pcp durch. Er benennt ergo ist "Hostnamen" in diesem Fall ohne lokale Domain.
Und das wird immer weitergereicht, wenn es lokal nicht aufgelöst werden kann.

Deswegen hatte ich die Frage so verstanden, dass alle unbekannten Hostnamen (ohne Domain) lokal mit Fehler beantwortet werden sollen. Das klappt meines Wissens nicht mal für den eigenen Rechner.

Die Suche nach der lokalen Domain ist falsch eingerichtet. Das kann auch ein Client-Problem sein. Die Beschreibungdeutet ebenso darauf hin.

Ist auf dem Test-Client unter "Netzwerk > Weitere Optionen > DNS > Such-Domains" die lokale Domain korrekt aufgeführt?

"drukcer" muss als "drukcer.MeineDomain" aufgefasst werden, so dass der lokale DNS sofort authoritativ mit NXDOMAIN antwortet. Um zu entscheiden, ob man ein komplizierteres Setup mit Split-DNS-Verfahren braucht, müsste man erst wissen, ob es "MeineDomain" auch offiziell im Internet gibt oder nicht.

Du müsstest noch unbound installieren. Dann löst Dein DNS alles lokal auf, bzw. eben nicht. Es wird dann aber keine Anfrage weiter geleitet.

Moin =) mein DNS ist auch DHCP und verteilt folgende Optionen:
der Testrechner(Mac mit aktueller Software) zeigt 'MeineDomain' in den Suchdomains. Trotzdem bekomme ich (während ping und nslookup das gewünschte Ergebnis liefern!) mit dem dig auf den Hostnamen keine zugehörige IP geliefert; weder am Testrechner, noch am DNS selbst. Auch dort benötige ich den +search für das dig.
Es scheint, als hätte mein DNS selbst noch nicht recht akzeptiert, Teil von 'MeineDomain' zu sein.

Maxgeb. die 20ms seh auch ich definitiv nicht als Problem an.. eher als Indiz für den Umstand, dass mein DNS Anfragen ins WAN hustet, die das WAN weder beantworten kann, beantworten möchte, noch irgendetwas angeht.

sgmelin: unbound schau ich mir auf jeden Fall an.. heut sollt die Post das SD Kärtchen für den Bastel Raspi bringen

Danke Euch allen für die Ideen und Tips!!! sehr großartig =)

Das ist das erste, was mir heute auch aufgefallen ist. Es ist aber kein Fehler, sondern Standardverhalten von dig, das nutzt per default nie die Searchlist.

Was mich eher wundert ist, daß @pcp schreibt, daß korrekt angegebene Namen ohne per dig auflösbar sind - das sollte nicht gehen. Deswegen würde mich die genaue Ausgabe von dig jeweils mit einem korrekten und einem inkorrekten Hostnamen interessieren.

Die bind9-Konfiguration sieht soweit OK aus, außer daß ich mich frage, was der Abschnitt
bewirken soll. Der ist eigentlich überflüssig.

Der nächste Ansatz ist dann, mit
die Protokollierung von Namensanfragen im bind9 einzuschalten und im relevanten Log (bei RHEL/CentOS/Alma etc. ist das /var/log/messages, eventuell nutzt Debian ein eigenes File) nachzuschauen, welche Anfragen dabei ankommen.

Ach so, noch eines zum generellen Setup - warum überhaupt ein Forwarder, wenn Du schon bind9 betreibst? Der kann die rekursiven Anfragen auch prima selbst beantworten und Du leitest nicht alle Deine externen DNS-Anfragen an einen Dienstleister (noch dazu Cloudflare) weiter, der als Datengräber bekannt ist.

Wenn schon, dann nähme ich eher einen Dienstleister wie quad9 oder noch besser Digitalcourage.

ich hoff, ich krieg das halberwegs übersichtlich dargestellt

hier zunächst die digs


hier zeigen die Laufzeiten, dass die Anfrage für drukcer.de (was korrekt ist) und die für drukcer nach draußen gehen. Das dig auf drukcer.MeineDomain wird passend von meinem DNS mit NXDOMAIN beantwortet.

Das syslog warf (uff.. enormes Grundrauschen, wenn vorher nicht Mail und Co mal geschlossen wird... ) folgende Zeilen zu den o.g. digs:


dazu passend die der tcpdump mit filter auf Port53 und host 1.1.1.1:


Danke für den Hinweis: den Eintrag "server 1.1.1.1 { };" hab ich entfernt.

muss gestehen, mein primäres Ansinnen war hier erst mal die Kombi aus schnellen Dialogen (und hier brilliert Cloudflare in meiner Region!) in Verbindung mit meinen eigenen Filtern, die ich, wenn der bind mal tut, als weitere Zone einbinde.
Das Peering oder Routing, dass mein Provider in Richtung der eigentlichen root Ressourcen nutzt, mündet für mich in Antwortzeiten von 600-1200ms. Die Responsen von Cloudflare laufen nur 10-12ms.
Die Wahl von Cloudflare werd ich sicher noch mal genauer für mich bewerten. Danke für den Hinweis!!

"drucker.de"? Das ist aber kein Name in Deiner Domain, nicht wahr? Vollkommen normal, daß der extern aufgelöst werden kann und "drukcer.de" nicht.

Unterschiede in der Laufzeit sind da vollkommen normal, zumal da unterschiedliche Cache-Haltezeiten zum Einsatz kommen (NXDOMAIN wird im allgemeinen kürzer im Cache gehalten als eine gültige Antwort). Es kann also passieren, daß die Antwort aus Deinem lokalen Cache kommt und das NXDOMAIN wieder vom TLD-NS geholt werden muß.

Der Rest sieht auch konsistent aus. Da ist alles im grünen Bereich. Daß dig die Searchlist nur bemüht, wenn man ihm das sagt, weißt Du jetzt auch.

Wenn Du den Verlauf der Namensauflösung genauer beobachten willst, hilft auch '+trace' (hier der Übersichtlichkeit halber mit '+nodnssec'):

Wozu? Das kann bind9 auch selbst. unbound ist nur ein Resolver.

Man kann jetzt argumentieren, daß ein autoritativer DNS-Server nicht auch noch Resolver sein sollte, um Cache Poisoning-Attacken zu vermeiden. Das ist aber eigentlich nur dann wirklich relevant, wenn der autoritative Server auch Anfragen aus dem Internet verarbeitet - was hier offenkundig nicht der Fall ist.

Der 'dig drukcer.de' war als Test für nen NXDOMAIN gedacht, dass wegen des TLD natürlich von 'außen' kommen muss und ja auch kam.

Vielen Dank Euch allen für den wertvollen Input!!

Wünsch Euch nen schönes Wochenende!

Wow! Was ist das für ein Provider? Oder ist Deine named.ca vielleicht "antik"?

Aber auch das ist eigentlich kein Thema, das passiert nur beim ersten Aufruf einer jeweiligen TLD, danach sind die Adressen der TLD-Nameserver im Cache (für ".de" z.B. zwei Stunden, d.h. alle zwei Stunden erfolgt ein Durchgriff auf das SOA-Record der Zone. Damit kann man leben).

Evtl. Offtopic?
Also als Externen DNS habe ich gute Erfahrung mit o.g. Quad9 (9.9.9.9) gemacht. Bekommt auch gute Bewertungen im Datenschutz und ist bei mir hier in NRW Rattenschnell.
Mein Kommentar hilft dir jetzt nicht bei deinem int. DNS-Server Problem aber die fehlgeleiteten Anfragen gehen dann wenigstens an "vertrauenswürdigere" Hände...

9.9.9.9 wendet Filter an. Wenn du das weißt und gut findest, prima. Ansonsten kannst du auch 9.9.9.10 von Quad9 nutzen, der filtert nicht: https://dnscrypt.info/public-servers/ Wenn man einen eigenen DNS(cache) betreibt, dann ist die Geschwindigkeit meist ja gar kein Kriterium, denn man muss idR nur einmal auf eine DNS Anfrage warten. Ausnahme wäre natürlich, wenn du dauernd unbekannte IPs auflösen musst oder du zB Spiele nutzt, die dauernd neue domains abfragen (gibt es sowas?).

Geschwindigkeits-Beispiel:
Bei mir (eigener DNS Cache) hat die erste Abfrage von mactechnews.de 39ms gebraucht, jede weitere 0ms.
Quad9 gefragt, erste Abfrage 24ms, jede weitere irgendwo zwischen 12ms und 15ms, manchmal auch 51ms.

Ich nutze einen DNS Resolver, da so keine der DNS Server meine vollständige Anfrage zu sehen bekommt. Und ich mir nicht überlegen muss, wem ich vertrauen will.
Weiterhin muss ich mir weniger Gedanken um DNS-Zensur machen (siehe ). Malware IPs blocke ich mit piHole, habe also Kontrolle über die Blockliste (anders als bei zB 9.9.9.9).

Und – da ich ja einen piHole betreibe – lässt sich ein DNS Resolver wie unbound einfach und schnell darin integrieren:
https://docs.pi-hole.net/guides/dns/unbound/

Dort werden auch kurz die Vorteile und Nachteile eines DNS Resolvers beschrieben:
Übrigens, die einfachste Möglichkeit, Privatsphäre und Sicherheit zu erhöhen, ist wahrscheinlich DoH.
Das bietet Firefox auch auf MacOS seit ein paar Versionen an und funktioniert auch mit Quad9 (9.9.9.9 unter Custom eingeben):
https://t3n.de/news/doh-kommt-firefox-setzt-dns-1256542/

Guter und wichtiger Hinweis, ja. Deswegen gebe ich, wenn ich Quad9 empfehle, meist auch die URL an und nicht die IP-Adresse des Nameservers (was ohnehin Unfug ist, da man, wenn schon, alle angeben müßte). 9.9.9.9 ist halt so schön einfach.
Das geht aber für pcp am Ziel vorbei, da er erstens kein Pi-Hole einsetzt und zweitens mindestens eine eigene Domain autoritativ betreiben will. Da geht dann an einem vollfunktionalen DNS-Server wie BIND oder PowerDNS kein Weg vorbei, und unbound zusätzlich bringt dann keinen echten Vorteil mehr.
Das Hauptproblem bei DoH ist halt, daß die Standardeinstellung bei Firefox auf Cloudflare zeigt. Da gefühlt 99.9% der Leute das nicht umstellen, erreicht es das Gegenteil von Privatsphäre - man gibt einem datengetriebenen Konzern seine gesamte DNS-Historie in die Hand (gut, Google wäre noch schlimmer. Aber nur etwas). Auch Quad9, trotz aller hehren Vorsätze, ist damit letztlich in einer privilegierten, zentralen Situation und das widerspricht jedem Dezentralisierungsbestreben.

Im eigenen Netz ist DoH aber ohnehin uninteressant, wenn man seine eigenen Resolver betreibt.

Auf jeden Fall. Sorry, ich hatte ja auf iBerts gekaperten offtopic-Zeig geantwortet (und nicht auf pcps, denn mit bind kenn ich mich nicht aus)…

Ich empfinde eine Standard-Empfehlung, einen "moderierten" DNS einzustellen – genau wie jede andere Art einer intransparenten Inhaltsfilterung – als gefährlich, vor allem, wenn man sich dessen nicht bewusst ist. Wenn man es weiß, kann man das dann natürlich aus guten Gründen tun.

Das hatte mich damals auch gewundert. Mozilla sagt dazu:
https://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs#w_how-did-mozilla-choose-cloudflare-as-a-trusted-resolver

Für mich geht das aber wieder zurück auf meine Ausgangsfrage "Wem will man trauen?"

Ja, und so habe ich das auch gefunden. Denn ich dachte, DoH wäre noch ein US-only Feature von Firefox. Da mein unbound auf einmal keine Anfragen vom Browser bekam, habe ich mich auf die Suche gemacht. Ist (leider? glücklicherweise?) in Firefox gut versteckt.

Nicht nur Quad9, der ganze DoH-Ansatz widerspricht dem mMn.

Leider scheint das ja ein Phänomen der heutigen Welt zu sein, zu "monopolisieren": Fast alle kaufen bei Amazon; kaum einer will mehr Zusatzsoftware, muss alles direkt von Apple kommen; was Google nicht kennt, existiert nicht etc. Aber das ist nun wirklich offtopic

Mich wundert bei Apple ein wenig, dass sie das Thema DNS noch nicht angegangen sind, da Datensicherheit bei Apple ja eine große Rolle im Marketing spielt. Es wäre für Apple ja einfach, etwas wie DNSCrypt zu implementieren und/oder einen eigenen DNS anzubieten. Allerdings auch mit der Gefahr, dass man das auf einmal nicht mehr umstellen kann. Aber da Apple ja immer noch keine andere Searchengine als Google per default einstellt, ist das derzeit unwahrscheinlich.

Vollkommen Deiner Meinung. Quad9 geht - wenn man nicht einfach 9.9.9.9 einträgt, sondern sich wirklich mal auf der Webseite umschaut - sehr transparent damit um, aber die Stoßrichtung ist schon allein deswegen eindeutig die zum gefilterten DNS, weil die 9.9.9.9 dem Namen entspricht und auch einigängiger ist als die ungefilterte 9.9.9.10.

Mea culpa, da habe ich auch geschlampt. Ich kann zu meiner Verteidigung höchstens anführen, daß ich den Service mangels Notwendigkeit auch nicht nutze
Ich will der Mozilla Foundation da gar nichts böses unterstellen. Es war sicherlich eine Entscheidung, die organisatorisch und technisch Sinn hatte, denn es ist ja auch niemandem damit gedient, schlagartig Hunderttausende von Usern auf einen Service zu schubsen, der dann einfach mal sang- und klanglos unter der Last kollabiert.

Aber meines Erachtens hätte man transparenter damit umgehen müssen und auch die Einstellmöglichkeit nicht ganz so sehr verstecken, wie das initial passiert ist. Einfach mal so ungefragt umstellen hat aus meiner Warte ein Geschmäckle.
Genau das meine ich.
Ich sehe das ein wenig differenzierter.

DOH bietet durchaus die Möglichkeit, die Sicherheit und Privatsphäre zu verbessern: Die meisten Benutzer verwenden ohnehin den Resolver, den ihr Zugangsprovider ihnen liefert (oder den von Google, wenn sie ganz besonders schlau sein wollen), haben also (ohne ein gewisses technisches Grundverständnis) genau so eine zentrale DNS-Lösung wie wenn sie DoH einsetzten. Die dann durch eine verschlüsselte und mit Zertifikaten abgesicherte zu ersetzen ist durchaus eine Verbesserung. Nicht mehr und nicht weniger zentralisiert, aber wenigstens nicht von jedem Deppen mit einem Sniffer mitzulesen.

Wie ja schon geschrieben ist das natürlich nicht der Fall, wenn man eigene Resolver betreibt. Da wäre dann höchstens eine Option, einen eigenen DoH-Server zu bauen und den dann für die Eigennutzung im Internet zu exponieren.

Der Haken daran (und der Grund, weshalb das Projekt recht weit hinten in der Queue ist) ist die mangelnde Unterstützung von DoH auf Betriebssystem-Ebene. Solange man es nicht wirklich als Ersatz für klassische einsetzen kann ist DoH aus meiner Sicht bestenfalls ein nice to have-Feature.
Ist es, aber irgendwie auch passend zum Thread: Einen eigenen DNS-Server (und -Resolver) einzurichten ist ja schon ein erster Befreiungsschlag von genau diesem Sog zur Zentralisierung. Davon brauchen wir eigentlich mehr.

Stimmt. Das wäre eine gute Initiative von MacTechNews: Workshop am Wochenende und dann einmal statt zweimal HiFi News?

„Wie richte ich einen DNS ein und warum sollte ich das tun?“
„Welche Tools helfen, Malware zu erkennen und zu entfernen?“
„Backup Strategien 101“
„Welche Tools optimieren meinen Mac?“
„Wie blocke ich Ads und warum ist das vielleicht unfair?“
„Wie surfe ich sicher?“
etc.