Agressief cache-gebruik levert snelheidswinst en efficiëntie op voor validerende resolvers

Hergebruik van NSEC(3)- en wildcard-records

RFC 8198 beschrijft een mechanisme voor het hergebruik van NSEC(3)- en wildcard-records in de cache van validerende resolvers. Door eerst te checken of een domeinnaam binnen het bereik van een al aanwezig record valt, kunnen nieuwe DNS(SEC)-query’s uitgespaard worden.

Heb je bijvoorbeeld een NSEC-record voor het (alfabetische) interval bravo.example.nl–echo.example.nl in je cache staan omdat je eerder de (niet-bestaande) domeinnaam charlie.example.nl opvroeg, dan kan je resolver datzelfde record hergebruiken om direct te concluderen dat ook de domeinnaam delta.example.nl niet bestaat. Op vergelijkbare wijze kan de resolver gelijk een positieve response teruggeven op basis van een eerder opgeslagen wildcard-record.

[user@system ~]$ dig +norec +multi +dnssec TXT charlie.example.nl
    @anytest1.sidnlabs.nl
; <<>> DiG 9.16.30-RH <<>> +norec +multi +dnssec TXT charlie.example.nl @anytest1.sidnlabs.nl
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61750
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 01ba1cdf2e880b520100000062df0af94fdf0eea786e7f97 (good)
;; QUESTION SECTION:
;charlie.example.nl.	IN TXT
;; AUTHORITY SECTION:
example.nl.		300 IN SOA ex1.sidnlabs.nl. hostmaster.sidn.nl. (
				1075       ; serial
				14400      ; refresh (4 hours)
				3600       ; retry (1 hour)
				604800     ; expire (1 week)
				300        ; minimum (5 minutes)
				)
example.nl.		300 IN RRSIG SOA 13 2 3600 (
				20220823233422 20220724223422 7104 example.nl.
				llG5YyoIpZ/ubvNld3O6DSWUP8AvBO3+gmhN3VC13hRo
				3yxh7JrDhVKLwQRPJ1PhC591PN38bcakxjJCtcMBYA== )
example.nl.		300 IN NSEC _33078fba9732a68a53d15a15566f9857.example.nl.
                         A NS SOA MX TXT AAAA RRSIG NSEC DNSKEY HTTPS CAA
example.nl.		300 IN RRSIG NSEC 13 2 300 (
				20220806144230 20220714040659 7104 example.nl.
				qf7rOQnHaLOqL+mqpAb497OsoHjd8WXTFMwycQJMro2H
				xOynUDvLZvSLYzoKTc6iwT2MHEouOveSKo27W9f75w== )
bravo.example.nl.300 IN NSEC echo.example.nl. TXT RRSIG NSEC
bravo.example.nl.300 IN RRSIG NSEC 13 3 300 (
				20220815214455 20220716205201 7104 example.nl.
				aT1XN9fBDuVpXdltnpKEidYBkY9qPX8YQcSxNZXlVC7/
				e9mJ15t9jDHeeQqb9+8qh4qDpQ2tGKhk0Qgf9jPcXw== )
;; Query time: 12 msec
;; SERVER: 2001:678:8::53#53(2001:678:8::53)
;; WHEN: Mon Jul 25 23:28:25 CEST 2022
;; MSG SIZE  rcvd: 577

Grotere snelheid en efficiëntie

RFC 4035 specificeerde (in sectie 4.5) dat een validerende resolver omwille van de actualiteit van zijn cache geen NSEC(3)- en wildcard-records moet hergebruiken (de auteurs spreken in dat geval van het blokkeren van autoritatieve data). Dat verbod wordt in deze sectie ook technisch afgedwongen door voor te schrijven dat de cache entries van een dergelijke resolver altijd gebaseerd moeten zijn op een volledige domeinnaam (FQDN).

De update in RFC 8198 raadt omwille van de snelheid en efficiëntie nu juist wel aan om NSEC(3)- en wildcard-records te hergebruiken voor het direct teruggeven van respectievelijk negatieve en positieve responses. Dat betekent dat een validerende resolver in deze gevallen zelf een antwoord zal samenstellen (synthetiseren) op basis van de actuele (specifieke) query en de opgeslagen (generieker) response.

Dit zogenaamde agressieve cache-gebruik is inmiddels geïmplementeerd in veelgebruikte validerende resolvers als BIND, de PowerDNS Recursor en Unbound:

Root servers

Volgens de auteurs van RFC 8198 en ontwikkelaars van DNS-resolvers moet de efficiëntiewinst van agressief cache-gebruik niet onderschat worden en is dit zelfs een extra reden om DNSSEC te gaan gebruiken.

