Aanmelding van een nieuwe standaard voor de pas toe of leg uit -lijst

aanmelddatum: 26 oktober 2011

Aanmelding van een nieuwe standaard voor de ‘pas toe of leg uit ‘-lijst Voor dit type aanmelding geldt dat alle criteria van toepassing zijn en alle vragen beantwoord dienen te worden. U wordt als eerst gevraagd uw persoonsgegevens en de basisinformatie van de standaard te geven. Vervolgens dienen de criteriavragen beantwoord te worden. De criteria vallen uiteen in criteria voor inbehandelname en inhoudelijke criteria.

0. Persoonsgegevens indiener & relatie tot standaard Deze gegevens worden door het Forum gebruikt om met u in contact te kunnen treden. De gegevens worden vertrouwelijk behandeld. 0.

Persoonsgegevens en relatie tot de standaard

0.1

Naam: […]

0.2

Organisatie: SIDN (Stichting Internet Domeinregistratie Nederland)

0.3

Functie: […]

0.4

Telefoonnummer: […]

0.5

E-mailadres: […]

0.6

Welke relatie bestaat er tussen uw organisatie en de standaard? SIDN is de registry voor het '.nl' country-code top-level domein. In die hoedanigheid spelen wij een belangrijke rol in het wereldwijde DNS ecosysteem. In 2010 besloot ICANN/IANA de root-zone van het DNS te beveiligen met DNSSEC, een maand later volgde SIDN met het signeren van de .nl-zone.

0.7

Zijn er (andere) overheidsorganisaties die de aanmelding van deze standaard ondersteunen? TNO en GovCERT in Nederland. ENISA op Europees niveau. Daarnaast is er binnen Nederland ondersteuning van diverse niet-overheidsorganisaties, waaronder NLnetLabs en SURFnet. En natuurlijk SIDN zelf.

Versie: 20111026


I. Basisinformatie aanmelding standaard De basisinformatie van de standaard vormt de basis voor de toetsing tegen de criteria. Probeer hier zo volledig mogelijk in te zijn. 1. 1.1

Basisinformatie standaard(en) (In geval van een set van standaarden, meerdere malen invullen) Volledige naam van de standaard

Domain Name System Security Extensions 1.2

Verkorte naam van de standaard DNSSEC

1.3

Versie van de standaard, vaststellingsdatum en status RFC4033, RFC4034, RFC4035 en overig, maart 2005, Status: IETF standaard.

1.4

