Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Software-update: Unbound 1.10.0

Unbound logo (79 pix) Als je een dns-look-up uitvoert, begint een recursor in eerste instantie met het stellen van de look-upvraag aan een dns-rootserver. Deze kan dan doorverwijzen naar andere servers, vanaf waar weer doorverwezen kan worden naar andere servers enzovoort, totdat uiteindelijk een server is bereikt die het antwoord weet of weet dat de look-up niet mogelijk is. Van dit laatste kan sprake zijn als de naam niet bestaat of de servers niet reageren. Het proces van het langslopen van verschillende authoritative servers heet recursie. Unbound is een dns-recursor met ondersteuning voor moderne standaarden, zoals Query Name Minimisation, Aggressive Use of Dnssec-Validated Cache en authority zones. De ontwikkelaars hebben enkele dagen geleden versie 1.10.0 uitgebracht en de changelog voor die uitgave ziert er als volgt uit:

Features
  • Merge RPZ support into master. Only QNAME and Response IP triggers are supported.
  • Added serve-stale functionality as described in draft-ietf-dnsop-serve-stale-10. `serve-expired-*` options can be used to configure the behavior.
  • Updated cachedb to honor `serve-expired-ttl`; Fixes #107.
  • Renamed statistic `num.zero_ttl` to `num.expired` as expired replies come with a configurable TTL value (`serve-expired-reply-ttl`).
  • Merge #135 from Florian Obser: Use passed in neg and key cache if non-NULL.
  • Fix #153: Disable validation for DSA algorithms. RFC 8624 compliance.
  • Merge PR#151: Fixes for systemd units, by Maryse47, Edmonds and Frzk. Updates the unbound.service systemd file and adds a portable systemd service file.
  • Merge PR#154; Allow use of libbsd functions with configure option --with-libbsd. By Robert Edmonds and Steven Chamberlain.
  • Merge PR#148; Add some TLS stats to unbound_munin_. By Fredrik Pettai.
  • Merge PR#156 from Alexander Berkes; Added unbound-control view_local_datas_remove command.