De grootste winst is te behalen op de root servers, waar meer dan de helft van de antwoorden [1, 2] uit NXDOMAIN-responses bestaat. Daarmee draagt dit mechanisme mogelijk ook bij aan het reduceren van DoS-aanvallen op het DNS-systeem (hoewel dergelijke aanvallen waarschijnlijk vaker direct zonder tussenkomst van cachende resolvers worden uitgevoerd). Maar daarvoor moeten eerst veel meer mensen DNSSEC gaan gebruiken.

De .nl-zone

Voor de .nl-zone is het percentage NXDOMAIN-responses veel lager: de afgelopen jaren is dat eerst opgelopen tot 10-15 procent, maar sinds 2 jaar is dit aandeel duidelijk aan het dalen (tot 5-10 procent nu). In dit geval kan die daling echter niet met de implementatie van RFC 8198 te maken hebben: tot voor kort was de .nl-zone ondertekend volgens de 'NSEC3 opt-out'-methode, wat betekent dat niet-ondertekende delegaties (dat wil zeggen: delegaties die wel NS-records maar geen DS-record hebben) geen eigen NSEC3-records kregen.

Die eerdere 'NSEC3 opt-out'-instelling hebben we eind 2022 uitgezet, zodat nu ook de niet-ondertekende delegaties van NSEC3-records zijn voorzien. Behalve een performance-verbetering voor validerende resolvers (als die agressief cache-gebruik ondersteunen), levert dat ook een extra bescherming op mocht de .nl-zone ooit in verkeerde handen vallen. Die NS-records kunnen nu immers niet meer veranderd worden zonder ook de bijbehorende NSEC3-records aan te passen.

Overigens hebben we geen nader onderzoek gedaan naar die grote pieken in de NXDOMAIN-responses. Het kan hier gaan om meetproblemen, DoS-aanvallen of pogingen om de .nl-zone middels brute-force te inventariseren (die laatste het meest waarschijnlijk).

Oude bug: foutieve NSEC-records

Rest ons nog te spreken over een oude bug in de software van netwerkleverancier F5 die nog steeds regelmatig problemen oplevert in combinatie met agressief cache-gebruik: Oudere versies van hun software (gebaseerd op BIND met een eigen front-end dat ook de ondertekening voor zijn rekening neemt) genereren foutieve NSEC-records waarin sommige van de recordtypen ontbreken. Omdat NSEC-records volgens de standaard alle aanwezige grenzen moeten bevatten, mogen resolvers die RFC 8198 ondersteunen ervan uitgaan dat niet-opgenomen recordtypen ook niet bestaan. Als gevolg daarvan kunnen bepaalde domeinnaam/recordtype-combinaties op bepaalde momenten (afhankelijk van wat er in de cache van de resolver is opgeslagen) onbereikbaar zijn.

Hoe moeilijk een dergelijk intermitterend probleem op te lossen is, ondervond network/systems engineer Ruben van Staveren. Omdat het MX-recordtype ten onrechte ontbrak in het NSEC-record, kon een klant zijn mail (soms) niet afleveren bij het domein 'minjenv.nl'. Terwijl Van Staveren in het probleem dook, moest de klant wel door. Vandaar dat daarvoor een aparte Unbound-instantie werd opgezet naast het dnsdist/PowerDNS-systeem. Tegelijkertijd bemoeilijkte dit wel het onderzoeken van deze sporadisch optredende fout. Alles bij elkaar is hij weken bezig geweest om te achterhalen wat er precies aan de hand was (op het moment van schrijven is deze bug op het 'minjenv.nl'-domein nog steeds niet gefixt).

Probleem bij operators van resolvers op het bord

Van Staveren blijkt bovendien niet de enige die tegen deze oude bug is aangelopen. Senior PowerDNS engineer Peter van Dijk zegt dat hij dit probleem nog steeds elke één à twee maanden tegenkomt. Hij "lost dat dan op" door een negatief trust anchor voor de betreffende domeinnaam in te stellen.

Voor sommige grote aanbieders van DNS-diensten en ontwikkelaars van DNS-resolver-software is deze bug zelfs aanleiding geweest om hun implementatie van RFC 8198 minder agressief te maken (ten koste van hun performance): zij gebruiken de grenswaarden in de NSEC(3)-records niet om een negatieve response te genereren.

Leverancier F5 heeft deze bug destijds wel gefixt in hun software [1, 2], maar het blijkt lastig/duur voor klanten om hun systemen te updaten, waarmee dit probleem nu bij operators van resolvers op het bord terecht komt.

Heb je als operator intermitterende problemen met het resolven van een specifieke domeinnaam, en denk je dat deze bug de oorzaak kan zijn, check dan bij de autoritatieve name server of daar niet ook een NSEC-record gepubliceerd is dat in tegenspraak is met het record voor de betreffende domeinnaam: in dat geval bevat het NSEC-record wel de betreffende domeinnaam als grens, maar niet het betreffende recordtype. De makkelijkste oplossing is dan inderdaad om een negatief trust anchor voor het betreffende domein aan te maken.