Dit is de gearchiveerde site van het DNSSEC Kennisplatform (2012-2018).
Actuele informatie over DNSSEC vind je op https://sidn.nl/dnssec/.

Google Public DNS servers doen nu ook DNSSEC-validatie

Gepubliceerd op 04-02-2013

De publieke DNS -servers van Google leveren vanaf vorige week ook validatie-informatie als gebruikers om DNSSEC vragen. Daarmee wordt DNSSEC steeds minder vrijblijvend en worden fouten in de configuratie harder afgestraft. Operators en registrars moeten aan de bak.

Begin vorige week heeft Google de validatie van DNSSEC op zijn publieke DNS-servers aangezet. Dat betekent dat domeinen die zijn ondertekend vanaf nu ook daadwerkelijk goed validerende records moeten leveren. Validerende resolvers als Unbound blokkeerden slecht geconfigureerde domeinnamen al, maar deze worden nog maar weinig gebruikt. De meeste clients bevatten immers alleen een stub resolver die afhankelijk is van de DNS-dienst zoals die bijvoorbeeld door internet-provider of IT-afdeling wordt verzorgd.

De AD-vlag

Op dit moment zijn er nog maar weinig DNS-servers die naast caching ook validatie doen. Hier in Nederland gaat het onder andere om SURFnet, T-Mobile en BIT. Google Public DNS cachete wel al de DNSSEC (RRSIG) records voor zijn gebruikers, maar deed nog geen validatie.

Sinds deze week zet Google echter de AD-vlag in zijn antwoorden als een client vraagt om DNSSEC. We kunnen dat laten zien door dig de +dnssec optie mee te geven als we een van de twee publieke servers (8.8.8.8 en 8.8.4.4) benaderen:

dig +dnssec +multi +noqr +noauthority +nocmd +nostats @8.8.8.8 MX sidnlabs.nl

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53500
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
sidnlabs.nl.            21475 IN MX 5 kamx.sidn.nl.
sidnlabs.nl.            21475 IN RRSIG MX 8 2 68400 20130223053732 (
                                20130124052016 20853 sidnlabs.nl.
                                cWqFNe9EZTdAhrdZH1nXeh7/U4f9F4IUW8ggE0iNM4U6
                                VcZ5wohDBahKldXjZqAWOy35XN8dorqyWHFNJ76wXelA
                                imJoV/4uq7WV0I7SwA2YFxAFQF+qplv0fUnhbf1kBta6
                                F7zUVg0uTzR/Dio2CT/dI4t5Ml+PRTMMLTuS5Ck= )

Behalve dat nu ook het RRSIG record (de digitale handtekening) voor de MX (mail exchange) wordt meegeleverd, zien we ook dat de AD-vlag (Authentic Data) is gezet (in de regel die begint met ';; flags:'). Dat betekent dat Google's DNS-server de hele vertrouwensketen (chain of trust) voor dit record heeft kunnen valideren.

De +dnssec optie zorgt ervoor dat dig in zijn query de DO-vlag (DNSSEC OK) zet. Daarmee vraagt de resolver om zowel RRSIG records als validatie. Tot nu toe werd geadviseerd om de AD-vlag in queries niet te gebruiken. Maar op dit moment wordt gewerkt aan een uitbreiding waarbij de AD-vlag ingezet kan worden om alleen om validatie te vragen. Daarmee wordt DNSSEC dus een stuk efficiënter voor stub resolvers die zelf geen validatie doen.

The last mile

De preciezen zullen opmerken dat het transport van de AD-vlag van de (publieke) DNS-server naar de client niet is beveiligd. Hoewel het voordehandliggend is om de validatie van DNSSEC te combineren met het cachen van de DNS records, wordt daarbij wel de cryptografisch beveiligde DNSSEC-keten verbroken. Dat maakt centrale validatie en het gebruik van de AD-vlag beter geschikt voor netwerken waar de beveiliging van 'the last mile' gegarandeerd is: bedrijfsnetwerken, campusnetwerken, en gesloten netwerken van internet-providers en mobiele operators. Het lijkt er dan ook op dat validatie op de client in de toekomst de standaard gaat worden.

Voor zo ver ik weet biedt Google geen beveiliging voor de verbinding tussen gebruikers en hun servers, zegt Miek Gieben, technisch adviseur bij SIDN. Ben je paranoïde aangelegd dan kun je voor de DNS-dienst het TCP-protocol gebruiken. Dat wordt bijvoorbeeld ondersteund door Unbound. Nadeel is dat het (in vergelijking met UDP) nogal zwaar is, en ook geen 100 procent veiligheid biedt. Kortom: gebruikers van Google Public DNS zullen het pad tussen hun client en de Google-servers moeten vertrouwen.

Belangrijke consequenties

Deze verandering in Google's DNS-dienst heeft belangrijke consequenties voor DNS-operators. Met name bij verhuizingen blijken DNSSEC-configuraties regelmatig beschadigd te raken: de nieuwe operator/registrar ondersteunt nog geen DNSSEC maar het oude sleutelmateriaal (het DS record) blijft staan bij de bovenliggende TLD registry (voor de .nl-domeinen is dat SIDN). De schade van die defecte configuraties bleef tot nu toe beperkt omdat er nog maar nauwelijks gevalideerd werd. Maar nu de grootste DNS-dienstverlener ter wereld — eind vorig jaar verwerkte Google al meer dan 70 miljard queries per dag — is gaan valideren, kan de houder van een Domeinnaam (of zijn operator/registrar) het zich niet meer veroorloven om die situatie te laten voorbestaan.

Dit laat vooral zien hoe snel zaken zich kunnen ontwikkelen, aldus Gieben. Tot nu toe kon je nog foutjes maken want er werd maar weinig gevalideerd. Nu Google dat wel doet, is dat dus wezenlijk veranderd: fouten worden nu harder afgestraft. Daarbij benadrukt hij dat DNSSEC een standaard onderdeel van DNS wordt. Niet alleen de configuratie op de server maar ook de validatie op de client is straks de normaalste zaak van de wereld.

Terug naar het nieuwsoverzicht