Bug Fixes
  • Fix typo to let serve-expired-ttl work with ub_ctx_set_option(), by Florian Obser
  • Update mailing list URL.
  • Fix #140: Document slave not downloading new zonefile upon update.
  • Downgrade compat/getentropy_solaris.c to version 1.4 from OpenBSD. The dl_iterate_phdr() function introduced in newer versions raises compilation errors on solaris 10.
  • Changes to compat/getentropy_solaris.c for, ifdef stdint.h inclusion for older systems. ifdef sha2.h inclusion for older systems.
  • Fix 'make test' to work for --disable-sha1 configure option.
  • Fix out-of-bounds null-byte write in sldns_bget_token_par while parsing type WKS, reported by Luis Merino from X41 D-Sec.
  • Updated sldns_bget_token_par fix for also space for the zero delimiter after the character. And update for more spare space.
  • Fix #138: stop binding pidfile inside chroot dir in systemd service file.
  • Fix the relationship between serve-expired and prefetch options, patch from Saksham Manchanda from Secure64.
  • Fix unreachable code in ssl set options code.
  • Removed the dnscrypt_queries and dnscrypt_queries_chacha tests, because dnscrypt-proxy (2.0.36) does not support the test setup any more, and also the config file format does not seem to have the appropriate keys to recreate that setup.
  • Fix crash after reload where a stats lookup could reference old key cache and neg cache structures.
  • Fix for memory leak when edns subnet config options are read when compiled without edns subnet support.
  • Fix auth zone support for NSEC3 records without salt.
  • Merge PR#150 from Frzk: Systemd unit without chroot. It add contrib/unbound_nochroot.service.in, a systemd file for use with chroot: "", see comments in the file, it uses systemd protections instead. It was superceded by #151, the unbound_portable.service file.
  • Merge PR#155 from Robert Edmonds: contrib/libunbound.pc.in: Fixes to Libs/Requires for crypto library dependencies.
  • iana portlist updated.
  • Fix to silence the tls handshake errors for broken pipe and reset by peer, unless verbosity is set to 2 or higher.
  • Merge PR#147; change rfc reference for reserved top level dns names.
  • Fix #157: undefined reference to `htobe64'.
  • Fix subnet tests for disabled DSA algorithm by default.
  • Update contrib/fastrpz.patch for clean diff with current code.
  • updated .gitignore for added contrib file.
  • Add build rule for ipset to Makefile
  • Add getentropy_freebsd.o to Makefile dependencies.
  • Fix memory leak in error condition remote.c
  • Fix double free in error condition view.c
  • Fix memory leak in do_auth_zone_transfer on success
  • Stop working on socket when socket() call returns an error.
  • Check malloc return values in TLS session ticket code
  • Fix fclose on error in TLS session ticket code.
  • Add assertion to please static analyzer
  • Fixed stats when replying with cached, cname-aliased records.
  • Added missing default values for redis cachedb backend.
  • Fix num_reply_addr counting in mesh and tcp drop due to size after serve_stale commit.
  • Fix to create and destroy rpz_lock in auth_zones structure.
  • Fix to lock zone before adding rpz qname trigger.
  • Fix to lock and release once in mesh_serve_expired_lookup.
  • Fix to put braces around empty if body when threading is disabled.
  • Fix num_reply_states and num_detached_states counting with serve_expired_callback.
  • Cleaner code in mesh_serve_expired_lookup.
  • Document in unbound.conf manpage that configuration clauses can be repeated in the configuration file.
  • Document 'ub_result.was_ratelimited' in libunbound.
  • Fix use after free on log-identity after a reload; Fixes #163.
  • Fix with libnettle make test with dsa disabled.
  • Fix contrib/fastrpz.patch to apply cleanly. Fix for serve-stale fixes, but it does not compile, conflicts with new rpz code.
  • Fix to clean memory leak of respip_addr.lock when ip_tree deleted.
  • Fix compile warning when threads disabled.
  • Fix spelling in unbound.conf.5.in.
  • Stop unbound-checkconf from insisting that auth-zone and rpz zonefiles have to exist. They can not exist, and download later.
  • contrib/drop2rpz: perl script that converts the Spamhaus DROP-List in RPZ-Format, contributed by Andreas Schulze.
  • Remove unused variable.
  • Add respip to supported module-config options in unbound-checkconf.
  • Updated contrib/unbound_smf23.tar.gz with Solaris SMF service for Unbound from Yuri Voinov.

Versienummer 1.10.0
Releasestatus Final
Besturingssystemen Linux, BSD, macOS, Solaris, Windows Server 2012, Windows Server 2016
Website NLnet Labs
Download https://nlnetlabs.nl/projects/unbound/download/
Licentietype Voorwaarden (GNU/BSD/etc.)

Door Bart van Klaveren

Downloads en Best Buy Guide

22-02-2020 • 20:45

46 Linkedin

Submitter: jpgview

Bron: NLnet Labs

Update-historie

Reacties (46)

Wijzig sortering
Voor (niet alle) ASUS routers is met Merlin firmware unbound als plug-in beschikbaar. In de nieuwste versie is het opzetten doodsimpel via het 'amtm' commando en dan de menu's volgen voor de installatie. Meer op
https://www.snbforums.com...cursive-dns-server.61669/
Ik draai dat inmiddels een paar dagen naar volle tevredenheid.

[Reactie gewijzigd door rikster op 23 februari 2020 14:30]

Ik weet even niet of ik goed zit, maar ik word graag gecorrigeerd, maar Unbound zet je dan dus in wezen 'tussen' bijvoorbeeld een Pi-Hole machine en het internet in?

Of is Unbound dan een forwarding DNS server zoals je bijvoorbeeld DNS.WATCH en Cloudflare kan opgeven binnen Pi-Hole?

[Reactie gewijzigd door CH4OS op 22 februari 2020 22:22]

je zet unbound inderdaad tussen pihole en het internet, dus client -> pihole -> unbound -> internet.

De reden waarom we dit doen:
Je kan pihole zo configureren dat die alle (niet geblockte) requests doorstuurt naar één resolver b.v. 8.8.8.8
Nadeel hiervan is dat google dan alle DNS requests van je ziet, en dus een profiel van je opbouwd (en die data ongetwijfeld gebruikt voor ad targeting, of zelfs gewoon doorverkoopt).

