Ik zoek de houder van een domeinnaam. Waar vind ik die?
Via de Whois kun je de huidige houder van een domeinnaam opzoeken. Om de persoonsgegevens in te zien moet je vanwege de privacygevoelige informatie eerst de gebruikersvoorwaarden van de Whois accepteren. Gegevens van privé personen kunnen ook afgeschermd zijn vanwege de AVG (Algemene verordening gegevensbescherming).
Op de pagina domeinnaam zoeken lees je meer over wat een domeinnaam is, de werking van de Whois en de privacy van persoonsgegevens.
Ik wil mijn domeinnaam verhuizen. Hoe doe ik dat?
Je wilt je domeinnaam verhuizen naar een andere registrar. Vraag dan je verhuistoken op bij je huidige registrar. Lees de verhuisstappen op de pagina domeinnaam verhuizen.
Ik wil mijn contact/adresgegevens aanpassen bij mijn .nl-domeinnaam. Hoe doe ik dat?
Neem contact op met je registrar. Jouw registrar kan de contactgegevens bij je domeinnaam voor je aanpassen. Wij raden je aan het resultaat te controleren via de Whois. Lees meer over het aanpassen van je gegevens bij contactgegevens wijzigen.
Waarom staat mijn domeinnaam in quarantaine?
Wij weten niet wat de reden van de opheffing is. Neem contact op met je registrar. Het voordeel van de quarantaine is dat je altijd de mogelijkheid hebt om een opheffing die je niet had bedoeld te herstellen.
Voorbeeld: In de voorwaarden van je registrar staat dat je elk jaar je abonnement moet verlengen. Dat gebeurt dan niet automatisch. Zo kan het gebeuren dat je domeinnaam wordt opgeheven zonder dat je er om gevraagd hebt.
Ik heb een klacht over mijn provider/registrar. Kan ik daarvoor bij SIDN terecht?
Wanneer je een klacht hebt over of een geschil met je registrar dan zijn er verschillende mogelijkheden om tot een oplossing te komen. Hierover lees je meer op pagina klacht over registrar. SIDN heeft geen formele klachtenprocedure voor het behandelen van een klacht over jouw registrar.
Waaraan moet ik voldoen als registrar?
Wil je zelf direct domeinnamen kunnen registreren bij SIDN voor je klanten of voor je eigen organisatie? Dan kun je .nl-registrar worden. Lees meer over de voorwaarden en de manier waarop je je kunt inschrijven als registrar via de pagina registrar worden.
Nauwkeurige, beveiligde systeemtijd cruciaal voor DNSSEC – en andersom!
Nauwkeurige, beveiligde systeemtijd cruciaal voor DNSSEC – en andersom!
Werken aan een veiliger tijdsdienst
donderdag 6 februari 2020
Afgelopen zomer introduceerde SIDN Labs een publieke tijdsdienst. Op het adres ntp.time.nl draait een NTP-service die je kunt gebruiken om de klok op je systemen en apparaten gelijk te zetten. Een goedlopende klok is belangrijk voor legio toepassingen. Denk aan het timestampen van documenten, berichten en mail, maar ook aan de tijdsweergave in de foto's en video's die je maakt op je mobiele telefoon.
Voor veel security-toepassingen is een nauwkeurige en betrouwbare tijdsbepaling zelfs essentieel. Denk dan aan het aggregeren van de logs op je servers (bijvoorbeeld voor CGNAT), aan de videobeelden van beveiligingscamera's, en aan de geldigheidsduur van digitale handtekeningen. Gaat het specifiek om de RRSIG records die bij het gebruik van DNSSEC aan je DNS-records worden toegevoegd, dan vormt de systeemklok zelfs een interessant aanvalsdoel voor hackers.
Vrijwel alle met internet verbonden computers, maken al gebruik van een of meerdere NTP-servers. De maker van het besturingssysteem stelt meestal een default lijstje in. Maar ook DHCP heeft de mogelijkheid om een lijstje met time servers aan te reiken zodra een computer het netwerk op gaat.
Vaak onderhoudt de leverancier zelf een aantal NTP-servers, en anders kun je bij de NTP Pool terecht. Die laatste is een initiatief van de internetgemeenschap, inmiddels bestaande uit duizenden NTP-servers, waarin ook onze time service opgenomen is. Aandachtspunt daarbij is wel dat de Pool ook misbruikt wordt door partijen die uitsluitend NTP-servers toevoegen om IPv6-adressen te verzamelen, om die systemen vervolgens te scannen [1, 2].
server 0.nl.pool.ntp.org
server 1.nl.pool.ntp.org
server 2.nl.pool.ntp.org
server 3.nl.pool.ntp.org
De beheerders van de Pool zorgen dat deze namen elk uur naar andere servers in de pool wijzen, om zo de last over de beschikbare systemen te verdelen. "Onze dienst trekt inmiddels zo'n 4.600 gebruikers per 5 minuten," vertelt Marco Davids, research engineer bij SIDN Labs. "Het grootste gedeelte van dat verkeer is nu nog afkomstig van de NTP Pool. Maar ook Cloudflare gebruikt onze service om zijn klanten in deze regio van stratum 1 NTP te voorzien. En ook de NLNOG RING is een gebruiker van onze dienst."
De nationale NTP-dienst
Zit je (netwerktechnisch gesproken) in de buurt van Arnhem – waar SIDN gevestigd is en ook de bulk van onze infrastructuur draait – dan raadt Davids je aan om de NTP-server direct te gebruiken (in combinatie met nog een paar andere NTP-servers). "Op de website van TimeNL vind je ook informatie om onze NTP-service in je computer in te stellen." Daarbij benadrukt hij dat dit zeker geen experimentele dienst is. "TimeNL is robuust opgezet en absoluut productiewaardig. Dit jaar willen we deze dienst nog betrouwbaarder maken door meerdere servers toe te voegen. Daarnaast zijn we in goed contact met VSL, de beheerder van de officiële Nederlandse atoomtijd, om te zien hoe we elkaar kunnen versterken. We willen TimeNL echt neerzetten als "de nationale NTP-dienst", net zoals diverse andere landen al zo'n dienst hebben."
Omdat TimeNL ook fungeert als onderzoeksproject voor SIDN Labs, wordt ondertussen druk verder gebouwd aan deze service. Zo is er vorige maand ook een (experimentele) NTS-server in de lucht gebracht. Waar een man-in-the-middle relatief makkelijk de onversleutelde UDP netwerkpakketten zoals gebruikt door NTP kan vervalsen of het afzenderadres kan vervangen (spoofen), voegt NTS (Network Time Security) TLS-authenticatie en NTP parameter negotiation toe. Omdat dat via een side channel gebeurt, weten client en server wel van elkaar wie ze zijn, maar wordt de snelle NTP-over-UDP uitwisseling zo min mogelijk vertraagd door cryptografie en tunneling. Op dit moment bevindt het NTS-protocol zich echter nog in de ontwikkelingsfase.
De klok verzet
Hoe belangrijk het hebben van een juiste systeemtijd is, blijkt uit het aantal internet-(beveiligings)protocollen dat met absolute tijdsaanduidingen werkt. Hieronder zie je bijvoorbeeld het huidige DNSSEC RRSIG record voor onze eigen website (via IPv4). Daarin staan duidelijk de begin- en eindtijd tot op de seconde nauwkeurig aangegeven.
sidn.nl. 3600 IN RRSIG A 8 2 3600 20200216081059 20200117081059
42033 sidn.nl. WHuezZNN0KPIgQdM1cGqBg+0HiJA0/hT5VnaDlo1puf++s0oFrnClJJr...
Weet een kwaadwillende de klok van een autoritatieve DNS-server of een validerende resolver te verzetten, dan kan hij proberen verlopen handtekeningen, ongeldig sleutelmateriaal, oude kwetsbaarheden en verouderde configuraties te misbruiken. Zo zou hij oude (ondertekende!) DNS-antwoorden opnieuw kunnen injecteren in een gecombineerde replay en cache poisoning aanval, waardoor gebruikers van de betreffende resolver omgeleid worden naar een IP-adres dat inmiddels in bezit van iemand anders is. In dit paper kun je lezen hoe bestaande kwetsbaarheden in NTP- en resolver-implementaties en -configuraties concreet gebruikt kunnen worden om records opgeslagen in de resolver cache eerder te laten verwijderen of juist langer te bewaren.
Gekraakt
Misschien weet een aanvaller zelfs een van de historische encryptie-algoritmen voor DNSSEC (hier bij IANA) te misbruiken, daarbij gebruikmakend van het feit dat het SHA-1 hash-algoritme inmiddels definitief gekraakt is.
Een andere mogelijkheid is het vergroten van de tijdsperiode (window of opportunity) die een aanvaller heeft om een brute-force aanval uit te voeren. Om de benodigde cryptografische verwerkingskracht met name op mobiele apparaten beperkt te houden, kiezen we bij de ondertekening van onze DNS-records meestal voor een beperkte lengte van de ZSK-sleutelparen. Dat compenseren we dan weer door de geldigheidsduur van de digitale handtekeningen kort te houden en de ZSK-sleutelparen snel te rollen. Door de systeemtijd te veranderen kan een aanvaller deze balans wellicht in zijn voordeel laten omslaan.
Het DNSSEC bootstrap probleem
Een van de onderliggende oorzaken is het DNSSEC bootstrap probleem: hoe weet een systeem dat nog helemaal geen tijdsinstelling heeft gekregen (en dan misschien op 1 januari 1970 begint te tellen) of de binnengekregen DNSSEC-handtekeningen geldig zijn? Bovendien is dit een snel groter wordend probleem naarmate er meer IoT devices aan het internet gehangen worden. Vanwege de kosten hebben die meestal geen Real-Time Clock (RTC) chip en batterij aan boord. Waar de NTP-software een eenmaal ingestelde systeemtijd op een volwaardige server kan beschermen door geen al te grote aanpassingen toe te staan, zijn kleine devices zonder RTC kwetsbaar na elke reboot.
Daarmee is het DNSSEC bootstrap probleem fundamenteel niet anders dan het probleem om het eerste DNSSEC trust anchor aan boord van een validerende resolver te krijgen. Daar hebben we dat opgelost door een uitgebreide procedure voor het downloaden en valideren ervan (niet cryptografisch waterdicht maar in redelijkheid) op te zetten. Het RFC 5011 mechanisme voor het updaten vanaf een bestaand trust anchor zou je dan kunnen vergelijken met de hierboven beschreven beveiligingsmaatregel waarbij NTP bij updates voortbouwt op de huidige systeemtijd door al te grote aanpassingen te negeren.
