Software-update: Unbound 1.22.0

Als je een DNS-lookup uitvoert, begint een recursor in eerste instantie met het stellen van de lookupvraag 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 lookup 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.22 is uitgebracht en hierin zijn de volgende veranderingen en verbeteringen aangebracht:

Features

• Add iter-scrub-ns, iter-scrub-cname and max-global-quota configuration options.
• Merge patch to fix for glue that is outside of zone, with `harden-unverified-glue`, from Karthik Umashankar (Microsoft). Enabling this option protects the Unbound resolver against bad glue, that is unverified out of zone glue, by resolving them. It uses the records as last resort if there is no other working glue.
• Add redis-command-timeout: 20 and redis-connect-timeout: 200, that can set the timeout separately for commands and the connection set up to the redis server. If they are not specified, the redis-timeout value is used.
• Fix #1144: [FR] log timestamps in ISO8601 format with timezone. This adds the option `log-time-iso: yes` that logs in ISO8601 format.
• Merge #871: DNS over QUIC. This adds `quic-port: 853` and `quic-size: 8m` that enable dnsoverquic, and the counters `num.query.quic` and `mem.quic` in the statistics output. The feature needs to be enabled by compiling with libngtcp2, with `--with-libngtcp2=path` and libngtcp2 needs openssl+quic, pass that with `--with-ssl=path` to compile unbound as well.

Bug Fixes

• Fix #1126: unbound-control-setup hangs while testing for openssl presence starting from version 1.21.0.
• Add cross platform freebsd, openbsd and netbsd to github ci.
• Fix for char signedness warnings on NetBSD.
• Fix #1127: error: "memory exhausted" when defining more than 9994 local-zones.
• Fix documentation for cache_fill_missing function.
• Fix #1130: Loads of logs: "validation failure: key for validation <domain>. is marked as invalid because of a previous" for non-DNSSEC signed zone.
• Fix that when rpz is applied the message does not get picked up by the validator. That stops validation failures for the message.
• Fix that stub-zone and forward-zone clauses do not exhaust memory for long content.
• Unit test for auth zone transfer TLS, and TLS failure.
• Fix to print port number in logs for auth zone transfer activities.
• Merge #1132: b.root renumbering.
• Fix for #1132, adjusted unit test for change in the test file.
• Fix for #1132, comment about adjusted copy of reference check.
• Merge #1135: Add new IANA trust anchor.
• Fix config file read for dnstap-sample-rate.
• Fix alloc-size and calloc-transposed-args compiler warnings.
• Fix comment to not trigger doxygen unknown command.
• Fix to limit NSEC and NSEC3 TTL when aggressive nsec is enabled (RFC9077).
• Add unit test for ttl limit for aggressive nsec.
• Fix and add comments in testdata/val_negcache_ttl.rpl.
• Merge #1140: Fix spelling mistake in comments.
• Fix doxygen warnings by commenting out CLANG_ASSISTED_PARSING, CLANG_ADD_INC_PATHS, CLANG_OPTIONS and CLANG_DATABASE_PATH; they were already disabled.
• Fix dns64 with prefetch that the prefetch is stored in cache.
• Attempt to further fix doh_downstream_buffer_size.tdir flakiness.
• More clear text for prefetch and minimal-responses in the unbound.conf man page.
• Merge #1143: Fix cache update when serve expired is used. Expired records are favored over resolution and validation failures when serve-expired is used.
• Fix negative cache NSEC3 parameter compares for zero length NSEC3 salt.
• Fix unbound dnstap socket test program analyzer warnings about unused variable assignments and variable initialization.
• Fix #1149: unbound-control-setup hangs sometimes depending on the openssl version.
• Fix #1128: Cannot override tcp-upstream and tls-upstream with forward-tcp-upstream and forward-tls-upstream.
• Fix to limit NSEC TTL for messages from cachedb. Fix to limit the prefetch ttl for messages after a CNAME with short TTL.
• Fix for dnstap compile of doqclient with doq disabled.
• Fix cookie_file test sporadic fails for time change during the test.
• Fix add reallocarray to alloc stats unit test, and disable override of strdup in unbound-host, and the result of config get option is freed properly.
• Fix to disable detection of quic configured ports when quic is not compiled in.
• Fix harden-unverified-glue for AAAA cache_fill_missing lookups.
• Fix contrib/aaaa-filter-iterator.patch for change in call signature for cache_fill_missing.
• Fix to display warning if quic-port is set but dnsoverquic is not enabled when compiled.
• Fix dnsoverquic to extend the number of streams when one is closed.
• Fix for dnstap with dnscrypt and dnstap without dnsoverquic.
• Fix for dnsoverquic and dnstap to use the correct dnstap environment.

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

