DNSSEC-SERVFAIL na het wijzigen van nameservers: diagnose en veilige migratie

Een migratie naar andere nameservers kan in elk beheerpaneel geslaagd lijken, terwijl de website toch onbereikbaar blijft. Het domein is actief, de nieuwe autoritatieve nameservers geven het verwachte IP-adres terug en er is niets veranderd aan de webserver. Toch melden validerende DNS-resolvers SERVFAIL. De ontbrekende schakel is vaak een DNSSEC-delegatie die nog vertrouwt op de ondertekeningssleutel van de vorige DNS-provider.

Bij het onderzochte incident mislukten normale DNS-query's, terwijl dezelfde query's wel slaagden wanneer DNSSEC-validatie werd omzeild. De bovenliggende zone publiceerde nog een oud DS-record, maar de nieuwe autoritatieve zone was aanvankelijk niet ondertekend. Nadat een passende sleutel was gepubliceerd en de nieuwe zone was ondertekend, gaven de geteste resolvers weer gevalideerde antwoorden. De belangrijkste les is niet dat je DNSSEC moet uitschakelen, maar dat het verplaatsen van nameservers en het overzetten van de DNSSEC-vertrouwensketen twee afzonderlijke handelingen zijn.

Waarom correcte A-records toch SERVFAIL kunnen opleveren

DNS beantwoordt twee verschillende vragen. Een A-record vertelt een resolver welk IPv4-adres bij een naam hoort. DNSSEC laat een validerende resolver controleren of dat antwoord te vertrouwen is. Correcte adresgegevens betekenen niet automatisch dat de DNSSEC-vertrouwensketen geldig is.

Bij een ondertekend domein loopt de keten van een vertrouwde bovenliggende zone via een DS-record (Delegation Signer) naar een DNSKEY in de onderliggende zone. Die onderliggende zone publiceert handtekeningen (RRSIG-records) over haar DNS-gegevens. Het DS-record bevat een hashwaarde die een geautoriseerde DNSKEY identificeert. Het is geen A-record, geen kopie van de privésleutel en geen instelling in een gewone editor voor zonebestanden.

Na het wijzigen van autoritatieve nameservers kan de bovenliggende zone nog een DS-record publiceren dat hoort bij de vorige ondertekenaar. Als de nieuwe zone de bijbehorende DNSKEY en handtekeningen niet heeft, kan een validerende resolver de vertrouwensketen niet voltooien. Doorgaans beschouwt de resolver het antwoord dan als ongeldig en retourneert hij SERVFAIL in plaats van een niet-geverifieerd adres.

Dit is iets anders dan een HTTP-storing: het verzoek bereikt de webserver mogelijk nooit. Het is ook iets anders dan een verlopen TLS-certificaat. DNSSEC valideert DNS-gegevens, terwijl HTTPS een latere verbinding tussen de browser en de server beveiligt.

Met welke test je een DNSSEC-fout van een ontbrekend record onderscheidt

De meest veelzeggende test gebruikt twee keer dezelfde resolver en dezelfde domeinnaam. Voer eerst een gewone query uit en controleer niet alleen het antwoord, maar ook de status:

dig example.com A +noall +comments +answer

Herhaal de query vervolgens met de CD-bit (DNSSEC Checking Disabled) ingeschakeld:

dig example.com A +cdflag +noall +comments +answer

Bij de waargenomen fout gaf de gewone query SERVFAIL terug; met de CD-bit ingeschakeld verscheen het verwachte A-record. Dat verschil wees sterk op een probleem met DNSSEC-validatie, niet op een ontbrekend DNS-record of een onbereikbare applicatie. Met +cdflag vraag je een recursieve resolver die dit ondersteunt om voor die query de gebruikelijke DNSSEC-validatie over te slaan. Het is een hulpmiddel voor diagnose, geen reparatie aan de browserkant en geen manier om DNSSEC voor bezoekers uit te schakelen.

