Can someone please confirm one of these explanations of the DNSSEC chain of trust?

Question

Let me apologize in advance for this question has been answered. I did have a good look and if it is here somewhere I missed it. My question hopes to clarify exactly what happens when a validating resolver queries a DNSSEC aware nameserver for a RR. I thought I understood the process, then I read an explanation written by someone I would think can speak authoritatively (no pun intended) on the subject. I think the easiest way for me to do this is to explain what I thought the process looked like and then the contrasting version. And hopefully, someone among you all will be able to clarify where I might be going wrong. Example A (or how I thought a DNSSEC query worked):

Host A sends a query to it's recursive caching DNS server for www.example.com The recursive server sends an iterative query to a DNS server that is authoritative for the root zone The root DNS server can't answer the query directly so it responds with:

A plain text referral for the authoritative name servers for the  com zone 

RRset of DNSKey records for the root zone (the root zone's PubKSK and PubZSK)
RRSig of the above DNSKey RRSet signed with the root zone's PvtKSK

DS record for the com zone (hash of the com zone's PubKSK)
RRSig of the above DS record (signed using the root zone's PvtZSK)

The recursive caching server hold's a copy of the Root zone's PubKSK so it verifies the above files as follows:

The RRSig containing Root zone's DNSkey record is decrypted using the Root zone PubKSK (already held) 
The hash of the Root PubKSK from the RRSig is compared to a hash of the Root PubKSK already held by the recursive server, to verify the authenticity of the key.

If the hashes match the key is trusted and therefore the Root PubZSK is also trusted and can be used to decrypt the RRSig of the DS record for the com zone

Once decrypted the hash of the come zone's PubKSK is compared to that in the DS record to verify that the com PubKSK can be trusted.

This has been my understanding of how the trust chain works. Now that the recursive server holds the com zone PubKSK the process is repeated, down to the example nameservers that respond with the IP for the webserver for that domain.

Example B:

I recently read Josh Reed's explanation of a query in para. 1.5 'How Does DNSSEC Change DNS LOOKUP?' on users.isc.org and he explains it almost in reverse.

In his explanation:

Host A queries it's recursive resolver for info on the web server www.isc.org 

The recursive server's requests on behalf of Host A will be answered by the name-servers responsible for isc.org and contain the records required by DNSSEC. 

Validation now begins when the recursive resolver asks the isc.org name-server for the keys for it's zone. Once those keys are provided then the recursive server then queries up (the parent) to validate responses in reverse fashion to Example A, until a trusted key (presumably or typically from the root) confirms that the chain can be trusted.

The question:

Can I trouble someone with a better understanding to confirm that my understanding (as explained in Example A) is incorrect? I don't doubt Josh Reed but the second example seems to be less efficient.

Answer 1

Both explanations are correct, they are just summaries of what happens, so obviously the devil is in the details. Including what shortcuts are used for efficiency, the state of the cache, if QNAME minimization is into play, etc.

But you do not need to think about theories, you can observe in real life.

Use the delv application. It is described as such:

delv is a tool for sending DNS queries and validating the results, using the same internal resolver and validator logic as named.

So using it show exactly what a (bind) recursive nameserver does, both about records fetching and then DNSSEC validation.

Let us try with: delv +rtrace +vtrace www.icann.org

After some time you get the final results at the end of the output:

; fully validated
www.icann.org.      0   IN  CNAME   www.vip.icann.org.
www.icann.org.      0   IN  RRSIG   CNAME 7 3 3600 20191117090520 20191027015903 8150 icann.org. mmVZ3tzEr1rRDXIVF4TiqcnAwyNzA6kV+FXq1/8CSeZfVUa1260NfIxQ TzaV05NHSvW7CqeBXskzmPjCkSAGpF2breelu+k1Qd9CfJ7/+gp38mFO zTddZdZDL+ddU5rlaeaF17OokcPUnBtR23buBmWZ/mK83heXSKrWHfKn lNQ=
www.vip.icann.org.  30  IN  A   192.0.32.7
www.vip.icann.org.  30  IN  RRSIG   A 7 4 30 20191107231353 20191031231353 52760 vip.icann.org. jtvLS1ylxThi0xlObrrDA4nSM5GbpKeBvhcKlRn3em103AIxGAMu7o24 5uzhGQVZn4AsEH62/2JfWYQVavOnsb4rI8+rl5iw/XmUkoy7neBNybB6 kjrfcaUbCNhjgoipGotlUolqlNjKKzkMHbGLdUCMOzdlacfuK1gz825c PuA=
www.vip.icann.org.  30  IN  RRSIG   A 7 4 30 20191109071334 20191102071334 14702 vip.icann.org. LxEa+CV0bIB9I2s8v9MaK9JXoOEghUiYSotxACrxq2TxclX/6HPWBX+l SF5Y6iQ5ikMTjKd3XjmRO0Bawq+b7NWX2EToGGhGv51Vv69xi8++03zg JoSimnGmLPoOwK/RS8+MOouS2O629ycAa9JGtpy+Erx/tahCc5oRpXfg 6h4=

So first you see that, for this record, DNSSEC was fully validated, and then you see the records themselves (this name is a CNAME).

Now if you get back to previous lines of the output you see how this conclusion was reached.

First, the name resolution itself, and grabing the relevant DS and DNSKEY byt climbing back to the root:

;; fetch: www.icann.org/A
;; validating www.icann.org/CNAME: starting
;; validating www.icann.org/CNAME: attempting positive response validation
;; fetch: icann.org/DNSKEY
;; validating icann.org/DNSKEY: starting
;; validating icann.org/DNSKEY: attempting positive response validation
;; fetch: icann.org/DS
;; validating icann.org/DS: starting
;; validating icann.org/DS: attempting positive response validation
;; fetch: org/DNSKEY
;; validating org/DNSKEY: starting
;; validating org/DNSKEY: attempting positive response validation
;; fetch: org/DS
;; validating org/DS: starting
;; validating org/DS: attempting positive response validation
;; fetch: ./DNSKEY

So in summary:

1. first getting the record itself, showing it exists in the icann.org zone
2. so fetching DNSKEY records for icann.org zone
3. since they exist, we now need the DS records in parent zone, org
4. since they exist, we now need the DNSKEY records in org
5. since they exist, we now need the DS records in parent zone, .
6. since they exist, we now need the DNSKEY records of this . zone
7. and we stop here because we discover that the DNSEY records we got are in fact our trusted key (from delv documentation: "-a anchor-file Specifies a file from which to read DNSSEC trust anchors. The default is /etc/bind.keys, which is included with BIND 9 and contains one or more trust anchors for the root zone ("."). ")

You can see that this first step, collecting DS and DNSKEY records, was bottom to top.

Now there is the second part of the output, validating th whole chain, and it goes like that:

;; validating ./DNSKEY: starting
;; validating ./DNSKEY: attempting positive response validation
;; validating ./DNSKEY: verify rdataset (keyid=20326): success
;; validating ./DNSKEY: signed by trusted key; marking as secure
;; validating org/DS: in fetch_callback_validator
;; validating org/DS: keyset with trust secure
;; validating org/DS: resuming validate
;; validating org/DS: verify rdataset (keyid=22545): success
;; validating org/DS: marking as secure, noqname proof not needed
;; validating org/DNSKEY: in dsfetched
;; validating org/DNSKEY: dsset with trust secure
;; validating org/DNSKEY: verify rdataset (keyid=9795): success
;; validating org/DNSKEY: marking as secure (DS)
;; validating icann.org/DS: in fetch_callback_validator
;; validating icann.org/DS: keyset with trust secure
;; validating icann.org/DS: resuming validate
;; validating icann.org/DS: verify rdataset (keyid=11324): success
;; validating icann.org/DS: marking as secure, noqname proof not needed
;; validating icann.org/DNSKEY: in dsfetched
;; validating icann.org/DNSKEY: dsset with trust secure
;; validating icann.org/DNSKEY: no DNSKEY matching DS
;; validating icann.org/DNSKEY: verify rdataset (keyid=18060): success
;; validating icann.org/DNSKEY: marking as secure (DS)
;; validating www.icann.org/CNAME: in fetch_callback_validator
;; validating www.icann.org/CNAME: keyset with trust secure
;; validating www.icann.org/CNAME: resuming validate
;; validating www.icann.org/CNAME: verify rdataset (keyid=8150): success
;; validating www.icann.org/CNAME: marking as secure, noqname proof not needed
;; fetch: www.vip.icann.org/A
;; validating www.vip.icann.org/A: starting
;; validating www.vip.icann.org/A: attempting positive response validation
;; fetch: vip.icann.org/DNSKEY
;; validating vip.icann.org/DNSKEY: starting
;; validating vip.icann.org/DNSKEY: attempting positive response validation
;; fetch: vip.icann.org/DS
;; validating vip.icann.org/DS: starting
;; validating vip.icann.org/DS: attempting positive response validation
;; validating vip.icann.org/DS: keyset with trust secure
;; validating vip.icann.org/DS: verify rdataset (keyid=8150): success
;; validating vip.icann.org/DS: marking as secure, noqname proof not needed
;; validating vip.icann.org/DNSKEY: in dsfetched
;; validating vip.icann.org/DNSKEY: dsset with trust secure
;; validating vip.icann.org/DNSKEY: verify rdataset (keyid=45993): success
;; validating vip.icann.org/DNSKEY: marking as secure (DS)
;; validating www.vip.icann.org/A: in fetch_callback_validator
;; validating www.vip.icann.org/A: keyset with trust secure
;; validating www.vip.icann.org/A: resuming validate
;; validating www.vip.icann.org/A: verify rdataset (keyid=52760): success
;; validating www.vip.icann.org/A: marking as secure, noqname proof not needed

As you can see now the process is top to bottom:

1. we validate the root key based on local data (trust anchor)
2. from that, we validate the DS record for org in root zone, as signed by a trusted DNSKEY
3. then the correspondig key is considered trusted and is seen as used in a DS record for icann.org
4. so we do the same step but one zone lower
5. and finally we validate the CNAME record for www.icann.org because this is the name we asked for
6. but since this is a CNAME and user (implicitely) asked for an A record, the resolution process continue
7. and the target of the CNAME record is in its own separate delegated record vip.icann.org so there is again a step of DS and DNSKEY records fetch and validation.
8. and all finishes well, with A record for www.vip.icann.org being fully validated.