dig ds c10r.facebook.com returns SERVFAIL

[Laurent Bigonville]

On 3/09/18 23:38, Tony Finch wrote:
>> 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.)

Don't take what I said about the internal working of systemd-resolved 
for granted :)

Looking at the log that I initially provided 
(https://github.com/systemd/systemd/issues/8897), it seems to revalidate 
the complete chain.

An idea what should be done to fix this then?