Leid niet te veel af uit een lege uitvoer met +short. Zowel een ontbrekend antwoord als SERVFAIL kan er met die weergave leeg uitzien. Houd tijdens het onderzoeken +comments ingeschakeld, zodat status: SERVFAIL en status: NOERROR zichtbaar blijven.

De vergelijking met de CD-bit laat op zichzelf niet zien welk onderdeel van DNSSEC faalt; ze geeft aan waar je verder moet zoeken. Een resolver kan ook tijdelijk problemen hebben met een upstreamserver. Herhaal de test daarom zo nodig en controleer de delegatie in de bovenliggende zone.

Controleer het DS-record in de bovenliggende zone, niet alleen de DNS-editor

Controleer of er DS-records voor het domein bestaan:

dig example.com DS +noall +comments +answer

Vraag voor een vollediger beeld van het delegatiepad de DNS-hiërarchie rechtstreeks op:

dig +trace example.com DS

Welke autoritatieve nameserver bij de bovenliggende zone hoort, hangt af van het topleveldomein. Het gaat om de verzameling DS-records die de bovenliggende zone publiceert, niet alleen om een samenvatting in het dashboard van de DNS-hostingprovider. Bij een verhuizing naar een andere registrar kunnen de nameservers gelijk blijven, en nameservers kunnen ook veranderen zonder dat het domein naar een andere registrar verhuist. Hoe dan ook moet het DS-record in de bovenliggende zone overeenkomen met de actieve autoritatieve zone.

Een DS-record heeft vier betekenisvolle velden: key tag, algoritme, digesttype en digest. De key tag is een handig herkenningspunt bij het oplossen van problemen, maar bewijst op zichzelf niet dat een DNSKEY overeenkomt. Ook de digest en de algoritmegegevens moeten passen bij een sleutel die de autoritatieve zone daadwerkelijk aanbiedt.

In dit geval was de doorslaggevende situatie eenvoudig: de bovenliggende zone publiceerde nog de eerdere DNSSEC-vertrouwensgegevens, terwijl de vervangende autoritatieve zone aangaf dat ondertekening niet actief was. De A-records waren aanwezig en konden worden opgehaald wanneer de validatie werd omzeild. De applicatieconfiguratie aanpassen of telkens hetzelfde A-record wijzigen zou die mismatch niet oplossen.

Twee manieren om een kapotte DNSSEC-delegatie te herstellen

Er zijn twee geldige herstelstrategieën. Ze lossen dezelfde mismatch in de vertrouwensketen op, maar hebben verschillende operationele gevolgen. Kies bewust één aanpak en wissel niet lukraak tussen beide.

Optie 1: Verwijder het verouderde DS-record en gebruik tijdelijk een niet-ondertekende zone

Laat de huidige registrar, of de DNSSEC-beheerfunctie die deze ondersteunt, het verouderde DS-record uit de bovenliggende zone verwijderen. Zodra de bovenliggende zone geen beveiligde delegatie meer aangeeft, kunnen validerende resolvers een niet-ondertekende onderliggende zone als onbeveiligd beschouwen in plaats van als ongeldig. DNS blijft werken, maar voor het domein ontbreekt tijdelijk DNSSEC-authenticatie.

Dit is vaak de eenvoudigere noodoplossing, mits er een betrouwbare manier bestaat om de verzameling DS-records in de bovenliggende zone te wijzigen. Laat de bestaande configuratie voor ondertekening ongewijzigd totdat eerder gecachte oude DS-records bij recursieve resolvers zijn verlopen. Alleen een DS-record verwijderen in een beheerpaneel is niet voldoende bewijs: controleer het record in de bovenliggende zone van buitenaf en houd rekening met de TTL. HTTPS staat los van de DNSSEC-instelling. Deze tijdelijke overgang naar een niet-ondertekende zone wordt ook beschreven in RFC 8078.

Optie 2: Onderteken de nieuwe zone en publiceer een bijpassend DS-record

