Software-update: PowerDNS Recursor 4.4.3

PowerDNS is een dns-server met een database als backend, waardoor het beheer van een groot aantal dns-entries op een gemakkelijke manier kan plaatsvinden. De ontwikkelaars hebben eerder besloten om de twee delen waaruit PowerDNS bestaat, een recursor en een authoritative nameserver, apart uit te geven, waardoor sneller en gerichter een nieuwe versie kan worden uitgebracht, aldus de ontwikkelaars.

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. De ontwikkelaars hebben PowerDNS Recursor 4.4.3 uitgebracht. De aankondiging van deze uitgave ziet er als volgt uit:

PowerDNS Recursor 4.4.3 Released

Today we are releasing PowerDNS Recursor 4.4.3.

This release fixes a bug where corrupted Newly Discovered Domain files could crash the recursor on startup and a bug where the wrong TTL could be used when inserting records into the packet cache. Additionally, a few minor DNSSEC related issues were fixed.

As usual, there were also other smaller enhancements and bugfixes. Please refer to the 4.4.3 changelog for details.

The 4.4.3 tarball (signature) is available at downloads.powerdns.com and packages for several distributions are available from repo.powerdns.com.

4.1 and older releases are EOL, refer to the documentation for details about our release cycles.

Please send us all feedback and issues you might have via the mailing list, or in case of a bug, via GitHub.

-Otto and the PowerDNS Team

Improvements

• Use a short-lived NSEC3 hashes cache for denial validation.

Bug Fixes

• More fail-safe handling of Newly Discovered Domain files.
• Handle policy (if needed) after postresolve.
• Return current rcode instead of 0 if there are no CNAME records to follow.
• Lookup DS entries before CNAME entries.
• Handle failure to start the web server more gracefully.
• Test that we correctly cap the answer’s TTL in expanded wildcard cases.
• Fix the gathering of denial proof for wildcard-expanded answers.
• Make sure we take the right minimum for the packet cache TTL data in the SERVFAIL case.

misc

• Pull in libfstrm for el8 build.

Versienummer	4.4.3
Releasestatus	Final
Besturingssystemen	Linux, BSD, macOS, Solaris, UNIX
Website	PowerDNS
Download	https://downloads.powerdns.com/
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (7)

[Theone098]

De echte nerd weet natuurlijk dat je dan een split-horizon DNS implementatie wilt doen. Tenminste, als je wilt dat de buitenwereld niet weet wat er allemaal in jouw netwerk draait.

Oh ja, en je moet vooral veel tijd over hebben. Ik heb al heel lang een eigen domein maar de DNS server laat ik door mijn provider doen (beheer het wel zelf).

[GertMenkel]

Ik heb zelf PowerDNS in gebruik voor een paar domeinen, eigenlijk is het gewoon onderhoudsvrij. Versio heeft geen competente API om een specifiek record te updaten dus ik besloot zelf PowerDNS te runnen. Kostte wat tijd om op te zetten, maar sindsdien draait het echt als een trein.

Ik heb een tijd split DNS gedraaid, maar dat werd op een gegeven moment zo'n bende van gecachede records die niet klopten en DNS-servers die in de war raakten, dat ik dat opgegeven heb. Ik heb nog wat subdomeinen in mijn pihole staan, maar dat is ook wel het enige nu. Jammer genoeg gaat dat wel ten koste van DNSSEC...

[Jerie]

Jammer genoeg gaat dat wel ten koste van DNSSEC...

Waarom? LE + wildcard zou moeten werken. Ik gebruik zelf LE voor de hostname van mijn externe IPv4/IPv6 en WireGuard, daardoor loopt al het verkeer via statisch toegewezen IPs. Het maakt dan niet uit waar de devices fysiek uithangen.

