Hacker News new | ask | show | jobs
by joveian 1551 days ago
I noticed a few weeks ago that developer.apple.com was failing DNSSEC and that this had been going on for a while (follow the "previous analysis" links to see earlier errors as well):

https://dnsviz.net/d/developer.apple.com/Yidc2Q/dnssec/

It doesn't seem like many people have noticed or cared, so I doubt many people use DNSSEC at all and the whole system could (and should) be scrapped one day with barely anyone noticing.

lima has an anaylsis of the issue causing trouble:

https://news.ycombinator.com/item?id=30757487

1 comments

APPLE.COM isn't signed at all; this isn't a DNSSEC issue.

In the future, if you want to check if something is DNSSEC-signed (things rarely are: DNSSEC is overwhelmingly not enabled on the commercial Internet), you can just `host -t ds <domain>`.

I noticed it because developer.apple.com failed validation using systemd-resolved with DNSSEC enabled when someone posted a link on HN (but worked fine with DNSSEC disabled). It still does. The main apple site doesn't have that issue (the post I linked to gave the general, non-DNSSEC related issue this time).

I tried several local utilities and options but couldn't find a reliable way to determine if a site would resolve under systemd-resolved with DNSSEC enabled other than using systemd-resolve with DNSSEC enabled. It seemed like any time dnsviz.net shows an error the domain will not resolve, but some things it shows as warnings also cause sites to not resolve while other warnings do not. My favorite is that Verisign's DNSSEC validator's domain fails to resolve with DNSSEC enabled.

Possibly some or all of this is systemd-resolved doing the wrong thing, however the errors and warnings on dnsviz.net make me think this is not the case. www.google.com, for example, does not show any warnings or errors.

GOOGLE.COM is also not DNSSEC-signed. Seriously, almost nothing is.
Right, but my point is "not DNSSEC-signed" does not seem to be the same as "free of configuration errors that prevent resolution of the name with DNSSEC enabled".
Which configuration errors would those be? Without a DS record, there's no DNSSEC happening at the resolver, is there?
I tried looking again and found that it is systemd-resolved's error at least in the developer.apple.com case (the Verisign one is a bit different but potentially might also be a systemd-resolved issue). It seems the issue is that the servers for g.applimg.com are completely DNSSEC-unaware and querying the DS record somehow doesn't work the way DNSSEC wants it to even in the "no DNSSEC" case, however the parent zone correctly indicates that there is no DNSSEC so it should be accepted.

https://github.com/systemd/systemd/issues/9867#issuecomment-...

It sounds like systemd-resolved has had a bunch of issues like that where it fails (or previously failed) on things that would be an issue if DNSSEC was enabled but shouldn't due to DNSSEC not being used. I'll stop blaming DNSSEC.