Oudere en aanstaande versies van de standaard inclusief (verwachte) publicatiedata en ondersteuningsstatus Alleen een “proposed standaard” variant: RFC2535 uit maart 1999 (voorafgegaan door RFC2065 uit januari 1997. Over aanstaande versies is nog niets bekend. Wel is de verwachting dat het de bestaande standaard nog zal worden uitgebreid met nieuwe signing-algoritmes.

1.5

Zie: http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xml Naam en vindplaats specificatiedocument (bij voorkeur URL of bijvoegen bij aanmelding) http://www.ietf.org/rfc/rfc4033.txt en verder

1.6

Naam van de standaardisatieorganisatie Internet Engineering Taskforce (IETF)

1.7

Kosten van deelname aan het standaardisatieproces (bijv. voor lidmaatschap) nvt

1.8

Kosten voor het verkrijgen van het specificatiedocument geen

1.9

Andere standaarden die genoemd worden in het specificatiedocument van de standaard DNSSEC is een beveiligingsuitbreiding op het reeds sinds 1983 bestaande DNS protocol. Aangezien de uitbreiding gebruikt maakt van 'digital signing' d.m.v. 'publickey cryptography', wordt er verwezen naar hiervoor benodigde standaarden, zoals de Base64 standaard van RFC3548 (die verouderd is en vervangen is door RFC4648). Tevens zijn er verwijzingen naar RFC3110 waarin is vastgelegd hoe de digitale handtekeningen op basis van RSA/SHA1 moeten worden gegenereerd. Verder wordt verwezen naar tal van andere RFC-standaarden waarmee een relatie bestaat (zoals bijvoorbeeld RFC1982. Uiteraard worden ook de originele DNS standaarden RFC1034 en RFC1035 vermeld.


2. 2.1

Toepassings- en werkingsgebied van opname Wat is het beoogde functioneel toepassingsgebied voor de standaard? Beveiliging van het DNS protocol (dat zelf is vermeld op de lijst met gangbare standaarden). Toelichting: Het DNS protocol is kwetsbaar voor misbruik. Een aanval die bekend staat als 'DNS cache pollution' (aka 'cache poisoning'), stelt kwaadwillenden in staat om argeloze gebruikers via een gemanipuleerd DNS-antwoord naar de verkeerde plek te leiden. DNSSEC biedt hiertegen bescherming. Feitelijk maakt DNSSEC het mogelijk DNS antwoorden te valideren, om met zekerheid vast te stellen of ze 'onderweg' niet zijn gemanipuleerd.

2.2

Ik pleit ervoor om DNSSEC in de gehele keten te gaan inzetten, dat wil zeggen dat zones worden gesigneerd en dat resolvers gaan valideren. Wat is het beoogde organisatorisch werkingsgebied voor de standaard? DNSSEC werkt, net als DNS, 'onder de motorkap' en is dus het domein van ICT systeembeheerders (maar ook 'security officers', gezien de beveiligingsaspecten ervan). DNSSEC kan (en zal naar verwachting) in de toekomst een rol gaan spelen bij de verbetering van de beveiliging van de PKI infrastructuur en kan dientengevolge ook relevant worden voor (technische) beheerders van webservers en websites. De gemiddelde gebruiker zal geen verschil merken tussen 'gewoon' DNS en DNS met DNSSEC.

II. Criteria voor inbehandelname De criteria voor inbehandelname worden gebruikt tijdens de intake om te bepalen of een aanmelding correct is en binnen de scope van de lijsten valt. De vragen dienen altijd beantwoord te worden met Ja, Nee of Onbekend, gevolgd door een toelichting. Criteria: De aanmelding is correct en valt binnen scope van de lijsten, d.w.z. de standaard: - Is toepasbaar voor elektronische gegevensuitwisseling tussen en met (semi-)overheidsorganisaties; - Draagt binnen het beoogde opnamegebied substantieel bij aan de interoperabiliteit van de (semi-)overheid; - Is niet reeds wettelijke verplicht. 1. 1.1

Valt de aangemelde standaard binnen de scope van de lijsten? Is de standaard toepasbaar voor elektronische gegevensuitwisseling tussen (semi-)overheidsorganisaties en bedrijven, tussen (semi-)overheidsorganisaties en burgers of tussen (semi-)overheidsorganisaties onderling? Ja De standaard is een beveiligings-extentie op het DNS, dat al op de lijst van gangbare standaarden is opgenomen.


1.2

Is het beoogde functioneel toepassingsgebied en het organisatorisch werkingsgebied van de standaard, voldoende breed om substantieel bij te dragen aan de interoperabiliteit van de (semi-)overheid? Ja Het toepassingsgebied is gelijk aan dat van DNS

1.3

Is het zinvol de standaard op te nemen, gezien het feit dat deze niet al wettelijk verplicht is voor het beoogde functioneel toepassingsgebied en organisatorisch werkingsgebied? Ja DNSSEC is nog niet wettelijk verplicht gesteld en zal dat op korte termijn ook niet worden.

III. Inhoudelijke criteria De inhoudelijke criteria worden gebruikt voor het expertonderzoek om te adviseren over het al dan niet opnemen van de standaard op één van de lijsten. Van u, als indiener van de standaard, wordt ook verwacht dat u de vragen die horen bij de inhoudelijke criteria beantwoord. De vragen dienen beantwoord te worden met Ja, Nee of Onbekend en altijd te worden voorzien van een toelichting op het antwoord.

1. Inhoudelijk criterium: Open standaardisatieproces Criterium: De ontwikkeling en het beheer van de standaard zijn op een open, onafhankelijke, toegankelijke, inzichtelijke, zorgvuldige en duurzame wijze ingericht.

Vragen: 1.1 1.1.1

Is de documentatie voor eenieder drempelvrij beschikbaar? Is het specificatiedocument beschikbaar zonder dat er sprake is van onacceptabele belemmeringen (zoals te hoge kosten en te hoge lidmaatschapseisen)? Ja Het betreft hier een open IETF standaard. Zie RFC5378 en http://trustee.ietf.org/faqs.html en http://trustee.ietf.org/license-info/

1.1.2

Is de documentatie over het ontwikkel- en beheerproces (bijv. het voorlopige specificatiedocument, notulen en beschrijving besluitvormingsprocedure) beschikbaar zonder dat er sprake is van onacceptabele belemmeringen (zoals te hoge kosten en te hoge lidmaatschapseisen)? Ja Zie: http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-intro/ en overige, te vinden via http://datatracker.ietf.org/wg/dnsext/

1.2 1.2.1

Is het intellectuele eigendomsrecht voor eenieder beschikbaar, zodat de standaard vrij implementeerbaar en te gebruiken is Stelt de standaardisatieorganisatie het intellectueel eigendomsrecht op de standaard m.b.t. bijvoorbeeld eventuele patenten- onherroepelijk royalty-free voor eenieder beschikbaar? Ja Zie vraag 1.1.1.

1.2.2

Garandeert de standaardisatieorganisatie dat partijen die bijdragen aan de ontwikkeling


van de standaard hun intellectueel eigendomsrecht onherroepelijk royalty-free voor eenieder beschikbaar stellen? Ja Zie RFC3979 (en RFC4879) en RFC5378.


III. Inhoudelijke criteria: 1. Open standaardisatieproces (vervolg)

1.3 1.3.1

Is de inspraak van eenieder in voldoende mate geborgd? Is het besluitvormingsproces toegankelijk voor alle belanghebbenden (bijv. gebruikers, leveranciers, adviseurs, wetenschappers)? Ja Zie onder andere: http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-intro/ballot/ https://www.ietf.org/mailman/listinfo/dnsext en diverse andere bronnen zoals vrij toegankelijke jabber-transcripties:

http://www.ietf.org/jabber/logs/dnsext/ enz. 1.3.2

Vindt besluitvorming plaats op een wijze die zoveel mogelijk recht doet aan de verschillende belangen? Ja Iedereen kan binnen de IETF zijn stem laten horen. Zie ook RFC6410.

1.3.3

Kan een belanghebbende formeel bezwaar aantekenen tegen de gevolgde procedure? Ja Het staat eenieder vrij zich te mengen in de discussie. Er zijn working group chairs en area directors waartoe men zich kan wenden. De IESG overziet dit proces. http://www.ietf.org/iesg/ en RFC5742.

1.3.4

1.3.5

Organiseert de standaardisatieorganisatie regelmatig overleggen met belanghebbenden over doorontwikkeling en beheer van de standaard? Ja IETF werkt veel met mailinglijsten, maar organiseert ook drie keer per jaar een meeting: 1 in de VS, 1 in Europa en 1 in Azië. Deze zijn vrij toegankelijk. Zie: http://www.ietf.org/about/process-docs.html en http://www.ietf.org/tao.html Organiseert de standaardisatieorganisatie een publieke consultatie voordat (een nieuwe versie van) de standaard wordt vastgesteld? Ja Zie vraag 1.3.4. De IETF is geheel transparant en voor staat open voor iedereen om aan deel te nemen.

1.4 1.4.1

Is de standaardisatieorganisatie onafhankelijk en duurzaam? Is de ontwikkeling en het beheer van de standaard belegd bij een onafhankelijke nonprofit standaardisatieorganisatie? Ja IETF is een non-profit organisatie. Feitelijk is het een grote, wereldwijde community van vrijwilligers, ondersteund door een klein secretariaat.

1.4.2

Zie RFC4071. Is de financiering van de ontwikkeling en het onderhoud van de standaard voor tenminste drie jaar gegarandeerd? Ja Zie eerdere antwoorden. De IETF DNSext working group is actief en kent kapitaalkrachtige leden, die er belang bij hebben dat de standaard goed onderhouden


blijft. SIDN is zo'n werkgroep lid.


III. Inhoudelijke criteria: 1. Open standaardisatieproces (vervolg) 1.5 1.5.1

Is het (versie) beheer van de standaard goed geregeld? Heeft de standaardisatieorganisatie gepubliceerd beleid met betrekking tot versiebeheer van de standaard? (met o.a. aandacht voor migratie van gebruikers) Ja Zie eerdere verwijzingen over de werkwijze van de IETF. Maar ook: http://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc4641bis/

1.5.2

Is het standaardisatieproces van de standaardisatieorganisatie zodanig goed geregeld dat het Forum zich kan onthouden van aanvullende toetsing bij de aanmelding van een nieuwe versie van de standaard? Ja Zie eerdere verwijzingen over de werkwijze van de IETF.

1.5.3

Is het belang van de Nederlandse overheid voldoende geborgd bij de ontwikkeling en het beheer van de standaard? Ja Nederland is van oudsher goed vertegenwoordigd in de internet community en de IETF. Er zijn geen aanwijzingen dat dit binnen afzienbare termijn zal veranderen.


III. Inhoudelijke criteria 2. Inhoudelijk criterium: Toegevoegde waarde Criterium: De interoperabiliteitswinst en andere voordelen van adoptie van de standaard wegen overheidsbreed en maatschappelijk op tegen de risico’s en nadelen. Vragen: 2.1 2.1.1

Verhoudt de standaard zich goed tot andere standaarden? Kan de standaard naast of in combinatie met reeds opgenomen standaarden worden toegepast (d.w.z. de standaard conflicteert niet met reeds opgenomen standaarden)? Ja DNSSEC is een uitbreiding op DNS en is backward compatible met oudere DNS varianten. Oude en nieuwe DNS-systemen kunnen zonder problemen met elkaar overweg. Met niet DNS gerelateerde standaarden is geen raakvlak en dus geen probleem.

2.1.2

Biedt de aangemelde standaard meerwaarde boven reeds opgenomen standaarden met een overlappend functioneel toepassings- en organisatorisch werkingsgebied? (Dit kan ook om een nieuwe versie van dezelfde standaard gaan.) Ja DNSSEC voegt een sterke beveiliging toe aan het DNS protocol. Dat is op zich al een grote meerwaarde (DNS is intrinsiek onveilig, denk aan de 'Kaminsky-attack'), maar DNSSEC opent ook deuren naar nieuwe toepassingen van het DNS. Bijvoorbeeld ter verbetering van het PKI systeem (mbv het in ontwikkeling zijnde DANE protocol). Maar ook de DKIM standaard (RFC4871) zal profiteren van DNSSEC. Idem voor RFC4408, RFC4255, RFC4398 en anderen

2.1.3

Biedt de aangemelde standaard meerwaarde boven bestaande concurrerende standaarden die in aanmerking zouden kunnen komen voor opname? Ja (er is in feite geen alternatieve of concurrerende standaard)

2.1.4

Is de standaard een internationale standaard of sluit de standaard aan bij relevante internationale standaarden? Ja Het is een officiële Internet Standaard.

2.1.5

Draagt de standaard voldoende bij aan interoperabiliteit zonder dat aanvullende standaardisatieafspraken (zoals lokale profielen) noodzakelijk zijn? Ja Vraag is niet geheel duidelijk. DNSSEC draagt niet bij aan interoperabiliteit, maar doet daar ook niets aan af. Aanvullende afspraken zijn in principe niet nodig. Het zou wel kunnen dat apparaten (zoals firewalls) die zich niet goed aan de standaarden houden, met gebruik van DNSSEC problemen zouden kunnen geven. Punt van aandacht is hierbij dat op de 'lijst gangbare standaarden' DNS staat genoemd met daarbij twee oude RFC's (RFC1034 en RFC1035). Firewalls die zich uitsluitend aan die beide RFC's conformeren, kunnen (en zullen waarschijnlijk) problemen gaan geven wanneer DNSSEC gebruikt zal worden. Er zijn immers tal van aanvullende RFC's aan het DNS-protocol toegevoegd (waaronder RFC2671). Aangezien DNSSEC al geruime tijd in gebruik is op het internet (de rootzone en de .nl-zone zijn bijvoorbeeld al


gesigned), mag worden aangenomen dat dergelijke firewalls een zeldzaamheid zijn geworden.


III. Inhoudelijke criteria: 2. Toegevoegde waarde (vervolg) 2.2 2.2.1

Wegen de kwantitatieve en kwalitatieve voordelen van adoptie van de standaard, voor de (semi-)overheid als geheel en voor de maatschappij, op tegen de nadelen? Draagt de adoptie van de standaard bij aan de oplossing van een bestaand, relevant interoperabiliteitsprobleem? Ja DNSSEC werkt van twee kanten: zij die hun zones voorzien van DNSSEC-beveiliging en zij die gebruik maken daarvan (mbv zogenaamde 'validerende resolvers'). Steeds meer domein-eigenaren gaan ertoe over hun zones te signeren. Als er aan de resolverkant geen validatie plaatsheeft, is dat signeren als het ware vergeefse moeite. Er is in die zin dan sprake van een 'interoperabiliteitsprobleem'. Het omgekeerde is ook het geval; wanneer steeds meer gebruikers gaan werken met validerende resolvers, maar de overheid haar domeinnamen nog niet voorziet van DNSSEC-beveiliging, is er sprake van een zekere vorm van interoperabiliteit op het gebied van DNS-beveiliging.

2.2.2

Draagt de standaard bij aan het voorkomen van een vendor lock-in (leveranciersafhankelijkheid)? Nee (noch is het omgekeerde het geval) Er bestaat geen (goede) 'proprietary' oplossing voor het probleem. Verndor lock-in derhalve niet aan de orde.

2.2.3

Wegen de overheidsbrede en maatschappelijke baten voor de informatievoorziening en de bedrijfsvoering op tegen de kosten? Ja DNSSEC validatie (op resolvers) is zonder noemenswaardige inspanningen te realiseren. Het signeren van zones op basis van DNSSEC is ontegenzeggelijk ingewikkelder, maar wordt wel steeds makkelijk gemaakt met de komst van nieuwe tools. De baten wegen op tegen de kosten, aangezien DNS een erg belangrijke functie vervult binnen het internet ecosysteem. Hoewel het risico wellicht beperkt is, zal de impact van een geslaagde Kamisky-aanval doorgaans groot zijn.

2.2.4

Zijn de beveiligingsrisico’s aan overheidsbrede adoptie van de standaard acceptabel? Ja DNSSEC voegt juist beveiliging toe. Daarentegen introduceert DNSSEC ook bepaalde risico's (zonewalk in geval van het gebruik van NSEC bijvoorbeeld, of een grotere kans op een DNS amplification attack). Deze risico's zijn echter acceptabel, temeer daar andere niveau's in de wereldwijde DNS namespace (de root en vele TLD's) ook al DNSSEC hebben geïmplementeerd.