Het alternatief is DNSSEC bij de nieuwe autoritatieve DNS-provider inschakelen, DNSKEY-sleutelmateriaal laten aanmaken, de zone ondertekenen en het bijbehorende DS-record in de bovenliggende zone publiceren. Een validerende resolver kan dan een vertrouwd pad naar de nieuwe DNSKEY opbouwen en het A-record valideren.

Dit was de herstelmethode die daadwerkelijk werd waargenomen. De DNS-beheerinterface meldde dat sleutels waren aangemaakt, de zone was ondertekend en een nieuw DS-record was gepubliceerd. Een daaropvolgende query naar de bovenliggende zone liet het nieuwe DS-record naast het vorige zien. Validerende recursieve query's leverden weer het verwachte A-record op. Een latere test gaf bovendien NOERROR terug met de ad-vlag ingesteld, wat aangaf dat die resolver de gegevens had geauthenticeerd.

De volgorde is belangrijk: een gepubliceerd DS-record heeft alleen nut als de bijbehorende DNSKEY en geldige handtekeningen al door de autoritatieve DNS-dienst worden aangeboden. De melding ‘published’ in een beheerpaneel vervangt geen externe controle. Gecachte DS-, DNSKEY-, RRSIG- en NS-records kunnen ervoor zorgen dat verschillende resolvers op verschillende momenten weer correct werken.

Waarom twee DS-records de website niet per se onbereikbaar hielden

Een verrassende uitkomst was dat de bovenliggende zone tijdelijk zowel een verouderd DS-record als een nieuw, geldig DS-record bevatte, terwijl DNSSEC-validatie toch slaagde. Dat is niet tegenstrijdig. Een verzameling DS-records mag meerdere records bevatten, zoals vaak gebeurt bij een sleutelovergang. Een validator vereist niet dat elk DS-record naar een op dat moment bruikbare sleutel verwijst. Er hoeft slechts één geldig authenticatiepad te bestaan via een geschikt DS-record naar een DNSKEY en geldige handtekeningen. RFC 6840 verduidelijkt dat validators één geldig pad moeten accepteren.

Dat betekent niet dat verouderde sleutels voor altijd mogen blijven staan. Een achterhaald DS-record maakt het beheer minder overzichtelijk en moet uiteindelijk worden opgeruimd zodra de nieuwe vertrouwensketen is geverifieerd. Maar dat is onderhoud, geen reden om nog een riskante DNSSEC-reset uit te voeren terwijl gevalideerde query's alweer slagen.

Er schuilt hier een bijzonder gevaarlijke valkuil in beheerpanelen: een actie met de naam ‘emergency unpublish DS’ kan betekenen dat alle DS-records worden verwijderd, inclusief het nieuwe, werkende record. Ook het uitschakelen van zoneondertekening terwijl er nog een DS-record is gepubliceerd, kan de storing onmiddellijk opnieuw veroorzaken. Geen van beide acties staat gelijk aan het verwijderen van één specifiek verouderd DS-record. Als de interface geen afzonderlijk record kan selecteren, laat dan via de registrar een gerichte wijziging uitvoeren in plaats van alles in één keer te resetten.

Zo wijzig je autoritatieve nameservers op een veilige manier

De veiligste volgorde hangt ervan af of de oude en nieuwe DNS-providers hun sleutels op elkaar kunnen afstemmen. Bij een gebruikelijke migratie met een tijdelijk niet-ondertekende periode voorkomt de volgende volgorde de mismatch die in dit incident optrad:

