Hacker News Reader

Comment by eqvinox | Hacker News Reader

The point of running a local unbound is indeed to turn on DNSsec validation. After that, it's the domains' fault for not using DNSsec. But at least your own stuff won't be tampered with, because you use DNSsec on your own domains, right? Right?

:-(

Coincidentally, a bunch of free wifi stuff blocks the root key queries unbound does at startup, resulting in nothing working until you get those records in there somehow (e.g. load_cache).

View on HN

I was under the impression that dnssec's entire value was rather controversial? I'm not a crypographer so I had to skim https://sockpuppet.org/blog/2015/01/15/against-dnssec/ and I still don't understand it, but if

> In fact, it does nothing for any of the “last mile” of DNS lookups: the link between software and DNS servers. It’s a server-to-server protocol.

is true, then I'm ... pretty unsold on its usefulness. Anyone wanna ELI5 whether that's untrue or anything's changed in the last decade?

I can't speak about the strength or weaknesses of the whole concept.

Out of curiosity I enabled DNSSEC checking beginning this year. I mostly noted nothing in my browsing. However, with 2 services I noted obscure problems that worked only partially. Some Jira plugins and Swedish railway SJ. I needed to excempt some of their domains from being checked to use their services. Of course you waste a couple of hours every time it happens because you don't think of DNSEC first when some web-based services behaves weirdly. There might be more requests not served to my browser, but I just never noticed or bothered to debug.

So not fit for general use. And even as an experienced developer it's not easy to understand why an exception would be needed. A bug in systemd? Incorrect data in DNS? A real attack?

Edit: I don't use standard DNS on port 53 at all. Blocked outgoing requests on that port. Everything DoH or DoT. Of course I need to trust those endpoints at least in repect to confidentiality. And most domains are unsigned. At least for those unsigned ones I need to just trust also in respect to integrity.

DNSSEC failures need to be louder. If websites that fucked up their DNSSEC would get the same error messages as websites that fucked up other parts of their security, people wouldn't be so eager to turn off security festures as workarounds.

Give SJ the option to turn off DNSSEC and their website will stay broken. Give people a "someone might be tampering with your connection" popup and they would start caring.

There are also other issues with DNSSEC that need working out, but I still believe it does much more good than it does bad. Leaving everything in the background with an easy-to-disable setting makes it next to useless.

> DNSSEC failures need to be louder.

Full ACK. As a part of this, DNSsec validation needs to be as close to the client app as possible and reasonable; definitely never off-host. (Caches can do additional validation, but that makes the error reporting complicated.)

corollary: the AD bit should never be relied on on anything actually on the network. Maybe on localhost, but even there it's questionable in UX results.

It's about time to question the whole off-host DNS resolver thing entirely. Fine if you want to have a cache, but the cache should return the whole record chain starting from the root in that case, so the client can validate it. Also fine to have an on-host cache that caches validation status.

DNSSEC as designed is pretty useless. It was designed in an era where computers could not be relied upon to do cryptographic validation of something like DNS records, so that duty was delegated to DNS servers like the ones ISPs ran, where records could be cached.

There are also potential downsides (like someone being able to enumerate your subdomains, if you care about such a thing) and it's often switched off by default on operating systems consumers use.

However, it's the only thing that validates DNS records at this moment. That alone makes it worth enabling, in my opinion. For many domain owners, you only need to tick the checkbox in your registrar's domain control pane. If you use a modern DNS server, it's also one config flag and maybe copy/pasting a handful of fields away.

I'll gladly turn off DNSSEC the moment we come up with something better. DoT/DoH doesn't solve the same problem and no real solutions seem to have been proposed. That said, modernisation efforts are still being done. Smaller keys and modern cryptography rather than the massive RSA ones for instance.

> DNSSEC as designed is pretty useless.

Another approach that we analysed in more detail is the distribution of the host key fingerprints via a special resource record. This removes any user interaction, potential human error, or presumed configuration of a user’s device because OpenSSH-client can query the DNS and do the comparison. It only requires the administrator to publish a host’s fingerprints as a set of SSHFP records, which can be securely obtained (DNSSEC). If the latter holds, MITM attacks are mitigated, and overall security is improved. [1]

[1]: "Improving SSH’s security with SSHFP DNS records" - https://blog.apnic.net/2022/12/02/improving-sshs-security-wi...

SSHFPS is what I should be using in my homelab if it weren't for the awful split-DNS setup I have!

I personally prefer the theoretical advantages of SSH certificates, but those don't have CRL support (let alone an ACME alternative) as far as I know, so that's not exactly perfect either.

I want DNSSEC('s goals and ambitions) to succeed, but having a "trusted" ISP server that sets a "trust me bro" bit is the design flaw that kills the original design.

There's a patch for openssh to use the ldns library and do its own DNSsec validation. A few distros apply it to their packages, though I'm not sure what the current status is. It never got accepted into openssh sadly.

Note the linked post is from 2015. But also:

> domain-validated certificates remain insecure

...99% of the internet runs on DV certificates; that's what ACME & Let's Encrypt are at the end of the day.

(You might also note I didn't actually speak in favor of DNSsec, I'm just arguing that running unbound locally without having DNSsec validation enabled isn't particularly useful. I am, generally, in favor of rolling out DNSsec, but it certainly has its problems. It doesn't help against ISP tampering on unsecured domains, for example. DoT and DoH are better against that, if [and only if] you have a trustworthy cache to point them at.)

Just yesterday, there was a talk by representatives from Ukraine and Germany about how and why they use DNSSEC:

<https://www.icann.org/en/engagement-calendar/details/icann-t...>

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

General DNSSEC rationale: <https://www.icann.org/resources/pages/dnssec-what-is-it-why-...>

DNSSEC adoption graph: <https://www.verisign.com/resources/dnssec-tools/dnssec-score...>

Automatic Certificate Management Environment (ACME), RFC 8555, recommends certificate issuers use DNSSEC when using DNS to validate control of the DNS zone:

  As noted above, DNS forgery attacks against the ACME server can
  result in the server making incorrect decisions about domain control
  and thus mis-issuing certificates.  Servers SHOULD perform DNS
  queries over TCP, which provides better resistance to some forgery
  attacks than DNS over UDP.
    
    An ACME-based CA will often need to make DNS queries, e.g., to [1]
  validate control of DNS names.  Because the security of such
  validations ultimately depends on the authenticity of DNS data, every
  possible precaution should be taken to secure DNS queries done by the
  CA. Therefore, it is RECOMMENDED that ACME-based CAs make all DNS
  queries via DNSSEC-validating stub or recursive resolvers.  This
  provides additional protection to domains that choose to make use of
  DNSSEC.
  
  An ACME-based CA must only use a resolver if it trusts the resolver
  and every component of the network route by which it is accessed.
  Therefore, it is RECOMMENDED that ACME-based CAs operate their own
  DNSSEC-validating resolvers within their trusted network and use
  these resolvers both for CAA record lookups and all record lookups in
  furtherance of a challenge scheme (A, AAAA, TXT, etc.).

[1]: https://www.rfc-editor.org/info/rfc8555/#section-11.2

> It’s a server-to-server protocol is true, then I'm ... pretty unsold on its usefulness.

You can run a DNSSEC-aware resolver like unbound on your laptop if you wanted to. It comes with a bunch of Linux distros.

Can and should! Unbound is very easy to set up, if you know how to administer Linux systems at all. It also acts as a local cache and I noticed a small improvement to page loading time because of having the cache. Otherwise there is no local cache - every single call to getaddrinfo sends a network request to your configured DNS server.

DNSSEC adoption rate means that this would be insufficient to detect (let alone prevent) that type of tampering for most domains. The correct solution is identified the the first paragraph of the post, which is to use a tamper resistant transport to the dns server (eg DoT, or DoH if you like everything being wrapped in http)

Which DNS server? Your client talks to a central cache (of your choice) which talks to the chain of servers for all relevant domains, most of which don't support DoT or DoH.

Adoption at the TLD is high as it is expected of the TLD operators but the second level is very low. So .org itself is signed but .org second level domains are just below 5% adoption overall. .com second level is around 4.2%. .net second level are a little higher at around 5.2%. So most people's answer would be a solid no. HN audience may be some of that 5%.

Reply on news.ycombinator.com