Dit is trouwens ook de reden waaom DOH en DOT zo een slecht idee zijn. Je geeft opnieuw al je data aan één bedrijf.

Unbound gebruiken we als recursive resolver. Dit wil zeggen, b.v. voor het domain www.example.com, dat unbound uitzoekt (bij de root servers) wat de DNS server is voor het domain example, en dan aan die DNS server het address voor www opvraagd. Voordeel hiervan is, dat geen enkele DNS server weet wat je allemaal uitspookt, ze weten alleen wat je bij hen hebt opgevraagd, geen enkele DNS server heeft genoeg data voor een profiel, e.g. privacy (verdeel en heers)

Beetje simpele verklaring, t'is iets ingewikkelder dan dat, maar het verklaard in (tamelijk) begrijpbare taal wat we ermee willen bereiken.

[Reactie gewijzigd door jpgview op 22 februari 2020 23:44]

Kan dit op die Chinese machines geïnstalleerd worden met meerdere lan-poorten samen met pihole ? Of moet je echt apart alles hebben en dan via switch??

Ik heb wel een rpi waar pihole op draait. Maar hoe zou dit het beste zijn om te configureren?
Je kan unbound gewoon op je pi installeren naast pihole. Even je Googlefu gebruiken.
pihole wordt slechts ondersteund op een beperkt aantal operating systems en cpu architecture, er is ook een docker image. Als het ding daaraan voldoet, is er support, anders ben je op je zelf aangewezen om het uit te zoeken.
Het is aan te raden pihole & unbound (& eventueel redis) te installeren op dezelfde machine, pihole-FTL met cache=0 (pihole support is het daar niet mee eens), unbound & redis met een cache die voor jou het beste past (aantal gebruikers, aantal devices)
Als je unbound en / of redis op een andere machine plaatst, is de winst, die je hebt door de unbound en redis cache, teniet gedaan door het extra network verkeer (LAN) dat je veroorzaakt, mogelijks wordt het zelfs trager.

Ik draai zelf pihole (nu beta5) en unbound en redis op een rpi 3B, sinds ik dit artikel heb geschreven (October 2019), tot op heden geen problemen ondervonden.
pihole wordt slechts ondersteund op een beperkt aantal operating systems en cpu architecture, er is ook een docker image. Als het ding daaraan voldoet, is er support, anders ben je op je zelf aangewezen om het uit te zoeken.
Ik heb dus Pi-Hole en Rebound (2 keer zelfs) in Docker Containers draaien.
Je kan pihole zo configureren dat die alle (niet geblockte) requests doorstuurt naar één resolver b.v. 8.8.8.8
Nadeel hiervan is dat google dan alle DNS requests van je ziet, en dus een profiel van je opbouwd (en die data ongetwijfeld gebruikt voor ad targeting, of zelfs gewoon doorverkoopt).

Dit is trouwens ook de reden waaom DOH en DOT zo een slecht idee zijn. Je geeft opnieuw al je data aan één bedrijf.
gebruik dan je provider DNS of 1.1.1.1
Privacy First: Guaranteed.
We will never sell your data or use it to target ads. Period.

We will never log your IP address (the way other companies identify you). And we’re not just saying that. We’ve retained a big 4 accounting firm to audit our assertions about our systems annually to ensure that we're doing what we say.

Frankly, we don’t want to know what you do on the Internet—it’s none of our business—and we’ve taken the technical steps to ensure we can’t.
- mijn provider telenet (belgie), doet op digitale tv aan targeted personalized advertising. Waar denk je dat ze de data vandaan halen. Er is een opt-out in de mijn telenet instellingen, de vraag is maar of ze zich er aan houden.
-1.1.1.1: We will never sell your data, tot er vroeg of laat een aangepaste privacy statement te voorschijn komt, onder druk van de investeerders, ze gaan dan zeker de data die ze al verzameld hebben, niet gebruiken...

Ik vermoed dat je ook wel eens een nieuwe privacy statement van google gekregen hebt. Daar ben je gebruiker, ze sturen een onbegrijpelijke nieuwe policy naar je toe, met de 'te nemen of te laten' boodschap inbegrepen.

Bij 1.1.1.1 ben je niet eens klant, wel gebruiker, geen account, alleen effe DNS instellingen aanpassen.

