SIDN gaat korting geven op domeinnamen met geldig security.txt-bestand

SIDN gaat websites korting geven als die een geldig en bruikbaar security.txt-bestand aanbiedt. Dat heeft de registry bekendgemaakt. Nu gebruikt ongeveer 2,2 procent van de .nl-domeinnamen een geldig security.txt.

De bedoeling van de korting is dat websites sneller overgaan tot het aanbieden van het tekstbestandje op de site, meldt SIDN. Hoe hoog de korting zal zijn en vanaf wanneer die gaat gelden, is nog onduidelijk. Het is onderdeel van meer maatregelen die SIDN neemt om het gebruik van security.txt aan te jagen. De bedoeling is dat er een plug-in komt voor hostingpakketten zoals Wordpress, om het tekstbestand makkelijk aan te maken en te beheren.

Security.txt is een standaard, waarin sites aan beveiligingsonderzoekers kunnen laten weten hoe en bij wie ze beveiligingsproblemen kunnen melden. Vooral het Digital Trust Center, onderdeel van het ministerie van Economische Zaken, ziet graag dat sites gebruik gaan maken van deze tekstbestandjes. Nu is de organisatie veel tijd kwijt aan het opsporen van de juiste mensen bij sites om beveiligingsproblemen te melden.

Lees meer

IT-banen

Reacties (86)

NLkaiser
14 maart 2024 18:48

Beetje jammer alleen dat sidn zelf geen security.txt file host

eelkef

@NLkaiser • 14 maart 2024 18:54

SIDN heeft zelf een redelijk uitgebreide staan op
https://www.sidn.nl/.well-known/security.txt.
Zou je ook als template kunnen gebruiken om zelf een security.txt-bestand te maken met eigen gegevens en PGP-key.

Natuurlijk is het beste om de standaard er bij te pakken als je het security.txt-bestand opzet.

Robtimus
@eelkef • 14 maart 2024 18:58

Ik denk dat https://securitytxt.org/ gebruiken om een security.txt bestand te genereren een stukje makkelijker is.

timothee
@Robtimus • 30 maart 2024 10:42

Klopt, alleen kun je via die website geen PGP toepassen. Het wordt wel aanbevolen, maar je moet zelf uitzoeken hoe je dat moet doen.

Netburst
@eelkef • 14 maart 2024 22:48

Grappig, http/403 via VPN

thutex
@eelkef • 15 maart 2024 14:04

en gelijk krijg je dan een mooie manier voor harvesters om al die lekkere email adresjes te gaan komen plukken....
waarom een txt file en niet gewoon een aparte pagina waar je een form neerpoot ofzo?
(ja, ok, dat kan vulnerable zijn of stuk zijn of.... maar die txt file vergeten te updaten is hetzelfde)

deadinspace
@thutex • 15 maart 2024 19:18

en gelijk krijg je dan een mooie manier voor harvesters om al die lekkere email adresjes te gaan komen plukken....
Waarom [...] niet gewoon een aparte pagina waar je een form neerpoot ofzo?

Waar heb je het over? Je kunt zelf kiezen of je e-mail adressen of een contactpagina in security.txt zet. e-mail adressen zijn alleen te harvesten als je die noemt, net als op elke andere webpagina.

... waarom een txt file ...

Omdat security.txt gestandaardiseerd is. Hierdoor is simpel en eenduidig (en eventueel geautomatiseerd, en eventueel digitaal ondertekend) te bepalen waar je moet zijn voor deze zaken.

thutex
@deadinspace • 15 maart 2024 21:16

dacht dat het nog in proposed zat en niet accepted/standardized (wel snel implemented door veel partijen, maar dat is niet altijd hetzelfde als standardized, toch?).
maar als je dus 'kan kiezen' en een contactpagina erinzet, heeft diezelfde site owner dan wss ook al een eenvoudig te vinden contactform (of, if not, doen ze de moeite wss niet voor de txt file aan te maken)

ergens anders werd het idee aangehaald dat de hoster dat gewoon 'in bulk' doet zodat zij bereikbaar zijn indien een van diens klanten vulnerable is, en op dat vlak is de txt wél weer logisch eigenlijk.
maar dan heeft die korting dus weinig zin, althans, voor de eindklant (de hosters zetten een txt op voor al hun klanten, en pocketen de korting zelf gewoon)

let op: ik zeg zeker niet dat het geen voordelen zou hebben (au contraire), maar de adoptie zal wss vooral gebaseerd gaan zijn op de hosters en weinig toegevoegde waarde of kortingen opleveren voor eindklanten.
(en afhankelijk van de hoster zijn houding, mss ook even weinig naar security toe)

Robtimus
@NLkaiser • 14 maart 2024 18:53

Ik denk dat je verkeerd kijkt, want deze bestaat wel degelijk: https://www.sidn.nl/.well-known/security.txt

Raymond Deen
@NLkaiser • 14 maart 2024 21:27

