Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

deSEC – Free Secure DNS

desec.io

Post reply on HN
Print view View original

61–65 of 65 posts

Re: deSEC – Free Secure DNS

#61

Post by zetanor »

peterthomassen wrote: post #60
zetanor wrote: post #55

Earlier quoted context omitted.

A problem there is needing to temporarily delete the entire domain just to update using a zone file. I don't manage the DNS for anything remotely critical, but if I did, it would be unacceptable. Either way, the workflow feels deeply incorrect (though most users likely will use the record editor or the API instead; even I'd use the API through DNSControl, now). Logging back into deSEC right now, it seems like the par…

First, I guess it would be a good idea to report discontent about things feeling "deeply incorrect" to our issue tracker. Just lamenting about the state of things won't change it. Unless I happen to swing by. -- We use dnspython for zone parsing, and it turns out that this is legacy (pre RFC 2308) behavior implemented there. You could say it's a bug there. We've created a patch: https://github.com/rthalley/dnspython/…

Call me cynical, but I've long stopped taking the time to report minor edge case bugs if I can't also provide a solution or patch, as such reports usually get ignored or sit at the bottom of a bugtracker forever. I likely didn't realize that deSEC was a FOSS stack at the time, or I might have looked into the zone file parsing further.

As for the zone file based workflow requiring zone deletion/recreation, perhaps a report/discussion would have led to something, but I was in the middle of testing managed DNS providers to get rid of my BIND servers and I didn't have any investment in deSEC, so it didn't occur to me to take the time. My initial post on here was less lamentation and more conveying personal experience to (possibly) save someone else some time.

In any case, none of these things were showstoppers for me (I went to another (paid) provider because I need very short TTL on some records for testing purposes), but I'm glad you took the time to look into the parser; it almost certainly will benefit others.

Re: deSEC – Free Secure DNS

#62

Post by dsl »

thayne wrote: post #56
wildylion wrote: post #50

Earlier quoted context omitted.

Exactly. And now there's https://datatracker.ietf.org/doc/html/rfc9539 > that allows encrypted DNS between authoritative and recursive servers as well.

That provides privacy, but not authentication.

Authentication was never the problem, transport security was.

This is why we pushed to deploy TLS everywhere instead of focusing on a scheme to PGP sign every webpage on the internet.

Re: deSEC – Free Secure DNS

#63

Post by thayne »

dsl wrote: post #62
thayne wrote: post #56

Earlier quoted context omitted.

That provides privacy, but not authentication.

Authentication was never the problem, transport security was. This is why we pushed to deploy TLS everywhere instead of focusing on a scheme to PGP sign every webpage on the internet.

Authentication is precisely the problem DNSSEC is supposed to solve. And authentication is part of transport security.

TLS usually does provide authentication. The certificate is signed by a chain that leads up to a trusted CA, and content of the stream is authenticated using an AEAD encryption algorithm. But RFC 9539 specifically doesn't require the certificate to be signed by a CA (and recommends using a self signed cert) or the client to verify the authenticity of the certificate used by the server.

This means that an active MitM could return whatever it wanted to the recursive resolver. Pulling that off is admittedly more difficult than a MitM on a public wifi network at a coffee shop, but it's still a gap in security.

And no, you can't just use Web PKI to verify connections to authoritative DNS servers, because Web PKI relies on DNS to confirm domain ownership.

Re: deSEC – Free Secure DNS

#64

Post by teddyh »

dsl wrote: post #34
teddyh wrote: post #30

Earlier quoted context omitted.

Rebuttal: https://easydns.com/blog/2015/08/06/for-dnssec/ >

That rebuttal held water 10 years ago, but fortunately we have made a lot of advancements since then. DNSSEC was a solution trying to solve the problem of DNS security while still maintaining transparency for DNS operators to spy on queries. At the time, passive DNS was one of the tent poles of tracking malware and responding to security incidents. We have since committed entirely to transport security in the form of…

The rebuttal is old because the criticism is old. If you give more up-to-date criticism, then more modern rebuttals are available.

”DNS security” can mean many things, but DNSSEC was meant to solve the problem of verification of DNS data, while still allowing for offline signing and secondary DNS servers serving pre-signed zones, without distributing the key everywhere. DoH/DoT do not solve this; they solve different problems.

Re: deSEC – Free Secure DNS

#65

Post by tptacek »

teddyh wrote: post #64
dsl wrote: post #34

Earlier quoted context omitted.

That rebuttal held water 10 years ago, but fortunately we have made a lot of advancements since then. DNSSEC was a solution trying to solve the problem of DNS security while still maintaining transparency for DNS operators to spy on queries. At the time, passive DNS was one of the tent poles of tracking malware and responding to security incidents. We have since committed entirely to transport security in the form of…

The rebuttal is old because the criticism is old. If you give more up-to-date criticism, then more modern rebuttals are available. ”DNS security” can mean many things, but DNSSEC was meant to solve the problem of verification of DNS data, while still allowing for offline signing and secondary DNS servers serving pre-signed zones, without distributing the key everywhere. DoH/DoT do not solve this; they solve different…

You don't seem to be sharing any of the modern rebuttals. I think it's telling that the old criticisms still basically stand.
Post reply on HN