Reacties (25)

[BasHouse]

Zou iemand mij kunnen vertellen waarom ik dit op mijn Windows 11 computer zou installeren?

Als je een DNS-lookup uitvoert, begint een recursor in eerste instantie met het stellen van de lookupvraag 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 lookup 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

Hier kom ik niet veel verder mee. Ja ik snap wat een DNS-recursor doet, maar wat moet ik daarmee op m'n pc?

[RobertMe]

Op je PC is het waarschijnlijk niet heel nuttig. Normaliter zou je dit in je netwerk draaien, hetzelfde als bv een PiHole of AdGuard Home (waarbij Unbound ook vaker gebruikt wordt als upstream server van een van deze twee. Terwijl Unbound an zich ook wel iets met blocklists kan, alleen niet zo fancy als PiHole of ADG, en zelf gebruik ik het ook als dusdanig, alleen Unbound, met blocklists, zonder PiHole / ADG). Reden om Unbound te draaien daarbij is dat je geen gebruik meer hoeft te maken van 1 specifieke DNS server. Als Ziggo klant (bv) gaat standaard al je DNS verkeer naar Ziggo, en kan Ziggo dus alle DNS verkeer inzien en dus weten welke websites je bezoekt (kan, geen idee of ze het doen). En hetzelfde geldt dan voor andere DNS servers die je gebruikt, Cloudflare, Google DNS, ..., allemaal kunnen ze inzien welke DNS queries je doet. Met Unbound is er echter niet 1 partij die kan inzien welke DNS queries je doet. De root DNS servers zien alleen dat je opvraagt "Waar vind ik .net?" of "Waar vind ik .nl?" zonder te weten welk specifiek domein je zoekt. Terwijl de .net server alleen ziet "Waar vind ik tweakers.net?", zonder te weten welke queries je stuurt naar de .nl server. En de DNS server van Tweakers ziet vervolgens uiteraard alleen "Waar vindt ik gathering.tweakers.net" of "Wat is het AAAA record van tweakers.net?". Terwijl als je de DNS server van je ISP gebruikt, of Cloudflare, of Google DNS, of..., dan zien die elke keer "wat is het AAAA record van gathering.tweakers.net?" + "Wat is het AAAA record van google.com" + .... Terwijl je met Unbound als je dat lokaal draait alleen Unbound hebt die "alles" weet.

En daarnaast kan Unbound ook weer caching doen. Iets wat de lokale DNS client (Windows bv) ook wel doet. Maar met Unbound lokaal op je netwerk heb je uiteraard 1 cache voor het hele netwerk. En als je nu op een PC "tweakers.net" bezoekt en de TTL van dat antwoord is 1 uur, en over 30 minuten kijk je op de telefoon op "tweakers.net" dan heeft Unbound het antwoord al lokaal. Iets dat voor DNS van de ISP / Cloudflare / ... uiteraard ook geldt, alleen heb je dan net dat beetje latency naar hun servers, en lever je mogelijk iets van privacy in. Waarbij Unbound ook weer geconfigureerd kan worden om prefetching te doen. Als die ziet dat er elke 5 minuten een query binnen komt voor "tweakers.net" en de lokale TTL is bv nog maar 1 minuut dan zal die alvast een nieuwe query naar de upstream doen, zodat als de volgende query binnen komt die alweer een antwoord klaar heeft staan dat niet "verlopen" is.

[BasHouse]

Ok, naja ik heb die AdGuard Home al jaren draaien op een rpi. Helemaal super.

[rbr320]

In dat geval zou je best op dezelfde Raspberry Pi Unbound kunnen installeren en instellen als de upstream DNS server, in plaats van de DNS server die AdGuard Home nu op de achtergrond gebruikt. Hiermee win je iets aan privacy en het is nauwelijks moeite of extra risico. Ik heb zelf Pi-Hole + Unbound op een Raspberry Pi 3 draaien en dat tweemaal zodat ik een backup DNS server in mijn netwerk heb.

[lodu]

Niet, windows computers zijn niet stabiel genoeg over het algemeen.

Maar zoals @Sharky zegt, wordt bijvoorbeeld gebruikt voor het blokkeren van bepaalde DNS queries (zoals advertentieservers).

Unbound wordt gebruikt door veel software zoals: Pi-Hole en OPNsense (firewall/router software).