remember: If a product is free, you're the product. Een andere filosofie, trust, but verify, is helaas niet mogelijk, je hebt er geen idee van wat ze met de data doen, ondanks alles wat ze zeggen.

Voorkomen is beter dan genezen, de unbound setup is zo eenvoudig, dat het geen argument is om unbound niet te gebruiken.

Maar iedereen doet natuurlijk wat hij / zij wil, als je vertrouwen hebt in bepaalde tech bedrijven, go for it...

[Reactie gewijzigd door jpgview op 23 februari 2020 10:55]

...je hebt er geen idee van wat ze met de data doen, ondanks alles wat ze zeggen.
Tja, als je zo wantrouwend te werk gaat of bent, heeft een filosofie als 'trust, but verify' natuurlijk geen enkele zin (je vertrouwt immers niets en niemand) en spreek je dus jezelf gewoon tegen. Ook zou het natuurlijk wat raar zijn als men A zegt, maar B doet met de data. Dat brengt een bedrijf ernstige schade toe, weliswaar alleen wanneer dat publiekelijk bekend wordt.

Je kan het immers verifiëren door het privacy statement te lezen. Als dat niet afdoende is voor je: sinds de GDPR / AVG (geen idee hoe hij in België heet) mag je de privacy officer(s) van bedrijven aanschrijven met een verzoek om jouw data. Dan zie je alle data die men van jou heeft. Ben je het niet eens met de data die ze van je hebben, vind je het teveel, of wat dan ook, kun je gewoon een verzoek tot verwijdering van die data doen (het recht om vergeten te worden). Daar zijn ze wettelijk voor verplicht aan mee te werken, dus het is zeker te weten betrouwbaar te maken. Ook kun je dan controleren of ze daadwerkelijk A zeggen en al dan niet B doen. ;)

En ja, dat is allemaal omslachtiger (want voorkomen is beter dan genezen, dus daar ben ik het zeker wel eens met je), maar betekend niet dat er dan niets meer aan te doen is.

Ik denk alleen wel als je dan echt zo wantrouwend bent, dat het verstandiger is om (minstens) offline te gaan, scheelt nog bergen geld ook, want dan kun je gewoon internet opzeggen. ;) Alleen dan weet je 100% zeker dat online bedrijven zoals techgiganten jouw data niet krijgen. Want wie weet wat Pi-Hole en Unbound doen... ;)

[Reactie gewijzigd door CH4OS op 23 februari 2020 12:53]

Als men A zegt, maar B doet

Ga hier de artikels over privacy problemen niet oplijsten, maar ik vermoed dat je ze af en toe ook wel leest, en je er vragen bij stelt.

Want wie weet wat Pi-Hole en Unbound doen...

pihole en unbound zijn open source, je kan 'trust, but verify' hier op toepassen, er zijn ook security analyzers die dat doen, recent nog een audit van unbound, met als resultaat, ondertussen opgeloste, issues.

Ik ga mijn internet abbo niet opzeggen. Ik beweer ook niet dat mijn privacy veilig is door al mijn paranoia maatregelen, integendeel, ik zoek alle dagen verder naar extra mogelijkheden. Die paranoia maatregelen zijn trouwens een goede leerschool, een van de streefdoelen van een tweaker, dacht ik.

Ik zeg alleen dat, wanneer er een eenvoudig alternatief beschikbaar is (unbound, daar gaat dit topic over), je er goed aan doet dat ook te gebruiken.
Tja, als je zo wantrouwend te werk gaat of bent, heeft een filosofie als 'trust, but verify' natuurlijk geen enkele zin (je vertrouwt immers niets en niemand) en spreek je dus jezelf gewoon tegen.
Jawel, want het alternatief dat gegeven wordt is de boel spreiden.

