Software-update: Unbound 1.11.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.11.0 uitgebracht en daarin zijn de volgende veranderingen en verbeteringen aangebracht:

  • Merge #225 from akhait: KSK-2010 has been revoked. It removes the KSK-2010 from the default list in unbound-anchor, now that the revocation period is over. KSK-2017 is the only trust anchor in the shipped default now.
  • Merge PR #93: Add dynamic library support.
  • Introduce 'include-toplevel:' configuration option.
  • Change default value for 'rrset-roundrobin' to yes.
  • Add SNI support on more TLS connections (fixes #193).
  • Add SNI support to unbound-anchor.
  • Merge PR #164: Framestreams, this branch implements dnstap connectivity in unbound. This has a number of new features. The dependency on libfstrm is removed. The fstrm protocol code resides in dnstap/dnstap_fstrm.h and dnstap/dnstap_fstrm.c. This contains a brief definition of what unbound needs. The make unbound-dnstap-socket builds a debug tool, unbound-dnstap-socket. It can listen, accept multiple DNSTAP streams and print information. Commandline options control it. Unbound can reconnect if the unix domain socket file socket is closed. This uses exponential backoff after which it uses a one second timer to throttle cpu down. There is also support to use TCP and TLS for connecting to the log server. There are new config options to turn them on, in the dnstap section in the man page and example config file. dnstap-ip with IP address of server for TCP or TLS use. dnstap-tls to turn on TLS. And dnstap-tls-server-name, dnstap-tls-cert-bundle, dnstap-tls-client-key-file and dnstap-tls-client-cert-file to configure the certificates for server authentication and client authentication, or leave at "" to not use that.
  • Fix #165: Add prefer-ip4: yesno config option to prefer ipv4 for using ipv4 filters, because the hosts ip6 netblock /64 is not owned by one operator, and thus reputation is shared.
Bug Fixes
  • protect X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS with ifdef for different openssl versions.
  • Merge PR #166: Fix typo in, by glitsj16.
  • Fix #169: Fix warning for daemon/remote.c output may be truncated from snprintf.
  • Fix #170: Fix gcc undefined sanitizer signed integer overflow warning in signature expiry RFC1982 serial number arithmetic.
  • Fix more undefined sanitizer issues, in respip copy_rrset null dname, and in the client_info_compare routine for null memcmp.
  • Merge PR #171: Add additional compilers and platforms to Travis testing, by noloader.
  • Merge PR #173: updated for config.guess and config.sub and sha256 digest for gpg, by noloader.
  • Merge PR #172: Add IBM s390x arch for testing, by noloader.
  • Fix #177: dnstap does not build on macOS.
  • Fix compiler warning in dns64/dns64.c
  • Merge PR #174: Add Android to Travis testing, by noloader.
  • Move android build scripts to contrib/ and allow android tests to fail.
  • Fix #175, Merge PR #176: fix link error when OpenSSL is configured with no-engine, thanks noloader.
  • Upgrade config.guess(2020-01-01) and config.sub(2020-01-01).
  • Merge PR #180 from noloader: Avoid calling exit in Travis script.
  • Merge PR #181 from noloader: Fix OpenSSL -pie warning on Android.
  • Update (from PR #179), by Jeffrey Walton.
  • Fix PR #182 from noloader: Add iOS testing to Travis.
  • Merge PR #186, fix #183: Fix unrecognized 'echo -n' option on OS X, by noloader
  • Fix #188: unbound-control.c:882:6: error: 'execlp' is unavailable: not available on tvOS.
  • Fix #189: mini_event.h:142:17: error: field 'ev_timeout' has incomplete type, by noloader.
  • Add check to make sure RPZ records are subdomains of configured zone origin.
  • Fix #192: In the unbound-checkconf tool, the module config of dns64 subnetcache respip validator iterator is whitelisted, it was reported it seems to work.
  • Merge PR #191: Update iOS testing on Travis, by Jeffrey Walton.
  • Fix #158: open tls-session-ticket-keys as binary, for Windows. By Daisuke HIGASHI.
  • Merge PR#134, Allow the kernel to provide random source ports. By Florian Obser.
  • Log warning when using outgoing-port-permit and outgoing-port-avoid while explicit port randomisation is disabled.
  • Merge PR #194: Add libevent testing to Travis, by Jeffrey Walton.
  • Fix .travis.yml error, missing 'env' option.
  • Merge PR #197 from fobser: Make log_ident_revert_to_default() a proper prototype.
  • Merge PR #198 from fobser: Declare lz_enter_rr_into_zone() static, it's only used in this file.
  • Fix compile on Solaris for unbound-checkconf.
  • Fix compile of test tools without protobuf.
  • Merge PR #200 from yarikk: add ip-dscp option to specify the DSCP tag for outgoing packets.
  • Travis fix for ios by omitting tools from install.
  • Merge PR #201 from noloader: Fix OpenSSL cross-compaile warnings.
  • Fix RPZ concurrency issue when using auth_zone_reload.
  • Make unbound-control error returned on missing domain name more user friendly.
  • Merge PR #203 from noloader: Update with current procedures.
  • Merge PR #207: Clarify if-automatic listens on and ::
  • Merge PR #208: Fix uncached CLIENT_RESPONSE'es on stateful transports.
  • Merge PR #206: Redis TTL, by Talkabout.
  • More documentation for redis-expire-records option.
  • Keep track of number of timeouts. Use this counter to determine if capsforid fallback should be started.
  • Merge PR #214 from gearnode: unbound-control-setup recreate certificates. With the -r option the certificates are created again, without it, only the files that do not exist are created.
  • Fix #220: auth-zone section in config may lead to segfault.
  • Fix help return code in unbound-control-setup script.
  • Fix for posix shell syntax for trap in nsd-control-setup.
  • Fix for posix shell syntax for trap in test script.
  • Add doxygen documentation for DSCP.
  • Fix #222: --enable-rpath, fails to rpath python lib.
  • Fix for count of reply states in the mesh.
  • Remove unneeded was_mesh_reply check.
  • Explicitly use 'rrset-roundrobin: no' for test cases.
  • Cache ECS answers with longest scope of CNAME chain.
  • windows compile warnings removal for ip dscp option code.
  • Fix for integer overflow when printing RDF_TYPE_TIME.
  • Update contrib/aaaa-filter-iterator.patch for the recent generate_sub_request() change and to apply cleanly.
  • Merge PR #241 by Robert Edmonds: contrib/ Do not use "Requires:".
  • Mention tls name possible when tls is enabled for stub-addr in the man page.
  • Fix default explanation in man page for qname-minimisation-strict.
  • Fix display of event loop method with libev.
  • iana portlist updated.
  • Move reply list clean for serve expired mesh callback to after the reply is sent, so that script callbacks have reply_info.
  • Also move reply list clean for mesh callbacks to the scrip callback can see the reply_info.
  • Fix for mesh accounting if the reply list already empty to begin with.
  • Fix for mesh accounting when rpz decides to drop a reply with a tcp stream waiting for it.
  • Review fix for number of detached states due to use of variable after end of loop.
  • Fix tcp req info drop due to size call into mesh accounting removal of mesh state during mesh send reply.
  • Fix #259: Fix unbound-checkconf does not check view existence. unbound-checkconf checks access-control-view, access-control-tags, access-control-tag-actions and access-control-tag-datas.
  • Fix offset of error printout for access-control-tag-datas.
  • Fix add missing DSA header, for compilation without deprecated OpenSSL APIs.
  • Fix to use SSL_CTX_set_tlsext_ticket_key_evp_cb in OpenSSL 3.0.0-alpha4.
  • Longer keys for the test set, this avoids weak crypto errors.
  • Add bidirectional frame streams support.
  • Fix check conf test for referencing installation paths.
  • Fix unused variable warning for clang analyzer.
  • Merge PR #234 - Ensure proper alignment of cmsg buffers by Jérémie Courrèges-Anglas.
  • Fix PR #234 log_assert sizeof to use union buffer.
  • Fix libnettle compile for session ticket key callback function changes.
  • Fix lock dependency cycle in rpz zone config setup.
  • Fix streamtcp to print packet data to stdout. This makes the stdout and stderr not mix together lines, when parsing its output.
  • Fix contrib/fastrpz.patch to apply cleanly. It fixes for changes due to added libdynmod, but it does not compile, it conflicts with new rpz code.


Versienummer 1.11.0
Releasestatus Final
Besturingssystemen Linux, BSD, macOS, Windows Server 2012, Windows Server 2016, Windows Server 2019
Website NLnet Labs
Licentietype Voorwaarden (GNU/BSD/etc.)

Door Bart van Klaveren

Downloads en Best Buy Guide

29-07-2020 • 10:30

35 Linkedin

Submitter: jpgview

Bron: NLnet Labs


Reacties (35)

Wijzig sortering
Ik heb hier een gist voor geschreven:
Hier gebruik ik unbound als dns resolver en staan ook de commands om hem te updaten vanaf source.
Dat 'doorverwijzen' gebeurt toch van DNS naar DNS ? Daar merkt mijn PC toch niets van ?
Wat is dan het nut/doel van deze software ?
Een DNS-recursor gaat zelf op zoek naar de DNS-entries:
Heel erg versimpelt:

Jij wilt naar gaan:
Jouw computer vraagt aan een DNS-recursor net IP-adres van:

Die DNS-recursor gaat bij de root domain servers (hardcoded in de configuratie van elke recursor) vragen: "Wie weet iets van: ".net" "
Een van de root domain servers reageert. Je moet bij de TLD nameserver a.b.c.d. zijn:

Jouw recursor gaat dan verder naar de TLD nameserver a.b.c.d. zijn:
"Wie weet iets van"
De TLD nameserver geeft terug: w.x.y.z is de authoritative domain nameserver van

Jouw recursor gaat dan verder naar de authoritative domain name server van
"Wat is het IP-adres van"
En de authoritative domain nameserver reageert met:

Het verschil tussen een dns-server en een dns-recursor is dat de dns-recusor zelf op zoek gaat, en de dns-server het aan de dns-recursor vraagt. (de dns-server delegeert het zoekwerk naar de dns-recursor). Het primaire doen van een dns-server (zoals bijvoorbeeld dnsmasq) is dan ook, dat je die kan verrijken met data (voor bijvoorbeeld je eigen LAN) en caching. Dus dat niet elk verzoek persé het internet op hoeft.

(( edit - leesbaarheid ))

[Reactie gewijzigd door lenwar op 29 juli 2020 11:26]

mooi uitgelegd, klein foutje echter

Die DNS-recursor gaat bij de root domain servers (hardcoded in de configuratie van elke recursor) vragen: "Wie weet iets van: ".net" "

Unbound haalt die informatie uit root.hints, een bestand dat bijkomend op je systeem aanwezig moet zijn. De meeste distro's hebben een of andere versie van root.hints aan boord, echter meestal (voorbeeld Raspbian) is dat bestand gedateerd.

Zelf refresh ik het bestand root.hints éénmaal per week (en ook het default bestand van de distro)
sudo wget -O /etc/unbound/root.hints
je moet het uiteraard wel ergens zetten waar unbound het kan vinden (entry in de config file van unbound)

bron, de pihole documentatie, maar uiteraard ook in de unbound documentatie.

Je kan nog een stap verder gaan, de root zone lokaal downloaden, en unbound vertellen waar die info gevonden kan worden, zo elimineer je één externe request, lees hier

Uiteraard moet je die zone file dan ook up to date houden, commando (unbound-control nodig):
sudo /usr/sbin/unbound-control auth_zone_transfer "."
Dankje ;)

Ik schreef dan ook dat het een versimpelde procedure is :) De root hints was voor mijn vertaling 'hardcoded in de configuratie'. Dekt allicht de lading niet helemaal, maar het gaat voornamelijk om het concept.
Er komt in de praktijk uiteraard meer bij kijken dan wat ik hierboven beschreef.