2.2.5

Zijn de privacyrisico’s aan overheidsbrede adoptie van de standaard acceptabel? Ja Privacy wordt in de regel juist beter gewaarborgd met DNSSEC. Voor het in 2.2.4 genoemde zonewalking probleem is een oplossing in de vorm van NSEC3 (RFC5155).



III. Inhoudelijke criteria 3. Inhoudelijk criterium: Draagvlak Criterium: Aanbieders en gebruikers hebben voldoende positieve ervaring met de standaard. Vragen: 3.1 3.1.1

Bestaat er voldoende marktondersteuning voor de standaard? Bieden meerdere leveranciers ondersteuning voor de standaard? Ja Steeds meer DNS software heeft goede, tot zeer goede ondersteuning voor DNSSEC: Qua open-source zijn dat: BIND 9 BIND 10 NSD Unbound PowerDNS OpenDNSSEC enz. Maar ook proprietary oplossingen bieden in toenemende mate ondersteuning voor DNSSEC.

3.1.2

Kan een gebruiker de conformiteit van de implementatie van de standaard (laten) toetsen? Ja Er zijn diverse manieren om dit te doen, waaronder diverse eenvoudige en vrij toegankelijke online hulpmiddelen: http://dnsssectest.sidn.nl/ http://dnssec-debugger.verisignlabs.com/ http://dnsviz.net/ http://dnscheck.iis.se/ etc. Daarnaast zijn er tal van command-line utilities en andere hulpmiddelen.

