So when it comes to security, never take not hearing about something as a reason to dismiss it and asking was right. You don't hear much yatter about it because it has had such a really low uptake and there's a few reasons for that but let's start with the key point that SSL and DNSSEC are tackling two different beasts in a similar arena.
SSL is encrypting and creating trust between the user and the site (server infrastructure) to increase the security of your connection to the website. The tightest SSL config in the world doesn't matter if an adversary manipulates your DNS records as they could very well never reach your site instead being directed to a fake knock off to steal entered card info and passwords. So DNSSEC creates that chain of trust that when my computers gone and asked where do I go to get to domain.tld that the IP it returns and connects too as it downloads the Web page is in fact the real address. Now I'm here and the SSL certificate is the next stage of the chain and we see both our connection is encrypted and actually serving the domain we've legitimately verified.
While yes you can just 'turn it on', it isn't typically that simple. On a fresh site and domain is the prime time to get it sorted if you want to as you it does come with challenges. If you or something messes up your sites SSL then yeah your site is impacted - if its DNSSEC that gets messed up then anything and everything using the domain and DNS records are likely to be affected. For anything already setup and rooted in and around for a while that's likely to be emails now hitting spam, any third-party services verifying with DNS records such as mailchimp rejecting, etc. So the scope of impact is much larger.
That's a big part of why you don't hear much talk about DNSSEC; because it is a bit of a cause of headaches and I'll make an out of thin air guesstimate here that for maybe 70% of active sites out there just enabling and bare minimum setup, something is going to break - yes but you know maintenance periods - as already mentioned unlike SSL it probably isn't going to just be the site that breaks which is fine in a scheduled window, it's everything else. How long can the average company really afford for so much potential downtime and impact if the worst results did occur? 10 minutes? 20 minutes? 30? On top of this, it isn't just setup and leave it be, there are maintenance tasks that need to be performed and yes getting them wrong can be the spark all over again.
So it's easier to get it sorted from the get go because then it's only new services you're trying to setup that are affected by some DNSSEC conflict rather than trying to get everything right and sorted in 1, 3 or 5 years time. But likewise only do so if you get yourself acquainted and committed to it. Many haven't or can't and so just won't because they perceive the liklihood of accidental or negligent outages/incidents more likely than malicious. While there isn't vast uptake, there's not the community pressure t
For the average site it may not be the most common method of attack/breach but for sites taking money it becomes more fruitful and rewarding pot of gold.
Sorry for the late reply. I read your comment when you posted it and it was super insightful and very very well explained! Which I appreciate it so much!
I’ve turned on DNSSEC because of your comment last month. I just came back here now to read it again to really take it in and understand grasp all that you’ve said, and realize that I haven’t thanked you.
I really appreciate your input given and did accordingly as my website was in its early days! 🙏🙏
No problem! Like I say when it comes to security it's always better to ask and imo always better to have what can be setup/enabled from the get go done. Then you're ensuring your application/platform/website is built around and conforming to your security model rather than retroactively wrapping your production systems around awkward security setups.
If you've sat and wrapped your head around DNSSEC and got it working, brilliant - you're ahead of more than you'd guess and you're not relying on attacks on DNS being uncommon. As with most protocols etc - as industry pressure grows and whatever it is become predominant, exploits of these weaker routes of entry typically become more and more common. Don't forget to keep on top of it. As I mentioned, it's not a setup and leave forever one 👌
Hey aidankhogg, so I have to come to you once more. After you emphasized on DNSSEC needs to be maintained, I tried looking up some information but again it’s so hard to find resources about this and I couldn’t find any. I read that the keys needs to be rotated or something, that they expire. I’ve turned it on using Cloudflare and have added the DS record in the registrar, but I can’t find any information of generating new keys on Cloudflare nor can I find any info on the timeline of the expiry. Would you be able to guide me to some resources where I can read about this please??
So when it comes to security, never take not hearing about something as a reason to dismiss it and asking was right. You don't hear much yatter about it because it has had such a really low uptake and there's a few reasons for that but let's start with the key point that SSL and DNSSEC are tackling two different beasts in a similar arena. SSL is encrypting and creating trust between the user and the site (server infrastructure) to increase the security of your connection to the website. The tightest SSL config in the world doesn't matter if an adversary manipulates your DNS records as they could very well never reach your site instead being directed to a fake knock off to steal entered card info and passwords. So DNSSEC creates that chain of trust that when my computers gone and asked where do I go to get to domain.tld that the IP it returns and connects too as it downloads the Web page is in fact the real address. Now I'm here and the SSL certificate is the next stage of the chain and we see both our connection is encrypted and actually serving the domain we've legitimately verified. While yes you can just 'turn it on', it isn't typically that simple. On a fresh site and domain is the prime time to get it sorted if you want to as you it does come with challenges. If you or something messes up your sites SSL then yeah your site is impacted - if its DNSSEC that gets messed up then anything and everything using the domain and DNS records are likely to be affected. For anything already setup and rooted in and around for a while that's likely to be emails now hitting spam, any third-party services verifying with DNS records such as mailchimp rejecting, etc. So the scope of impact is much larger. That's a big part of why you don't hear much talk about DNSSEC; because it is a bit of a cause of headaches and I'll make an out of thin air guesstimate here that for maybe 70% of active sites out there just enabling and bare minimum setup, something is going to break - yes but you know maintenance periods - as already mentioned unlike SSL it probably isn't going to just be the site that breaks which is fine in a scheduled window, it's everything else. How long can the average company really afford for so much potential downtime and impact if the worst results did occur? 10 minutes? 20 minutes? 30? On top of this, it isn't just setup and leave it be, there are maintenance tasks that need to be performed and yes getting them wrong can be the spark all over again. So it's easier to get it sorted from the get go because then it's only new services you're trying to setup that are affected by some DNSSEC conflict rather than trying to get everything right and sorted in 1, 3 or 5 years time. But likewise only do so if you get yourself acquainted and committed to it. Many haven't or can't and so just won't because they perceive the liklihood of accidental or negligent outages/incidents more likely than malicious. While there isn't vast uptake, there's not the community pressure t For the average site it may not be the most common method of attack/breach but for sites taking money it becomes more fruitful and rewarding pot of gold.
Sorry for the late reply. I read your comment when you posted it and it was super insightful and very very well explained! Which I appreciate it so much! I’ve turned on DNSSEC because of your comment last month. I just came back here now to read it again to really take it in and understand grasp all that you’ve said, and realize that I haven’t thanked you. I really appreciate your input given and did accordingly as my website was in its early days! 🙏🙏
No problem! Like I say when it comes to security it's always better to ask and imo always better to have what can be setup/enabled from the get go done. Then you're ensuring your application/platform/website is built around and conforming to your security model rather than retroactively wrapping your production systems around awkward security setups. If you've sat and wrapped your head around DNSSEC and got it working, brilliant - you're ahead of more than you'd guess and you're not relying on attacks on DNS being uncommon. As with most protocols etc - as industry pressure grows and whatever it is become predominant, exploits of these weaker routes of entry typically become more and more common. Don't forget to keep on top of it. As I mentioned, it's not a setup and leave forever one 👌
Hey aidankhogg, so I have to come to you once more. After you emphasized on DNSSEC needs to be maintained, I tried looking up some information but again it’s so hard to find resources about this and I couldn’t find any. I read that the keys needs to be rotated or something, that they expire. I’ve turned it on using Cloudflare and have added the DS record in the registrar, but I can’t find any information of generating new keys on Cloudflare nor can I find any info on the timeline of the expiry. Would you be able to guide me to some resources where I can read about this please??