Overigens doet Unbound ook DNS forwarding, niet alleen recursie.

[Reactie gewijzigd door lodu op 17 oktober 2024 16:14]

[SubSpace]

Niet stabiel genoeg? Raar argument
Ik zou ook niet zo snel Windows draaien als nameserver, tenzij het een domain controller is, maar met stabiliteit heeft dat niks te maken.

[lodu]

Een desktop computer die je actief gebruikt moet je nou eenmaal af en toe opnieuw opstarten, updaten en kan ook gewoon crashen.

Kans dat dus je resolver eruit ligt is vele malen groter.

[xxs]

Mijn pihole met unbound praat met de openbare DOH server van Mullvad. Mullvad draait alles in geheugen en geen logging op disks. Alle queries dus encrypted over de lijn.

Iemand die daar op wil schieten waarom dit wel of juist geen goed idee is?

https://mullvad.net/en/help/dns-over-https-and-dns-over-tls

[Reactie gewijzigd door xxs op 17 oktober 2024 16:58]

[johnnyquid]

Thanks voor de tip!

[xxs]

Je unbound.conf ziet er dan zo uit:


# Unbound configuration file for Debian.
#
# See the unbound.conf(5) man page.
#
# See /usr/share/doc/unbound/examples/unbound.conf for a commented
# reference config file.
#
# The following line includes additional configuration files from the
# /etc/unbound/unbound.conf.d directory.
include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"

server:
tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt"

forward-zone:
name: "."
forward-tls-upstream: yes # use DNS-over-TLS forwarder
forward-first: no # do NOT send direct
forward-addr: 194.242.2.2@853#dns.mullvad.net

Of een Mullvad server naar keuze met extra blocking of zo.

Unbound op een pihole installeren:
https://docs.pi-hole.net/guides/dns/unbound/

[RobertMe]

Wat is het nut van DoT / DoH als je het verkeer ogenschijnlijk al over de Mullvad VPN stuurt? Enige risico zit dan of in je eigen netwerk (van Unbound naar de VPN client) en van de Mullvad server naar de Mullvad DNS server. En in beide gevallen zullen de problemen "groter" zijn als daar iemand kan meekijken. En het verkeer dat bij jou de router/het modem verlaat is dus al encrypted doordat het over de VPN gaat. Lijkt mij persoonlijk dus niet heel nuttig?

* RobertMe heeft zelf dan weer wel Unbound achter een VPN draaien. Dus Unbound die over een VPN naar buiten gaat. En een DNS leak test komt dan ook uit op de VPN server en niet op mijn IP of zo. Enige wat het gebruik van de DNS van de VPN provider zou toevoegen is dat misschien het verkeer nog iets anoniemer is als de VPN aanbieder maar een (/aantal) DNS servers heeft waardoor het verkeer vanaf verschillende VPN servers v.w.b. DNS weer op een grote hoop wordt gegooid (maar waarschijnlijker lijkt mij dat elke VPN server ook een forwarding DNS server draait). Risico is dan weer dat als de VPN server niet kan verbinden met die ene/enkele DNS server dat er dus geen werkende DNS is.

Edit:
Even getest. Op mijn telefoon direct verbonden met de VPN aanbieder via hun app en de test op dnsleaktest.com gedaan => IP adres matcht dat van de VPN server (dus hetzelfde IP als een willekeurige "wat is mijn IP adres" site).
Vervolgens de VPN verbroken, verbonden met mijn wifi netwerk dat over VPN naar buiten gaat, zelfde test gedaan, en hetzelfde resultaat. IP adres van de DNS leak test komt overeen met het IP adres van ds VPN server / dat elke "wat is mijn IP" site laat zien.
Voor mij zou het v.w.b. IP adres(sen) dat (andere) DNS servers zien dus niet uit maken of ik puur Unbound over de VPN naar internet laat gaan en laat "recursive resolven" of dat ik alles forward naar de DNS van de VPN boer. En het gebruik van DoH / DoT zou dan ook niks toevoegen, gezien de DNS server (ogenschijnlijk) op de VPN server draait en dus via een local socket kan/zal gaan en het verkeer dus alleen gesnift kan worden door iemand die al (root) toegang tot de server zou hebben.

[Reactie gewijzigd door RobertMe op 17 oktober 2024 17:47]

[xxs]

Dank je voor je feedback, maar je doet de aanname dat de rest van mijn verkeer over een VPN gaat.