3.2 3.2.1

Kan de standaard rekenen op voldoende draagvlak? Wordt de aangemelde versie van de standaard binnen het organisatorische werkingsgebied door meerdere organisaties gebruikt? Ja De rootzone, die aan de basis staat van het DNS is gesigneerd, alsmede tal van TLD's Zie: http://en.wikipedia.org/wiki/List_of_Internet_top-level_domains Binnen Nederland gebruiken verschillende organisaties deze standaard, waaronder:

3.2.2

SIDN, SURFnet, NlnetLabs, T-Mobile, XS4ALL, BIT, Networking4All enz. Wordt een vorige versie van de standaard binnen het organisatorische werkingsgebied door meerdere organisaties gebruikt? Ja Dit heeft met name betrekking op gebruikte signing-algoritmes en het gebruik van NSEC en het later geïntroduceerde NSEC3. Ze worden allemaal gebruikt. De standaard kent ook voorlopers, maar die zijn het experimentele stadium nooit ontstegen.


3.2.3

Is de aangemelde versie backwards compatible met eerdere versies van de standaard? Ja DNSSEC is backward compatible met alle eerdere versies van DNS, tot aan de aller oudste (uit 1983) aan toe. Voor alle DNS software die RFC3597 ondersteund, geldt dat DNSSEC in zekere mate ook 'forward compatible' is. Dwz: er is sprake van verminderde functionaliteit, maar data wordt wel geaccepteerd (voorbeeld: een authoritative name server die geen DNSSEC ondersteuning heeft, zal geen goede slave zal zijn van een name server met DNSSEC, maar accepteert de DNSSEC records wel).