Zie het volgende fragment:

3. Location of the security.txt File
For web-based services, organizations MUST place the "security.txt" file under the "/.well-known/" path, e.g., https://example.com/.well-known/security.txt as per [RFC8615] of a domain name or IP address. For legacy compatibility, a "security.txt" file might be placed at the top-level path or redirect (as per Section 6.4 of [RFC7231]) to the "security.txt" file under the "/.well-known/" path. If a "security.txt" file is present in both locations, the one in the "/.well-known/" path MUST be used.

Afkomstig van: https://www.rfc-editor.org/rfc/rfc9116

Herko_ter_Horst

14 maart 2024 18:02

Websites? Sinds wanneer doet SIDN in websites?

Het gaat dus om domeinen c.q. domeinhouders. Maar domeinhouders doen geen zaken met SIDN, maar met een van de vele registrars. De korting gaat naar de registrar en dan is het maar afwachten of die dat doorgeeft aan de domeinhouder.

joppybt
@Herko_ter_Horst • 14 maart 2024 21:16

Ik vind dit ook heel vreemd.

SIDN gaat over domeinnamen. Daar wordt in de praktijk heel vaak een DNS achter gehangen met een A-record dat wijst naar een website. Maar dat is geenszins verplicht. Je kunt uitstekend een domeinnaam geregistreerd hebben zonder dat daar ooit een website achter komt.

Een waarom specifiek de focus op security.txt? Gaat SIDN ook korting geven als je website (zoals het hoort) https ondersteunt? En nog meer korting als je netjes TLS 1.3 met sterke cipher suites ondersteunt?

Calypso
@Herko_ter_Horst • 14 maart 2024 18:20

Precies - en wanneer gaat de korting dan gegeven worden, bij initiele registratie gaat in elk geval niet lukken. Ook een leuke:als je een domeinnaam alleen hebt voor bijv. mail of andere doeleinden (en dus geen website hebt), dan zou je geen korting krijgen?

Maar het is een initiatief lijkt het vanuit de Vereniging van Registrars; ik heb een vermoeden wie er van gaan profiteren...

[Reactie gewijzigd door Calypso op 14 maart 2024 18:22]

Azbest
@Herko_ter_Horst • 14 maart 2024 23:18

Nou dat, en dan nog zoiets: Welke oen gaat heden in 2024 een plain tekst bestand op internet zetten met zijn contact gegevens. Dat is ongeveer hetzelfde als roepen: SPAM? Ja graag!

Defspace
@Azbest • 15 maart 2024 01:23

Inderdaad. Ik heb zelf een tijdje een security.txt bestand op mijn site gehad met uiteraard een speciaal security adres, nog nooit zo snel zo veel spam gehad. Ik ga zeer zeker geen 06 vermelden.

deadinspace
@Azbest • 15 maart 2024 19:24

Nou dat, en dan nog zoiets: Welke oen gaat heden in 2024 een plain tekst bestand op internet zetten met zijn contact gegevens. Dat is ongeveer hetzelfde als roepen: SPAM? Ja graag!

Dan zet je toch je contact-pagina die voor dit soort zaken gebruikt mag worden in de security.txt? Het is niet alsof het een e-mail adres moet zijn ofzo.

laptopleon
@Azbest • 15 maart 2024 23:24

Afgezien daarvan: Ik dacht dat hier het veldje ‘abuse contact’ voor was bedacht in de whois db?

Ethelind
@DarkForce • 15 maart 2024 13:39

Mooie mailbox om de spamfilter te trainen toch?
Gelijk alles wat in /spam/ gezet word door jezelf laten in trainen door je spamfilter.
Win Win situatie.

x86dev
@DarkForce • 17 maart 2024 10:51

Bestandje voorzien van dummy data. Jouw website, jouw content.

[Reactie gewijzigd door x86dev op 17 maart 2024 10:52]

Lagonas
14 maart 2024 17:59

Het probleem dat ik zie is; Hoe gaat de eigenaar van de website deze korting krijgen? Het domeinnaam wordt normaliter afgenomen bij een webhoster, niet rechtstreeks bij SIDN.

moppentappers
@Lagonas • 14 maart 2024 18:00

Niet, de webhoster zorgt dat overal een security.txt is die waarschijnlijk dan naar de hoster leid en die pakt het dan verder op naar de klant toe.

Robtimus
@moppentappers • 14 maart 2024 18:52

Als mijn hoster dat doet dan ben ik er z.s.m. weg. Dat betekent namelijk dat ze de content van mijn website aanpassen, en daar moeten ze vanaf blijven.

EnigmA-X

@Robtimus • 14 maart 2024 19:41

Jouw hoster hoeft daar geen content voor aan te passen.

Wat vrijwel iedere hoster zal doen is een alias configureren in de nginx/apache configuratie welke /.well-known/security.txt afvangt naar een centrale file.

