Cookies op Tweakers

Tweakers is onderdeel van DPG Media en maakt gebruik van cookies, JavaScript en vergelijkbare technologie om je onder andere een optimale gebruikerservaring te bieden. Ook kan Tweakers hierdoor het gedrag van bezoekers vastleggen en analyseren. Door gebruik te maken van deze website, of door op 'Cookies accepteren' 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.9.2

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 versie 1.9.2 uitgebracht met de volgende veranderingen:

Features
  • add type CAA to libpyunbound (accessing libunbound from python).
  • Fix #17: Add python module example from Jan Janak, that is a plugin for the Unbound DNS resolver to resolve DNS records in multicast DNS [RFC 6762] via Avahi. The plugin communicates with Avahi via DBus. The comment section at the beginning of the file contains detailed documentation.
  • travis build file.
  • PR #16: XoT support, AXFR over TLS, turn it on with master: <ip>#<authname> in unbound.conf. This uses TLS to download the AXFR (or IXFR).
Bug Fixes
  • Fix for #4233: guard use of NDEBUG, so that it can be passed in CFLAGS into configure.
  • Add log message, at verbosity 4, that says the query is encrypted with TLS, if that is enabled for the query.
  • Fix #4239: set NOTIMPL when deny-any is enabled, for RFC8482.
  • Fix #4240: Fix whitespace cleanup in example.conf.
  • Fix that tls-session-ticket-keys: "" on its own in unbound.conf disables the tls session ticker key calls into the OpenSSL API.
  • Fix crash if tls-servic-pem not filled in when necessary.
  • Fix auth-zone NSEC3 response for empty nonterminals with exact match nsec3 records.
  • Fix for out of bounds integers, thanks to OSTIF audit. It is in allocation debug code.
  • Fix for auth zone nsec3 ent fix for wildcard nodata.
  • Move goto label in answer_from_cache to the end of the function where it is more visible.
  • Fix auth-zone NSEC3 response for wildcard nodata answers, include the closest encloser in the answer.
  • Fix spelling error in log output for event method.
  • Fix to reinit event structure for accepted TCP (and TLS) sockets.
  • Fix to use event_assign with libevent for thread-safety.
  • verbose information about auth zone lookup process, also lookup start, timeout and fail.
  • Fix to wipe ssl ticket keys from memory with explicit_bzero, if available.
  • Fix that auth zone uses correct network type for sockets for SOA serial probes. This fixes that probes fail because earlier probe addresses are unreachable.
  • Fix that auth zone fails over to next master for timeout in tcp.
  • Squelch SSL read and write connection reset by peer and broken pipe messages. Verbosity 2 and higher enables them.
  • Update python documentation for init_standard().
  • Typos.
  • Fix tls write event for read state change to re-call SSL_write and not resume the TLS handshake.
  • Better braces in if statement in TCP fastopen code.
  • iana portlist updated.
  • Scrub RRs from answer section when reusing NXDOMAIN message for subdomain answers.
  • For harden-below-nxdomain: do not consider a name to be non-exitent when message contains a CNAME record.
  • Fix wrong query name in local zone redirect answers with a CNAME, the copy of the local alias is in unpacked form.
  • contrib/fastrpz.patch updated for code changes, and with git diff.
  • Fix #29: Solaris 11.3 and missing symbols be64toh, htobe64.
  • Fix #30: AddressSanitizer finding in lookup3.c. This sets the hash function to use a slower but better auditable code that does not read beyond array boundaries. This makes code better security checkable, and is better for security. It is fixed to be slower, but not read outside of the array.
  • Fix edns-subnet locks, in error cases the lock was not unlocked.
  • Fix doxygen output error on readme markdown vignettes.
  • Squelch log messages from tcp send about connection reset by peer. They can be enabled with verbosity at higher values for diagnosing network connectivity issues.
  • Attempt to fix malformed tcp response.
  • Fix #31: swig 4.0 and python module.
  • Note that so-reuseport at extreme load is better turned off, otherwise queries are not distributed evenly, on Linux 4.4.x.
  • Fix that spoolbuf is not used to store tcp pipelined response between mesh send and callback end.
  • Fix double file close in tcp pipelined response code.
  • Fix to define _OPENBSD_SOURCE to get reallocarray on NetBSD.
  • Fix to guard _OPENBSD_SOURCE from redefinition.
  • Fix that fixes the Fix that spoolbuf is not used to store tcp pipelined response between mesh send and callback end, this fixes error cases that did not use the correct spoolbuf.
  • Fix another spoolbuf storage code point, in prefetch.
Versienummer 1.9.2
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 Japke Rosink

Meukposter

19-06-2019 • 09:43

4 Linkedin

Submitter: jpgview

Bron: NLnet Labs

Update-historie

Meer historie

Reacties (4)

Wijzig sortering
Ik heb zelf altijd gemengde gevoelens bij het zelf draaien van een eigen DNS-server/DNS-recursor. Even los van het 'het is leuk/geeky/etc, want dat kan op zich natuurlijk al voldoende reden zijn natuurlijk. Maar als je het puur objectief bekijkt, dus zonder de fun/geeky factor vind ik het voor thuisgebruik niet echt zinvol.