Ik heb hier echt al jaren niks mee gedaan. Hoe vaak veranderen die root hints tegenwoordig in de praktijk? "Vroeger" veranderde ze bijna nooit, en was het meer dan voldoende om ze één keer per jaar te updaten. Ofwel, je nam de moeite er niet voor en ze kwamen met de patches van bind mee. Dat had volgens mij ook voornamelijk te maken dat het allemaal anycast adressen waren en zijn.
Voornamelijk de datum lijkt het ;)
< ; last update: July 16, 2020
< ; related version of root zone: 2020071603
> ; last update: June 08, 2020
> ; related version of root zone: 2020060801

< ; last update: July 16, 2020
< ; related version of root zone: 2020071603
> ; last update: December 05, 2019
> ; related version of root zone: 2019120501

Heb er toevallig twee staan op een pihole en even gekeken naar de laatste versie.

[Reactie gewijzigd door ninjazx9r98 op 29 juli 2020 14:47]

handig lees/kijkvoer:

Computerphile - How DNS Works

A cat explains DNS
Dat staat wat slecht uitgelegd in het artikel.

Als jij een DNS lookup doet, gebeurt dat via jouw provider. Ook als je Pi-Hole gebruikt is er nog altijd een upstream waar jij alle vragen neerlegt. Dit heeft privacy bezwaren: vertrouw jij jouw provider of Google/Cloudflare/OpenDNS voldoende dat zij niets doen met jouw bezoekersverkeer?