Exact zoals ze dat doen met error pages zoals @mmjjb ook noemt.

svennd
@EnigmA-X • 15 maart 2024 09:33

Maar dat is toch niet echt de bedoeling ? security.txt is bijvoorbeeld om vulnerabilities te melden, maar als webhoster kun je toch die oude wordpress niet upgraden zonder de eigenaar mooi te vragen ?

EnigmA-X

@svennd • 15 maart 2024 13:54

De meeste wordpress hosters maken gebruik van een soort "multisite" wordpress instance. Dus niet een wordpress install per website. In bijna alle gevallen wordt de wordpress install door de webhoster gemanaged (qua versie en update policy).

Los daarvan kan je het ook van een ander perspectief bekijken: een klant weet nauwelijks/niet wat een vulnerability is en/of wat hij/zij daarmee moet. Krijgt de klant de melding en doet die er vervolgens niets mee, dan krijgt de webhoster meestal de schuld als de website wordt gedefaced of informatie lekt.

Een webhoster heeft niet alleen wat meer kennis in huis, maar kan zo ook zijn reputatie beschermen. Als het ernstig is kan een webhoster een website ook gewoon geheel offline halen (uitschakelen) indien er sprake is van een ernstige vulnerability.

mmjjb
@Robtimus • 14 maart 2024 19:02

Deels heb je gelijk, maar het zelfde geld voor het aanbieden van bijv. Letsencrypt; een default error pagina, etc.

In welke mate is het aanpassen als het een fallback is? Letterlijk genomen: ja. Maar de meeste gebruikers zullen dit waarsch. zelfs als een plus punt zien, als de hoster een eventuele melding bijv. automatisch doorzet naar de klant

Frame164
@Robtimus • 14 maart 2024 19:46

Liever dat een hoster dit algemeen doet dan dat men dit aan allerlei developers overlaat die het als sluitpost maar even uitstellen en vergeten. De ervaring leert dat dit geen favoriete zaken zijn waar devs mee bezig zijn. Het zijn allemaal "moetjes" en als het even kan sla je dat over.

CAPSLOCK2000

SIDN
Nederland
Websites en community's

@Frame164 • 15 maart 2024 11:42

De vraag is wel een beetje hoeveel de hoster kan doen.
Het doel van security.txt is (contact)informatie aanbieden. Die moet wel kloppen anders heb je er niet veel aan. Typisch zal de hoster dat niet weten en zeker niet mogen gebruiken, van de AVG. De hoster kan dus hooguit de eigen gegevens in security.txt zetten. Iets is beter dan niets maar ik heb twijfels hoeveel de hoster echt kan aanbieden.

McBacon
@moppentappers • 15 maart 2024 09:23

En wat als je een VPS'je met een web service bij een ander bedrijf hebt dan waar je de domeinnaam hebt geregistreerd? Of überhaupt een (unmanaged) VPS, de hoster gaat niet zomaar inloggen en jouw eigen configs aanpassen.

moppentappers
@McBacon • 15 maart 2024 10:55

Dan krijgen ze de korting niet, die situaties zijn toch de minderheid.

CyBeR
@Lagonas • 14 maart 2024 18:03

Niet. De domeinnaamregistrar krijgt de korting, met het idee dat die hosters cq. site-eigenaren (cq zichzelf) aansporen om security.txt te implementeren. Of zij een dergelijke korting vervolgens ook bieden aan de domeinnaameigenaar is vervolgens aan hen.

Zo heeft SIDN dat ook gedaan voor DNSSEC met als gevolg dat .nl een van de meest-beveiligde TLD's is.

RobbyTown

@CyBeR • 14 maart 2024 18:37

DNSSEC is voor sommige webhosters ook een mooie oplossing voor kopperverkoop.

Zie Blog antagonist, stukje naar beneden in de reactie.

Wil je DNSSEC en domein bij Antagonist? Dan ook de rest afnemen bij Antagonist anders heb je geen DNSSEC op je .nl Dus jammer maar helaas je kan geen Cloudflare gebruiken.

Als test even gekeken als het andersom dan wel kan

. Het bijzonder is wel dat het andersom wel werkt. Bij mijn.host de .nl staan, de nameservers van antagonist gepakt dan werkt DNSSEC wel. Zie screenshot.

Die info staat nergens echt duidelijk vermeld. Wanneer het wel en niet kan en hoe en wat. Na wat speurwerk / artikelen lezen kom je het dus toevallig tegen.

EnigmA-X

@RobbyTown • 14 maart 2024 19:54

DNSSEC laat zich niet eenvoudig configureren wanneer je registrar niet jouw DNS-hosting doet. Jouw DNS host moet namelijk bepaalde records hosten om DNSSEC te laten werken. Jouw key moet hash validatable zijn met de DS van de TLD registry (en die moet weer validatable zijn met de root).