Wat als dat niet zo is? Dan worden op mijn manier de DNS queries wel encrypted en niet meer leesbaar dan wanneer je Unbound rechtstreeks met de root servers laat praten. Stel dat je in een 'sleepnetje' komt dan zijn normale queries via unbound leesbaar, echter niet als je via DOH/DOT gaat.

[RobertMe]

Ik had schijnbaar niet goed gelezen en dacht "192.???.2.2" oftewel een intern adres, met dus het idee dat het de DNS server over een tunnel zou zijn. Van de VPN provider die ik gebruik weet ik ook niet of die de DNS server publiekelijk aanbieden.

[xxs]

Je kan in jouw setup ook nog steeds Mullvad gebruiken, jouw eigen VPN tunnel met weet ik veel en over die tunnel gaan dan de DOH/DOT DNS queries via Mullvad.

En dat is exact wel mijn setup maar ik wilde e.e.a. uitelkaar trekken om verwarring te voorkomen.

[Reactie gewijzigd door xxs op 17 oktober 2024 18:21]

[Sharky]

Dit is met name leuk voor enthousiastelingen die hun lokale netwerk volledig onder controle willen hebben. Dus bijvoorbeeld in combinatie met een reverse proxy om van buitenaf een eigen server te benaderen, pihole (of adguard) voor het blokkeren van dns-verzoeken naar advertentienetwerken en unbound voor dns. Dit installeer je niet op een lokale pc maar op een server of nas op je lokale netwerk. De meesten zullen dit denk ik als Docker draaien.

[bytemaster460]

Is ook een stuk privacy. I.p.v. een publieke DNS-server gebruik je je eigen DNS-server met een eigen cache. Je DNS-verzoeken gaan dus niet constant via dezelfde DNS-server.

[Prince]

Lompe vraag misschien, maar wat is dat dashboard op de screenshot? Standaard is dit toch gewoon een DNS service (port 53) en geen webinterface... is dit een plugin, ander pakket,...?

[[Thomas]]

Ziet er uit als een Grafana dashboard met wat stats uit unbound.

[Prince]

ok, maar het is niet dat ze een kant en klaar docker image oid hebben met dit erbij?

[lodu]

https://github.com/jianershi/docker-unbound-grafana

Deze ziet er wel redelijk uit als je het mij vraagt.

[[Thomas]]

Nee, dit komt standaard niet als een bundel of een enkele container, Grafana heeft wel zijn eigen docker container maar daar zul je dan zelf nog een Prometheus database onder moeten hangen (kan ook met Docker) en Prometheus de Unbound stats laten scrapen van een losse Prometheus exporter voor Unbound.

Als je al een hele Grafana/Prometheus setup hebt is dit super handig, maar als dit je enige use-case is is dit zwaar overkill.

Unbound heeft zelf ook in de documentatie nog wat andere opties voor monitoring: https://unbound.docs.nlne...pics/core/monitoring.html

Grafana getting started met Prometheus: https://grafana.com/docs/...arted-grafana-prometheus/
let op, deze handleiding gaat uit dat je grafana.com gebruikt, maar dit kan ook een zelf gehoste Grafana zijn

Prometheus exporter voor Unbound: https://github.com/letsencrypt/unbound_exporter

[Jopandrik]

Ik gebruik Unbound versie 1.17.1 o.b.v. Debian(Proxmox). Dat is wat Debian betreft de laatste versie.
Ik heb Unbound 1.22 inmiddels gecompileerd (gcc) en gebuild, maar verder durf ik deze nieuwe versie van Unbound (make) net te installeren omdat ik geen inzicht heb hoe ik de oude versie moet deïnstalleren.

Wie kan me verder helpen.
Alvast bedankt,

[fuzzyduck]

Dan maak je in proxmox toch gewoon een snapshot of backup van je lxc? Lekker prutsen en als je faalt(zoals ik best wel eens doe ) dan zet je die terug.

Edit.. ik lees dat je hem native draait? Misschien handiger om hem te verplaatsen naar een container

[Reactie gewijzigd door fuzzyduck op 17 oktober 2024 22:54]

[Jopandrik]

Ik draai Unbound samen met PiHole in een lxc container. Unbound heb ik met "apt install unbound" geïnstalleerd. Ik ga wel wat proberen en begin met "apt remove unbound".
Maak wel eerst een snapshot.

@fuzzyduck : bedankt voor je reactie

[lodu]

verkeerd geplaatst, moest hier

[Reactie gewijzigd door lodu op 17 oktober 2024 16:13]