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.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 Google+

Submitter: jpgview

Bron: NLnet Labs

Update-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.)
Jouw keuze natuurlijk om Cloudflare meer te vertrouwen dan de root-server operators. Persoonlijk vind ik dat iedereen een echte DNS server thuis zou moeten hebben (en dus niet een veredelde stub-resolver als dnsmasq)

De enige reden om het niet te doen is als je niet geeft om de correctheid van de DNS informatie die je krijgt (je hebt geen controle over DNSSEC als je het een ander laat doen, en die kan andere afwegingen maken) en het belangrijkste is het gebruiken van interne machines. Dus als je niet een naam wil gebruiken voor je lokale NAS/printer/sabnzb/whatever die je bereikt met een RFC1918 IP adres (als je IPv6 gebruikt is het natuurlijk wel ok als je "echte" adressen hebt), dan is het niet nodig.

Als je dat wel wilt is de veiligste manier om die namen/adressen in je lokale config te gooien, om RFC1918 adressen in publieke DNS te zetten geeft weer attackmogelijkheden. Lokale DNS resolving for the win!

Persoonlijk vind ik het ook gewoon leuk om m'n DNS kennis op peil te houden, maar dat is tweaker gedrag :)

TLDR;
>Je moet een stukje software/hardware(?) in de lucht houden en goed geconfigureerd houden
Voor een resolver triviaal
>Je moet een stukje software vertrouwen
Zowel voor je eigen DNS server als een andere server. Met code-signing is het voor open-source software eigenlijk bijna nooit een probleem.
> Het kan trager zijn
Het kan ook sneller zijn.. hangt van je caching instellingen af. Maar het is zo dat er minder personen zijn die de cache vullen dan bij je ISP/cloudprovider. Feit is dat de resolving server dichter bij is als je het lokaal draait en dus lagere latencies mogelijk maakt dan ergens anders.
>Je ISP kan (aldanniet bewust) redelijk simpel je DNS-queries manipuleren
je ISP is de baas over jouw verbinding. Als er iets aangepast wordt moet dat breed uitgemeten worden in de media nieuw of anderszins
>De DNS-root servers kunnen jou(w IP adres) volgen
De bedrijven die root servers onderhouden zijn niet bezig in de reclamewereld en hebben dus veel minder reden om foute dingen te doen met jouw data. Daarnaast kan je nog query minimization toepassen waardoor de root alleen weet welke TLD je zoekt, die paar keer dat de TLD nog niet in de cache zit. Je komt een stuk minder vaak bij de root servers dan je denkt.


Laatste opmerking, unbound is een geweldig stukje software van Nederlandse bodem. Iets om trots op te zijn!

[Reactie gewijzigd door mediumdry op 19 juni 2019 13:05]

`quote` (want ik weet niet hoe ik tekst van een andere gebruiker moet aanhalen)
De enige toegevoegde waarde van PiHole zou dan de GUI zijn
`/qoute`

Met regexex, voor zover ik weet alleen in pihole-FTL, hou ik met een paar regular expressions een heleboel troep tegen. Hier vind je een paar regular expressions die er werkelijk toe doen. Zelf heb ik uit deze reddit post ook nog de facebook en AMP expressions toegevoegd. Lijkt mij redelijk toegevoegde waarde.

`quote`
Misschien is dat naïef, maar Cloudflare heeft een core business die gebaseerd is op vertrouwen
`/quote`
Ik vertrouw de grote spelers niet. If You're Not Paying For It, You Become The Product. Als het even kan, geen google, geen facebook, geen cloudflare, enz…

Er zijn nog redenen om het niet met je eens te zijn, maar goed, iedereen doet wat hij / zij wil, it's a free world.

Mijn laatste pihole + unbound topic bied een oplossing voor ongefilterde DNS, door gebruik te maken van de locale unbound implementatie. Veel gebruikers, die voor b.v. de vrouw "unfiltered DNS" moeten toelaten gebruiken dan maar google of OpenDNS als alternatief voor de gefilterde (pihole) oplossing.
Deze oplossing laat je (een deel) van je privacy behouden, zonder al je data aan de grote spelers cadeau te doen.
Ik sta op het punt om thuis mijn router te vervangen door een pfSense box, en dnscrypt-proxy met Cloudfare DNS over HTTPS lijkt daar een mooie toevoeging op. Bedankt! :)

Op dit item kan niet meer gereageerd worden.


OnePlus 7 Pro (8GB intern) Nintendo Switch Lite LG OLED C9 Google Pixel 3a XL FIFA 19 Samsung Galaxy S10 Sony PlayStation 5 Wetenschap

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank, Intermediair en Independer de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2019 Hosting door True