Dit is voor Jan met de Pet die de website van de spelletjesclub wil hosten niet uit te leggen. Dat zal de voornaamste reden zijn dat een partij als Antagonist gewoon dit advies geeft, gebaseerd op het gemiddelde type klant wat zij hebben.

Tot slot, het feit dat jij in de SIDN-whois ziet dat DNSSEC enabled is, wil niet zeggen dat het goed geconfigureerd is. Als jij verzaakt de juiste records aan te maken staat daar gewoon "ja", maar werkt het niet.

RobbyTown

@EnigmA-X • 14 maart 2024 20:14

Klopt, je moet er wat werk instoppen. Voor de leek alles bij 1 partij handig, die zullen ook niet van cloudflare hebben gehoord of snappen hoe dat samen gaat met nameservers enzo

Tot slot, het feit dat jij in de SIDN-whois ziet dat DNSSEC enabled is, wil niet zeggen dat het goed geconfigureerd is. Als jij verzaakt de juiste records aan te maken staat daar gewoon "ja", maar werkt het niet.

Goeie dat wist ik niet. Ik dacht als daar DNSSEC staat ja dan zal het wel kloppen

.

Het volgende namelijk ervaren toen ik het is ging testen.
Vanuit mijn.host op ns van mijn.host stond DNSSEC op ja (via whois), logisch eigen spul
Daarna bij mijn.host de ns op antagonist geeft DNSSEC nee aan (via whois), logisch het is over 2 partijen verdeeld.
Via deze tool: https://dnschecker.org/dn...up.php?query=&dns=dnsauth die keys opgesnort en ingevoerd bij antagonist mijn.host (omdat domein bij mijn.host staat maar de hosting antagonist is)
Nog een keer whois gedaan. DNSSEC is naar ja gegaan. Maar lijkt niet alles te zeggen lees ik nu.