Bij een DNS-recursor gaat de software zelf op zoek naar de DNS entry. Dit verloopt dan via de root-servers en tussenliggende DNS servers. Uiteindelijk wordt de DNS-server van de domeinnaam zelf geraadpleegd voor het exacte record. Zo is er geen centraal punt meer wat weet waar jij allemaal naar toe browsed.

Het voordeel is betere privacy. Het nadeel van een DNS-recursor is dat websites opzoeken trager gaat. Je merkt dan wat de impact van DNS-caching is bij een upstream. De eerste keer dat je een website bezoekt moet je immers veel DNS-requests uitvoeren.

[Reactie gewijzigd door YaPP op 30 juli 2020 10:15]

Je kan pi-hole prima laten samenwerken met unbound. Hier is de guide:
Unbound draai je dan ook doorgaans op een Server, en niet op je eigen PC.
Dat *is* dan die DNS to DNS waar je het over hebt.
meestal in combinatie met Pi-Hole.
Zodat je geen DNS providers (Google, CloudFlare, OpenDNS, Ziggo) etc hoeft te gebruiken en je je eigen footprint (verzamelen van gegevens) weer wat kleiner maakt.
zie voor meer info @sircampalot
volgens mij heb je geen externe DNS provider nodig als je PiHole icm Unbound gebruikt.....
Je hebt nog steeds een en ander extern nodig maar kunt daarvoor gebruik maken van de root servers.
Of je de root servers dan weer 'externe DNS provider' wilt noemen of niet is dan weer een keuze :)
het is maar welk naampje het beestje wilt geven.

