> On 4 Sep 2018, at 8:40 am, Laurent Bigonville <bigon+b...@bigon.be> wrote: > > On 3/09/18 23:38, Tony Finch wrote: >>> On 3 Sep 2018, at 21:26, Laurent Bigonville <bigon+b...@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@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: ma...@isc.org _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
