On 02 Dec 2013, at 12:23, Tony Finch <d...@dotat.at> wrote: > Tangentially from the topic of draft-wouters-edns-tcp-chain-query, I have > noticed a gap in performance between what BIND's validating resolver does > and what the DNSSEC specifications allow. > > If I run the following commands to prepare the cache ... > > $ rndc flush > $ dig dnskey uk > $ dig dnskey ac.uk > > ... then these commands to watch what happens with a sample query ... > > $ rndc trace 11 > $ dig www.cam.ac.uk > $ rndc notrace > > ... I can see the following series of queries and responses, one after > another: > > (1) send www.cam.ac.uk IN A ? to ac.uk nameserver > receive delegation response > (2) send www.cam.ac.uk IN A ? to cam.ac.uk nameserver > receive answer > (3) to validate www.cam.ac.uk IN A ... > send cam.ac.uk IN DNSKEY ? to cam.ac.uk nameserver > receive answer > (4) to validate cam.ac.uk DNSKEY ... > send cam.ac.uk IN DS ? to ac.uk nameserver > receive answer > > This is twice as slow as it should be. > > In RFC 4035 section 3.1.4, authoritative name servers that are returning a > referral are required to include the DS RRset (or a proof of nonexistence) > alongside the delegation NS RRset and glue, all in the same response. > > So in the trace above, step (4) is redundant: the resolver already > received the DS in step (1).
In this case, yes. However, this is not consistent across all delegation points. As an example, UK and ORG.UK are hosted from the same set of servers. When asked about, say, nominet.org.uk, these servers will happily refer to the proper nameservers, including a DS record for nominet.org.uk. However, the validating resolver needs to explicitly ask for the org.uk DS record, since it will not show up in any delegation response. It might be this specific trade-off (asking explicitly for DS instead of opportunistically learning DS along the way, which might fail) why named choses to ask for the DS record. > Furthermore, the presence of the DS in the referral tells the resolver > that it will need the DNSKEY RRset in order to validate the answer, so it > should send queries (2) and (3) concurrently. Not necessarily. www.cam.ac.uk might be an unsigned delegation from the signed cam.ac.uk, so this might be followed by another query (for the www.cam.ac.uk record from the www.cam.ac.uk name servers). If that succeeds, only then validation makes sense. > I am aware there was some debate about top-down vs. bottom-up validation, > and that BIND does bottom-up validation. What are the advantages of > bottom-up validation? It seems to be fundamentally twice as slow as > top-down validation. Independent of top-down vs bottom up, I think it makes sense to complete the delegation chain first, then complete the validation chain (which happens in named, that is, you first see (1) and (2), then (3) and (4). I agree there is some room for optimisation, using previously obtained information (like the DS record and its signature) to complete the validation chain, which has a complexity cost as well. Roy
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