Op zich heb je verder een punt. Ik las laatst hoe goed SearX is (tov Google). Maar dan kom je dus of een eigen instance te draaien (wat extra werk is), of je gaat er eentje gebruiken van een random nobody die je niet kent.
Want wie weet wat Pi-Hole en Unbound doen...
Is volledig open source, en draait in je eigen netwerk. Dat kun je dus auditen.
Pihole en unbound zijn open source, die kun je zelf controleren als je het niet vertrouwt. dat geeft mij toch meer zekerheid dan een papieren belofte.
een provider moet helemaal geen dns-request snoopen, want ze zien zo al naar waar al je traffic naartoe gaat en in het geval van een triple-play provider kan die in theorie ook meteen weten wanneer je thuis bent, naar welke programma's je kijkt, hoe vaak je met je moeder belt, bij welke nutsmaatschappijen of andere bedrijven je klant bent, ... dat kán allemaal, maar daarom zijn er ook wetten, toezichthouders en rechtbanken. Uiteindelijk zal je toch ergens een partij moeten vertrouwen en als je bang bent dat een dienst in de toekomst gaat veranderen, dan kan je geen enkele dienst meer vertrouwen (wie weet wat de datacenter-hosts allemaal afluisteren voor de CIA).

Met dit soort reacties en topics komen we altijd op machtsmisbruik en samenzweringen terecht en uiteindelijk is er geen oplossing voor vertrouwensproblemen, dus ik denk dat we die discussie niet moeten voeren.
Maar als je toch alle ads blockt met pi-hole (of iets anders), wat maakt het dan nog uit dat Goochel je data gebruikt voor ad targeting cq profiel-opbouw?
Of ga ik hier een beetje te kort mee door de bocht?

Om mezelf voor de duidelijkheid even als voorbeeld te nemen: ik zie nooit ads. Nul komma nul. Ik weet wel dat er profielen van me bestaan maar daar merk ik dus verder niets van.
als je er niks mee inzet dat google alles over je weet, heb je gelijk. Vroeg of laat word het profiel van je, dat ergens op het internet rond slingert misbruikt. Voorkomen is beter dan genezen is mijn filosofie. T'is niet omdat je geen ads ziet, dat ze geen data verzamelen, b.v. nederlanders uit Groningen zijn meer op Samsung websites dan op iRobot web sites geweest, verkopen die data, aan Samsung...
Okay ik zie je punt thx
Voor wat het waard is (zelf gebruik ik 8.8.8.8 ook niet omdat ik niet alles bij Google wil onder brengen). Maar Google zegt de data niet langer dan 2 weken vast te houden, te corroleren en te combineren.

Zie hier:
https://developers.google.com/speed/public-dns/privacy

What we log

Google Public DNS stores two sets of logs: temporary and permanent. The temporary logs store the full IP address of the machine you're using. We have to do this so that we can spot potentially bad things like DDoS attacks and so we can fix problems, such as particular domains not showing up for specific users.

We delete these temporary logs within 24 to 48 hours.

In the permanent logs, we don't keep personally identifiable information or IP information. We do keep some location information (at the city/metro level) so that we can conduct debugging, analyze abuse phenomena. After keeping this data for two weeks, we randomly sample a small subset for permanent storage.

We don't correlate or combine information from our temporary or permanent logs with any personal information that you have provided Google for other services.
google zegt…

Ik heb hier 3 machines 24/7 draaien, op elke machine is mail geconfigureerd, MSMTP stuurt de resultaten van cron scripts door naar een unieke google mail box (eentje voor elke machine) Verder heb ik ook nog een aantal google mailboxes, specifiek voor mail van forums (pfsense, Raspbian, pihole, …)
Wanneer ik google mail (web) open doe, toont de inlog pagina, mij een login keuze voor al die verschillende mail addressen, ze zoeken dus wel degelijk uit welke mailboxen (en calenders) door de zelfde persoon? / IP? gebruikt worden, en koppelen die aan elkaar (geen cookies, die wis ik dagelijks). We don't correlate or combine information from our temporary or permanent logs with any personal information that you have provided Google for other services? Yeah, right!

If a product is free, you are the product.

Nogmaals, iedereen doet wat hij wil, trust the company? feel free to use it. Voor mezelf heb ik uitgemaakt dat er voldoende schandalen aan het licht zijn gekomen, om er zeker van te zijn dat, wat ze zeggen en wat ze doen, twee totaal veschillende dingen zijn, als er al iets aan het licht komt, zeggen ze dat het zo niet bedoeld was (bugje), maar dat de gebruikers zich vooral niet geviseerd hoeven te voelen. Ze hebben geen intresse voor jouw privacy, ze hebben er geen belang bij, integendeel.