Maar bij het gebruik van de root server, wordt voorzover ik weet, geen logging bij gehouden dat ik een adres heb opgevraagd. Wat anders is dan bij Google, CLoudFlare, OpenDNS, Ziggo etc
Als je Unbound lokaal draait "ziet" Ziggo nog steeds ieder DNS request dat je naar de (authoritative) servers doet.
Je zou Unbound ergens op een anonieme server moeten hosten, zodat je encrypted connecties daarheen kan maken die je provider niet kan zien, en wat er vervolgens tussen die server en alle dns servers gebeurd is weer niet herleidbaar tot jou.
Dan ziet ziggo inderdaad je dan verkeer niet meer. Maar na de dns lookup maak je alsnog verbinding met gekregen IP adres welke ziggo wel weer kan zien. Je provider zal altijd je verkeer kunnen zien, direct of indirect.
Klopt, maar het punt van @MAdD was dat de provider niet meer zou kunnen zien welke adressen worden opgevraagd, en dat klopt niet volledig.

[Reactie gewijzigd door frickY op 30 juli 2020 08:03]

Klopt! Heb net de combinatie van unbound+pihole draaien. Mooi spul, en je lekt net weer een beetje minder info aan de data-hongerige garde.
Zit een beetje te twijfelen of ik Unbound zal installeren.
Als ik die lijst met bug fixes zie vraag ik me af hoe stabiel het is? :?

Tegelijkertijd lees ik best veel enthousiaste verhalen van gebruikers, dus ergens doet me dat vermoeden dat de stabiliteit wel goed is.

