SIDN: banken scoren nog steeds slecht op dnssec-beveiliging

Volgens de SIDN is het slecht gesteld met de dnssec-beveiliging van Nederlandse domeinnamen. Vooral de bankensector zou slecht scoren met de invoering van de beveiliging, die onder andere moet voorkomen dat gebruikers naar valse ip-adressen doorgesluisd worden.

In de afgelopen jaren heeft de SIDN zich ingezet om de beveiliging van domeinnaaminformatie met digitale handtekeningen zo breed mogelijk ingevoerd te krijgen, onder andere met een incentive-regeling die de registrars een korting geeft op ondertekende domeinnamen. Dat had tot gevolg dat inmiddels 46 procent van de 5.701.008 .nl-domeinen met dnssec beschermd is, maar de grote groei is er wel uit. Grote invoeringsprojecten van providers zijn er in de afgelopen twee jaar niet meer geweest.

Bij een recente inventarisatie onder zevenduizend domeinnamen heeft de stichting de invoering per sector onder de loep genomen. De inventarisatie is als pdf beschikbaar. Daaruit blijkt dat vooral bij banken de invoering nog erg laag is: slechts 4 van de 64 domeinen zijn ondertekend. De stichting noemt dit zorgelijk. Ook bij de internet- en telecomsector valt er nog een wereld te winnen: van de 79 domeinen van internetproviders ondersteunen 17 dnssec. Mobiele aanbieders en de ondernemingen die verantwoordelijk zijn voor de datatransportbackbone, scoren volgens de SIDN ronduit slecht.

Roelof Meijer, algemeen directeur SIDN, wijst erop dat het de tweede keer op rij is dat banken het slechtst scoren, terwijl die het meest te maken hebben met spoofing en phishing. Overheden hebben een flinke inhaalslag gemaakt, want in 2014 was nog 14 procent van de overheidssites beveiligd maar inmiddels is dat 59 procent.

Reacties (35)

[PCR]

Ik klap er even simpelweg een linkje in met een goede uitleg over DNSSEC van SIDN: https://www.dnsseccursus.nl/

DNSSEC is best pittig om snel onder de knie te krijgen kan ik mij zo voorstellen.

Paar hoofdpunten van SIDN vanuit dat linkje die een verklaring kúnnen geven voor de wat moeizame opkomst van DNSSEC:

• Doorlooptijd voor het opzetten van DNSSEC is enkele weken tot enkele maanden
• Signen met DNSSEC is complex en vergt dus complexe kennis
• De configuratie van DNSSEC moet tiptop zijn. DNS vergeeft fouten veel makkelijker dan DNSSEC.
• Laste Mile Problem: er is geen verificatie van resolving vanaf de laagste resolver tot jouw browser

Punt 3 is op het gebied van veiligheid een voordeel en op het gebied van 99.9999% bereikbaarheid een nadeel. Het is hoe je er naar wilt en zou moeten kijken.

[Dorank]

Doorlooptijd voor het opzetten van DNSSEC is enkele weken tot enkele maanden

Het actieveren van DNSSEC is minuten werk, daarna loop je tegen de caching ttl van de bestaande records. MAW het is niet anders dan elke andere DNS wijziging.

Het deactiveren van DNSSEC is afhankelijk van de TTL van je eigen records en die van SIDN (lijkt 1 uur te zijn).

Signen met DNSSEC is complex en vergt dus complexe kennis

Als je een dnsserver gebruikt dit dit on the fly doet, heb je geen kennis nodig anders dan het achterhalen van de sleutels die je aan SIDN moet communiceren.

De configuratie van DNSSEC moet tiptop zijn. DNS vergeeft fouten veel makkelijker dan DNSSEC.

Garbage In / Garbage Out. In essentie is DNSSEC niet anders. Aan de inhoud wordt niets veranderd, alleen komen er meer records terug die de validiteit cryptografisch moeten waarborgen.

Laste Mile Problem: er is geen verificatie van resolving vanaf de laagste resolver tot jouw browser

Een browser heeft hier niets mee te maken, als je een DNS resolver gebruikt die DNSSEC validiteit afdwingt, heb je in het geval van fouten in DNS(SEC) geen resultaat op een DNS query.

[PCR]

Aangezien je al die punten van SIDN debunked ben ik benieuwd hoe zij er tegenaan kijken.

