dig ds c10r.facebook.com returns SERVFAIL

[Tony Finch]

> On 3 Sep 2018, at 21:26, Laurent Bigonville <bigon+bind at bigon.be> wrote:
> 
> The problem is that systemd-resolved (maybe other software are doing the same?) is asking the DS record to check if the record is supposed to be signed (well I think) before trying to do DNSSEC validation of the client side.

I am shocked (appalled!) and surprised (gobsmscked!) to learn that systemd-resolved is using an unwise and brittle validation algorithm.

(The Right Thing for a validating stub like systemd-resolved is to concurrently send DS+DNSKEY queries for all the possible zone cuts above the qname, at the same time as the original query, then validate top-down. This costs 1 RTT (or 2 RTT if there are CNAMEs or SRVs etc.) and avoids backwards compatibility problems at the lower levels of the tree. Minimal latency overhead, tho you need to validate as the answers arrive so you can bail out early for insecure domains in order to avoid getting stuck due to servers that drop unknown QTYPEs or other brokenness like c10r. The extra bonus for DNS-over-TCP/TLS/HTTPS is that the concurrent queries can be sent in one go: one TLS record, one write() syscall, one TCP segment.)

> I'm also wondering (and pardon my ignorance but), why does bind tries all the forwarders and the the auth server if the 1st server already reply with an empty answer and an NOERROR?

When BIND is forwarding it just gets SERVFAIL from the upstream resolver, and it can’t tell if that is because the upstream resolver is broken or the authoritative servers, so it tries the next resolver. When BIND is doing iterative resolution talking directly to auth servers, it gives up immediately when it gets the unexpected referral. I don’t know why it doesn’t retry in this case; possibly because the DS logic is a bit special. There aren’t any NOERROR/NODATA responses in this scenario.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at