_      _            _
         _ __ ___ (_) ___| | __  _ __ | |
        | '_ ` _ \| |/ _ \ |/ / | '_ \| |
        | | | | | | |  __/   < _| | | | |
        |_| |_| |_| |\___|_|\_(_)_| |_|_|
                  | |
                  |_|       Thoughts on (technical) stuff...
You're from: 54.242.188.217

Samenvatting

In de loop van zondag 28 oktober is er een foutsituatie ontstaan bij het
publiceren van een nieuwe ZSK (met key tag: 20331). Deze nieuwe ZSK was
namelijk nog niet gepubliceerd in het DNS, terwijl de door SIDN gebruikte
software (OpenDNSSEC) ervan uitging dat dit wel het geval was.

Als gevolg hiervan was de zogenaamde 'pre-publication'-tijd van de nieuwe ZSK
te kort. Toen er RRSIG's in de .nl-zone verschenen die waren gemaakt met de
nieuwe ZSK, was de TTL van de oude DNSKEY RRset nog niet verstreken, waardoor
deze nog werd gebruikt door validerende resolvers, met DNSSEC validatiefouten
tot gevolg. Deze validatie problemen ontstonden ongeveer om 20:45 u.

Getroffen:

Zij die gebruik maken van DNSSEC-validatie.

Oplossing:

Na het verstrijken van de TTL (maximaal 2 uur), of het anderszins verversen van de cache (bijvoorbeeld door een herstart van de resolver), werd het juiste sleutelmateriaal gebruikt en werkte validatie weer.

Oorzaken

SIDN heeft de samenloop van omstandigheden onderzocht, de volgende factoren speelden een rol:

  • Een fout (vastloper) in OpenDNSSEC, waardoor de zonefile-publicatie stil kwam te liggen.
  • Discrepantie tussen de vermeende situatie volgens OpenDNSSEC en de werkelijke situatie in het DNS, met als gevolg een te korte pre-publish periode van de nieuwe ZSK.

SIDN zal maatregelen treffen om herhaling te voorkomen.

Posted in: dutch, dns(sec)

5 comments

We hebben toch nog wel het een en ander te ontdekken bij het implementeren van 'nieuwe?' technologie... Benieuwd welke verrassingen we nog meer gaan tegenkomen. Ik ben wel heel benieuwd wat SIDN verwacht te doen om herhaling te voorkomen. Immers, het beheersen van samenloop van omstandigheden is een ware uitdaging...
'Onofficieel', we gaan de timers in OpenDNSSEC wrs ruimer zetten. Zodat een sleutel langer in DNS moet zitten. Waarschijnlijk ook nog andere maatregelen.
Een andere aanpak zou kunnen zijn om, net als met KSKs, een expliciete bevestiging te ontvangen als een ZSK daadwerkelijk is gepubliceerd. Of teruggetrokken. Of gebruikt in signing.

Hiermee zou wel worden gebroken met de 'traditie' dat OpenDNSSEC in isolatie zijn werk doet, ongestoord door de buitenwereld.
Ja, daar zitten we ook aan te denken, maar heeft ods door hooks voor?
Ik ben wel heel benieuwd wat SIDN verwacht te doen om herhaling te voorkomen. Immers, het beheersen van samenloop van omstandigheden is een ware uitdaging...

Comments are closed

If you really, really want to comment, please mail miek@miek.nl.

0 comments in moderator queue