Ik twijfel wel wat aan het activeren van DNSSEC in een paar minuten bij grote organisaties als KPN, Rabobank en de overheid zoals je stelt. Denk je dat ze dat echt in zo'n korte tijd kunnen doen? Ik heb zelf geen ervaring met implementatie van DNSSEC in de praktijk bij grotere organisaties.

[CAPSLOCK2000]

Technisch gezien hoeft het inderdaad niet ingewikkeld te zijn en het wordt steeds eenvoudiger. Maar in de bankenwereld is niks ooit eenvoudig. Banken zijn oerconservatief en lopen altijd ver achter op andere sectoren waar veiligheid belangrijk is. Voor iedere scheet is daar een zes maanden durende procedure nodig met aanvragen in drievoud.

Het moeilijkste aan DNSSEC is procedureel. Je moet je omgeving monitoren en af en toe nieuwe keys publiceren. Banken zijn volgens mij wel goed in dat soort procedures netjes uitvoeren, wat dat betreft zijn ze dus in het voordeel.

[Dorank]

De laatste keer dat ik de cursus URL bekeken heb ik jaren geleden (op het moment dat ik DNSSEC wilde implementeren). Op dat moment leek het allemaal erg nieuw/eng/foutgevoelig. De praktijk wijst anders uit.

Als je "1" authoritative DNS platform hebt, is het echt super simpel als je getest hebt dat een test domain functioneerd. Als je met delegates werkt voor subdomeinen wordt het al moeilijker omdat je de keten van signers moet valideren (en die delegates wellicht onder jou controle vallen).

