Software-update: Unbound 1.19.0

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. Versie 1.19.0 is uitgebracht en hierin zijn de volgende veranderingen en verbeteringen aangebracht:

Features

• Fix #850: [FR] Ability to use specific database in Redis, with new redis-logical-db configuration option.
• Merge #944: Disable EDNS DO. Disable the EDNS DO flag in upstream requests. This can be helpful for devices that cannot handle DNSSEC information. But it should not be enabled otherwise, because that would stop DNSSEC validation. The DNSSEC validation would not work for Unbound itself, and also not for downstream users. Default is no. The option is disable-edns-do: no
• Expose the script filename in the Python module environment 'mod_env' instead of the config_file structure which includes the linked list of scripts in a multi Python module setup; fixes #79.
• Expose the configured listening and outgoing interfaces, if any, as a list of strings in the Python 'config_file' class instead of the current Swig object proxy; fixes #79.
• Mailing list patches from Daniel Gröber for DNS64 fallback to plain AAAA when no A record exists for synthesis, and minor DNS64 code refactoring for better readability.
• Merge #951: Cachedb no store. The cachedb-no-store: yes option is used to stop cachedb from writing messages to the backend storage. It reads messages when data is available from the backend. The default is no.

Bug Fixes

• Fix for version generation race condition that ignored changes.
• Fix #942: 1.18.0 libunbound DNS regression when built without OpenSSL.
• Fix for WKS call to getservbyname that creates allocation on exit in unit test by testing numbers first and testing from the services list later.
• Fix autoconf 2.69 warnings in configure.
• Fix #927: unbound 1.18.0 make test error. Fix make test without SHA1.
• Merge #931: Prevent warnings from -Wmissing-prototypes.
• Fix to scrub resource records of type A and AAAA that have an inappropriate size. They are removed from responses.
• Fix to move msgparse_rrset_remove_rr code to util/msgparse.c.
• Fix to add EDE text when RRs have been removed due to length.
• Fix to set ede match in unit test for rr length removal.
• Fix to print EDE text in readable form in output logs.
• Fix send of udp retries when ENOBUFS is returned. It stops looping and also waits for the condition to go away. Reported by Florian Obser.
• Fix authority zone answers for obscured DNAMEs and delegations.
• Merge #936: Check for c99 with autoconf versions prior to 2.70.
• Fix to remove two c99 notations.
• Fix rpz tcp-only action with rpz triggers nsdname and nsip.
• Fix misplaced comment.
• Merge #881: Generalise the proxy protocol code.
• Fix #946: Forwarder returns servfail on upstream response noerror no data.
• Fix edns subnet so that queries with a source prefix of zero cause the recursor send no edns subnet option to the upstream.
• Fix that printout of EDNS options shows the EDNS cookie option by name.
• Fix infinite loop when reading multiple lines of input on a broken remote control socket. Addesses #947 and #948.
• Fix #949: "could not create control compt".
• Fix that cachedb does not warn when serve-expired is disabled about use of serve-expired-reply-ttl and serve-expired-client-timeout.
• Fix for #949: Fix pythonmod/ubmodule-tst.py for Python 3.x.
• Better fix for infinite loop when reading multiple lines of input on a broken remote control socket, by treating a zero byte line the same as transmission end. Addesses #947 and #948.
• For multi Python module setups, clean previously parsed module functions in __main__'s dictionary, if any, so that only current module functions are registered.
• Fix #954: Inconsistent RPZ handling for A record returned along with CNAME.
• Fixes for the DNS64 patches.
• Update the dns64_lookup.rpl test for the DNS64 fallback patch.
• Merge #955 from buevsan: fix ipset wrong behavior.
• Update testdata/ipset.tdir test for ipset fix.
• Fix to print detailed errors when an SSL IO routine fails via SSL_get_error.
• Clearer configure text for missing protobuf-c development libraries.
• autoconf.
• Merge #930 from Stuart Henderson: add void to log_ident_revert_to_default declaration.
• Fix #941: dnscrypt doesn't work after upgrade to 1.18 with suggestion by dukeartem to also fix the udp_ancil with dnscrypt.
• Fix SSL compile failure for definition in log_crypto_err_io_code_arg.
• Fix SSL compile failure for other missing definitions in log_crypto_err_io_code_arg.
• Fix compilation without openssl, remove unused function warning.
• Mention flex and bison in README.md when building from repository source.

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

Reacties (12)

[vespino]

Gebruikt dit nu al een tijdje ipv Pi-hole: https://registry.hub.docker.com/r/klutchell/unbound

In m'n Docker dir heb ik een config "a-records.conf" met regels zoals de volgende om zo vervelende ads te blokkeren:

server:
local-zone:"protect-your-privacy.net" static
local-zone:"go2cloud.org" static
local-zone:"adk2x.com" static
etc.

En voor custom DNS records:

local-zone:"fqdn" redirect
local-data:"fqdn A x.x.x.x"

Gemiddeld 0.01% CPU load en 30mb geheugen.

[JeroenED]

Ik gebruik deze in combinatie met pihole. Mijn pihole doet zijn requests naar unbound. Unbound is niet gefilterd en kan eventueel direct gebruikt worden. Hierdoor heb je toch de privacy van de recursive resolver en de eenvoudige configuratie en caching van pihole.

[vespino]

"Unbound is niet gefilterd en kan eventueel direct gebruikt worden."

Wat bedoel je hier precies mee?

[JeroenED]

Bij mij staat unbound ingesteld op ip 192.168.1.43 en pihole op 192.168.1.42. In pihole heb ik ingesteld dat hij niet forward naar cloudflare of google, maar naar 192.168.1.43. Unbound doet dan z'n recursive DNS-lookup (Dus zonder google of cloudlfare die je kunnen tracken), geeft dat door aan pihole en pihole antwoord dan aan mij.

