On Tue, Aug 23, 2022 at 09:21:33AM -0700, nate <post...@linuxpowered.net> wrote:
> On 2022-08-22 14:46, Viktor Dukhovni wrote: > > [..] > > > You don't need to sign your own domain in order to secure outbound > > traffic > > to domains that others have signed. You just need a local validating > > resolver such as "unbound", with DNSSEC validation turned on. > > Ok, yeah I was thinking more of DANE for my own domains rather than > validating others. > > > My take is that the person in question likes being a cult leader, > > dispensing wisdom to adherents, who then, along with the leader, get to > > feel superior to the uninitiated masses. > > Interesting! I have no idea who that person is just came across that > post in a comment on a website somewhere years ago, I had read others > complain about DNSSEC but hadn't seen what appeared to be as fairly > organized specific thoughts on the subject rather than a one liner > that they hate DNSSEC without saying why. > > > The tooling around DNSSEC has significantly improved recently, making > > hands-off auto-pilot operation much simpler in e.g. BIND 9.16 and later. > > Or you can get your domain professionally operated by Google, one.com, > > OVH, ... who operate millions of signed domains with no issues. > > I checked and I do have BIND 9.16 where I host my domains(on my own > servers). I'll think about it more, my home setup is quite simple I > haven't invested much time in it since before 2010 probably(other > than OS updates and stuff to keep it going). > > I have been using Dyn DNS for work related DNS stuff since about 2009, > even though Oracle keeps saying they plan to retire the legacy Dyn > stuff(and say the newer Oracle cloud DNS uses the same Dyn backend), > it's still alive until May 2023 at least. > > > In any case, outbound DANE does not require anything non-trivial on your > > end. > > Good to know, thanks!! > > nate DNSSEC has become really easy since BIND 9.16. The only big investment in time is reading about DNSSEC to make sure that you understand what's happening. The BIND documentation for DNSSEC is good, and once you understand what it's doing, it can be done with a single extra line of configuration (unless you want to get fancy with the policy), and communicating records for the parent zone to your registrar. I started with it a year ago and have just had my first batch of new CDS/CDNSKEY records appear for an annual rollover (my choice). There's no risk of an outage because BIND won't do anything drastic until I've told it that the new DS record is published and the old DS record is withdrawn. I had to set up some monitoring to know when the new CDS/CDNSKEY records appear, but that's just cron+host+diff. An important thing to check first is how good your registrar is when it comes to adding and removing DS and/or DNSKEY records. Before DNSSEC, I was with a registrar that couldn't do it at all, so I switched to a much better one. Uploading them is done with a web form. No API unfortunately, but I've just asked if they're willing to add one. That anti-DNSSEC page seems very silly and/or out of date. It's true that there are security measures that have been developed with the assumption/acceptance that DNS is insecure, but they have their own problems, and there's probably a lot of stuff that just accepts the insecurity rather than doing anything to mitigate it, so that's not very compelling. And modern small keys exist now. And its popularity is steadily increasing. And the claim that the government controls your keys is just wierd. I don't understand that claim at all. Maybe the author doesn't know what escrow means. cheers, raf