edit
Ik vind het prima dat heel veel gebruikers 8.8.8.8 of 1.1.1.1 gebruiken. Zolang die 'data gathering methods' voldoende resultaat opleveren, zullen ze geen (minder) energie steken in het zoeken naar andere methodes om je data te bemachtigen.
/edit

[Reactie gewijzigd door jpgview op 23 februari 2020 12:51]

De informatie die ik aanhaalde ging over je eerdere reactie:

"Nadeel hiervan is dat google dan alle DNS requests van je ziet, en dus een profiel van je opbouwd (en die data ongetwijfeld gebruikt voor ad targeting, of zelfs gewoon doorverkoopt)."

Die link die ik stuurde ging over de privacy over de Google dns servers. Volgens Google verkopen ze deze data niet en gebruiken ze dit ook niet voor ad targeting.

Bij andere diensten (zoals het Gmail voorbeeld wat je aanhaald) doen ze dat inderdaad wel.

Nu heeft Google zelf het recht om de algemene voorwaarden aan te passen dus grote kans dat ze uiteindelijk toch zwichten (WhatsApp anyone?) voor de aandeelhouders. Maar dat even terzijde.

Ik heb een tijd terug op een podcast (ben even kwijt welke) gehoord dat de Google dns engineers die dienst echt hebben opgebouwd vanwege het grote aantal brakke dns servers en deze dns dienst hebben gebouwd om dit te fixen.

Ik denk dat het resultaat best goed gelukt is. Maar ik ben het met je eens. Als je niet betaald voor een product dan ben je het product. Maar de insteek van het dns team daar is dus niet die data te koppelen. Hoe lang ze dat volhouden.... De tijd zal het leren.

[Reactie gewijzigd door L0g0ff op 23 februari 2020 13:19]

Ik heb hier 3 machines 24/7 draaien, op elke machine is mail geconfigureerd, MSMTP stuurt de resultaten van cron scripts door naar een unieke google mail box (eentje voor elke machine) Verder heb ik ook nog een aantal google mailboxes, specifiek voor mail van forums (pfsense, Raspbian, pihole, …)
Wanneer ik google mail (web) open doe, toont de inlog pagina, mij een login keuze voor al die verschillende mail addressen, ze zoeken dus wel degelijk uit welke mailboxen (en calenders) door de zelfde persoon? / IP? gebruikt worden, en koppelen die aan elkaar (geen cookies, die wis ik dagelijks). We don't correlate or combine information from our temporary or permanent logs with any personal information that you have provided Google for other services? Yeah, right!
Sorry, maar dit stuk is totale onzin en echt veel te ver overdreven. Google houdt ook aan hun kant bij op welke accounts er is ingelogd geweest vanaf welk IP-adres en pas als er is ingelogd met account X, dan weet Google dat Y en Z daar ook bij horen (omdat ze dat kunnen zien aan de sessie ID's, niet eens de cookies dus).

Ze laten jou dus zien op welke accounts jij eerder bent ingelogd geweest vanaf jouw IP-adres, meer niet. Dat komt echt niet doordat je Google DNS bijvoorbeeld gebruikt hoor, is gewoon puur door jouw acties dat Google dat weet. ;) Hoe moet zoiets te correleren zijn op DNS niveau? :? Het enige dat ze kunnen doen met de DNS is bijvoorbeeld relateren aan zoekacties en naar welke sites je dan zoal geweest bent. Maar niet met welk account je zoal inlogt, dat is immers geen DNS-aangelegenheid.

[Reactie gewijzigd door CH4OS op 23 februari 2020 13:39]

Je kan ook gewoon alleen unbound gebruiken met dezelfde functionaliteit als de PiHole.

Dat scheelt weer een stukje software ertussen
Wat ook een handige feature is, is dat hij de DNS record op de achtergrond al gaat opvragen net voor de TTL verstrijkt, zodanig dat het DNS-record onmiddellijk beschikbaar is op het moment dat het opgevraagd wordt.