Zijn er ervaringsdeskundigen hier die daar iets over kunnen zeggen?
Ik gebruik unbound sinds de oplossing is aangereikt door de pihole developers (jaren geleden). Naast het feit dat unbound uiterst stabiel is (nog nooit een crash gehad), is het ook de beste oplossing, als je privacy bewust bent. Doordat unbound allemaal veschillende DNS servers contacteert, om uiteindelijk een IP address als resultaat te geven, heeft geen enkele DNS provider het volledige beeld van jouw requests. Google weet dus dat je bij hen bent geweest, maar niet dat je ook tweakers leest (tenzij je natuurlijk chrome gebruikt, dan weten ze na verloop van tijd zelfs de maat van je schoenen).

Ik compileer unbound wel zelf lokaal, de versies in de distros lopen altijd wel achter. Zeker als er security fixes zijn, is dit aan te raden, omdat unbound nu eenmaal rechtstreeks verbinding heeft met de buitenwereld.
Grappig dat je dit zegt over Chrome.

Toevallige vandaag zelf ontdekt dat op dezelfde pc gebruiken van Edge en Chrome (beide laatste release versie) op 1 specifieke pagina andere resultaten geeft terwijl ik pi-hole gebruik:
De volgende 2 script worden door Chrome wél ingeladen maar door Edge niet:

Ik heb beide domeinen in pi-hole staan en Chrome vertikt het om in die gevallen pi-hole te raadplegen terwijl Edge dat wel doet en vervolgens netjes in de console en netwerk tab bij die bestanden zegt dat het niet te laden was.
Daarom ben ik altijd al huiverig geweest voor Chrome(lees Google) producten. Die hebben een “eigen” wil.
Over het algemeen worden (ernstige) security fixes gewoon netjes gefixed in distro packages. Daarom kun je die packages ook prima gebruiken, enige wat je misschien zal missen zijn nieuwe features vanuit een nieuwere versie.
Het is zeker wel stabiel, Unbound word veel gebruikt, het is open source, mensen sturen patches om kleine issues to fixen. De fixes zijn vooral voor features, de basis functionaliteit werkt prima.

[Reactie gewijzigd door Lennie op 29 juli 2020 13:19]

Je moet je denk ik primair afvragen wat je doel is. Over het algemeen is het sneller om een snelle publieke DNS-server te gebruiken (bijvoorbeeld die van Cloudflare, OpenDNS, Google, enz.), maar dan heb je het 'probleem' dat zij in theorie een profiel van jouw DNS-queries kunnen maken. Als je dus niet wilt dat één partij (anders dan je ISP) dat doet, dan kan je Unbound gebruiken. (in het geval van Cloudflare en Google hebben zij ook andere manieren om je te profileren als ze dat echt willen, gezien hun dominante positie op het internet, maar dat is een andere discussie :) )

Dat snelheidsverschil zit hem voornamelijk in de latency van je internetverbinding en het aantal verzoeken dat je recursor daadwerkelijk de deur uit moet doen t.o.v. een standaard dns-server. (3 of 4, afhankelijk van je opzet voor een dns recursor tegen 1 voor een dns server) De snelle DNS-servers van bijvoorbeeld Google, OpenDNS en Cloudflare zitten op low-latency lijnen en ook nog is in de harten van het internet. (vrijwel direct op de IXPs)

Als je het gewoon 'leuk vindt' om een DNS-recursor te draaien kan het ook een reden zijn. Ik heb jaren en jaren geleden altijd de bind recursor gebruikt. Puur vanuit een hobby-perspectief. Ik heb toentertijd ook regelmatig allerlei dingen gedaan met optimalisaties en dergelijke.
Het 'grappige' was, dat als je een snelle externe DNS-server gebruikt dat dat echt een factor 10 tot 20 sneller kan zijn. (er zijn tools die heel veel DNS-verzoeken sturen naar meerdere partijen en je snelheidsrapportages laten zien. Uiteraard zijn dit 'slechts' benchmarks, maar het is wel aardig om te zien). Toen ik dat jaren geleden dus had omgezet naar OpenDNS (die sneller was dan Google volgens die tools) en later Cloudflare, maakte mijn toenmalige vriendin uit haarzelf de opmerking "Heb je iets met het internet gedaan... Hij lijkt sneller". Dat was voor mij de bevestiging dat het echt wel merkbaar sneller was dan thuis hosten. (ik had niks tegen haar gezegd. Ik dacht het zelf wel gezien te hebben, maar dat kon ook placebo zijn. Het feit dat zij het volledig uit haarzelf zij, wist ik dus dat het klopte wat ik dacht te zien)
Het downloaden ging uiteraard niet sneller, maar alles 'reageerde vlugger'. Dat had dus blijkbaar met die latencies te maken.

