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

DNS-foutrapportage van resolvers naar autoritatieve nameservers

RFC 9567 definieert mechanisme voor geautomatiseerde foutmeldingen

Envelopjes die door een virtuele pijplijn gevormd door enen en nullen vliegen.
  • donderdag 19 september 2024

DNS-informatie loopt traditioneel alleen van de autoritatieve nameservers naar de cachende resolvers en de eindgebruikers. In geval van problemen – denk bijvoorbeeld aan verlopen DNSSEC-handtekeningen – kon een beheerder alleen per mail, telefoon of sociale media op de hoogte worden gebracht.

RFC 9567 implementeert nu voor het eerst een mechanisme waarbij resolvers foutmeldingen naar de nameservers kunnen sturen. Daarvoor maakt het nog steeds gebruik van de reguliere DNS-berichtenuitwisseling, waarbij foutinformatie nu in de query wordt verwerkt.

Tot nu toe had een autoritatieve nameserver geen mogelijkheid om meldingen uit de buitenwereld te ontvangen in geval van DNS-problemen. Een DNSSEC-validerende resolver die tegen een bogusdomeinnaam aanloopt, kan niets meer doen dan deze blokkeren voor de eindgebruiker. Zoals de naam al aangeeft, wordt de autoritatieve nameserver geacht volledig onafhankelijk van de downstream DNS-infrastructuur eigenstandig te zorgen voor een correct ondertekende zone.

Reguliere DNS-berichtenuitwisseling

RFC 9567 definieert een mechanisme waarmee resolvers (geautomatiseerd) problemen kunnen melden bij de operator van een autoritatieve nameserver. Dat begint bij de autoritatieve nameserver die een EDNS0/OPT-record van het type Report-Channel (optie 18) met zijn antwoorden meestuurt. Daarin staat een agentdomein aangegeven dat de resolver kan gebruiken om meldingen naartoe te sturen.

Het rapportagemechanisme maakt gebruik van de reguliere DNS-berichtenuitwisseling. Stel bijvoorbeeld dat de autoritatieve nameserver met zijn antwoorden voor het domein servfail.nl het agentdomein agent.example.nl meestuurt. Een resolver die het domein servfail.nl niet kan valideren, stuurt dan een query voor het TXT record-type naar deze geconstrueerde domeinnaam (QNAME):

_er.1.servfail.nl.7._er.agent.example.nl

De waarde 1 in deze naam geeft aan dat de melding het recordtype A betreft. Je vindt de volledige lijst hier bij IANA. De waarde 7 is het nummer van de foutmelding. Deze meldingen zijn gedefinieerd in RFC 8914. In dit geval gaat het dus om een verlopen handtekening ('Signature Expired').

Let op dat de eerste waarde na het '_er'-label komt en de tweede ervoor. Dit laatste om te voorkomen dat de meldingen interfereren met de reguliere adresruimte.

Bovendien mag het agentdomein natuurlijk niet onder hetzelfde domein vallen als het hoofddomein: in geval van problemen kan het agentdomein dan immers ook niet bereikt worden voor de foutmelding.

De agent

Op het agentadres draait een speciale (autoritatieve) DNS-server die alle binnenkomende meldingen (in de vorm van query’s zoals hierboven beschreven) verwerkt tot statistieken en waar nodig alerts genereert.

Bovendien stuurt de monitoringagent nog een DNS-antwoord terug naar de resolver, waarmee de agent de ontvangst van de melding bevestigt. Omdat alle informatie over de melding in de query (QNAME) zelf is verwerkt, doet de inhoud (RDATA) van dat antwoord er verder niet toe. Belangrijker is de TTL-waarde, want het reguliere DNS-caching-mechanisme wordt hier ook gebruikt om te voorkomen dat de agent wordt overspoeld met steeds dezelfde foutmeldingen.

Het idee is dat agents aparte systemen worden die de binnenkomende meldingen verzamelen, statistiek bedrijven en waar nodig alerts versturen – vergelijkbaar met de (commerciële) diensten voor de verwerking van DMARC-rapportages. "Naar mijn mening hoort automatische foutafhandeling niet thuis in het DNS-protocol," zegt Roy Arends, Principal Research Scientist bij ICANN en een van de editors van RFC 9567. "De agent kan onderdeel zijn van een autoritatieve nameserver als PowerDNS of NSD, maar de evaluatie van binnenkomende meldingen en het verhelpen van fouten is echt een apart onderdeel."

Geen authenticatiemechanisme

Om spoofing van foutmeldingen op de agent-ingang te voorkomen, moeten reporting resolvers per se gebruikmaken van TCP (in plaats van het veel efficiëntere UDP) of van DNS Cookies (een simpel authenticatie-mechanisme om DNS-verbindingen over UDP te beschermen). Ter bescherming van de privacy wordt QNAME Minimalization ingezet.

DNS error reporting bevat verder geen authenticatiemechanisme – denk bijvoorbeeld aan de authorization records van DMARC, waarmee verwerkers van foutmeldingen expliciet aangeven berichten voor een specifiek maildomein te willen ontvangen. Bij deze standaard kan in principe iedereen willekeurige foutmeldingen naar een agent sturen, of een bogusdomein opzetten om anderen foutmeldingen naar een agent te laten sturen. Volgens Arends hoeft dit echter geen problemen op te leveren. "In de DNS-wereld kan iedereen alles naar iedereen sturen. Er is geen bestaande relatie tussen een resolver en een autoritatieve nameserver waarop je iets van een autorisatie zou kunnen bouwen. Sowieso wil je de resolvers niet met een extra cryptografische taak opzadelen, want die worden al genoeg belast. In de praktijk zal een agent dus ook allerlei onzin binnenkrijgen. Fouten zullen echter een consistent patroon van meldingen opleveren, waar de agent vervolgens op kan acteren."

Laatste vangnet en troubleshooting

Op dit moment heeft de .nl-zone een klein half uur verversingstijd nodig voor elke nieuwe publicatie. Na de upgrade van DNSSEC-algoritme nummer 8 naar nummer 13 vorige zomer kosten alle tests en de validatie van de volledige zone nu net zo veel tijd als het ondertekenen ervan.

De toepassing van RFC 9567 zou voor de .nl-zone op geen enkele manier een vervanging kunnen zijn voor de huidige checks, maar misschien wel een aanvulling. "Zelfs als wij ooit naar dynamische updates zouden overstappen – waar nu geen concrete plannen voor zijn – dan mag dat niet minder deugdelijk zijn dan onze huidige aanpak," aldus Marco Davids, Research Engineer bij SIDN Labs. "Ook al is het misschien ingewikkelder om alles grondig te checken voor publicatie, wij kunnen ons niet veroorloven om van derden te moeten horen dat er iets niet klopt. Maar DNS error reporting zou in aanvulling op alle bestaande checks kunnen fungeren als een allerlaatste vangnet voor als alle andere onverhoopt hebben gefaald."

"Voor minder essentiële second-leveldomeinnamen kan RFC 9567 wel een belangrijke rol spelen. Daar kan DNS error reporting een makkelijke toevoeging zijn die kan helpen om snel problemen op te lossen."