Even check via internet.nl gedaan (geen idee als dat dan klopt en wel veilig is of dat het dan ook hetzelfde is als de 'ja' bij whois die dus niet alles wil zeggen. Het lijkt goed te zijn.

[Reactie gewijzigd door RobbyTown op 14 maart 2024 21:10]

Spykie
@RobbyTown • 15 maart 2024 08:01

De beste tool om dit eventjes te testen vind ik: https://dnsviz.net de website van verisign hieronder werkt stukken beter.

Het is dus belangrijk dat je de DNSSEC sleutels van je DNS infrastructuur publiceert bij de partij die de domeinnaam in beheer heeft. Als je dat niet doet heb je een DNSSEC sleutel mismatch en zal je domeinnaam offline gaan.

Bijkomend probleem bij de .NL TLD is dat de .NL zone maar eens per uur bijgewerkt wordt waardoor, in tegenstelling tot andere TLD's, DNSSEC wijzigingen niet live plaatsvinden maar in plaats daarvan met maximaal een uur vertraging verwerkt worden.

[Reactie gewijzigd door Spykie op 15 maart 2024 09:09]

3raser
@Spykie • 15 maart 2024 09:05

Ik vind die tool nogal omslachtig en traag. Ik gebruik altijd de tool van Verisign om te controleren of DNSSEC werkt. Die is heel rap en geeft duidelijk met vinkjes aan wat er wel en niet klopt. Staat alles op groen, dan werkt DNSSEC.

Spykie
@3raser • 15 maart 2024 09:08

Bedankt voor de aanvulling!

Geloof het of niet, maar die tool bedoelde ik eigenlijk

Het was nog vroeg'ish

[Reactie gewijzigd door Spykie op 15 maart 2024 09:09]

jaaphuib
@3raser • 15 maart 2024 18:43

Wat is er mis met https://internet.nl ?

3raser
@jaaphuib • 16 maart 2024 10:30

Waarom zou daar iets mis mee zijn?

GertMenkel

Websites en community's

@RobbyTown • 14 maart 2024 21:00

Ik heb nooit bij antagonist gehost, maar ik heb ook nooit echt problemen gehad met het hosten van .nl-domeinen met valide DNSSEC. Je registrar moet wat DNS-records goed zetten, en als Antagonist dat niet voor elkaar kan krijgen maar een vage partij als Versio wel, zegt dat wat over de kwaliteit die ik van Antagonist's service kan verwachten.

RobbyTown

@GertMenkel • 14 maart 2024 21:16

Als je alles bij 1 partij pakt staat DNSSEC goed. Niets aan de hand alles is netjes ingesteld.

Als je gaat splitten mijn.host het domein en de hosting bij Antagonist.

Nameservers van antagonist ingegeven bij mijn.host in. Als je niets doet blijft bij mijn.host in elk geval het sleutel stuk leeg. Met als gevolg DNSSEC nee.

Die heb ik er toch handmatig in moeten zetten om het weer op DNSSEC te krijgen. Maar een 'leek' heeft geen idee hoe je aan de sleutel komt, het word door mijn.host niet automatisch opgehaald wat Antagonist heeft.

[Reactie gewijzigd door RobbyTown op 14 maart 2024 21:16]

GertMenkel

Websites en community's

@RobbyTown • 14 maart 2024 23:30

Ik denk dat leken en domeinnamen sowieso niet geweldig samengaan, helemaal als die meerdere hosts gaan gebruiken. Er is een reden dat dit meestal door externe bedrijven wordt gedaan.

Gelukkig/jammer genoeg maakt de status van DNSSEC toch niet zoveel uit, omdat het een vaag protocol is dat allerlei extra opties en configuratie nodig heeft om nut te hebben. In tegenstelling tot HTTPS, is er eigenlijk geen enkele druk om je DNSSEC goed in te stellen en is de impact van een compleet kapotte DNSSEC-configuratie minimaal. Het levert vooral een leuke score op internet.nl op.

RobbyTown

@Lagonas • 14 maart 2024 18:19

Precies. Daar ben ik ook benieuwd naar.

Als het via domeinnaamregistrar gaat en dat implementeren strijken sommige nog meer winst op

.

Kort lijstje (zonder kortingen jaar op jaar prijs voor .nl). Sommige lopen al lekker binnen, met de korting erbij nog meer dan of gaat de klant een daling van .nl prijzen zien

?

ex btw prijs jaar op jaar
mijn.host €4,99
intention €7,99
antagonist € 14,26
versio € 21,99

t.martinali
@RobbyTown • 14 maart 2024 20:31

SIDN geeft nog veel meer korting als je veel domeinnamen hebt.

(zie ook https://tweakers.net/nieuws/57284/hostingbedrijven-in-geweer-tegen-prijsverhoging-sidn.html)

"Deelnemers met meer dan 10.000, 25.000, 50.000 of 100.000 domeinnamen in beheer, krijgen respectievelijk 2 procent, 4 procent, 6 procent en 8 procent korting op hun factuur."

emansom
@Lagonas • 14 maart 2024 18:12

Niet te veel vragen stellen, bij SIDN hebben ze alles tip top in orde en verstand van zaken!

_PieterZ
14 maart 2024 17:59

Nog nooit over deze standaard gehoord, klinkt interessant immers ik een aantal .nl domeinen in eigendom heb. Ookal weet ik niet of het maatschappelijk verantwoord is door korting aan te bieden, denk ik wel dat dit een goede aansporing is om het web veiliger te maken.

RobbyTown

@_PieterZ • 14 maart 2024 18:11

https://internet.nl/ die 'tool' checkt er sinds een tijd oa op.
Was toen ook in het nieuws: nieuws: Internet.nl voegt validatie voor security.txt toe aan domeintest

autostatic
@RobbyTown • 14 maart 2024 18:22

Is sinds vorig jaar een verplichting voor sites die aan de overheid gelieerd zijn: https://www.digitaleoverh...-verplicht-voor-overheid/
Ook is het aan te raden dit te implementeren als je zaken doet met de overheid.

gaitjan2
@RobbyTown • 14 maart 2024 18:16

Ja, en die test is behoorlijk kritisch!
En dan niet kwa inhoud maar qua vormgeving.
Iets met CR+LF of zoiets.

[Reactie gewijzigd door gaitjan2 op 15 maart 2024 19:14]

RobbyTown

@gaitjan2 • 14 maart 2024 18:22

Nou vooral een klein beetje irritant op sommige punten

.

Als www zonder je primair is, ziet die security.txt als OK (als je dat hebt ingesteld natuurlijk)

Als je dan op www erbij checkt dan scoort alles OK behalve dat security.txt want die staat niet op de www maar op de non www.

aikebah
@RobbyTown • 14 maart 2024 18:50

Als je dan op www erbij checkt dan scoort alles OK behalve dat security.txt want die staat niet op de www maar op de non www.

Kwestie van gewoon ff zelf een redirect op de www voor inregelen naar je niet-www security.txt zou ik verwachten? Of gaat de tool daar niet goed mee om?

RobbyTown

@aikebah • 14 maart 2024 19:14

Dat snapt die dus niet / kan die niet mee omgaan. Dan komt er ook nog een advies over Canonical. Die is dus non www, als je dus met www checkt beginnen ze daarover. internet.nl heeft dus een waardeloze uitleg

.

Hieronder de fix $_/-\o_$
GertMenkel in 'SIDN gaat korting geven op domeinnamen met geldig security.txt-bestand'

[Reactie gewijzigd door RobbyTown op 14 maart 2024 21:32]

aikebah
@RobbyTown • 14 maart 2024 20:36

da's wel slecht van die tool dan ja

autostatic
@RobbyTown • 14 maart 2024 21:06

Zelf doe ik het andersom (non-www redirecten naar www en security.txt Encryption en Canonical velden op de www versie) en dat werkt wel. Volgens mij is dit stukje nog wel een beetje een moving target, is nog niet helemaal uitgekristalliseerd hoe je dit het beste kunt implementeren.

GertMenkel

Websites en community's

@RobbyTown • 14 maart 2024 21:05

Je kunt meerdere Canonical-URL's invullen als zowel www.domein.nl als domein.nl op hetzelfde bestand uitkomen. Zie de spec:

If this field appears within a "security.txt" file and the URI used to retrieve that file is not listed within any canonical fields, then the contents of the file SHOULD NOT be trusted.

Canonical: https://www.example.com/.well-known/security.txt
Canonical: https://someserver.example.com/.well-known/security.txt

RobbyTown

@GertMenkel • 14 maart 2024 21:25

Dank voor deze gouden tip $_/-\o_$ . Nu is zowel www als non goed. Zo duidelijk word het niet helemaal op internet.nl verteld

. Had maar 1 Canonical.

mmjjb
@RobbyTown • 14 maart 2024 19:14

Goede test! Thanks voor de tip!

Info voor mede tweakers:
Triest om te zien dat Office 365 (Exchange) by default geen IPv6 ondersteuning heeft.

Moet zo te lezen aangevraagd worden via een support ticket: https://www.alitajran.com/enable-ipv6-exchange-online/

RobbyTown

@mmjjb • 14 maart 2024 19:20

Zo zijn er nog wel meer.

Wat dacht je van Cloud86, allemaal zeer positieve reviews en test verslagen maar ze hebben geen ipv6, alleen bij VPS.

In die verslagen zoals deze en deze (zelfs de beste webhosting) geen woord over ipv6 dat ze dat niet hebben. Maar op internet.nl ga je nooit 100% krijgen bij webhosting enkel bij vps (en dat is nogal aan de prijs) als je dus daar klant bent ook al zit je bij de nr 1 provider.

[Reactie gewijzigd door RobbyTown op 14 maart 2024 19:22]

autostatic
@RobbyTown • 14 maart 2024 21:03

Hetzner heeft VPS'jes voor een paar euro in de maand waarmee je de 100% wel haalt.

GertMenkel

Websites en community's

@mmjjb • 14 maart 2024 21:08

Microsoft (en de meeste platformen die op Azure zitten) kunnen niet omgaan met IPv6. Ik heb het idee dat de vage manier waarop Microsoft IPv6 heeft opgezet daar wat mee te maken heeft.

Een van de meest irritante op dat lijstje is Github.com dat nog steeds geen AAAA heeft. Veel dev machines en andere services zouden zo naar IPv6-only kunnen gaan, ware het niet dat Microsoft het nog steeds niet voor elkaar gekregen heeft om Github IPv6 te geven. Gitlab.com doet het natuurlijk wel prima.

DarkForce
@_PieterZ • 15 maart 2024 10:21

Schijnveiligheid is geen veiligheid...

SIDN heeft e-mail adressen van de domeinhouder, tech etc. etc. en in principe zouden deze gegevens kunnen worden gebruikt om iemand bij beveiligingsproblemen te benaderen. Een security.txt zorgt er alleen maar voor dat de houder c.q. verantwoordelijke partij(en) een overvloed aan spam gaan ontvangen omdat bots straks default alleen nog security.txt hoeft te crawlen.

Begrijp me niet verkeerd, ik heb al een tijdje security.txt op mijn domeinnamen, maar bij allen heb ik ze ook direct naar een :blackhole: verwezen aangezien al binnen 48 uur de eerste spam binnen kwam op speciaal hiervoor aangemaakte e-mail adressen.

In principe had het stukken gemakkelijker opgelost kunnen worden wanneer SIDN een online meldingsformulier/methode aan te bieden (via sidn.nl of een nieuwe website) waarbij de tech(2) contact van het domeinnaam een e-mail ontvangt bij eventuele veiligheidsproblemen. Deze gegevens zijn tenslotte allang en breed bekend bij SIDN. Stuur dan vervolgens jaarlijks een reminder zodat contactgegevens altijd up to date zijn of het domein suspended wordt en je bereikt er veel meer mee.

lasharor
14 maart 2024 17:57

Waarom staat dat niet in de WHOIS?

ernstoud

@lasharor • 14 maart 2024 18:01

WhoIS is sinds de AVG totaal nutteloos. Staat geen enkele informatie in van de hoster of site eigenaar.

mschol
@ernstoud • 15 maart 2024 00:01

WhoIS is sinds de AVG totaal nutteloos. Staat geen enkele informatie in van de hoster of site eigenaar.

mijn .nl domein heeft echter gewoon 2 mailadressen (technical en administrative contact), de Registrar en de reseller erin staan

Genoeg informatie om contact op te nemen lijkt mij?

svennd
@mschol • 15 maart 2024 09:38

Als ethisch hacker wil je naar security.txt kijken om een vulnerability te melden, dan wil je niet naar de registrator of reseller sturen, maar naar de webhost beheerder. (meestal) Overigens ben ik als Belg wel jaloers, dnsbelgium doet bitter weinig incentive zoals deze.

DarkForce
@svennd • 15 maart 2024 10:24

Een ethisch hacker is ook wel bereid om via de website van SIDN een formulier in te vullen waarna de backend automatisch zoekt naar het e-mail adres van een tech contact dat bij een domein hoort zodat via deze weg contact kan worden opgenomen.

Enige tijd geleden echter gaf SIDN al aan mij te kennen dat niet iedere houder de contactgegevens van het domein up to date houd, maar juist door alles via zo'n formulier te doen en jaarlijks een automatische check uit te voeren kan je er ook voor zorgen dat domeinen suspended worden als de contactgegevens onjuist zijn. Daarmee sla je niet 1 maar 2 vliegen in één klap.

svennd
@DarkForce • 15 maart 2024 11:09

Dan speelt de SIDN wel een andere rol. In Belgïe is bijvoorbeeld de CCB (https://ccb.belgium.be/nl) een partij waar je vulnerabilities kunt melden over websites, om zo te voldoen aan de wettelijke eisen als ethisch hacker. SIDN speelt dus een compleet andere rol in Nederland op die manier dan hier.

Stefan
@lasharor • 14 maart 2024 17:58

Dat zal dan waarschijnlijk tegelijk worden gedaan.

djwice
14 maart 2024 18:41

Hier is een lijst met andere bestanden die je als webmaster / webhosting partij / website eigenaar kunt overwegen om in de .well-known folder te zetten:
https://en.m.wikipedia.org/wiki/Well-known_URI

Kijk in je logs en zie welke bij jou al vaker zijn opgevraagd. Begin dan met de meest opgevraagde toe te voegen. En processen er voor in te richten.

Dit zorgt niet alleen voor verlaging van je hosting kosten, ook zorgt het voor betere vindbaarheid in zoekmachines en waardering door algoritmes van socials.
Los daarvan zorgt het dat je processen ingericht krijgt / op orde krijgt die je niet had gedacht dat bestonden maar je wel veel gedoe gaan besparen in de toekomst.

Vaak is het proces zo simpel als even wat informatie opzoeken van wat er in moet staan, de informatie binnen je eigen organisatie ophalen, tekst bestandje schrijven en op website zetten.

Meest complexe type vereist een private/public key genereren (je Linux of Database beheerder weet wel hoe) en formulier /mailbox bij de juiste persoon in je organisatie aan laten komen.

[Reactie gewijzigd door djwice op 14 maart 2024 18:46]

mmjjb
@djwice • 14 maart 2024 18:54

Goed dat SIDN dit aanmoedigt met een korting. Nu hopen dat de domeinverkopers deze ook werkelijk doorberekenen. Ik kan overigens uit het artikel niet opmaken over hoeveel korting het gaat; weet iemand dit?

Off topic:
Weer zo'n waardeloze chatgpt reactie. Wordt langzamerhand tijd dat tweakers een report knop voor dit soort troep maakt.

djwice
@mmjjb • 14 maart 2024 21:20

Welke reactie is van ChatGPT? Die van jou?

Hier kun je de prijzen van SIDN vinden:
https://www.sidn.nl/onze-prijzen

Lidmaatschap kost ook geld.
Je moet heel wat domeinnamen beheren om de infrastructuur, beheer, lidmaatschap en registratiekosten (€ 4,15 per jaar) lager te laten zijn dan die van https://mijn.host/

Voorbeeld bij AWS kost een DNS zone file $0,50 excl. BTW per maand en DNSSEC ook $1,- per key per maand.

De kosten gaan omlaag bij 25 domeinnamen naar $0.10 per maand per DNS zone, maar je DNSSEC blijft $1,- per maand per key.

[Reactie gewijzigd door djwice op 14 maart 2024 21:26]

mmjjb
@djwice • 14 maart 2024 22:14

De enige zin in je reactie die niet vanuit Chatgpt lijkt te komen is de eerste. Want de rest slaat wederom de plank volledig mis. Ik heb het toch overduidelijk over de korting die ze gaan aanbieden en niet de algemene domein prijs of verdere ongerelateerde onzin zoals wat AWS rekent.

djwice
@mmjjb • 14 maart 2024 22:43

Grappig dat je dat denkt. Ik gebruik geen AI, schrijf teksten gewoon zelf.
Zoals de waard is ...

Je hoopt dat hosting partijen de korting aan jouw gaan doorrekenen. Ik gaf een kort voorbeeld over de kosten van DNS hosting als je dat netjes wil doen (AWS zit heel dicht bij de kostprijs voor generieke services).

Vandaar dat ik denk dat je niet kunt verwachten dat .nl domeinnamen structureel veel lager dan €4,99 zullen worden. Sterker nog, 25 jaar terug waren
.com domeinnamen $6.95 bij de goedkoopste aanbieder als je ze meer jaren kocht (incl. DNS en email). Ik verwacht dat de prijzen voor .nl uiteindelijk niet veel daar onder zullen blijven, tenzij het verlies leidende promotie acties zijn, om mensen uiteindelijk naar andere producten te krijgen of een bepaald markt volume te behalen etc.

Maar blijkbaar wil je graag goedkoper dan €4,99 en zie je de relatie met AWS niet. Een Azure voorbeeld dan? Of een RPi als DNS server? Reken het maar door zou ik zeggen.

djwice
@mmjjb • 14 maart 2024 22:48

Maar hoe ongerelateerd heb jij dan op mijn reactie - die over /.well-known/ gaat, waar security.txt onderdeel van is - gereageerd?

Dan wil je weten of de 2% korting op die €4,15 ook aan jou zullen worden doorberekend als jij een .txt bestandje op je server zet?
Dat is ongerelateerd aan mijn uitleg waarom je niet alleen security.txt maar ook andere /.well-known/ functies aan zou moeten zetten.

Maar antwoord op je vraag:
Ik denk eerder dat die 2% korting, geld vrij maakt bij hosting providers met veel domeinnamen om iemand in te huren om /.well-known/security.txt voor al haar klanten goed in te richten.
Dus jij gaat dit niet als korting merken, maar als een betere beveiligingsservice.

En mijn tip is dan: kijk ook naar de andere /.well-known/ functies, als je toch met security.txt aan de slag gaat.

[Reactie gewijzigd door djwice op 14 maart 2024 22:57]

Stetsed
14 maart 2024 18:02

Ik ben het met @Lagonas eens dat ik niet begrijp hoe ze deze korting gaan geven. Ik heb op dit moment geen NL domeinen, maar voor als ik NL domeinen will ga ik niet naar SIDN, daarvoor ga ik naar Porkbun/Namecheap/Whatever, ik heb zelf geen interacties met SIDN. Dus hoe ik dit in de realiteit zie uit pakken is dat SIDN die korting dan geeft, maar de domain registrars blijven gewoon hetzelfde vragen voor de domains, dus dan is het niet korting voor de consument maar voor de bedrijven die dat doen.

walkstyle
14 maart 2024 20:55

Voor Wordpress bestaat er al een plugin: https://wordpress.org/plugins/wp-security-txt/

Snow_King

@walkstyle • 14 maart 2024 21:20

Precies! Die gebruik ik zelf ook al een tijdje

JeroenV_
@walkstyle • 15 maart 2024 12:02

Die had ik ook al eens gevonden, maar gezien de waarschuwing die erbij staat niet gebruikt.

This plugin hasn’t been tested with the latest 3 major releases of WordPress. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress.

Maar hij werkt dus nog wel goed met de huidige versies?

RobbyTown

@JeroenV_ • 15 maart 2024 14:09

Dat zag ik ook. Hij werkt nog wel. Maar die plugin heeft nogal in verhouding veel bestanden en mappen voor het geen wat die toevoegt.... Ik heb het handmatig gedaan.

Upload je de map .well-known met daarin security.txt
Inhoud security.txt (of zelf maken op https://securitytxt.org/ als je meer wilt)
Contact: je email of je contact
Expires: 2025-01-01T13:37:00.000Z
Preferred-Languages: nl
Canonical: https://naamwebsite.nl/.well-known/security.txt
Canonical: https://www.naamwebsite.nl/.well-known/security.txt

Kortom 1 map en 1 bestand ipv 85 bestanden, 11 mappen wat de plugin doet.

Optioneel (aangezien bij plugin kan) Dit voeg je toe in je htaccess: Redirect 301 /security.txt https://naamwebsite.nl/.well-known/security.txt

[Reactie gewijzigd door RobbyTown op 15 maart 2024 14:11]

JeroenV_
@RobbyTown • 15 maart 2024 14:44

Thanks, ik ga eens hobbyen

Jrz
15 maart 2024 06:58

Dus ipv een DNS record wordt je nu verplicht je attack surface te vergroten door een webserver te draaien

svennd
@Jrz • 15 maart 2024 09:42

Wat wil je anders achter je DNS records draaien ? FTP servertje ?

er is wel al DNS only draft : https://dnssecuritytxt.org/ maar dat is (nog?) geen standaard.

freddieleeman
15 maart 2024 10:22

Voor de mensen die hun security.txt uitgebreid willen valideren: https://www.uriports.com/tools?method=securitytxt

Slechts 19% van de domeinen met een security.txt in de top 1 miljoen website zijn volledig correct. https://www.uriports.com/blog/security-txt/

1 2 Volgende

Op dit item kan niet meer gereageerd worden.

SIDN gaat korting geven op domeinnamen met geldig security.txt-bestand

Lees meer

IT-banen

Reacties (86)

Sorteer op:

Weergave:

Tweakers maakt gebruik van cookies

Toestemming beheren

Functioneel en analytisch

Relevantere advertenties

Ingesloten content van derden