3.2.4

Zijn er voldoende positieve signalen over toekomstige gebruik van de standaard door (semi-)overheidsorganisaties, het bedrijfsleven en burgers? Ja Dit is een gewetensvraag. De standaard kent voor- en tegenstanders en heeft voor- en nadelen. Er is een gestadige tendens van een almaar groeiend draagvlak. Affaires zoals het Diginotar-debacle hebben daartoe bijgedragen. Binnen de IETF DANE werkgroep wordt namelijk gewerkt aan een protocol waarmee DNS in combinatie met DNSSEC gebruikt zou kunnen worden ter verbetering van het PKI systeem. Ook het feit dat DNSSEC al ruim een jaar met succes in de root wordt toegepast en de ontwikkeling van allerhande hulpmiddelen om DNSSEC eenvoudiger te maken, dragen hieraan bij. Naarmate andere aanvalsvectoren beter worden beveiligd, komt DNS als aanvalsvector ook dichterbij. Er gaan derhalve steeds meer stemmen op dat het DNS moet worden beveiligd met behulp van DNSSEC.

III. Inhoudelijke criteria 4. Inhoudelijk criterium: Opname bevordert adoptie Criterium: De opname op de lijst is een geschikt middel om de adoptie van de standaard te bevorderen. Toelichting lijsten: a. Met de lijsten wil het College de adoptie van open standaarden bevorderen die voldoen aan de voorgaande criteria (open standaardisatieproces, toegevoegde waarde, draagvlak); b. Met de “pas toe of leg uit”-lijst beoogt het College dit soort standaarden verplichten als: 1. hun huidige adoptie binnen de (semi-)overheid beperkt is; 2. opname op de lijst bijdraagt aan de adoptie door te stimuleren o.b.v. het "PToLU"-regime. (functie=stimuleren). c. Met de lijst met gangbare standaarden beoogt het College dit soort standaarden aan te bevelen als: 1. hun huidige adoptie binnen de (semi-)overheid reeds hoog is; 2. opname op de lijst bijdraagt aan de adoptie door te informeren en daarmee onbedoelde afwijkende keuzes te voorkomen. (functie=informeren) Vragen: 4.1 4.1.1

