dig ds c10r.facebook.com returns SERVFAIL

Mark Andrews marka at isc.org
Mon Sep 3 23:03:41 UTC 2018



> On 4 Sep 2018, at 8:40 am, Laurent Bigonville <bigon+bind at bigon.be> wrote:
> 
> 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?

Upgrade facebook’s DNS servers to ones that are DNSSEC aware.  DS lives in the parent
zone at a zone cut.  STD 13 servers don’t know this.  DNSSEC aware ones do know this.
DS lookups will work where all the recursive servers are DNSSEC aware and the delegating
servers are DNSSEC aware.  DS lookups will also work for non delegation points (NODATA
responses are expected) and for non existent names (NXDOMAIN).

DS lookups will fail at a delegation point if the delegating server is not DNSSEC aware.

Mark

> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org



More information about the bind-users mailing list