Wij hebben voor een aantal interne systemen een eigen DNS server op basis van Python, en dat zou uiteraard een performance bottleneck kunnen worden. We draaien dus unbound ervoor, met bovengenoemde feature erbij; en alle responses zijn 0ms :)
Hier vind je meer informatie: https://nlnetlabs.nl/projects/unbound/about/

Het ligt er volgens mij net aan wat je wilt doen, maar als ik mij niet vergist wordt deze service vaak gebruikt als tussenlaag naar de uiteindelijke DNS wat inderdaad DNS.WATCH, Google of Cloudflare kan zijn. Meestal is dat over DNS-over-HTTPS (DoH) en worden requests lokaal gecached of geblokkeerd zoals een Pi-Hole dat doet. Het is meer dan een DNS-forwarder, deze kan ook zijn eigen 'boek' opbouwen/bijhouden.

[Reactie gewijzigd door foxgamer2019 op 22 februari 2020 22:44]

Dank voor de link, maar had ik er inderdaad even bij moeten zeggen dat ik die pagina al gelezen heb.
En uitgaande van jouw toevoeging, neem ik aan dat ik inderdaad correct zit. :)
Dan is het zeker het overwegen waard!
Unbound is primair een resolver, forwarden kan ook maar is niet de hoofdfunctie. Unbound is vooral voor organisaties die juist geen externe DNS resolver willen gebruiken.
Umbound kan geen DoH, wel DoT en dnscrypt.
Unbound is een name server en een alternatief voor ISC Bind en PowerDNS. Ze doen ongeveer hetzelfde, ieder op een eigen wijze. Ze kunnen als autoritatieve name server (bv. als hoster) of als recursieve name server (bv. als Internet provider) worden gebruikt, of beide. Hoe je het zelf gebruikt is je eigen keuze.

Sommige providers bieden TLS aan voor client lookups, dat zorgt ervoor dat queries worden versleuteld. Daarvoor kun je ook unbound gebruiken.

Test wat een provider gebruikt: dig @nameserver version.bind chaos txt
Unbound is niet authorative, al kun je wel kleine aanpassingen doen aan de antwoorden die je geeft.
Beiden kan.

Pi-Hole gebruikt een modified dnsmasq. Die kun je vervangen door bijvoorbeeld Unbound, ja. Op de forums van Pi-Hole staat daar voor howto's.
Ondertussen reeds twee dagen up and running op raspberry pi 3B / Raspbian November (02-13-2020)
Ik gebruik pihole +unbound met reddis dbcache. Tot hiertoe geen problemen.
De methode om v1.9.6 te compileren, kan zonder wijzigingen gebruikt worden om 1.10.0 op te bouwen (geen extra of andere libraries nodig).

[Reactie gewijzigd door jpgview op 22 februari 2020 23:47]

Waarom is het handig om dit met Redis te combineren?

[Reactie gewijzigd door Muncher op 22 februari 2020 22:40]

De verklaring is als volgt
- unbound ontvangt een request
- unbound kijkt in zijn memory cache (ga er even vanuit dat er geen data beschikbaar is)
- unbound kijkt in de cachedb (reddis), als daar een antwoord beschikbaar is, geeft unbound dat aan de client.
- ongeacht of er een bruikbaar antwoord in de reddis cache zit of niet, word de query naar de correcte DNS server gestuurd
- het antwoord van de DNS server wordt gebruikt om de client een antwoord te geven (als dat al niet gebeurd was - zie twee stappen hoger) en om de reddis cache te updaten.

hier (GitHub) compile unbound en install reddis script (unbound moet met een extra library gecompileerd worden - libhiredis)
hier (GitHub) de extra unbound conf file.