Je hebt een aantal voors:
- Je bent niet afhankelijk van de uptime van een andere partij (de DNS servers van je ISP of een derde partij als Cloudflare, Google of OpenDNS of wat dan ook)
- Een derde partij kan geen logboeken bijhouden van welke DNS-queries jij doet (je ISP kan dit nog wel door domweg UDP-verkeer in de gaten te houden. Hier kom ik later op terug)
- Een derde partij kan 'gehacked' zijn en jou dus verkeerde informatie terugsturen (dus dat je DENKT dat je bij de echte tweakers.net aan het lezen bent, maar stiekem op een derde site die zo jouw login-gegevens binnenharkt. Dit kan, mits goed geconfigureerd en afgedwongen met behulp van DNSSEC worden beperkt.
- Als de name servers van die derde partij HEEL rot zijn, dan kan caching een voordeel zijn, maar dat zal in de praktijk minimaal zijn.
- Het kan sneller zij als je derde partij een hele rotte DNS-server heeft (verderop mijn persoonlijke ervaring hieromtrent)

Er zijn ook een aantal tegens:
- Je moet een stukje software/hardware(?) in de lucht houden en goed geconfigureerd houden
- Je moet een stukje software vertrouwen (wie zegt dat er geen malafide code in zit. Geen enkel stuk software is gegarandeerd veilig, en niet veel mensen hebben de knowhow om dat goed te verifieren)
- Het kan trager zijn (aangezien alle kleine queries nu over jouw eigen internetlijntje gaan en veelal op kleine computertjes draaien (raspberry pi's/NAS'en), en niet direct vanaf een groot data centre met betere/sneller hardware en internetlijnen (sneller, lagere latency, enz.)
- Je ISP kan nog steeds als je DNS-queries volgen (want het is allemaal UDP verkeer)
- Je ISP kan (aldanniet bewust) redelijk simpel je DNS-queries manipuleren. Dit kan met DNSSEC deels worden afgevangen, maar niet volledig.
- De DNS-root servers kunnen jou(w IP adres) volgen (anders volgen ze alleen je ISP/derde partij, wat een stuk minder persoonlijk is)


Persoonlijk ben ik van mening dat de voors niet opwegen tegen de tegens. Zelf gebruik ik de DNS-servers van Cloudflare in combinatie met dnscrypt-proxy (DNS over HTTPS protocol). Dit is uiteraard ook een stukje software die in de lucht gehouden moet worden en je moet vertrouwen (het draait op mijn Unify routertje, dus in elk geval geen extra hardware)

Persoonlijk vertrouw ik de Cloudflare DNS diensten volledig. Misschien is dat naïef, maar Cloudflare heeft een core business die gebaseerd is op vertrouwen, stabiliteit en snelheid (ze verkopen in elk geval geen gepersonaliseerde advertenties e.d.). Doordat alles via DoH verloopt ziet mijn ISP niet de inhoud van mijn DNS-verzoeken voorbij komen. (tussen mijn netwerk en Cloudflare is alles versleuteld).
Cloudflare handelt voor mij de DNS-verzoeken af met een gigantische cacheopslag/snelheid enz.

Ik heb een tijdje terug, toen ik zelf een DNS-recursor in m'n netwerkje gehad en deed toen een benchmark (die doet een hele vracht DNS-verzoeken naar alles en nogwat). Wat bleek. Mijn eigen recursortje was velen malen trager dan bijvoorbeeld Google/OpenDNS en Cloudflare (uit m'n hoofd was het toen een factor 15 à 20 trager ofzo). Toen ik de boel om had gezet naar OpenDNS viel het mij dan ook direct op dat de boel sneller was (uiteraard niet in bandbreedte maar wel in reactietijden. Het voelde 'kwieker') maar dat kon natuurlijk een placebo-effect zijn, omdat m'n benchmarkjes dat zeiden.

Toen m'n vrouw een paar uur later thuis kwam, vroeg ze na een paar minuten ineens uit zichzelf "Heb je iets met het internet gedaan ofzo? Hij is sneller!" (ze had uiteraard geen idee dat ik met internet bezig was)
Sindsdien heb ik de boel omgezet naar Cloudflare omdat Cloudflare zowel dnscrypt als DNSSEC ondersteund (OpenDNS ondersteund alleen DoH). In benchmarks in Cloudflare ook iets sneller als OpenDNS, maar in de praktijk merk ik dat niet

Voetnoot: dnscrypt-proxy heeft voor mij ook PiHole vervangen. Het heeft weliswaar niet zo'n mooie web-interface, maar wel ook een blacklist/whitelist van domeinen die automatisch wordt bijgewerkt. PiHole kan verder bijna hetzelfde maar ondersteund vooralsnog geen DNSCrypt/DoH. (In de PiHole documentatie staat hoe je dnscrypt-proxy er tussen moet zetten, maar dat maakt eigenlijk heel PiHole alleen maar een extra schakel, dus die had ik er toen maar tussenuit gehaald. De enige toegevoegde waarde van PiHole zou dan de GUI zijn.)

Op dit item kan niet meer gereageerd worden.


Nintendo Switch (OLED model) Apple iPhone 13 LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S21 5G Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Nintendo Switch Lite

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