UNBOUND - Eigener Rekursiver & Sicherer DNS Server
-
@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