Bereid eerst de doelzone voor. Kopieer de vereiste A-, AAAA-, CNAME-, MX-, TXT- en andere relevante records. Test de nieuwe autoritatieve nameservers rechtstreeks voordat je de delegatie wijzigt.
Controleer DNSSEC in de bovenliggende zone. Kijk of er DS-records bestaan en wie die kan aanpassen. Doe dit ook als je DNSSEC nooit zelf hebt ingeschakeld; sommige DNS-diensten ondertekenen zones automatisch.
Verwijder het oude DS-record terwijl de oude ondertekende zone nog actief is. Controleer de wijziging bij de autoritatieve nameserver van de bovenliggende zone en wacht vervolgens lang genoeg totdat eerder gecachte DS-gegevens zijn verlopen. De wachttijd hangt af van de waargenomen TTL's, niet van een universeel vast aantal minuten.
Wijzig de nameserverdelegatie. Houd de vorige autoritatieve DNS-dienst beschikbaar zolang gecachte NS-delegaties er nog naar kunnen verwijzen. Houd rekening met de NS-TTL's van de bovenliggende zone en controleer welke servers verschillende resolvers daadwerkelijk gebruiken.
Beslis of je DNSSEC opnieuw inschakelt. Als de nieuwe dienst niet-ondertekend moet blijven, publiceer dan geen DS-record. Moet de zone wel ondertekend zijn, controleer dan of de nieuwe DNSKEY en handtekeningen correct worden aangeboden voordat je het bijpassende DS-record publiceert. Stem dit af op eventuele caches die nog oude NS-records bevatten, om een nieuwe validatiemismatch te voorkomen.
Valideer onafhankelijk. Controleer het DS-record in de bovenliggende zone, de autoritatieve DNSKEY, gewone recursieve DNS-resolutie en het resultaat van de authenticatie bij validerende resolvers.

Als ononderbroken DNSSEC-bescherming vereist is, verdient een uitdrukkelijk gecoördineerde sleutelovergang of een overgang met meerdere ondertekenaars de voorkeur boven een niet-ondertekende tussenperiode. Beide DNS-providers moeten daarvoor de benodigde sleutel- en ondertekeningsconfiguratie ondersteunen. Alleen de oude DS-digest naar de nieuwe provider kopiëren is geen sleutelovergang.

Korte controlelijst na de migratie

Controleer na elke wijziging aan DNSSEC zowel de DNS-records als het bewijs dat resolvers die accepteren:

dig example.com DS +noall +comments +answer
dig example.com DNSKEY +dnssec +noall +comments +answer
dig example.com A +dnssec +noall +comments +answer
dig example.com A +cdflag +noall +comments +answer

Gebruik voor het controleren van geauthenticeerde antwoorden een validerende recursieve resolver. NOERROR samen met het verwachte A-record betekent dat de DNS-resolutie is geslaagd. Een extra ad-vlag geeft aan dat de resolver het antwoord volgens zijn DNSSEC-beleid heeft geauthenticeerd. Ontbreekt de ad-vlag, dan bewijst dat op zichzelf nog niet dat er iets mis is, want de mogelijkheden en het beleid van resolvers en de gebruikte queryvlaggen verschillen. Als DNSKEY-query's via een validerende resolver tijdens een storing mislukken, vraag dan als onderdeel van het onderzoek ook de actieve autoritatieve DNS-dienst rechtstreeks op.

Stop niet na één geslaagd antwoord van een resolver. Verschillende caches kunnen tijdelijk verschillende delegaties en sleutels bevatten. Werk ook eventuele openstaande supportverzoeken bij: een eerdere instructie om alle DS-records te verwijderen wordt gevaarlijk zodra een nieuw, werkend DS-record is gepubliceerd. Vermeld in een vervolgbericht expliciet dat de actieve sleutel behouden moet blijven en dat, indien nodig, alleen het verouderde record verwijderd mag worden.

De storing werd niet veroorzaakt door een verkeerd webserveradres. Ze ontstond doordat de plek waarvandaan DNS-antwoorden werden geleverd veranderde, zonder eerst de vertrouwensgegevens aan te passen waarmee resolvers bepalen welke antwoorden ze kunnen vertrouwen. De praktische vraag vóór elke overstap naar andere nameservers is daarom: Welke DS-records publiceert de bovenliggende zone, en voldoen de DNSKEY en handtekeningen van de doelzone daaraan?