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).
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.
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.
Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
