Verhuizen met DNSSEC : IETF-methode heeft de voorkeur
Onlangs organiseerde hosting provider Oxilion op haar kantoor een Lunch & Learn bijeenkomst. Daarbij sprak een aantal DNS -specialisten, zowel intern als extern, over de verhuizing van DNSSEC-beveiligde domeinen.
De probleemstelling was al snel duidelijk: het overzetten van een ondertekend domein van de ene naar een andere DNS-operator zonder de bescherming te verbreken, vereist sowieso samenwerking tussen de latende en verkrijgende operator. Dat impliceert ook de medewerking van de latende operator, ondanks dat deze het betreffende domein en misschien wel de hele klant verliest. Hoewel beide partijen in principe zonder problemen informatie uit zouden kunnen wisselen, zal dat in de praktijk niet altijd zonder problemen verlopen.
Twee methoden
Uitgangspunten bij het overzetten van een domein zijn dat een beveiligde naam tijdens de verhuizing steeds beveiligd moet blijven, dat deze te allen tijde moet blijven functioneren, en dat de betrokken DNS-operators geen private sleutels zullen uitwisselen.
Dan blijken er tot nog toe twee methoden bekend te zijn waarmee een domein van de ene naar de andere operator kan worden overgezet:
- De IETF-methode:
Bij deze methode, bedacht bij SIDN, wordt voorafgaand aan de verhuizing de oude ZSK in de nieuwe zone bij de nieuwe DNS-operator met een nieuwe KSK gesigneerd. Vervolgens wordt in de zone bij de oude DNS-operator de nieuwe ZSK meegenomen en gesigneerd met de oude KSK. Op dat moment vindt de administratieve verhuizing plaats (registrar change), waarop de nieuwe KSK (DS) naar SIDN wordt gestuurd, zodat ook de nieuwe zone gevalideerd kan worden. Na het verlopen van de TTL van de oude key set (een potentiële showstopper) kan een DNS operator change (NS change) plaatsvinden. Na het wachten van de TTL op de oude NS set (een vaste waarde) kan de oude KSK (DS) bij SIDN verwijderd worden. En na het afwachten van de TTL van de oude DS records (een vaste waarde) kan de nieuwe ZSK uit de oude zone verwijderd worden.
Voordelen:
- Het proces is duidelijk beschreven en kan volledig geautomatiseerd worden.
- Het bericht waarin de nieuwe ZSK wordt aangeboden kan door middel van een token geautoriseerd worden.
- De latende registrar hoeft niet zelf DNS-operator te zijn voor volledige ondersteuning.
- Het lijkt implementeerbaar voor meerdere registries/TLD's.
Nadelen:
- Het aantal stappen is relatief hoog.
- Er dient een TTL van een oude KEY set afgewacht te worden. Wanneer deze erg hoog is, zal de verhuizing praktisch onmogelijk uitgevoerd kunnen worden met behoud van volledig beveiliging.
- Het ICANN-alternatief:
Bij deze methode wordt voorafgaand aan de DNS operator change de nieuwe KSK (DS) bij SIDN aan de Domeinnaam toegevoegd. Het domein is dan nog geregistreerd bij de oude registrar en maakt nog steeds gebruik van de oude name servers. Na het afwachten van de TTL op de DS records (een vaste waarde van twee uur) zal de verkrijgende DNS-operator de volledige oude zone binnen moeten halen. Dit zou kunnen via AXFR en de registry zou hierin als proxy kunnen fungeren. Het voordeel daarvan is dat de DNS-operators onderling makkelijk afspraken kunnen maken. Het nadeel is echter dat je een behoorlijke lijst met ACL's moet gaan bijhouden. Daarna wordt de nieuwe ZSK toegevoegd aan de zone en wordt de RRSet gesigneerd met de nieuwe KSK. Vervolgens wordt de zone gesigneerd met de nieuwe ZSK maar worden de oude RRSIG's bewaard. Hierna vindt de DNS operator change plaats (name server change). Na verloop van TTL van de parent NS (een vaste waarde) zullen de validerende name servers de nieuwe zone aanspreken om te valideren. Daarbij kunnen de oude records ook nog steeds gevalideerd worden omdat de oude RRSIG's bewaard zijn.
Voordelen:
- Het proces is relatief eenvoudig en in weinig stappen af te ronden.
- Er hoeft geen TTL afgewacht te worden die niet door de ontvangende registry bepaald wordt. Hierdoor is de waarde van de TTL die je moet wachten altijd vooraf bekend, en is het proces binnen acceptabele tijd af te ronden.
Nadelen:
- Er dient een volledige zone transfer uitgevoerd te worden van de oude naar de nieuwe DNS-operator. Dit zou via AXFR opengezet kunnen worden, waardoor het te automatiseren is. Het is echter niet vanzelfsprekend dat een groot deel van de DNS-operators zal meewerken aan het openzetten van AXFR naar een registy of de verkrijgende DNS-operator.
- De timing wordt erg kritisch: de oude RRSIG records hebben een bepaalde geldigheidsperiode. Wanneer deze verloopt gaat DNSSEC mogelijk bogus.
- Gedurende de verhuizing (vanaf het moment van de zone transfer) mag er niets meer gewijzigd worden aan de oude zone zonder dat de nieuwe DNS-operator deze informatie ook krijgt.
Consensus
Na het afwegen van de voor- en nadelen is de groep tot de consensus gekomen dat bij het ICANN-alternatief de enige werkbare oplossing zou zijn om het te kunnen automatiseren middels AXFR. Men is echter van mening dat dit in de praktijk niet zal gaan gebeuren. Verder ziet de groep in de IETF-methode een goede mogelijkheid tot implementatie binnen SIDN en meerdere registries. Het probleem in de IETF-methode met betrekking tot de TTL kan niet met een technische maatregel worden opgelost, maar bijvoorbeeld wel een procedurele maatregel. Zo zou SIDN kunnen eisen van een DNS-operator dat deze een acceptabele (lees: niet te hoge) TTL hanteert voor DNSKEY-informatie in de zone. De groep is tot de conclusie gekomen dat de voorkeur uitgaat naar het gebruik van de IETF-methode en adviseren SIDN dan ook dit mee te nemen in verdere ontwikkelingen. Daarbij moet gezegd worden dat het registrars onderling vrij staat om het ICANN-alternatief in de praktijk wel te gebruiken.
