11
Setup BIND9 with AdGuard and DoT
Hallo zusammen,
ich befasse mich gerade mit dem setup von Bind9 in Zusammenhang mit AdGuard. Aktuell nutze ich Unbound auf der OPNSense. Dort habe ich DNSSEC support enabled und ebenfalls DoT mittels AdGuard eingerichtet. Unbound möchte ich nun durch bind9 ersetzen.
Aktuell habe ich folgendes funktionierend audbauen können:
Strecke: Client -> BIND9 -> AdGuard mit standard dns port 53. Alle requests kann ich in AdGuard als plain DNS sehen, also gehe ich davon aus die Kette wie gewünscht funktioniert.
Zusätzlich ist eine zone mit einer internen domain erzeugt.
Strecke: Client -> BIND9 -> interner Server
Anbei meine config:
#named.conf
Die default zone ist unverändert
Datei: named.conf.options
Restliche infos zu der privaten Zone spare ich mir an dieser Stelle, da ich denke, dass die infos nicht weiter relevant sind. Interne Auflösungen mittels nslookup funtkionieren weiterhin.
Was nicht funktioniert:
IP 11 ist mein bind9 server, wobei der port 53 für bind korrekt ist. da der erster hopp die 53 ist, dann soll es ja weiter zu AdGuard auf 10853. Ich kann den request im AdGuard nicht sehen -> macht Sinn bei der Meldung
sudo systemctl status bind9 zeigt dann
Die Meldung sagt mir, dass versucht wird zdf.de auf dem AdGuard mit Port 10853 aufzulösen, aus meiner Sicht richtig, da hier ja dann die resolver aufgelisted sind. Dennoch wird die connection abgewiesen. ich frage mich a) warum b) von wem und c) warum sehe ich das nirgends in logs etc. Alle Firewalls auf der Strecke sind dekativiert.
Könnt ihr mir einen Hinweis geben wo ich ran muss? Wie sieht der generelle Weg aus? Ist das was ich versuche überhaupt möglich? ChatGPT , Youtube und goolge brachten mir die letzten stunden leider keinen weiteren Erfolg in der Fragestellung.
ich befasse mich gerade mit dem setup von Bind9 in Zusammenhang mit AdGuard. Aktuell nutze ich Unbound auf der OPNSense. Dort habe ich DNSSEC support enabled und ebenfalls DoT mittels AdGuard eingerichtet. Unbound möchte ich nun durch bind9 ersetzen.
Aktuell habe ich folgendes funktionierend audbauen können:
Strecke: Client -> BIND9 -> AdGuard mit standard dns port 53. Alle requests kann ich in AdGuard als plain DNS sehen, also gehe ich davon aus die Kette wie gewünscht funktioniert.
Zusätzlich ist eine zone mit einer internen domain erzeugt.
Strecke: Client -> BIND9 -> interner Server
Anbei meine config:
#named.conf
//...
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
include "/etc/bind/named.conf.dhub-zone";
acl trusted_networks {
192.168.100.0/24;
192.168.30.0/24;
};Die default zone ist unverändert
Datei: named.conf.options
//...
allow-query { trusted_networks; };
forwarders {
192.168.100.10 port 10853;
};
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
forward only;
dnssec-validation yes;
listen-on-v6 { none; };Restliche infos zu der privaten Zone spare ich mir an dieser Stelle, da ich denke, dass die infos nicht weiter relevant sind. Interne Auflösungen mittels nslookup funtkionieren weiterhin.
Was nicht funktioniert:
nslookup zdf.de 192.168.100.11
Server: 192.168.100.11
Address: 192.168.100.11#53
** server can't find zdf.de: SERVFAIL sudo systemctl status bind9 zeigt dann
connection refused resolving 'zfd.de/A/IN': 192.168.100.10#10853 Die Meldung sagt mir, dass versucht wird zdf.de auf dem AdGuard mit Port 10853 aufzulösen, aus meiner Sicht richtig, da hier ja dann die resolver aufgelisted sind. Dennoch wird die connection abgewiesen. ich frage mich a) warum b) von wem und c) warum sehe ich das nirgends in logs etc. Alle Firewalls auf der Strecke sind dekativiert.
Könnt ihr mir einen Hinweis geben wo ich ran muss? Wie sieht der generelle Weg aus? Ist das was ich versuche überhaupt möglich? ChatGPT , Youtube und goolge brachten mir die letzten stunden leider keinen weiteren Erfolg in der Fragestellung.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 7138996542
Url: https://administrator.de/contentid/7138996542
Printed on: April 28, 2024 at 18:04 o'clock
11 Comments
Latest comment
Hallo,
von wo holt sich AdGuard denn die DNS Einträge?
Müsste es nicht eher so sein:
Client -> AdGuard -> Bind -> RootServer oder sowas wie Quad9
Ich hab so etwas, einfach mit Pihole. Aber ebenfalls mit eigenen Zonen in Bind.
von wo holt sich AdGuard denn die DNS Einträge?
Müsste es nicht eher so sein:
Client -> AdGuard -> Bind -> RootServer oder sowas wie Quad9
Ich hab so etwas, einfach mit Pihole. Aber ebenfalls mit eigenen Zonen in Bind.
Naja, bind ist im Grunde nur forwarder für externe. Ich nutze bind zu erst in der Kette da bind bei mir dann interne Namen auflöst ohne das die an adguard gehen. In adguard sind dann die upstreans eingetragen.
Ich hab dir config mal mit unbound probiert. Gibt am Ende den gleichen Fehler. Denke fast, dass es an ad adguard liegt und nicht an bind oder unbound.
Gucke mir später mal das setup auf der Sense an vielleicht sehe ich da den entscheidenden Unterschied.
Ich hab dir config mal mit unbound probiert. Gibt am Ende den gleichen Fehler. Denke fast, dass es an ad adguard liegt und nicht an bind oder unbound.
Gucke mir später mal das setup auf der Sense an vielleicht sehe ich da den entscheidenden Unterschied.
Vielleicht solltest du zuerst einmal klären warum dein AdGuard die bei ihm eingehende DNS Connection auf Port 10853 vom Unbound aktiv abweist! Nur daran scheitert es ja. Der Unbound versucht ja irgendwas was der AdGuard nicht mag und die Verbindung dann aktiv abweist.
Vermutlich kann der kein DNSSEC?! Vielleicht testet du es erst einmal mit "dnssec-validation no;" um ggf. solche Fehler auszuschliessen.
Ein Wireshark oder tcpdump Trace des (abgewiesenen) Verbindungsaufbaus schafft ebenso Klarheit! Immer strategisch vorgehen beim Troubleshooting!
Vermutlich kann der kein DNSSEC?! Vielleicht testet du es erst einmal mit "dnssec-validation no;" um ggf. solche Fehler auszuschliessen.
Ein Wireshark oder tcpdump Trace des (abgewiesenen) Verbindungsaufbaus schafft ebenso Klarheit! Immer strategisch vorgehen beim Troubleshooting!
Grundsätzlich richtig. Was ich nur nicht verstehe; ich hab dieselbe AdGuard config mit einen unbound auf OPNsense ja am Laufen. Daher kann ich eigentlich ausschließen dass der AdGuard ein Problem hat. Das was anders ist, ist eben der Host von bind oder eben eine neue unbound Installation. Ich gehe davon aus dass hier der Fehler zu finden ist. Normal DNS auf custom Port 1053 geht auch ohne Probleme.
Zwei Tests könnte man noch machen:
1.
Bei bind einen anderen Forwarder eintragen z.B. 9.9.9.9 und schauen ob Bind grundsätzlich wie erwartet funktioniert.
2.
Mit dig oder nslookup direkt einen Anfrage an adguard machen und schauen ob und wie er antwortet. Adguard hat ja sicher auch Logs, die wären hilfreich.
Abgesehen von deinem beschriebenen Problem, möchte ich aber nochmals darauf hinweisen, warum ich die Strecke Client->Pihole->Bind vor der Variante Client->Bind->Pihole bevorzuge.
Bind kann rekursive Abfragen machen. Das sind dann letztendlich direkte Anfragen an die DNS Root Server. Damit ist man nicht auf (ev. gefilterte) DNS Server seines Providers oder anderer obskurer Anbieter wie Google 8.8.8.8 oder Cloudflare 1.1.1.1 als Upstreamserver angewiesen. Ich persönlich bevorzuge das.
Pihole und Adguard können, so viel ich weiss, keine rekursiven Anfragen.
Zusätzlich habe ich mit Bind nicht nur Zonen für eine interne Domain, sondern er ist auch Nameserver für öffentliche Domains. Je ein Primary und Secondary Bind Server natürlich.
1.
Bei bind einen anderen Forwarder eintragen z.B. 9.9.9.9 und schauen ob Bind grundsätzlich wie erwartet funktioniert.
2.
Mit dig oder nslookup direkt einen Anfrage an adguard machen und schauen ob und wie er antwortet. Adguard hat ja sicher auch Logs, die wären hilfreich.
Abgesehen von deinem beschriebenen Problem, möchte ich aber nochmals darauf hinweisen, warum ich die Strecke Client->Pihole->Bind vor der Variante Client->Bind->Pihole bevorzuge.
Bind kann rekursive Abfragen machen. Das sind dann letztendlich direkte Anfragen an die DNS Root Server. Damit ist man nicht auf (ev. gefilterte) DNS Server seines Providers oder anderer obskurer Anbieter wie Google 8.8.8.8 oder Cloudflare 1.1.1.1 als Upstreamserver angewiesen. Ich persönlich bevorzuge das.
Pihole und Adguard können, so viel ich weiss, keine rekursiven Anfragen.
Zusätzlich habe ich mit Bind nicht nur Zonen für eine interne Domain, sondern er ist auch Nameserver für öffentliche Domains. Je ein Primary und Secondary Bind Server natürlich.
Daher kann ich eigentlich ausschließen dass der AdGuard ein Problem hat. Das was anders ist,
Fakt ist ja aber nun mal das der Adguard aktiv diese eingehende Session abweist. Mit anderen Worten der DNS Prozess versteht etwas nicht am Protokoll.Es timed also nicht nur stumm aus sondern wird aktiv abgewiesen. Ein sicheres Indiz das der ansprechende Unbound mit irgendwas ankommt was der Adguard DNS nicht mag.
WAS das ist sagt dir Wireshark oder tcpdump.
Normal DNS auf custom Port 1053 geht auch ohne Probleme.
1053 ist ein reservierter IANA Port und Tabu!!!https://www.iana.org/assignments/service-names-port-numbers/service-name ...
Du solltest es als kundiger Netzwerk Admin tunlichst lassen solche weltweit fest reservierten Ports für andere, nicht Standard konforme Dinge zu missbrauchen!
Wenn, dann nimmt man immer die freien und dafür vorgesehen Ephemeral Ports zwischen 49152 und 65535. Sprich also sowas wie 50053 z.B. 🧐
Zum Rest hat der Kollege @HansFenner oben schon alles gesagt!
ok, danke erstmal für euren support. Ich sagte ja ich probiere und spiele 
ich habe mich nun für einen leicht veränderten weg entschieden.
Meine chain: Client -> AdGuard -> Bind9 -> www
Dazu habe ich zwei spezifische Fragen:
Danke euch und nicht meinen Kopf abreißen :D
ich habe mich nun für einen leicht veränderten weg entschieden.Meine chain: Client -> AdGuard -> Bind9 -> www
Dazu habe ich zwei spezifische Fragen:
- Ich verstehe das Konzept von DoT oder DoH denke ich noch nicht komplett. Ich habe in meiner Kette 2 Server (AdGuard und Bind), muss ich beiden beibringen z.b über Port 853 für DoT nutzbar zu sein. Mache ich dies nicht habe ich z.B.: in meinem Netzwerk normalen DNS traffic auf Port 53 und würde erst später einen DoT fähigen Upstream angeben. Ist das so korrekt?
- Wenn ich ich bind9 die forward section auskommentiert lasse geht es direkt an die roor server die unter (in meinem fall) /usr/share/dns/root.hints hinterlegt sind. Trage ich eigene upstreams in der forwwarder section ein z.b.: 9.9.9.9 oder andere werden diese genutzt. Hier könnte ich z.B.: auch (wie jetzt auch) DoT Einträge setzen. Soweit korrekt?
Danke euch und nicht meinen Kopf abreißen :D
1.)
Nein, weil es sinnfrei ist intern mit DoT oder DoH zu arbeiten. Das ist ja alles unter deiner Hoheit und hier musst du nicht verschlüsseln. Es reicht also die klassische simple DNS Port 53 Kommunikation mit UDP und/oder TCP. Folglich lautet die Antwort: Nein, du musst ihnen Port 853 intern nicht beibringen. Die Clients kommen ja ebenso immer unverschlüsselt dort an.
Lediglich das was nach extern geht also Bind9 -> www kannst (musst es aber nicht!) du mit DoT oder DoH verschlüsseln wenn du entsprechende DNS Server nutzt die das auch verstehen am anderen Ende!
2.)
Mit anderen Worten: Es ist korrekt wenn du diese dort vorgibst und nicht die Root Server nutzt.
Generell fragt sich warum du den "Durchlauferhitzer" bind9 überhaupt noch dazwischenhast? Lokale DNS Namen kannst du ja auch dem Adguard beibringen und den lässt du dann direkt auf die DoT oder DoH Server. Erspart dir einen unnötigen DNS Umweg...
Nein, weil es sinnfrei ist intern mit DoT oder DoH zu arbeiten. Das ist ja alles unter deiner Hoheit und hier musst du nicht verschlüsseln. Es reicht also die klassische simple DNS Port 53 Kommunikation mit UDP und/oder TCP. Folglich lautet die Antwort: Nein, du musst ihnen Port 853 intern nicht beibringen. Die Clients kommen ja ebenso immer unverschlüsselt dort an.
Lediglich das was nach extern geht also Bind9 -> www kannst (musst es aber nicht!) du mit DoT oder DoH verschlüsseln wenn du entsprechende DNS Server nutzt die das auch verstehen am anderen Ende!
2.)
forward section auskommentiert lasse geht es direkt an die roor server
Ist natürlich wenig sinnvoll was die Laufzeiten angeht. Besser ist hier immer die DNS Server deines Providers zu nutzen oder zumindestens lokale in der EU. https://www.privacy-handbuch.de/handbuch_93d.htmMit anderen Worten: Es ist korrekt wenn du diese dort vorgibst und nicht die Root Server nutzt.
Generell fragt sich warum du den "Durchlauferhitzer" bind9 überhaupt noch dazwischenhast? Lokale DNS Namen kannst du ja auch dem Adguard beibringen und den lässt du dann direkt auf die DoT oder DoH Server. Erspart dir einen unnötigen DNS Umweg...
@aqui
Also da muss ich doch etwas widersprechen ;)
(Kommt letztendlich natürlich auch immer drauf an, was man eigentlich für ein Endziel hat und das ist ja bei jedem recht individuell.)
zu 1)
Ich nutze weder DoT noch DoH, aber wenn es irgendeinen Sinn machen soll, dann ja wohl nur wenn es der Client (Browser) nutzt. Für mich sehe ich den Sinn nur, die DNS Abfragen zum Schutz der Privatsphäre zu verschlüsseln, sinngemäss zu https. Damit man halt innerhalb des eigenen Netzwerkes nicht mehr mit Wireshark sniffen kann.
Jetzt gibt es eigentlich nur 2 Möglichkeiten:
a) Der Benutzer gibt in seinem Client einen entsprechenden DNS Server ein, dem er dann auch vertrauen muss (also für mich dann bitte kein EU, kein Google und kein Cloudflare Server)
b) Ein Admin setzt in seinem Netz einen DoH/DoT fähiges System ein, dass dann praktisch als Man-in-the-middle funktioniert. D.h. der Benutzer muss dem Admin vertrauen, weil der ja doch wieder alles mitloggen kann. Die Frage ist jetzt eher: Wo sendet man seine DNS Anfragen hin, wenn man auch seinem ISP und eben Google etc. nicht vertraut? Root Server können kein m.W. kein DoT/DoH.
zu 2)
Also dass Anfragen zu Root Servern langsamer sind, stimmt schon. In der Praxis merkt man davon allerdings nichts. Die Antworten werden danach ja mehrfach gecached und zwar im Browser, im Betriebssystem und auch noch beim eingesetzten DNS Server.
Ich bevorzuge Rootserver wirklich aus dem Grunde, dass ich keine Lust habe, mir von irgendwelchen EU-Bürokraten-Gutmenschen gefälschte, umgeleitete oder sonst wie geänderte Resultate vorgaukelt zu lassen. Angefangen hat es mit illegalen Glückspielseiten, zu Streaming-Seiten mit Kinofilmen oder sicher bald auch zu Seiten mit nackigen Weibern. (Letzteres würde ich natürlich nie anschauen, es geht nur ums Prinzip).
Ich möchte aber auch keinen Gratis-DNS Server vom ISP und den anderen üblichen Verdächtigen nutzen, nur damit diese alles loggen, verwerten und viel Kohle machen können. Denn sonst wäre es ja nicht kostenlos.
Aber eben, jeder hat da so seine eigenen Bedürfnisse
Also da muss ich doch etwas widersprechen ;)
(Kommt letztendlich natürlich auch immer drauf an, was man eigentlich für ein Endziel hat und das ist ja bei jedem recht individuell.)
zu 1)
Ich nutze weder DoT noch DoH, aber wenn es irgendeinen Sinn machen soll, dann ja wohl nur wenn es der Client (Browser) nutzt. Für mich sehe ich den Sinn nur, die DNS Abfragen zum Schutz der Privatsphäre zu verschlüsseln, sinngemäss zu https. Damit man halt innerhalb des eigenen Netzwerkes nicht mehr mit Wireshark sniffen kann.
Jetzt gibt es eigentlich nur 2 Möglichkeiten:
a) Der Benutzer gibt in seinem Client einen entsprechenden DNS Server ein, dem er dann auch vertrauen muss (also für mich dann bitte kein EU, kein Google und kein Cloudflare Server)
b) Ein Admin setzt in seinem Netz einen DoH/DoT fähiges System ein, dass dann praktisch als Man-in-the-middle funktioniert. D.h. der Benutzer muss dem Admin vertrauen, weil der ja doch wieder alles mitloggen kann. Die Frage ist jetzt eher: Wo sendet man seine DNS Anfragen hin, wenn man auch seinem ISP und eben Google etc. nicht vertraut? Root Server können kein m.W. kein DoT/DoH.
zu 2)
Also dass Anfragen zu Root Servern langsamer sind, stimmt schon. In der Praxis merkt man davon allerdings nichts. Die Antworten werden danach ja mehrfach gecached und zwar im Browser, im Betriebssystem und auch noch beim eingesetzten DNS Server.
Ich bevorzuge Rootserver wirklich aus dem Grunde, dass ich keine Lust habe, mir von irgendwelchen EU-Bürokraten-Gutmenschen gefälschte, umgeleitete oder sonst wie geänderte Resultate vorgaukelt zu lassen. Angefangen hat es mit illegalen Glückspielseiten, zu Streaming-Seiten mit Kinofilmen oder sicher bald auch zu Seiten mit nackigen Weibern. (Letzteres würde ich natürlich nie anschauen, es geht nur ums Prinzip).
Ich möchte aber auch keinen Gratis-DNS Server vom ISP und den anderen üblichen Verdächtigen nutzen, nur damit diese alles loggen, verwerten und viel Kohle machen können. Denn sonst wäre es ja nicht kostenlos.
Aber eben, jeder hat da so seine eigenen Bedürfnisse
wenn es irgendeinen Sinn machen soll, dann ja wohl nur wenn es der Client (Browser) nutzt.
Nein, nicht zwingend. In der Regel verwendet jeder zu 99,99% einen Caching DNS Server wie z.B. den heimischen Router oder Firewall. Hier spricht der Client diesen lokal an ohne Verschlüsselung was ja intern im eigenen, geschützten Netz auch üblich ist.Der Caching DNS kann dann (muss aber nicht) mit DoT oder DoH verschlüsseln weil er ja über ein öffentliches Netz geht um diese Anfragen, zumindestens auf dem Transport, unsichtbar zu machen.
Es macht also auch so durchaus Sinn.
Aber wie du schon richtig sagst es kommt IMMER aufs Design an und welche Security Anforderungen und Bedürfnisse man sich setzt!
Damit man halt innerhalb des eigenen Netzwerkes nicht mehr mit Wireshark sniffen kann.
Gut, aber wer macht das im eigenen Netz und auch wenn... Im eigenen Netz "kennt" man ja auch so oder so immer seine eigenen Abfragen. Ob man das nun sniffert oder nicht ist damit ja irrelevant denn du weisst ja wenn du Seiten mit "dänischen Western" besuchst. Anders sieht es natürlich mit Trackern, Zählpixel und dem anderen Schnüffelzeugs aus was dir über fast alle Webseiten untergejubelt wird. Da hilft der Wireshark eher zur Horizonterweitertung bzw. PiHole oder AgGuard schieben dem ein Riegel vor.Wichtig ist nur wenn solche DNS Abfragen über öffentliche Netze gehen wie das Internet wo die ganze Welt nicht nur mitsniffern kann, sondern es bekanntlich ja auch dediziert macht das man die Option der Verschlüsselung mit DoH oder DoT hat.
Wie dann DNS Server Betreiber nach dem Entschlüsseln mit diesen Daten umgehen ist dann, wie du schon sagtst, wieder eine ganz andere Frage! Was Google damit macht ist ja leider allgemein bekannt.
Mit deinen genannten 2 Möglichkeiten a. und b. hast du absolut Recht. Das sind ja auch die bekannten und üblichen Lösungen wenn man einmal von den hardgecodeten DoH Servern in manchen Web Browsern absieht die das dann out of the Box zumindestens für HTTP Traffic machen. Dann natürlich wieder zu DNS Servern die die Browser Entwickler vorbestimmen oder man sie customizen muss sofern das das Browser Setup überhaupt zulässt. Beim gruseligen Edge Browser kann man ja leider sehen wie weit sowas getrieben wird.
Letzteres würde ich natürlich nie anschauen
Gibt ja auch solche mit nackigen Kerlen! 🤣Du hast aber absolut Recht was das Thema vertrauenswürdige und zensurfreie DNS anbetrifft und musst gar nicht widersprechen denn wir liegen mit der Meinung gar nicht auseinander. 😉
Zurück zum Thema und Thread des TOs...
Wenn's das denn war bitte nicht vergessen deinen Thread als erledigt zu schliessen!
