12 februari 2015
Aandachtspunten bij de configuratie van PowerDNS voor DNSSEC
PowerDNS is de meest gebruikte autoritatieve/administratieve DNS -server bij registrars die in bulk hun domeinen ondertekenen. Naar aanleiding van de ervaringen bij die implementaties heeft hoofdontwikkelaar Bert Hubert al eerder een aantal tips op een rijtje gezet. Hieronder voegen we daar nog drie recente aandachtspunten aan toe:
- Na elke mutatie aan een zone file moet je niet vergeten de 'pdnssec rectify-zone' opdracht uit te voeren. Deze zorgt ervoor dat de meta-informatie benodigd voor het aanmaken van de digitale handtekeningen (RRSIG-records) ook wordt aangepast.
PowerDNS slaat DNSSEC-specifiek materiaal zo veel mogelijk op in aparte tabellen, zodat beheerders het zicht op de DNS-records niet verliezen. Wijzigingen in de zone file hebben echter niet alleen gevolgen voor de handtekeningen voor de betreffende record sets, maar bijvoorbeeld ook voor de NSEC(3)-records.
Voor 'hidden masters' (administratieve servers) is het vanaf PowerDNS versie 3.4.0 niet meer nodig om een rectify-zone uit te voeren. Volgens Marco Davids, Technisch Adviseur bij SIDN, is het vergeten van de rectify-zone-opdracht een van de meest voorkomende fouten van dit moment. - Tot halverwege 2013 was NSEC3 opt-out de default-instelling in PowerDNS. RFC 5155 (sectie 12.2) raadt het gebruik daarvan echter af.
De NSEC3 opt-out was bedoeld voor zones met een heleboel niet-beveiligde delegaties (typisch voor TLD-beheerders). Zij konden die delegaties buiten beschouwing laten bij het genereren van de NSEC3-records. Nadeel is dat kwaadwillenden via een onveilige delegatie informatie aan de zone toe zouden kunnen voegen zonder dat dit cryptografisch gedetecteerd kan worden.
Hoewel die default-instelling van PowerDNS alweer een poos geleden is aangepast, blijken er nog steeds aardig wat oudere PowerDNS-installaties te zijn waarvoor nooit meer naar de NSEC3 opt-out optie is gekeken. - Tenslotte is het aan te raden om gelijk ook naar de NSEC3-instellingen voor 'iterations' en 'salt' te kijken. Die staan default ingesteld op respectievelijk '1' en 'ab'. Andere instellingen hiervoor kunnen het voor een aanvaller veel moeilijker maken om de NSEC3 hash-waarden te kraken. Kraken wil in dit geval zeggen: achterhalen welke domeinnamen wel en niet bestaan.
De 'iterations'-parameter bepaalt hoe vaak het hash-algoritme (recursief, d.w.z. op zichzelf) herhaald wordt, om op die manier het grootschalig uitrekenen ervan te vertragen. Een hoog aantal iteraties vraagt echter ook meer rekenkracht aan server- en client-zijde. In sectie 5.3.2 van RFC 6781 wordt een waarde van 100 gegeven als een goede trade-off tussen veiligheid en performance.
De 'salt'-parameter is een string die voor het hashen aan de Domeinnaam (FQDN) wordt toegevoegd en daarmee dictionary-aanvallen bemoeilijkt en de inzet van rainbow-tabellen.
RFC 6781 sectie 5.3.3 raadt aan de 'salt'-parameter regelmatig te vervangen — bij voorkeur bij het rollen van het ZSK-sleutelpaar, want dan moeten alle handtekeningen (RRSIG-records) sowieso opnieuw gegenereerd worden. Het achterliggende idee is dat een aanvaller door het veranderen van het 'salt' gedwongen wordt opnieuw te beginnen met het genereren van zijn tabellen. Dit heeft echter alleen zin bij zones waarvan de namen snel veranderen. Anders kan een aanvaller eenmaal gevonden namen immers hergebruiken om snel een tabel voor het nieuwe 'salt' te genereren.
Specifiek voor PowerDNS-gebruikers is het veranderen van de 'salt'-parameter sowieso minder relevant omdat PowerDNS geen geautomatiseerde key roll-overs doet.
Voor het aanpassen van de NSEC3 paramaters gebruik je het volgende commando:pdnssec set-nsec3 example.nl '1 0 100 DEADBEEF'
waarbij de tweede parameter (0) de NSEC3 opt-out vlag bevat.