Opname op de lijst bevordert de adoptie van de standaard. Is de “pas toe of leg uit”-lijst het passende middel om de adoptie van de standaard binnen de (semi)overheid te bevorderen? Ja DNSSEC opereert, net als DNS (en IPv4 / IPv6) onder de motorkap, ontrokken aan het zicht van de gemiddelde gebruiker. Daar vervult het een immens belangrijke rol, maar die is lastig uit te leggen. Bovendien is er sprake van een 'kip-ei' situatie (“waarom zou ik signeren als er toch niemand valideert?”) Het is daarom lastig een goede business case rondom DNSSEC te formuleren (al lijkt dat een kwestie van tijd).


Opname op de “pas toe of leg uit lijst” zou kunnen helpen bij het doorbreken van de vicieuze cirkel. 4.1.2

Is de lijst met gangbare open standaarden het passende middel om de adoptie van de standaard binnen de (semi)overheid te bevorderen? Nee Gebruik van DNSSEC is nog niet gangbaar en opname op de lijst met gangbare open standaarden zou derhalve ongepast zijn. Opmerking: DNSSEC is op zichzelf geen compleet protocol. Het is een uitbreiding op het DNS protocol, dat wel al op de lijst met gangbare standaarden is opgenomen. DNSSEC kan niet als een nieuwe versie van de DNS-standaard gezien worden. Anders gesteld: DNS zonder DNSSEC kan prima werken DNSSEC zonder DNS is onzinnig. Bovendien werkt DNSSEC niet goed bij DNS-software die alleen maar RFC1034 en RFC1035 ondersteund (zoals genoemd op de lijst met gangbare standaarden). Er zijn nog een aantal andere RFC's vereist, waaronder RFC2671 en RFC3597.

4.2

Zijn er naast opname op de lijst aanvullende adoptiemaatregelen nodig?

4.2.1

Is de inzet van aanvullende adoptie-instrumenten (communicatief, financieel, juridisch), door andere partijen dan het Forum/College Standaardisatie, noodzakelijk? Onbekend DNS is een complex protocol, waar door de jaren heen flink aan is gesleuteld. Toevoegen van DNSSEC maakt het niet simpeler. Het voegt 'trust' toe aan het DNS en 'dwingt' derhalve tot nadenken over een 'beveiliginsbeleid'. Dit gaat verder dan een puur technische kennis en bemoeienis.

4.2.2

Kan een uitgebreid adoptieadvies van Forum Standaardisatie helpen bij het wegnemen van knelpunten in de adoptie? Ja Zie 4.1.1


Verzending Als u het aanmeldingsformulier zo volledig mogelijk heeft ingevuld, dan kunt u deze als bijlage versturen naar [email protected] Gebruikt u dan als onderwerp: "Aanmelding standaard". Na ontvangst van het formulier ontvangt u binnen 5 dagen een ontvangstbevestiging per e-mail. Bedankt voor uw aanmelding.

Aanmelding van een nieuwe standaard voor de pas toe of leg uit -lijst

Recommend Documents