DNS-Resolver und Forwarding richtig verstehen

Logic

Moin moin,

da ich ein Problem mit der DNS-Auflösung habe, bräuchte ich hier bitte einmal einen schlauen Tipp! Problem gestaltet sich wie folgt:

Meine Firewall übernimmt für mein LAN auch die DNS-Auflösung. Hierzu habe ich z.B. die öffentlichen DNS-Server von Google in der Firewall hinterlegt. Wenn ich nun jedoch avm.de aufrufen möchte, dann sagt mir mein Browser, dass er die Domain nicht kennt. Die DNS-Auflösung schlägt fehl.

Prüfe ich per dig unter Linux die Domain, dann sollte Google sie hingegen kennen:

logic@box ~ % dig @8.8.8.8 avm.de    

; <<>> DiG 9.13.3 <<>> @8.8.8.8 avm.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8187
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;avm.de.				IN	A

;; ANSWER SECTION:
avm.de.			2670	IN	A	212.42.244.122

;; Query time: 17 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Nov 03 13:34:16 CET 2018
;; MSG SIZE  rcvd: 51

Frage ich hingegen meine Firewall samt DNS-Resolver erhalte ich ein Timeout. Frage ich hingegen heise.de oder google.com an, dann erhalte ich über den lokalen DNS-Resolver sehr wohl eine Antwort. Dies verdeutlicht mein Problem, dass ich offenbar nicht bei allen Anfragen Probleme habe.

Ich habe mir die Einstellungen im DNS-Resolver nun einmal angesehen und gemerkt, dass die Option "Enable Forwarding Mode" nicht aktiv ist. Sobald ich diese aktiviere habe ich bei den DNS-Anfragen keine Probleme mehr. Deaktiviere ich das Forwarding wieder, habe ich die bestehenden Probleme.

Nun könnte ich einfach Forwarding an lassen und mich damit zufrieden geben. Gelesen habe ich jedoch, dass Forwarding oft negativ mit der Privatsphäre in Verbindung gebracht wird und man daher, wenn man auf Privatsphäre darauf Wert legt, kein Forwarding nutzen sollte.

An dieser Stelle eröffnet sich mir eine Verständnisfrage: Wenn ich das Forwarding nicht aktiviere, woher holt sich der Resolver dann seine Informationen? Vom SOA direkt? Gerne möchte ich mein System "so privat" wie möglich konfigurieren, weswegen ich gerne die Arbeitsweise verstehen und somit besser beurteilen können möchte.

Vielleicht gibt es hier einen klugen Kopf, der helfen kann :)

pfadmin

Hi,
wenn du die Server von Google eingetragen hast, machst du ein forwarding, kein resolving. Ein Resolver löst selber auf, dazu befragt er die authoritativen DNS Server ab. Erst die Root Server aus seiner hinterlegten root.hints datei nach .de, dann die denic nach avm, dann www beim DNS von AVM. Sobald du etwas zu google schickst, löst google das für dich auf und gibt nur die Antwort, wo www.avm.de ist. (avm.de ist was anderes!)

Löst du selber auf, kann niemand das DNS verbiegen oder sperren. Löst google für dich auf, könnten sie sich entscheiden alle Seiten mit Nippeln nicht aufzulösen, und dafür lieber auf ein paar Waffenverkäufer aufzulösen.

Stellst du den Resolver ein, wird unbound genutzt, stellst du den Forwarder ein wird dnsmasq genutzt. Stellst du unter Resolver "Enable Forwarding Mode" ein, wird unbound im Forwarding Modus benutzt.

Schalte mal dnssec ab, ob es daran liegt.

Gruß
pfadmin

JeGr

@logic said in DNS-Resolver und Forwarding richtig verstehen:

Meine Firewall übernimmt für mein LAN auch die DNS-Auflösung. Hierzu habe ich z.B. die öffentlichen DNS-Server von Google in der Firewall hinterlegt. Wenn ich nun jedoch avm.de aufrufen möchte, dann sagt mir mein Browser, dass er die Domain nicht kennt. Die DNS-Auflösung schlägt fehl.

Ein paar Fakten, die man ebenfalls im Hinterkopf halten muss:

wie schon @pfadmin richtig sagt: ein Resolver löst selbständig auf wie jeder DNS Server im Netz. Jede Domain via SOA über die DNS ROOTs.
Einige DNS Server, Provider, ISPs o.ä. haben aber durchaus IP Blocks drin, so dass der Resolver bei der Abfrage scheitert, wenn du bspw. von einer dynamischen T-Online IP aus versuchst, die Domain aufzulösen. Da viele Angriffe, (D)DOS Angriffe auf DNS (kleine UDP Pakete) etc. gern aus solchen größeren dynamischen Netzbereichen von Bots kommen - und da sind schlampig gepflegte Client PCs leider gern genutzt - stehen diese Netzbereiche gerne mal auf Blocklisten (auch bei SMTP)
Bei Multi-WAN Setups kann es ebenfalls schwierig sein, den Resolver zu nutzen, da die Abfragen wechselnd von verschiedenen Interfaces kommen können wobei eines wieder das obige Problem hat etc. Daher wird in Multi-WAN Setups abgeraten, den Resolver zu nutzen, sondern auf die Forwarding Funktion hingewiesen.