Maar hier werk ik met een plaform van powerdns met autosigning en replicatie via een database. Het activeren van DNSSEC is niets anders dan bij SIDN de keys toevoegen. Het enige probleem is dan bij een verhuizing van de domeinnaam, de klant moet zelf voor verhuizing even nadenken om DNSSEC ruim van te voren te deactiveren ('zn eigen verantwoordelijkheid, maar een goede hoster zal daarop wijzen).

[CAPSLOCK2000]

SIDN heeft daar een oplossing voor, die heet EPP Key Relay, maar niet alle hosters ondersteunen dat. Als beide partijen het ondersteunen dan hoeft de klant zelf niks te doen.

[Evdpol]

dnssec 2008 r2 server
max 45 min werk volgens het youtube filmpje
https://www.youtube.com/watch?v=ntws9XZ_lDU

[FvdM]

Punt 3 is op het gebied van veiligheid een voordeel en op het gebied van 99.9999% bereikbaarheid een nadeel.

Is er veel gebruikte client software bekend dat zich niet aan het protocol houdt?

Dat klinkt een beetje hetzelfde een mailclient die zich niet aan SMTP houdt, dan komt de mail gewoon niet aan. Op mijn mailserver zijn het altijd met 100% zekerheid alleen de spammers die bijvoorbeeld 'Mail To' doen ipv 'RCPT TO'. Dat is gewoon een domme fout. Geldt dat ook niet voor DNS, dat het de alleen de foute scripts zijn die de kantjes er af lopen?

[PCR]

Het gaat SIDN er meer om dat een onjuiste configuratie van DNS niet direct problemen hoeft op te leveren terwijl bij DNSSEC dat sneller problemen oplevert door onder meer de chain of trust.

Citaat uit gesproken tekst van mijn linkje naar SIDN: "In DNS werken net niet goed geconfigureerde settings meestal ook maar met DNSSEC moet alle instellingen kloppen."

[SiGNe]

Ik hoefde er zelf niks aan te doen, TransIP heeft 't standaard aanstaan bij hun domeinnamen.

[Evdpol]

dnssec 2008 r2 server
max 45 min werk volgens het youtube filmpje

https://www.youtube.com/watch?v=ntws9XZ_lDU

[lenwar]

Ik heb me is een tijdje geleden op het geheel ingelezen, en zo zaligmakend is heel DNSSEC niet. Het basisidee is natuurlijk goed, eigenlijk zelfs noodzakelijk, maar de uiteindelijk uitvoering is zeer matig.

- Extra verkeer tijdens DNS-requests
- Afhankelijkheden van extra services die authenticatie moeten uitvoeren
- Relatief zwakke encryptie
- Het is vrij complex om op te zetten (als je het eenmaal hebt, heb je het natuurlijk)

Mede door hoe het geheel is opgezet is het al meermalen gebeurd dat domeinen/sites niet beschikbaar waren doordat er ergens halverwege de keten een storing was

https://ianix.com/pub/dnssec-outages.html


Deze zaken zijn iets als DNSCurve beter opgenomen.

Bronvermelding is allicht niet helemaal neutraal, maar het is wel food-for-thought.
https://blog.opendns.com/2010/02/23/opendns-dnscurve/

[CAPSLOCK2000]

- Extra verkeer tijdens DNS-requests

In praktijk is dat niet echt een probleem. De meeste clients maken gebruik van lokale resolvers die de meest gebruikte records in de cache hebben staan.

- Afhankelijkheden van extra services die authenticatie moeten uitvoeren

Dat punt snap ik niet, welke services heb je het over? DNSSEC zit juist helemaal in DNS.

- Relatief zwakke encryptie

De crypto is modulair. DNSSEC is zo opgezet dat je crypto kan kiezen die past bij de situatie en je keuzes kan veranderen als dat nodig is. Op dit moment wordt er met goede reden nog veel gebruik gemaakt van SHA1 maar dat is niet fundamenteel.

DNSSEC wordt nog wel eens aangevallen omdat er nog veel gebruik wordt gemaakt van SHA1 en dat is tegenwoordig in de ban. Dat wordt echter vooral gedaan door mensen die crypto niet echt begrijpen. Alle crypto is kraakbaar als je genoeg tijd hebt, de vraag waar het om gaat is hoe lang een sleutel mee gaat en hoeveel tijd er nodig is om die te brute-forcen. Er zijn nog geen snelle aanvallen tegen SHA1 bekend.

Omdat DNSSEC gebruik maakt van kort levende sleutels die regelmatig gewisseld worden is het nog geen probleem dat er nog SHA1 gebruikt wordt voor sleutels die maar een paar dagen geldig zijn. Wel voorzien experts dat de dag er aan komt dat SHA1 gekraakt wordt. Voor die tijd wil je over zijn gestapt naar iets anders. SSL-certificaten gaan vaak jaren lang mee. Als je nu een SSL-cert aanvraag kun je beter maar geen SHA1 meer gebruiken; de kans is te groot dat het gekraakt wordt binnen de levensduur van dat certificaat. Als je het echter over DNSSEC-sleutels hebt en je sleutels maar 14 dagen mee gaan dan is het allemaal niet zo'n probleem.
Als je iets nieuws opbouwt kun je beter wat anders dan SHA1 gebruiken, maar het is niet zo dat de wereld omvalt als je het nog niet hebt uitgefaseerd.

Mede door hoe het geheel is opgezet is het al meermalen gebeurd dat domeinen/sites niet beschikbaar waren doordat er ergens halverwege de keten een storing was

Klopt, dat is een beetje het nadeel van alle vormen van beveiliging. Een slot op de voordeur houdt ook vaker de bewoners tegen dan inbrekers. In praktijk heb je er vooral last van, je hebt het voor die éne keer dat je het wel echt nodig hebt.

Deze zaken zijn iets als DNSCurve beter opgenomen.

Bronvermelding is allicht niet helemaal neutraal, maar het is wel food-for-thought.
https://blog.opendns.com/2010/02/23/opendns-dnscurve/

DNSCurve is helaas bedacht door DJB. DJB snapt veel van beveiliging maar aan DNS heeft hij een broertje dood (hij heeft ook z'n eigen DNS-server geschreven die afwijkt van wat de rest van de wereld doet). DNSCurve heeft overigens een opvolgers, DNSCrypt.

Beide systemen werken op een heel ander niveau dan DNS en lossen eigenlijk andere problemen op. Dat is ook nuttig, maar geen alternatief. DNSCurve/DNSCrypt werkt meer als HTTPS; die protocollen beveiligen eigenlijk alleen het kanaal, niet de inhoud. DNSCrypt is nuttig als je wil voorkomen dat je DNS-verkeer wordt afgeluisterd, je kan echter niet controleren of de informatie die je krijgt ook echt klopt.

[lenwar]

Klopt, dat is een beetje het nadeel van alle vormen van beveiliging. Een slot op de voordeur houdt ook vaker de bewoners tegen dan inbrekers. In praktijk heb je er vooral last van, je hebt het voor die éne keer dat je het wel echt nodig hebt.

Maar hier is het nogal een dingetje, dat als iemand iets met z'n sleutel doet, de hele straat niet meer z'n huis in kan. Het is al veelvuldig gebeurd dat er een heel TLD nier meer beschikbaar was doordat iemand een foutje maakte/er iets mis ging. Dus dat is nogal een dingetje.

DNSCurve is helaas bedacht door DJB. DJB snapt veel van beveiliging maar aan DNS heeft hij een broertje dood (hij heeft ook z'n eigen DNS-server geschreven die afwijkt van wat de rest van de wereld doet). DNSCurve heeft overigens een opvolgers, DNSCrypt.

Beide systemen werken op een heel ander niveau dan DNS en lossen eigenlijk andere problemen op. Dat is ook nuttig, maar geen alternatief. DNSCurve/DNSCrypt werkt meer als HTTPS; die protocollen beveiligen eigenlijk alleen het kanaal, niet de inhoud. DNSCrypt is nuttig als je wil voorkomen dat je DNS-verkeer wordt afgeluisterd, je kan echter niet controleren of de informatie die je krijgt ook echt klopt.

DNSCrypt verzorgt een encrypted verbinding met je ingestelde DNS servers (tegen afluisteren). DNSCurve heeft encrypted/signed DNS-records op de name servers staan. Dit zorgt dan toch voor de authenticiteit/integriteit van de data (want niemand kan die data nabootsen, tenzij ze m'n hele domein meenemen naar een andere Name Server en daar alle records opnieuw aanmaken, maar daar beschermd DNSSec volgens mij ook niet tegen toch?)

Dus in mijn beleving:
DNSCrypt - Gecodeerde verbdinding tussen 'mijn pc' en m'n 'DNS Servers'
DNSCurve - Authenticiteitscontrole tussen mijn DNS Cache en de Name Server Forwarders

Algemene info met bronvermeldingen in dit document:
https://www.softscheck.co...CURVE_RFIDSYSTECH2010.pdf

Als ik er helemaal naast zit hoor ik het graag

[CAPSLOCK2000]

Maar hier is het nogal een dingetje, dat als iemand iets met z'n sleutel doet, de hele straat niet meer z'n huis in kan. Het is al veelvuldig gebeurd dat er een heel TLD nier meer beschikbaar was doordat iemand een foutje maakte/er iets mis ging. Dus dat is nogal een dingetje.

Het is inderdaad van een andere schaal, maar tegelijkertijd is het nog maar zelden echt een probleem geweest. Alle begin is moeilijk maar de meeste grote jongens hebben hun zaakjes nu wel op orde en weten wat ze moeten monitoren enzo.
Ik verzorg al jaren DNSSEC-beveiligde resolvers voor vele duizenden gebruikers en het aantal incidenten is op de vingers van 1 hand te tellen.
Het is waar dat DNSSEC de boel complexer maakt en een extra kans toevoegt dat er iets stuk gaat, maar dat probleem lijkt niet groter dan de honderduizend andere problemen waar een website/domein stuk van kan gaan.

Dit zorgt dan toch voor de authenticiteit/integriteit van de data (want niemand kan die data nabootsen, tenzij ze m'n hele domein meenemen naar een andere Name Server en daar alle records opnieuw aanmaken, maar daar beschermd DNSSec volgens mij ook niet tegen toch?)

Jawel, DNSSEC beschermd daar wel tegen. Een belangrijk onderdeel van DNSSEC, dat zowel een sterke kant als een zwakte is, is dat je de sleutels publiceert in je "parent" domein. De sleutels van voorbeeld.com zijn dus opvraagbaar bij de DNS-servers van .com. Verhuizen naar een andere nameserver verandert daar niks aan.

Dus in mijn beleving:
DNSCrypt - Gecodeerde verbdinding tussen 'mijn pc' en m'n 'DNS Servers'
DNSCurve - Authenticiteitscontrole tussen mijn DNS Cache en de Name Server Forwarders

Dat klopt wel zo'n beetje.

DNSCurve zie ik gaan toekomst hebben, DNSCurve gaat er namelijk van uit dat je (al) de (authorative) nameservers echt kan vertrouwen en beheren. Alle nameservers moeten namelijk toegang hebben tot dezelfde private key. Als je kijkt hoe moderne DNS-infrastructuur er uit ziet, met honderden geografisch verspreide servers beheerd door verschillende cloud-partners dan denk ik dat die aanname niet vol te houden is.

Het belangrijkste voordeel van DNSCurve was snelle crypto. Omdat de crypto van DNSSEC modulair is kun je tegenwoordig echter ook die snelle crypto gebruiken die gebaseerd is op "curves".

Voor zover ik weet ligt de ontwikkeling van DNSCurve al jaren stil. Voor DNSCrypt zie ik nog wel een toekomst, maar DNSCurve gaat het denk ik niet halen.

[Verwijderd]

Voor firefox is er een extension die laat zien of een website dnssec/tlsa ondersteunt

https://www.dnssec-validator.cz/

[Maurits van Baerle]

Die gebruik ik ook. Best interessant om te zien wie er allemaal al aan DNSEC doen. Ik ben alleen volgens mij pas één site tegengekomen die ook TLSA op de webserver gebruikt (freebsd.org).

[CAPSLOCK2000]

Ik beheer er een paar, ik wil hier geen reclame maken, maar onze belangrijkste webservers van mijn organisatie (15k gebruikers) publiceren de juiste records.

Als je echt op zoek bent naar TLSA kun je misschien beter naar mailservers kijken. Mailservers hebben namelijk veel meer te winnen dan webservers. Voor webservers hebben we een hele rits technieken (HSTS, HPKP, SNI, een popup-up voor de gebruiker, https-everywhere) om aan te geven dat er HTTPS gebruikt moet worden en hoe.

Voor mailservers was er dusver helemaal niks. Ja, je kan wel SSL/StartTLS doen maar je kan het niet afdwingen. Vrijwel iedere mailserver doet een fallback naar plain-text als je SSL/StartTLS blokkeert of anderszins verstoort. Als MITM is het daarom dood eenvoudig om alle mailserver te forceren om encryptie uit te schakelen en plain-text te mailen.

DANE maakt daar een einde aan. Als je een moderne mailserver hebt (bv Postfix) dan zal die encryptie afdwingen als er een DANE-record is en desnoods weigeren om te verbinden als dat niet lukt.

[Verwijderd]

Sites die zich focussen op security en privacy lopen voorop

https://tutanota.com/nl/
https://www.torproject.org/

[Verwijderd]

Hoe moeilijk kan het zijn he?
Bind9 onder linux ondersteunt het out-of-the-box, dnsmasq volgens mij ook.

[bjv]

Eh, volgens mij bedoel je het valideren van DNSsec gesigneerde records. Volgens mij gaat het artikel over het met DNSsec ondertekenen van records/domeinen. Hiervoor moet je sleutels genereren en opnemen in de zone files. En het aller aller belangrijkste is er voor zorgen dat je nieuwe sleutels genereert voordat de oude verlopen. Kortom, er moeten procedures in place zijn binnen je organisatie voordat je DNSsec moet aanbieden.

Als banken ergens goed in zijn, dan zijn het procedures. Maar blijkbaar niet voor hun eigen domeinnaampjes...

[Edgarz]

Dit soort zaken doen banken zelf niet. Daarvoor zijn contracten afgesloten met vendoren/externe partijen. Dat maakt de kosten voor deze zaken (en benodigde procedures) ook direct een stuk hoger: Indien niet in het contract opgenomen gaat de teller dubbel lopen. Men wacht dus waarschijnlijk eerst op een contractherziening (en het zijn langdurige contracten), directe baten heeft deze vorm van beveiliging namelijk vrijwel niet. En security technisch is DNSec geen wondermiddel maar slechts een oplossing voor een relatief beperkt en klein potentieel probleem.

[Reactie gewijzigd door Edgarz op 23 juli 2024 05:54]

[CAPSLOCK2000]

En security technisch is DNSec geen wondermiddel maar slechts een oplossing voor een relatief beperkt en klein potentieel probleem.

Dat doet DNSSEC te kort, want dat is maar één aspect. Overigens zou ik het niet beperkt noemen, DNS zit in alle aspecten van internet. Als er iets mis gaat met DNS dat stort al het andere ook in.

Het andere aspect is dat DNSSEC het mogelijk maakt om DNS als "trust anchor" te gebruiken. Dat idee is op zich niet nieuw, er zijn al tal van protocollen die DNS gebruiken om beveilingsinformatie te verspreiden. Denk bijvoorbeeld aan SPF en DKIM, maar ook de codes die je publiceert om een SSL-certificaat aan te vragen of om je domein aan gmail te koppelen.
Dusver is dat alleen nooit beveiligd. We vertrouwden er maar op dat het goed zou gaan, maar daar kun je natuurlijk niet echt op bouwen.
DNSSEC maakt het mogelijk om dit soort informatie wel echt te vertrouwen. Er zijn al verschillende toepassingen die daar gebruik van maken, de bekendste is DANE. Met DANE publiceer je in DNS welke SSL-certificaten (of leveranciers) je gebruikt. Zo kan je client nog voor de eerste verbinding wordt opgezet al vaststellen of er SSL gebruikt moet worden. Voor protocollen als SMTP is dat heel erg hard nodig.
Andere leuke toepassingen zijn het publiceren van SSH-fingerprints en IPSEC-sleutels zo kun je een SSH / VPN verbinding opzetten met een onbekend systeem op internet en toch zeker weten dat je niet wordt geMITMed.

[jurri@n]

Ik neem aan dat je nu DNS resolvers bedoeld. Volgens mij doet dnsmasq geen authoritive DNS. Dat is nl. wel waar de SIDN onderzoek naar heeft gedaan.

Maar je bewering blijft verder correct. Bind, PowerDNS, ze ondersteunen het allemaal out-of-the-box zonder al te veel werk.

[labmuisfrl]

Bind inderdaad wel. echter zijn er nog een x aantal partijen die gebruik maken van bind in combinatie met dlz. deze heeft geen ondersteuning voor dnssec...

[Rik.]

Dit is wel een kwalijke zaak. Wij delen al onze gegevens met banken, maar de banken hebben zelf de zaakjes niet op orde.

Het is tijd dat de overheid hier eens wat harder tegen optreed... maar ook dat is lastig, die hebben het zelf ook niet op orde.

[kaphot]

Als je als bank al een named certificaat gebruikt moet al opvallen dat die niet gebruikt wordt.

Met https geef je aan dat de verbinding end-to-end van het certificaat versleuteld is. Dat wil nog niets zeggen of je end ook inderdaad de instantie is die jij wilt.

Er wordt veel gefocused op het snel uitrollen van https overal, terwijl de meeste pagina's geen privacygevoeligde data bevatten. Hierdoor wordt een vals gevoel van veiligheid gegeven, omdat je het certificaat moet vertrouwen en veel gebruikers niet verder kijken dan de kleur van het slotje.

Hetzelfde geldt voor bijvoorbeeld een whatsapp waarbij er wordt aangegeven dat de verbinding privé is. Daar wordt niet bij verteld dat Facebook rustig je berichten binnenkrijgt en door kan sluisen naar adverteerders etc.

Dnssec heeft als bedoeling dat je het juiste ip adres van een website krijgt, maar beschermt nog steeds niet tegen aanvallen op routers waardoor je bij een andere server met verkeerd certificaat terecht komt. In dat geval zal het ontbreken van named certificaat aangeven dat het niet om de juiste website gaat, terwijl dnssec daar niets tegen doet.

Daarom stellen dat banken en instanties slecht bezig zijn door wel named certificaten te gebruiken in plaats van dnssec getuigt van onkunde over security.

Daarnaast, wat bij dnssec wordt vaak niet gerealiseerd wordt is wat het effect is bij intrekken van het certificaat om wat voor reden dan ook. Dan krijgt iedereen een certificaatfout zodra ze de website willen bezoeken, totdat de dnssec provider het nieuwe certificaat ook in gebruik heeft genomen. Hierdoor kun je onnodig lang onbereikbaar zijn, terwijl het certificaat op de website nog steeds leidend moet zijn of de website te vertrouwen is.

En gebruik je een dns die niet gebruik maakt van dnssec heb je er ook nog eens niets aan.

[Reactie gewijzigd door kaphot op 23 juli 2024 05:54]

[Maurits van Baerle]

Volgens mij is DNSSEC aan de "serverkant" ook helemaal niet zo complex. Bij de meeste hosters die ik gebruik staat het standaard aan en hoef je er niets voor te doen. Mijn beleid is al een tijdje dat alle nieuwe projecten die public facing zijn Dual-Stack IPv4+IPv6 moeten zijn en HTTPS en DNSSEC gebruiken.

Als je het nou over Public Key Pinning hebt, dat is een compleet ander verhaal en daarbij begrijp ik dat banken erg voorzichtig zijn (ook al hebben ze er veel profijt van).

[Reactie gewijzigd door Maurits van Baerle op 23 juli 2024 05:54]

[hoenderdos]

Volgens de tool die Batiatus aangeeft heeft tweakers.net ook nog geen DNSSec. net zoals ing.nl en rabobank.nl

[Jeldert]

Volgens het rapport gaat het om de volgende 4 banken:

• ASN
• ASR
• DHB
• Interbank

[Vorkie]

Ik zie dat tweakers.net zelf ook dnssec nog niet helemaal heeft geïmplementeerd, heeft dat nog een reden?