UNBOUND - Eigener Rekursiver & Sicherer DNS Server
-
Ich verwende eigentlich immer 3600 und damit finde ich habe ich einen sehr guten Mittelwert.
Darunter bringt es nicht mehr wirklich viel. Darüber finde ich es teilweise zu lang.
Ich habe eigentlich auf meinen Recursern recht gute Query und Packet Hits.
Auch die Query Latenz ist echt super. Ich verwende dazu PowerDNS. -
@thiasaef said in UNBOUND - Eigener Rekursiver & Sicherer DNS Server:
Die ist hauptsächlich so kurz, weil es Geld bringt und weil es bequem ist. 30 Sekunden sind einfach nur Käse.
Quark. Wenn man kritische Setups hat, die bspw. via DNS VPN Tunnel o.ä. aufbauen müssen und man hat vor Ort eben leider weil wir in solch einem tollen Internet-Entwicklungsland leben nur Dorf-DSL mit dynamic IP, dann ist TTL Shorting das einzige was du sinnvoll machen kannst. Und wenn dir übern Tag mal wieder das Netz wegfliegt und du dann im dümmsten Fall ne Stunde warten darfst, bis sich ein Tunnel gegen eine dynamische IP wieder aufbaut, weil man TTL von 3600 ausgerollt hat, ist man nur noch am Kopf gegen den Tisch hauen :)
Irgendwelche Expired Entries sollte man nicht ausliefern. Zudem man damit auch DNSSEC kaputt machen kann bei einem key rollover o.ä. Das ist einfach Käse.
Zudem ist im breiten Einsatz der DNS Aufruf, selbst wenn er ein paar ms länger dauert, kaum spürbar. Es gibt einen schönen Erfahrungsbericht von jemand, der sich ein "DoHoT" Setup gebaut hat: DNS over HTTPS over TOR. Klingt komisch, ist aber sogar relativ gut. Auch wenn ich DoH kein Stück mag (im normalen Einsatz bei Clients), war der Ansatz, den zentralen DNS im Netz via DoH und TOR nach draußen zu verschleiern, immens viel intelligernter als diese ganzen Full-VPN Ansätze, die ich immer wieder lese. Aber warum das Konzept in dem Fall interessant ist, ist etwas anderes: Es stellt sich nämlich heraus, dass DoH natürlich - weil TCP - natürlich langsamer als normales DNS ist und via TOR dann natürlich nochmal etwas gebremst wird. Nur hat das nur in sehr wenigen Szenarien überhaupt eine Rolle gespielt, denn die paar ms, die das insgesamt ausmacht, fielen in der Praxis weder beim Surfen noch bei anderen Anwendungen großartig ins Gewicht. Klar, direkt zu Beginn ist man sehr drauf geeicht, das sofort wahr zu nehmen, später war es aber kaum noch ein Thema.
Langer Rede kurzer Sinn: SO großartig wird der Unterschied zwischen Forwarding und Resolving IMHO gar nicht ausfallen, als dass man dafür großartig irgendwelche Settings (außer nem größeren Cache) einstellen müsste. DNS Resolving anmachen, das Ganze auch in System / General richtig konfigurieren (also ohne Forwarder oder eben mit und die Option dann auf primär Resolver nutzen einstellen) und die Sense dann einfach den Clients präsentieren :)
Kurze Interna: Ich nutze das tatsächlich ähnlich wie der OP anfänglich.
Ich habe 2 PiHoles (Container in Proxmox), die sich synchronisieren (der 2. PiHole holt sich die Daten vom 1., so dass man nur einen pflegen muss mit Deny Listen und Ausnahmen etc.)
Da die PiHoles ja den DNSmasq nutzen (forwarder), habe ich bei diesem eingetragen, dass er interne DNS Domains ggf. an die entsprechenden Server weiterreicht, die die Domain kennen (bspw. work Kram via VPN an den FirmenDNS etc.) Alles andere für das keine Overrides existieren, wird an die pfSense geschickt, die das dann via Resolver direkt im Netz auflöst. Somit keine Konzentration von DNS Abfragen an einer Stelle im Netz (wie Google, Cloudflare, oder sonst wer). Möchte aber in Zukunft mal das DoHoT Konzept ausprobieren, die externen DNS queries via HTTPS und TOR zu tunneln. Eventuell lässt sich das dann direkt in den PiHoles als Variante 1 und die Sense mit Resolver als Variante 2 eintragen, dass - sollte der DoHoT Weg kaputt sein - der normale Resolver Weg gegangen wird. :) -
@jegr said in UNBOUND - Eigener Rekursiver & Sicherer DNS Server:
Wenn man kritische Setups hat, die bspw. via DNS VPN Tunnel o.ä. aufbauen müssen
Dann ist man in meinen Augen selber schuld, wenn man sich mit
Serve Expiredin den Fuß schießt.Quark.
Pauschal ist es quark, aber ganz allein bin ich mit meiner Meinung wohl trotzdem nicht, siehe: https://forum.netgate.com/post/942471
DNS over HTTPS over TOR. Klingt komisch, ist aber sogar relativ gut.
Interessante Idee, ist auf jeden Fall einen Versuch wert.
-
aber mal ein anderes Thema, warum liefert mir Unbound ganz unabhängig von
Serve Expired'schlechtere' Ergebnisse als der Telekom DNS?drill youtube.com @pfsense.home.arpa ping 172.217.23.78 ~ 22.51 ms ... drill youtube.com @speedport.ip ping 216.58.212.142 ~ 17.33 ms -
@thiasaef Verstehe deinen "Code" Block nicht. Du vergleichst pings und fragst nach DNS?
-
Ich gehe von aus das @thiasaef darauf hinweisen wollte, das er über unterschiedliche DNS-Server unterschiedliche IP-Adressen aufgelöst bekommt und die IP-Adresse über den Telekom-DNS bei dem Ping da in dem Moment geringfügig niedrigere Latenz zeigte.
-
exakt - nur, dass der Unterschied in meinen Augen nicht geringfügig ist und ich mich außerdem frage, welche Auswirkungen das Ganze auf das Peering hat.
Unbound liefert sowohl bei flickr.com als auch bei youtube.com durch die Bank signifikant weiter entfernte Server zurück. In der Regel 5-7 Hops mehr mit entsprechend längeren Antwortzeiten.
Unbound:
--- 13.225.22.74 ping statistics --- 60 packets transmitted, 60 received, 0% packet loss, time 59105ms rtt min/avg/max/mdev = 26.550/28.606/33.718/1.573 msTelekom DNS:
--- 13.32.18.119 ping statistics --- 60 packets transmitted, 60 received, 0% packet loss, time 59102ms rtt min/avg/max/mdev = 16.336/17.522/20.835/0.836 ms -
welche Auswirkungen das Ganze auf das Peering hat
Der Durchsatz zur vom Unbound Resolver vorgeschlagenen Adresse ist heute komplett im Keller (~ 500 KBit/s).
Der Durchsatz zur vom Telekom DNS vorgeschlagenen Adresse liegt massiv höher (~ 50 MBit/s).
Der Server hinter der von Unbound vorgeschlagenen Adresse ist heute 11 Hops weiter entfernt.
Lösungsvorschläge? Ausnahmeregeln erstellen?
-
Ich nutze auch den Resolver-Mode in pfSense.
Die Auflösung zeigt für mich keine Besonderheiten.
W:\Temp>nslookup youtube.com
Server: pfSense.localnet
Address: 192.168.1.1Nicht autorisierende Antwort:
Name: youtube.com
Addresses: 2a00:1450:4001:80e::200e
142.250.185.78W:\Temp>tracert youtube.com
Routenverfolgung zu youtube.com [142.250.185.78]
über maximal 30 Hops:1 <1 ms <1 ms <1 ms pfSense.localnet [192.168.1.1]
2 4 ms 4 ms 4 ms p3e9bf44a.dip0.t-ipconnect.de [62.155.244.74]
3 10 ms 11 ms 10 ms 217.5.118.30
4 10 ms 10 ms 10 ms 62.157.250.46
5 10 ms 10 ms 10 ms 108.170.231.245
6 10 ms 10 ms 10 ms 142.250.62.151
7 10 ms 10 ms 10 ms fra16s48-in-f14.1e100.net [142.250.185.78]Ablaufverfolgung beendet.
W:\Temp>nslookup flickr.com
Server: pfSense.localnet
Address: 192.168.1.1Nicht autorisierende Antwort:
Name: flickr.com
Address: 13.224.101.176W:\Temp>tracert flickr.com
Routenverfolgung zu flickr.com [13.224.101.176]
über maximal 30 Hops:1 <1 ms <1 ms <1 ms pfSense.localnet [192.168.1.1]
2 4 ms 4 ms 4 ms p3e9bf44a.dip0.t-ipconnect.de [62.155.244.74]
3 7 ms 7 ms 7 ms d-ed5-i.D.DE.NET.DTAG.DE [62.154.43.130]
4 10 ms 12 ms 11 ms 80.157.204.58
5 17 ms 15 ms 15 ms ae8.cr1-zur2.ip4.gtt.net [89.149.128.154]
6 15 ms 15 ms 17 ms ip4.gtt.net [46.33.78.98]
7 16 ms 20 ms 18 ms 52.93.42.56
8 15 ms 17 ms 15 ms 52.93.242.37
9 * * * Zeitüberschreitung der Anforderung.
10 * * * Zeitüberschreitung der Anforderung.
11 * * * Zeitüberschreitung der Anforderung.
12 * * * Zeitüberschreitung der Anforderung.
13 * * * Zeitüberschreitung der Anforderung.
14 15 ms 15 ms 15 ms server-13-224-101-176.zrh50.r.cloudfront.net [13.224.101.176]Ablaufverfolgung beendet.
-
also dass das Problem existiert, steht mittlerweile außer Frage (siehe: https://www.onlinekosten.de/forum/showthread.php?t=146426), mir geht es jetzt eigentlich nur noch um eine praktikable Lösung. Bei flickr.com ist das Problem bei mir mit Abstand am stärksten ausgeprägt. Heute Morgen Ping zur Unbound Adresse (33 ms), Ping zur Telekom DNS Adresse (16 ms).
Ich verwende eigentlich immer 3600
...
Darüber finde ich es teilweise zu lang.Wenn via
Serve Expiredein abgelaufener Eintrag wiedergegeben wird, dann wird die "Reply TTL" standardmäßig auf 30 s gesetzt. -
@wkn said in UNBOUND - Eigener Rekursiver & Sicherer DNS Server:
Ich gehe von aus das @thiasaef darauf hinweisen wollte, das er über unterschiedliche DNS-Server unterschiedliche IP-Adressen aufgelöst bekommt und die IP-Adresse über den Telekom-DNS bei dem Ping da in dem Moment geringfügig niedrigere Latenz zeigte.
@thiasaef said in UNBOUND - Eigener Rekursiver & Sicherer DNS Server:
exakt - nur, dass der Unterschied in meinen Augen nicht geringfügig ist und ich mich außerdem frage, welche Auswirkungen das Ganze auf das Peering hat.
Das ist bei Multicast DNS Adressen völlig normal. Da wird eben via DNS oder deiner Origin IP ermittelt, welches Ergebnis dir zurückgegeben wird. Und demzufolge bekommt man dann eben ne andere IP (oder mehrere die RR durchrotieren) zurückgemeldet. Normaler Mechanismus :)
Unbound liefert sowohl bei flickr.com als auch bei youtube.com durch die Bank signifikant weiter entfernte Server zurück. In der Regel 5-7 Hops mehr mit entsprechend längeren Antwortzeiten.
Nicht Unbound liefert das, sondern deine Konfiguration. Unbound nutzt fürs Resolving deine IP bzw. dein WAN. Bei Multicast DNSen könnte es jetzt sein, dass dann eben für deine Source IP "geschätzt" wird, welcher Server dir am nächsten ist. Dann bekommst du eben andere Ergebnisse. Bei anderen größeren Forwardern ist ggf. bekannter wo und wie die angebunden sind, welches Peering etc. und dann gibts eben andere IPs zurück. IPs sprechen eben keine exakte Geolocation, daher kanns da immer Abweichungen geben.
Kann deine Probleme mit Response Zeiten aber nicht nachvollziehen. Mir ist es völlig wurscht WO (Hops) der Server steht, wichtig ist die Zeit zur Antwort und die ist bei meinem Unbound bislang völlig in Ordnung. Was ich beim Dig als "query time" zurück bekomme (und das ich die wichtige Zeit) liegt unter dem, was ich via Forwarding zu 9.9.9.9 oder 8.8.8.8 bekomme und damit ist mir Distanz oder Ping völlig wurscht. :)
Dass der zurückgelieferte Server dann vielleicht weniger optimal ist - man kann multicast DNSe da IMHO nicht beeinflussen.
-
Bei Multicast DNSen könnte es jetzt sein, dass dann eben für deine Source IP "geschätzt" wird, welcher Server dir am nächsten ist.
Auch klar, nur verstehe ich nicht, wie bei der Schätzung dann ein Server in den USA rauskommen kann. Lässt sich irgendwie herausfinden, ob wirklich meine WAN IP als Schätzgrundlage verwendet wird? Double NAT sollte darauf ja eigentlich keinen Einfluss haben, oder?
Mir ist es völlig wurscht WO (Hops) der Server steht
Mir auch, solang es nicht dazu führt, dass ich dann aufgrund der Peering Problematik der Telekom am anderen Ende der Nahrungskette stehe.
wichtig ist die Zeit zur Antwort und die ist bei meinem Unbound bislang völlig in Ordnung.
Bei mir auch, es geht ja um die Antwortzeit des Servers hinter der IP aus der Antwort von Unbound.
-
@thiasaef said in UNBOUND - Eigener Rekursiver & Sicherer DNS Server:
Auch klar, nur verstehe ich nicht, wie bei der Schätzung dann ein Server in den USA rauskommen kann. Lässt sich irgendwie herausfinden, ob wirklich meine WAN IP als Schätzgrundlage verwendet wird? Double NAT sollte darauf ja eigentlich keinen Einfluss haben, oder?
Double NAT sollte an der Stelle gar keine Rolle spielen, da sich der Resolver nicht mit seiner internen Adresse meldet. Müsste man aber ggf. mal recherchieren, was/warum/wieso da welcher Eintrag retourniert wird.
Interessant finde ich, dass ich das bei mir nicht nachvollziehen kann. 4 Tests: Meine Sense mit Resolver, meine PiHoles (die die Sense nutzen), 8.8.8.8 und 9.9.9.9 sowie 1.1.1.1
PiHole #1 / #2: youtube.com has address 142.250.185.110 110.185.250.142.in-addr.arpa domain name pointer fra16s49-in-f14.1e100.net. pfSense Unbound: youtube.com has address 142.250.185.110 110.185.250.142.in-addr.arpa domain name pointer fra16s49-in-f14.1e100.net. Cloudflare 1.1.1.1: youtube.com has address 216.58.207.238 238.207.58.216.in-addr.arpa domain name pointer arn09s19-in-f14.1e100.net. Google DNS: youtube.com has address 142.250.185.142 110.185.250.142.in-addr.arpa domain name pointer fra16s49-in-f14.1e100.net. Quad 9: youtube.com has address 172.217.23.238 238.23.217.172.in-addr.arpa domain name pointer prg03s06-in-f14.1e100.net. alternativ alle paar Requests auch: youtube.com. 157 IN A 172.217.23.206 206.23.217.172.in-addr.arpa domain name pointer prg03s05-in-f14.1e100.net.Mein Resolver bekommt also nicht (immer) die gleiche IP wie einer der großen Forwarder, aber eine grob korrekte Zuteilung für einen Youtube FE Server in FRA. Googles eigener DNS gibt manchmal 185, manchmal 186.142 zurück, bleibt aber konstant bei Frankfurt. Cloudflare schwankt auch mal, gibt aber anscheinend nicht den optimalen YT Service zurück. Quad Nine ebenfalls nicht.
Bei Tests auf verschiedenen Interfaces (also entweder Kabel oder DSL bei mir), sieht man ebenfalls, dass sich sofort die Adresse ändert, aber sonst konstant bleibt:
[2.5.0-RELEASE][root@mirage]/root: dig +short youtube.com @1.1.1.1 -b 192.168.177.9 216.58.207.238 [2.5.0-RELEASE][root@mirage]/root: dig +short youtube.com @1.1.1.1 -b 192.168.177.9 216.58.207.238 [2.5.0-RELEASE][root@mirage]/root: dig +short youtube.com @1.1.1.1 -b 192.168.177.9 216.58.207.238 [2.5.0-RELEASE][root@mirage]/root: dig +short youtube.com @1.1.1.1 -b 192.168.177.9 216.58.207.238 [2.5.0-RELEASE][root@mirage]/root: dig +short youtube.com @1.1.1.1 -b 192.168.177.9 216.58.207.238 [2.5.0-RELEASE][root@mirage]/root: dig +short youtube.com @1.1.1.1 -b 192.168.178.9 216.58.198.206 [2.5.0-RELEASE][root@mirage]/root: dig +short youtube.com @1.1.1.1 -b 192.168.178.9 216.58.198.206 [2.5.0-RELEASE][root@mirage]/root: dig +short youtube.com @1.1.1.1 -b 192.168.178.9 216.58.198.206 [2.5.0-RELEASE][root@mirage]/root: dig +short youtube.com @1.1.1.1 -b 192.168.178.9 216.58.198.206 [2.5.0-RELEASE][root@mirage]/root: dig +short youtube.com @1.1.1.1 -b 192.168.178.9 216.58.198.206Beispiel hier war YT via DSL oder Kabel (unterschiedliche Fritzbox etc.) man sieht also sofort - IP Reply ändert sich - bleibt aber von der Geo Verortung her stabil. Ist in diesem Fall für Cloudflare sogar negativ, denn die Adressen sind arnXYsXY Adressen von Googles e100 network. Also US IPs. Das dürfte dann eher kein so tolles Viewing Erlebnis sein.
Google DNS liefert via DSL 142.250.185.142 und via Kabel 172.217.23.110 zurück. Beides u.a. in FRA verortet, wobei die Kabel IP .110 theoretisch auch Milan sein kann (laut Reverse Info).
Quad9 liefert via DSL schon 3 Adressen, alle 3 prefixed mit prgXYsXY. Ich könnte irren, aber ich mutmaße, dass das Server in Prag sein könnten. Beim Kabel drehen sie vogelwild und geben mir ein Dutzend unterschiedliche Server, jeder Request quasi einen neuen. Hier tauchen dann auch die unterschiedlichsten IPs auf. Mal wird YT in FRA, dann AMS (Amsterdam), PAR(is) oder ganz andere Standorte rückgeliefert. Komischerweise nur bei Kabel, DSL returned die gleichen 3 immer wieder.
Somit scheint das für mich extrem von der public IP abzuhängen, da ich hier das gleiche System testen lies, das lediglich über 2 unterschiedliche Fritzboxen 2 unterschiedliche IP Wege ins Netz nimmt und trotz gleichem Standort je nach IP des Providers durch die Bank komplett andere IPs als Query Answer zurückbekommt wenn man einen Anycast DNS fragt. Daher ist es nicht verwunderlich, dass man für DNS Fragen an einen CDN Service wie bspw. YT ggf. andere Antworten bekommt als man meint, diese aber abhängig sind von der eigenen IP und/oder ob ein Forwarder gefragt wurde. Ob man das verbessern kann? Schwierige Antwort. Überschreiben wäre eine Möglichkeit (mit einem Forward für bspw. youtube.com an Googles DNS bspw.) aber Schuld hat da IMHO der Unbound eher nicht.
Grüße (und Danke für die Experimentvorlage :))
-
Unbound im Resolver-Modus:
dig +short flickr.com @pfsense.home.arpa 13.225.37.234 host 13.225.37.234 234.37.225.13.in-addr.arpa domain name pointer server-13-225-37-234.cdg3.r.cloudfront.net.Telekom DNS:
dig +short flickr.com @speedport.ip 13.224.190.234 host 13.224.190.234 234.190.224.13.in-addr.arpa domain name pointer server-13-224-190-234.fra2.r.cloudfront.net.Google DNS:
dig +short flickr.com @8.8.8.8 13.225.37.234 host 13.225.37.234 234.37.225.13.in-addr.arpa domain name pointer server-13-225-37-234.cdg3.r.cloudfront.net.Cloudflare DNS:
dig +short flickr.com @1.1.1.1 13.249.14.162 host 13.249.14.162 162.14.249.13.in-addr.arpa domain name pointer server-13-249-14-162.cdg53.r.cloudfront.net.Ich versuch mein Glück mal mit folgender Ausnahmeregel:
forward-zone: name: "flickr.com" forward-addr: 192.168.2.1
