Kies jouw kleur

Veel bezocht

Veelgestelde vragen

  • 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.

Meer veelgestelde vragen

Verouderd IPv4-gebaseerd internet ongeschikt voor peer-to-peer toepassingen

NAT bederft spelbeleving

  • maandag 4 februari 2019

Hoewel NAT (Network Address Translation) ons heeft geholpen om het gebruik van IPv4 flink te rekken, hebben we met de grootschalige inzet van deze technologie onszelf tegelijkertijd in de voet geschoten. Omdat je computer nu geen uniek IP-adres meer heeft, is deze voor de buitenwereld onbereikbaar geworden. Voor peer-to-peer toepassingen resulteert dat zelfs met nieuwe workarounds als STUN, TURN en ICE in vertragingen en verbindingen die vaak helemaal niet meer tot stand willen komen.

Hoewel sommigen nog betogen dat IPv6 een oplossing is voor een probleem dat zich nooit heeft voorgedaan — namelijk het opraken van de IPv4-adressen — zitten wij daar heel anders in: de IPv4-adressen zijn namelijk allang op. Dat ons internet nog niet krakend en piepend tot stilstand is gekomen, hebben we vooral te danken aan technische workarounds. De meest bekende daarvan is Network Address Translation (NAT), waarbij een heleboel gebruikers via één gedeeld IPv4-adres het internet op gaan.

Met NAT en aanverwante lapmiddelen hebben we weliswaar ons acute probleem opgelost, maar onszelf tegelijkertijd in de voet geschoten. De internetaansluiting die de meeste gebruikers nu hebben biedt namelijk geen volwaardig internet zoals dat ontworpen en bedoeld is. Omdat je computer geen uniek IP-adres meer heeft, is deze voor de buitenwereld onbereikbaar geworden. Met Carrier-Grade NAT (CGNAT), een cascade van meerdere NAT-lagen, is dit probleem nog veel groter geworden.

STUN

Zolang je zelf verbindingen initieert, typisch naar een web- of mailserver, is het geen probleem dat je eigen computer niet direct bereikbaar is vanaf internet. Maar voor real-time toepassingen als internettelefonie (VoIP), instant messaging en multi-player games moeten de deelnemers direct (dat wil zeggen: zonder vertraging) UDP-datapakketten naar elkaar kunnen versturen. Heeft een van de twee geen IPv6, dan moet dat noodgedwongen over IPv4. En zit je zoals vrijwel alle IPv4-gebruikers op een NAT-netwerk, dan kan dat niet zonder de hulp van een speciale STUN-server (Session Traversal Utilities for NAT). Deze wordt door de ene client gebruikt om zijn eigen externe IP-adres/poortnummer te achterhalen, waarna die informatie via het sessiebeheer/signaling-protocol van de betreffende applicatie met de andere client wordt gedeeld.

Zitten beide clients achter NAT, dan wordt het al gauw heel ingewikkeld, en worden afhankelijk van de tussenliggende NAT-technieken verschillende strategieën gevolgd (NAT traversal) om de twee peers toch met elkaar te kunnen laten praten. Wat je hier als gebruiker vooral van merkt is dat het vaak gewoon niet meer lukt om een goede verbinding tot stand te brengen. Wie is er niet bekend met de VoIP- en WebRTC-sessies waarbij beeld en/of geluid maar in één richting werkt en onmogelijk volledig aan de praat te krijgen is? Wat daar misgaat is dat onderliggende dataverbindingen (meestal gebaseerd op RTP) niet tot stand kunnen worden gebracht.

TURN en ICE

Als uiterste redmiddel kan voor dit soort gevallen een TURN-server (Traversal Using Relays around NAT) worden ingeschakeld. Zoals de naam al aangeeft fungeert deze server als relay tussen de twee peers. Dat betekent dat multimedia-data door de ene client naar de TURN-server wordt verstuurd, zodat de andere client die informatie daar weer op kan halen. Hier wordt het probleem van peers die elkaar niet kunnen bereiken dus opgelost door een aparte internetserver (uiteraard wel voorzien van een uniek IPv4-adres) als tussenschakel te gebruiken.

Het nadeel van TURN is dat elke verbinding eigen resources (databuffers) nodig heeft op de server, en dat de relay veel, gecentraliseerde bandbreedte vraagt. Dat maakt deze oplossing duur en moeilijk schaalbaar. Bovendien levert de extra tussenstap vertraging op, iets dat je juist wilt voorkomen bij real-time toepassingen.

Het ICE-protocol (Interactive Connectivity Establishment) tenslotte is weer ontwikkeld om zo veel mogelijk te voorkomen dat je moet terugvallen op een TURN-server. Daartoe worden achtereenvolgens verschillende methoden en transportadressen (IP-adres/poortnummer) geprobeerd om twee peers met elkaar te verbinden. Alleen als het echt niet anders lukt fungeert TURN als laatste fallback.

Multi-player games

Niet voor niets hamert ook Microsoft op het belang van IPv6. De multi-player games op hun Xbox consoles werken immers het snelst (en het goedkoopst) als deelnemers via IPv6 direct met elkaar kunnen communiceren. Een extra relay in de vorm van een TURN-server gaat ten koste van de real-time interactie tussen spelers, en dat bederft de spelbeleving.