Opgelet: troubleshooten is niet eenvoudig, er is niet veel over te vinden op het www.
Opgelet2: pihole developers zijn hier allergisch aan, reken niet op support als het word reddis vermeld word.
Dus het is een uitbreiding op je memory cache? Geinig. Sloopt dit niet de Sd-kaart(als in: veel lees en schrijf acties)
Redis is een in-memory key-value storage. Het zit dus in het RAM, schrijfacties daarheen hebben geen gevolgen voor de MicroSD kaart.
Wat is dan nog het nut? unbound memory cache of extra stappen voor redis in memory?
Met Redis kun je dus de verzoeken (domein.tld (key) en het resultaat, het IP-adres (value)) opslaan in het RAM geheugen. Dat is veel sneller dan ophalen van disk.
Echter heeft unbound zelf een memory cache welke in het RAM in een hashtable wordt opgeslagen (https://nlnetlabs.nl/docu...nd/ietf67-design-02.pdf). Hoeveel sneller het dan wordt met redis zal je moeten meten maar ik verwacht niet gigantische verschillen, laat staan dat het merkbaar is in de praktijk. Verder is het leuk dat redis een restart overleeft, maar ik denk niet dat de meeste mensen hun Raspberry vaak restarten.

Voor eenvoudig gebruik kan je denk ik het beste de officiële guide gewoon kan volgen:
https://docs.pi-hole.net/guides/unbound/
En dan deze eenvoudige tweaks er nog bij:
https://www.reddit.com/r/...slow_performance/f1jnuq1/
Je kan de redis cache delen tussen verschillende servers zodat ze samen een grote cache hebben.
Dat is inderdaad een situatie die het gebruik van Redis als cache verantwoord, en dan zou ik een aparte machine gebruiken voor de database, maar dat is in mijn ogen voor 99,9% van de Pihole gebruikers niet echt relevant.

Het is typisch een "oplossing" die ik wellicht zelf ook zou installeren, gewoon omdat het kan en het leuk is om eens mee te experimenteren, om het vervolgens weer te verwijderen omdat het de boel nodeloos complex maakt :P
Klopt, maar voor pihole gebruikers is unbound sowieso niet zo interessant, dat is toch vooral nuttig in grotere en professionele omgevingen.
Oh jee. Daar gaat mijn zondag! :D Thanks voor het uitleggen.
je kan zelf bepalen wanneer de reddis memory cache (ik gebruik 32Mb) naar disk word geschreven wordt, ga hier niet verder op ingaan, maar de redis man page lijst de commando's op, die je in scripts kan gebruiken om dat te verwezelijken (ik gebruik daar een cron job voor). Groot voordeel is dat die cache dan een unbound restart, een redis restart of zelfs een reboot overleefd.

[Reactie gewijzigd door jpgview op 22 februari 2020 23:33]

Hoezo is het een normale manier van inrichten geworden om een resolving DNS server naar een upstream resolver op het publieke internet te wijzen i.p.v. recursie gewoon zijn werk te laten doen zoals het ontworpen en bedoeld is? Pihole stond nog op mijn lijstje om eens te bekijken maar deze gewoonte is echt bezopen.. Als het echt nodig is om er zelf Unbound o.i.d. nog tussen te klussen, is mijn vertrouwen op voorhand weg.
Het is niet moeilijk om dit gewoon zelf in te richten met alleen unbound of bind en dan ook recursive en ad blocking
Punt is dat Pihole zichzelf totaal diskwalificeert als oplossing voor DNS door dit blijkbaar totaal verkeerd in te steken. Recursie hoort de default te zijn met forwarding als optie wanneer het niet anders kan. Op deze manier werkt het product misvattingen in de hand over de manier waarop DNS is bedoeld te werken en krijg je oneigenlijke discussies over datagraaien door Google/Cloudflare etc. terwijl je daar nu nét juist met een eigen resolver helemaal geen last van zou moeten hebben. Helaas, je moet er omheen werken. Dat kan allemaal wel, maar je moet dan eerst weten dat er iets niet in de haak is. Gemiste kans dit.
ben ik met je eens, echter heeft pihole gekozen voor een product wat geen recursie kan doen, en heeft dat later aangevuld met unbound als recursor.

ik heb om deze reden dan ook geen pihole draaien maar bind met dezelfde lijsten als pihole.
en sinds kort test ik dezelfde functionaliteit met alleen unbound. beide werken goed.

je hebt alleen geen community die pihole heeft en geen webgui en geen API. maar goed het gaat mij toch alleen om de functionaliteit

verder is pihole een leuk project, snap alleen niet zo goed voor de keuze van dnsmasq (FTL)

[Reactie gewijzigd door Zjemm op 23 februari 2020 19:14]

Op dit item kan niet meer gereageerd worden.


Apple iPhone 11 Microsoft Xbox Series X LG OLED C9 Google Pixel 4 CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True