Unbound rechtsreeks gebruiken kan ook. Als ik mijn DNS-server instel op 192.168.1.43 kan ik alle domeinen ophalen (ongefilterd dus ook advertentiedomeinen). Wanneer is dit handig? vb. sommige apps sturen zoveel requests waardoor je blocked ratio op 0.0 staat omwille van al die lokale DNS-requests naar je database-service. Of ze komen de limiet tegen en blokkeert pihole al hun requests. Dit doe je uiteraard niet lichtzinnig.

Daarbovenop: pihole is bedoeld voor adblocking, unbound is bedoeld als DNS-resolver. Met jouw local-zone regels zeg gewoon dat protect-your-privacy.net lokaal staat en dan het domein zoekt op de 'verkeerde plek'.

[lenwar]

(Dus zonder google of cloudlfare die je kunnen tracken)

Dat is wel heel kort door de bocht. Cloudflare en Google beheersen het halve internet Maar goed. Ze kunnen in elk geval minder makkelijk je DNS-verkeer volgen.

Mijn voornaamste probleem met privé een DNS recursor gebruiken is dat men de root-server onnodig hard belast. "Stel dat" (het gaat nooit gebeuren, maar puur hypothetisch) 0,1% van de internetgebruikers dat zouden doen, dan liggen die root-servers plat. (Veel mensen reageren met 'Ja, maar unbound cachet'. Dat klopt. Dat doet dnsmasq ook. Sterker nog. Je computer/telefoon doet dat ook )

Wat in de praktijk voor mij ook een probleem is, is dat het DNS-verkeer niet versleuteld is. Stel dat je thuis een DoH server zou gebruiken (dus voor intern) en die via ODoH richitng Cloudflare of Google zou sturen, dan ben je beter afgeschermd. Niemand kan jouw DNS-verzoeken volgen of halverwege aanpassen, en het is nog versleuteld ook.

[rbr320]

Ik ben het totaal niet met je eens en zou zelfs het omgekeerde willen beweren: standaard DNS verkeer is helemaal niet zo belastend voor het internet als geheel en de DNS root servers in het bijzonder, omdat het om erg weinig data gaat dat over het UDP protocol wordt verstuurd. Mocht een van de root DNS servers een keer overbelast worden dan is het bij UDP een kwestie van wat pakketjes droppen en het probleem is opgelost. UDP is daarom zeer geschikt voor het type data dat door middel van DNS verzoeken wordt uitgewisseld.

DoT en DoH gaan (helaas) over het TCP protocol. Voor elke TCP verbinding moeten resources worden gereserveerd totdat de verbinding wordt gesloten of er een time-out is bereikt. Dat brengt een veel grotere belasting met zich mee dan bij UDP het geval is. Gelukkig wordt dit probleem een beetje binnen de perken gehouden omdat bij DoT en DoH "serialization" van de DNS verzoeken verplicht is, maar nog steeds is het een stuk minder efficient dan het gebruik van UDP voor dit type verkeer.

Om zeker te weten dat het antwoord dat je op een DNS verzoek krijgt klopt en er niet tussentijds mee is gerommeld hebben we DNSSEC. De data gaat nog steeds leesbaar over het netwerk, maar is wel met sleutels ondertekend zodat je zeker kunt zijn van de integriteit van de bron en het antwoord. Ik begrijp de wens om privacy maar persoonlijk ben ik geen fan van DoT of DoH. Als iedereen dat zou gaan gebruiken brengt dat volgens mij een veel grotere belasting voor de DNS infrastructuur met zich mee dan als iedereen een eigen recursive resolver zou gaan gebruiken. Bovendien heb ik liever dat mijn verzoeken worden verspreid over non-profit partijen die geen belang hebben bij het loggen van de verzoeken zoals ICANN en SIDN, dan dat commerciële partijen als Google en Cloudflare met nog meer data aan de haal gaan.

[RobertMe]

Veel mensen reageren met 'Ja, maar unbound cachet'. Dat klopt. Dat doet dnsmasq ook. Sterker nog. Je computer/telefoon doet dat ook

Ja maar... ook dat klopt niet. Ja, beide cachen. Maar Unbound zal ook de tussenliggende stuff cachen. Dus als die weet waar .com te vinden is zal die de volgende keer niet meer aan een root server vragen waar .com te vinden is. En als die weet waar tweakers.net te vinden is zal die direct aan de NS van tweakers.net vragen waar gathering.tweakers.net te vinden is. Terwijl dnsmasq of elke andere lokale caching DNS server alleen bv een A of AAAA van tweakers.net weet en om gathering.tweakers.net te resolven weer naar zijn upstream moet.

[vespino]

Ah duidelijk. Ik heb ervoor gekozen om Unbound dus direct te gebruiken, zonder tussenkomst van bijv. een Pi-hole. Ik heb de interface niet nodig en de default lijsten zijn onnodig uitgebreid. Bovendien verbruikt het zo net wat minder resources, ook al heeft Pi-hole ook geen superzware belasting natuurlijk.

De lijst die ik nu gebruik, gebruikte ik voorheen rechtstreeks op mijn router/firewall. Door nu Unbound direct te gebruiken, ontlast ik mijn router/firewall en mocht het nodig zijn, kan ik die laatste nog altijd direct/ongefilterd gebruiken.

[Jack Flushell]

En hele mooie stats!

[kiekerjan]

Waar is het plaatje bij dit artikel van? Zit er ergens in unbound een gui verstopt?

[EverLast2002]

Lijkt op een Grafana dashboard.
Unbound zelf heeft geen GUI.

[Toet3r]

Heb nu al tijdje 2x unbound draaien in docker containers in combinatie met pihole. Werkt perfect.