Let wel. Bovenstaande anekdote is ondertussen ongeveer 15 jaar geleden. Toen bestond unbound nog niet eens volgens mij :) De verschillen zullen tegenwoordig allicht anders zijn. De latency op onze particuliere internetlijnen en netwerkkaarten zijn echt veel lager geworden en de processors die wij in onze 'servers' hebben zijn ook vele malen sneller dan vroeger.
Zelf heb ik twee pi-holes met Unbound in mijn netwerk draaien. Als ik de DNS Speed Benchmark van Steve Gibson draai ( dan zie ik juist dat mijn pi-holes + Unbound echt ontzettend veel sneller zijn dan alle publieke DNS-servers. Omgekeerde ervaring dus!

Ook als je geen Unbound hebt draaien is DNSBench een handige tool om te zien welke DNS-servers je moet instellen voor de snelste reactietijden in jouw situatie.
Ik heb dezelfde ervaring als @ultramarine
Ik ben verre van een expert in de materie, maar met de info op kan je probleemloos Unbound installeren. Ondertussen gebruik ik Unbound al een goede 6 maand en heb nog nooit problemen ondervonden. Niet twijfelen!
Klopt! Die handleiding is inderdaad goed.

Iedereen bedankt voor de input.
Ik heb vandaag unbound aangezet op allebei mijn Piholes.

Ik merk geen verschil in snelheid bij het laden van pagina's. Tenminste, als er al verschil is (positief of negatief) dan is het dermate klein dat het me niet opvalt :)

Ik merk wel hetzelfde als @Tiimmeh : in de apt-repository staat versie 1.9.0-2+deb10u. Maar dat zal hopelijk ook wel een keer goed komen.
Mooie updates de laatste tijd, zou graag een bump willen naar deze versie op mijn PiHole. Iemand een idee hoe je dit kan updaten op een PiHole? Volgens apt zit ik al op de recentste versie, maar dat is 1.9.0-2+deb10u2..
ik heb dit installed(ook na een apt-get update):
unbound/oldstable,now 1.6.0-3+deb9u2 armhf [installed]

Heb al zitten zoeken, maar zie niet echt een makkelijke manier om te upgraden. Waarom vindt apt-get geen nieuwere versie?
Dat ligt aan het operating system dat je draait - deb9u2 lijkt bvb Raspian Stretch te zijn?
Die is ondertussen best oud en heeft ook een oude versie van Unbound package...

Voor @Tiimmeh : dat is inderdaad de laatste versie die Buster meegeeft, je kan dat omzeilen door ofwel zelf to compilen ofwel even een Frankenbuild te maken door te faken dat je Bullseye draait ipv Buster (maar dat wordt typisch niet aangeraden). versie 1.10.1-1 is beschikbaar via een backport
Dat kan kloppen ja. Heb er al lang niet meer naar omgekeken.
Zal binnenkort eens kijken of ik hem kan updaten naar wat nieuws. Heb nu een Pi4 met ubuntu 20,04 in de meterkast liggen. Wellicht dat ik daar PiHole en unbound maar op ga zetten.
Daar ben ik ook benieuwd naar, de laatste keer dat ik het probeerde te updaten, was ik gelijk afgesloten - gelukkig heb ik in zo'n geval nog een reserve sd liggen, maar het zorgt er wel voor dat ik terughoudend ben met het updaten van Unbound.

Het zou mooier zijn als er een soort commando als "Pihole -up" bestond.

Op dit item kan niet meer gereageerd worden.

Google Pixel 7 Sony WH-1000XM5 Apple iPhone 14 Samsung Galaxy Watch5, 44mm Sonic Frontiers Samsung Galaxy Z Fold4 Insta360 X3 Nintendo Switch Lite

Tweakers is samen met Hardware Info, AutoTrack,, Nationale Vacaturebank, Intermediair en Independer onderdeel van DPG Media B.V.
Alle rechten voorbehouden © 1998 - 2022 Hosting door True

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.


Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details


    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details