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?
_______________________________________________
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
