> 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.)

> 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  <d...@dotat.at>  http://dotat.at


_______________________________________________
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

Reply via email to