Vroeger (zo'n kleine 18 jaar geleden) gebruikte ik in mijn huis-LAN split horizon. Eerst met Djbdns, daarna met PowerDNS. Momenteel maak ik geen gebruik meer van split horizon (plus de Pi-Hole draait wat anders dan PowerDNS). Er is maar 1 publiek externe hostname (en die DNS besteed ik gratis uit), en immers weet ik gezien WireGuard precies welk statische IP adres bij welke device hoort. In ssh_config staan wel legio aliasen ed. Nginx reverse proxy en wat IPT/PF rules doet de rest.

Bij bijv mijn vorige baan was dit alles gezien omvang wel handig geweest maar je zou ook hosts file (of ssh_config) in git kunnen dumpen. Voor mij was dat niet nodig omdat ik SSH forwarding proxy gebruikte, had ik aan 1 ssh_config genoeg.

Bovendien kun je met Dnsmsq ook statische hostnames assignen aan IPs die via DHCP worden uitgegeven. Dus ik mis op huis-LAN de noodzaak. Wil je persé een recursor of split horizon dan heeft PowerDNS, hoewel geschreven in C, een betere track record dan BIND, zelfs BIND 9. Voor alleen LAN is de attack surface hoe dan ook laag.

[StGermain]

Waarvoor zou je dit als privépersoon gebruiken?

[Trousercough]

Als je niet afhankelijk wil zijn van de DNS servers van grote partijen, zoals bijvoorbeeld je ISP.
Ik heb zelf bijvoorbeeld een pihole installatie lopen die vervolgens via Rebound zijn dns verzoeken doet.
Zo houd je zelf de meeste controle over hoe deze lookups gaan.

[goldrnr]

Als je een beetje tech-savvy (lees nerd) bent en het leuk vindt om zelf thuis een domeintje te hebben met al je apperatuur etc netjes in dns (en dan wel dynamisch via dhcp toegevoegd of zo).
Dan is het best interessant om dit of met isc-bind of powerdns te doen.

Of de recursor ook echt met een database werkt weet ik niet, ik weet dat Nominum ooit bind 9 had herschreven en gesplitst in een authoratief deel en een recursing/caching deel waarbij het authoratief deel inderdaad een database had voor makkelijke en in-service aanpassingen aan de content en de configuratie terwijl het recursive deel juist vanwege performance helemaal in memory draaide en een relatief kleine configuratie file kende waarin je kon bepalen hoe de recursive lookups moesten worden
geforward en beantwoord.

Je kunt de recursor ook wel vergelijken met een pi-hole of er mee combineren zelfs

Dus als je een beetje interesse hebt in techniek ipv rgb-lampjes dan is dit wel een topic voor mensen thuis

[GertMenkel]

Ik zou persoonlijk geen BIND draaien als je domein niet heel groot is, PowerDNS is een stuk vriendelijker. Is ook wat makkelijker te automatiseren, wat wel handig is voor bijvoorbeeld wildcard certificates van let's encrypt.

Een eigen recurser heeft voor je privacy zijn voor- en nadelen. Aan de ene kant stuur je zo niet je hele browse-geschiedenis door naar je provider/Google/Cloudflare, aan de andere kant kan je ISP nog prima zien welke namen jij opvraagt aangezien DNS onversleuteld is; je kunt het risico verplaatsen door de recurser ergens in de cloud te hangen en dan met iets als DNS over TLS of DNS over HTTPS of gewoon DNS over een VPN het verkeer te versleutelen; dan moet je alleen wel zo'n server en setup willen hebben.

Daarnaast loop je op die manier her risico dat websites je echte IP vinden als je een VPN gebruikt, omdat je DNS-server niet per se door die VPN loopt terwijl je PC dat wel doet, en websites gewoon het IP van de resolver kunnen vinden. Als je Cloudflare of Google gebruikt, kan je DNS-verkeer altijd via hun servers en dus de VPN, en weet de DNS-server van de websites die je bezoekt niet zo precies wie jij bent.

Het is best interessant om je eigen recurser te draaien, maar als je het doet, val je wel op, wat een van de slechtste dingen is die je kan overkomen als je om je privacy geeft.