Allerdings wird aktuell vom Kollegen Donnerhacke (hallo Lutz!) u.a. in der c't und Co korrekt darauf hingewiesen, dass Geschichten wie DNS over TLS und der Crypto Hype prinzipiell was gutes darstellen (mehr https schadet nie!) aber gerade beim DNS am Ziel vorbeigehen. Klar ist es nett, den DNS Call per se zu verschlüsseln, damit ihn keiner (auch nicht der Provider) mitlesen kann. Schützen tut dies aber nur BIS zum DNS Server, denn der muss den Request schließlich beantworten. Damit steht man dann so oder so wieder vor dem gleiche Trust-Problem wie vorher: glaube ich Google, Quad-Nine oder eher Cloudflare (oder dem ISP DNS oder sonstwem), dass sie ihren Server ordentlich konfiguriert haben und kein Schindluder treiben, wie eben:

NXDomain Errors umschreiben und auf Dummy Seiten redirecten -> Hallo Telekom!
In Diverse Kategorien vorfiltern -> Ahoi Quad-Nine
Statistiken zu den Abfragen erheben -> Google, Nine & many others
DNS poisoning betreiben?

Im Prinzip sind die Bestrebungen wie DoT natürlich ne schöne Sache. Nur sehen viele bei der Nutzung den Sinn vor lauter Crypto nicht. Es mag schön sein, seine abgehenden DNS Calls zu encrypten, damit der eigene ISP nicht sieht, dass man in der Pause auf Prnhb surft - quatsch ist es trotzdem, denn nach dem DNS ruft ihr die Seite per HTTPS auf. Und spätestens wenn die IP dann geroutet wird, ist es eh klar, was (zumindest grob) aufgerufen wird (ja, außer man routet alles via einem VPN und verzichtet dann ggf. auf Bandbreite, Latenz etc.).

Die Frage stellt sich ganz einfach, welches Sicherheits- (Schutz!) oder welches Privatsphäre-Bedürfnis man hat oder braucht. Damit ergeben sich dann die Empfehlungen der ganzen anderen Punkte :)

Gruß Jens

Logic

Moin moin,

leider hat es mit der Antwort etwas gedauert, kam leider nicht vorher dazu.

Aber gut, dann habe ich den Resolver ohne Forwarding richtig verstanden und eigentlich ist es auch genau das, was ich möchte. Ich möchte unverfälschte DNS-Antworten vom Root-DNS/SOA ohne Zentralisierung auf einen Dienst bzw. DNS-Anbieter.

Die derzeit eingetragenen DNS-Server greifen halt nur wenn ich Forwarding an mache, was ich nun erst einmal nicht tun möchte.

Bleibt für mich jedoch die Frage wieso ich www.avm.de (ignorieren wir mal ohne www) nicht aufgelöst bekomme. Hin und wieder treffe ich halt auch andere deutsche Domains - interessanterweise gefühlt immer nur DE-Domains.

Wenn ich nun per dig einen Google DNS anfrage, dann erhalte ich für www.avm.de die IP-Adresse 212.42.244.122
Schaue ich nun in die Statistik meines DNS Resolvers, dann finde ich dort diese beiden IP-Adressen: 212.42.244.66 und 212.42.244.67 für avm.de (vermutlich die NS von AVM)
Die SOA von avm.de ist die ns1.avm.de und dies besitzt 212.42.244.66, ns2.avm.de hat die 67 (okay, Vermutung bestätigt)
Wenn ich einen der NS für www.avm.de direkt "andigge", dann bekomme ich die gleiche Antwort wie von Google
Rufe ich einmal www.avm.de über die pfsense Funktionalität "Diagnostics/DNS Lookup" auf, dann sehe ich den korrekten Record. Hier werden nun jedoch auch die externen DNS angefragt, ich kann daher nicht sehen woher die Antwort kommt
Digge ich direkt von meinem PC, ohne Angabe eines DNS, mit "dig www.avm.de" dann erhalte ich eine leere Antwort

DNSSEC habe ich einmal deaktiviert. Dies hat keine Änderungen bewirkt.

Da ich von meinem PC und meiner Leitung direkt mit dem DNS von AVM sprechen kann vermute ich keine Blockade oder ähnliches. Dennoch würde ich gerne dieses Problem lösten, da Forwarding für mich eigentlich keine Option ist. Hier würde ich dann doch gerne meine Privatsphäre schützen.