Een opgefriste DNS-werkbank
Snel en eenduidig verschillende (authoritative) name server-implementaties testen
Kies jouw kleur
Veel bezocht
Veelgestelde vragen
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.
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.
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.
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.
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.
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.
Snel en eenduidig verschillende (authoritative) name server-implementaties testen
We hebben onze DNS workbench flink onder handen genomen en een opfrisbeurt gegeven, want hij werd wat sleets. Hij kan er nu weer een tijdje tegenaan. Bovendien is de broncode vrijgegeven als open source. Maar wat was de DNS workbench ook alweer en waarom weet een selecte groep (gevorderde) gebruikers hem toch steeds weer te vinden?
Een aantal jaren geleden alweer, waren we op zoek naar een hulpmiddel om snel en eenduidig verschillende (authoritative) name server-implementaties aan de tand te kunnen voelen en met elkaar te vergelijken. En dan niet alleen maar op basis van gangbare voordehandliggende instellingen, die meestal wel goed zijn geïmplementeerd en getest door softwareontwikkelaars, maar juist ook met zogenaamde cornercases en minder voordehandliggende test-scenario’s. En toen de DNS workbench daarmee geboren werd, bleek deze voor anderen ook interessant. Daarom besloten we hem aan te bieden als een online service, voor iedereen vrij te gebruiken.
De DNS workbench bestaat uit een combinatie van 5 verschillende open source name server-producten, namelijk: BIND9, PowerDNS, Knot, YADIFA en NSD. Elk van deze name servers is primary (master) server van maar liefst 421 zonefiles, die speciaal voor dit doel (geautomatiseerd) zijn gegenereerd. Ze zijn onder te verdelen in:
Zonefiles met allerhande RR types, waaronder types die ‘obsolete’ verklaard zijn en diverse exotische types die je in het wild nog nauwelijks tegenkomt maar waarvoor name servers misschien nog wel ondersteuning bieden. Wil je dit testen, dan kan dat bijvoorbeeld d.m.v.
dig GPOS gpos.types.wb.sidnlabs.nl [@knot.sidnlabs.nl]
In dit voorbeeld vraag je om het weinig voorkomende GPOS-type (aan de Knot-server). Zou je om het veel algemenere AAAA-type willen vragen, dan wordt dat dus:
dig AAAA aaaa.types.wb.sidnlabs.nl [@bind9.sidnlabs.nl]
(aan de BIND9-server)
Dit experiment laat onder andere zien dat niet alle name servers (zomaar) alle RR types ondersteunen. Voor YADIFA is eerst een conversie naar RFC3597-formaat nodig, voordat het deze zonefile wil inladen. PowerDNS laadt de zone wel in, maar geeft problemen bij een AXFR (zone transfer). We vonden dus op deze manier ook bepaalde bugs. YADIFA crashte zelfs bij:
dig +tcp ANY delegations.wb.sidnlabs.nl @yadifa.sidnlabs.nl
Deze bug is inmiddels gefikst en we draaien deze verbeterde versie, die is gecompileerd van de YADIFA broncode, op de workbench. Van de andere name server-software draaien we nog, zolang als dat kan, de packages zoals die meekomen met Ubuntu 18.04.
We bieden de zone met bijzonder RR types zowel gesigneerd als ongesigneerd aan.
Dit betreft een uitgebreide ‘DNS tree’ (met de naam ‘bad-dnssec’) van zones die op de een of andere manier foutief zijn gesigneerd, waarmee onder andere DNSSEC-validatiesoftware kan worden getest.
Ter illustratie: de zone ‘ok.ok.ok.bad-dnssec.wb.sidnlabs.nl’ is (als enige) helemaal foutloos gedelegeerd en gesigneerd. Maar de zone ‘signotincepted.ok.ok.bad-dnssec.wb.sidnlabs.nl’ eindigt (op het meest linkse label) in een delegatie die is gesigneerd in de toekomst en waarvan de digitale handtekeningen dus nog niet geldig zijn.
Combinaties zijn ook mogelijk. Bijvoorbeeld ‘signotincepted.nods.ok.bad-dnssec.wb.sidnlabs.nl’, die ook in de toekomst is gesigneerd, maar die tevens in de parent-zone geen DS record heeft. Zoek de verschillen met de eerdergenoemde zone in DNSviz. Dat is een bijzonder handige debug-tool, die trouwens zelf ook weer te testen valt met de DNS workbench. De eerstgenoemde zone is wel ‘bogus’, de tweede is feitelijk ‘insecure’, omdat er in de zogenaamde parent-zone geen DS is. Zo geeft dit experiment diverse variaties om te kunnen testen tegen validerende resolvers. Dat leverde onder andere de inzichten op dat de meeste resolvers ‘top down’ valideren, maar sommige ook ‘bottom up’, wat directe consequenties kan hebben voor bijvoorbeeld bovenstaand test-scenario.
Andere fouten die bewust in deze ‘bad-dnssec’-tree zijn aangebracht zijn: een digitale handtekening met ongeldige gegevens, een digitale handtekening die is verlopen, en een handtekening die is gezet met een onbekend, gefingeerd algoritme.
Dit experiment is bedoeld om de diverse (gesigneerde) delegatiecombinaties te testen. De zone ‘bind9.powerdns.knot.delegations.wb.sidnlabs.nl’ is bijvoorbeeld gedelegeerd aan Knot, die hem weer herdelegeert aan PowerDNS die hem herdelegeert aan BIND9. Deze zone leeft dus uiteindelijk op een BIND9 name server, maar een resolver passeert tijdens het resolving-proces een Knot- en een PowerDNS-server. Dat levert dan weer deze behoorlijk uitgebreide DNSviz-afbeelding op.
Alle zonefiles in de workbench zijn voor iedereen beschikbaar via een DNS zonetransfer (AXFR). Dit kan met en zonder TSIG sleutels (diverse algoritmes), bijvoorbeeld:
dig axfr ok.bad-dnssec.wb.sidnlabs.nl @nsd4.sidnlabs.nl
of
dig -y "wb_md5:Wu/utSasZUkoeCNku152Zw==" \
axfr ok.bad-dnssec.wb.sidnlabs.nl @bind9.sidnlabs.nl
Tenslotte hebben we op verzoek nog 3 zonefiles zijn toegevoegd. Bijvoorbeeld een zonefile met een CNAME onder de APEX, wat volgens de standaard niet is toegestaan. En een zonefile waar NSEC3 opt-out wordt getest.
Al met al zijn er met bovenstaande experimenten allerlei tests mogelijk om te kijken hoe de gebruikte software zich gedraagt en hoe andere tooling omgaat met de diverse fouten die we bewust hebben geïntroduceerd in de DNS zonefiles.
Heb je hierover nog ideeën, dan horen we dat graag! Zelf hebben we er ook nog wel een paar. Zo willen we in de toekomst nieuwere signeeralgoritmes zoals ECDSA gaan toevoegen aan de test-set en experimenten die betrekking hebben op IDN’s.
Als je de workbench al gebruikt, dan horen we dit natuurlijk ook graag. We zijn heel benieuwd waarvoor je ‘m gebuikt en of we je nog kunnen helpen met verbeteren.
Je vindt de workbench hier: https://workbench.sidnlabs.nl/ en de broncode staat hier: https://github.com/SIDN/workbench.
Artikel door:
Deel dit artikel