Nuttige aanbevelingen voor operators van DNSSEC-validerende resolvers

Een groot gedeelte van deze Draft gaat over het beheer van de trust anchors voor DNSSEC, zowel de gewone als de negatieve trust anchors (NTA's). Reden is dat validatieproblemen volgens de auteurs vaker veroorzaakt worden door operators (zowel van resolvers als van nameservers) en bugs dan door aanvallen.

Systeemtijd

Maar de Draft trapt af met het belang van de juiste systeemtijd. We hebben het belang daarvan voor DNSSEC (en andere beveiligingsprotocollen) in detail uitgelegd in een eerder verschenen artikel. Specifiek voor DNSSEC geldt dat de digitale handtekeningen (in de RRSIG-records) een (absolute) geldigheidsduur hebben. Dat betekent dat deze niet gevalideerd kunnen worden als de systeemtijd niet juist ingesteld is.

Dat is vooral een probleem bij apparaten zonder eigen Real-Time Clock (RTC) – denk maar aan de Raspberry Pi. Dergelijke apparaatjes moeten elke keer na het opstarten (via het netwerk) de juiste tijd ophalen (middels NTP/NTS [1, 2]).

De enige werkbare oplossing is automatisering middels NTP/NTS, maar dan blijf je met het bootstrap-probleem zitten. Bij het opstarten moet de juiste tijd van internet opgehaald worden, maar op dat moment kunnen de digitale handtekeningen nog niet gevalideerd worden (de systeemtijd staat dan misschien wel op 1 januari 1970).

Dat betekent dat je moet kiezen uit 2 kwaden: of een hard IP-adres gebruiken of een niet-gevalideerde call naar een NTP-server doen. In ieder geval mag (kan) een validerende resolver niet opstarten voordat de juiste systeemtijd beschikbaar is. Behalve dat actuele handtekeningen dan niet willen valideren, zou een aanvaller bijvoorbeeld ook een replay-aanval kunnen uitvoeren, waarbij verlopen handtekeningen opnieuw worden ingezet.

Naast deze initialisatie-problematiek moet de operator ook daarna regelmatig blijven checken of de systeemtijd niet (te veel) afwijkt.

DNSSEC trust anchors

Net als bij de systeemtijd speelt ook bij de initialisatie van het DNSSEC trust anchor (de publieke sleutel van de rootzone, die het beginpunt vormt van de DNSSEC chain of trust) een bootstrap-probleem. Hoewel er een uitgebreide procedure en tooling beschikbaar is om het trust anchor te downloaden van de IANA-website en te valideren, wordt deze vooral gebruikt door softwareontwikkelaars en packagers. Operators vertrouwen meestal op het trust anchor dat initieel in de software zelf is ingebakken of met het pakket wordt meegeleverd. Voordeel daarvan is dat je ervan uit mag gaan dat de trust anchors up-to-date zijn als de software dat is.

Bij de ingebruikname van een resolver dient de operator zich wel ervan te vergewissen dat het gebruikte trust anchor inderdaad het juiste is. De software zelf bevat echter ook vaak mechanismen om bij het opstarten de geldigheid van zijn initiële trust anchors te checken.

Installeer je nog aparte trust anchors, bijvoorbeeld voor gebruik binnen je eigen (niet publieke) domein example.home (een trust point dat niet onder de DNSSEC-boom valt), dan zul je voor de validatie daarvan ook zelf procedures op moeten zetten.

Automatische updates

Updates van het trust anchor (noodzakelijk bij de rollover van het root KSK-sleutelpaar zoals die in 2018 plaatsvond) verlopen inmiddels veelal automatisch via het mechanisme beschreven in RFC 5011. Daarbij wordt de nieuwe publieke sleutel binnengehaald als DNSKEY-record en gevalideerd via de bestaande (oude) DNSSEC-vertrouwensketen.

Hoewel updates volgens RFC 5011 volledig geautomatiseerd verlopen, moet de operator bij de configuratie wel verifiëren dat deze optie aan staat en dat de timing-parameters correct zijn ingesteld. Ook moet de operator regelmatig controleren of de gebruikte trust anchors inderdaad de juiste zijn. Dat laatste is vooral na een reboot van belang.

Het geautomatiseerde validatieproces voor initiële/nieuwe trust anchors levert een probleem op specifiek voor resolvers in containers: die zijn vaak niet lang genoeg in de lucht ("up") om het hele validatieproces (dat weken duurt) te kunnen doorlopen.

Check actuele trust anchors

Het checken van de actuele trust anchors kan meestal met een simpel commando of query naar de betreffende server. Voor de Unbound resolver gaat dat bijvoorbeeld als volgt:

[user@system ~]$ dig @127.0.0.1 trustanchor.unbound -c CH -t TXT +short
". 20326"

En voor BIND named kun je met onderstaand commando de actuele trust anchors dumpen:

rndc secroots

In de file '/var/named/data/named.secroots' tref je dan een overzicht als volgt aan:

secure roots as of 11-Mar-2023 18:12:41.458:

 Start view localhost_resolver
   Secure roots:

./RSASHA256/20326 ; managed

   Negative trust anchors:

 Start view internal
   Secure roots:

./RSASHA256/20326 ; managed

   Negative trust anchors:

 Start view external
   Secure roots:

./RSASHA256/20326 ; managed

   Negative trust anchors:

Daarnaast wordt de operator in deze Draft aangeraden om signalering volgens RFC 8145 aan te zetten. Daarmee kunnen de operators van de rootservers via de key id's van de actuele trust anchors de voortgang van rollovers volgen.

Vanzelfsprekend moeten logs gegenereerd worden van alle gebeurtenissen rondom de initialisatie van de resolver en het rollen van trust anchors, en moet er een alert gegenereerd worden als een initialisatie of rollover om wat voor reden dan ook mislukt is. Vooral de afwezigheid van het actuele trust anchor is een probleem, omdat daarbij valide, ondertekende domeinnamen niet meer geaccepteerd worden.

Negatieve trust anchors

Als de resolutie van een domein mislukt omdat aan de autoritatieve zijde iets mis is, kan een (tijdelijke) uitzondering voor validatie gemaakt worden door een negatief trust anchor aan de configuratie toe te voegen. Vanzelfsprekend moet wel eerst gecontroleerd worden of het inderdaad om een misconfiguratie gaat en niet om een aanval.

Hoewel de operator van een resolver niet verplicht is om te helpen problemen aan de zijde van autoritatieve nameservers op te lossen, wordt wel aangeraden om contact op te nemen alvorens een problematische domeinnaam als NTA toe te voegen (ook omdat het inderdaad om een aanval kan gaan). Automatisch toevoegen mag in geen geval!

Meestal gaat het bij configuratieproblemen om moeilijkheden met de ondertekening of de DNSKEY/DS-records, of om inconsistenties in de gebruikte ZSK/KSK-sleutelparen. Bij dat laatste (vaak veroorzaakt doordat bij een rollover de timing-perioden niet in acht worden genomen!) wordt vanwege de complexiteit aan autoritatieve zijde aangeraden om niet te proberen de problemen daarop te lossen (bijvoorbeeld door zelf op zoek te gaan naar valide DNSSEC-records). De operator van een resolver heeft in het algemeen immers geen enkele controle over configuratieproblemen bij de operator van een willekeurig domein. Vaak heeft hij niet eens een directe (out-of-band) ingang bij de beheerder van het betreffende domein.

Meer over NTA's lees je in RFC 7646.

Root KSK rollover

De relevantie van dit alles wordt de komende tijd veel groter, aangezien ICANN begin deze maand de voorbereidingen voor de volgende root KSK rollover in gang heeft gezet.

Daarnaast wordt ook gewerkt aan de overstap naar een nieuw cryptografisch algoritme. Research engineer bij SIDN Labs, Moritz Müller, is vorige maand benoemd als lid van het Root Zone Algorithm Rollover Study Design Team dat de plannen voor deze transitie moet ontwikkelen.

De overstap naar een nieuw cryptografisch algoritme staat zeer waarschijnlijk los van de komende "reguliere" rollover. Voor deze zomer wordt alleen een aanbeveling voor een nieuw algoritme verwacht.